1. 首页
  2. 文章列表
  3. 现代企业级互联网应用的架构演变(一步一步打造出高性能的web应用)

1. 不同系统不同语言之间的交互

现在我们常见的不同系统不同语言之间的交互使用RestAPI,Http请求。RestAPI,即“面向资源的WebAPI服务”。从字面上理解,它其实就是“基于Web的服务”。而服务却是双方的,有服务需求方,就有服务提供方。服务提供方对外发布服务,服务需求方调用服务提供方所发布的服务。如果说得再专业一点,RestAPI其实就是建立在HTTP 协议上实现异构系统通讯的工具。没错!RestAPI说白了还是基于 HTTP 协议的,也就是说,数据是通过 HTTP进行传输的。最早我们是用WCF开发SOAP服务实现WebAPI,后面我们是用REST服务实现WebAPI(这个目前使用比较多,也最我用得最多的这一种)。基于WCF也可以开发REST服务,不过我们一般直接使用MVC或者其他MVC框架实现REST服务。
但是在很多人的印象中RestAPI的话一般指十来年的基于ajax的各种交互技术,现在除了一些公司在用之外用得人也很少了。广义的话Webservice就是Web服务了,一切皆服务。

2. 不同系统相同语言之间的交互

常见的不同系统相同语言之间的交互用RPC(远程过程调用),或者RMI(远程方法调用)实现,不用对外部提供服务,当然上面说的也可以使用在相同语言之间的交互,只是我常用的是RPC。

3. 单个产品的架构演进

一般我们只是一个单产品的情况下的架构演进过程,如果需要对外提供Web服务,通常使用REST服务实现。

1. 分布式架构的初始阶段架构

懒得勤快的博客_全栈开发者_互联网分享精神

初始阶段的小型系统应用程序、数据库、文件等所有的资源都在一台服务器上。
特征:应用程序、数据库、文件等所有的资源都在一台服务器上。
描述:通常是服务器操作系统同时部署网站程序、数据库等,汇集各种软件以及一台廉价服务器就可以开始系统的发展之路了。

2. 应用服务和数据服务分离的系统架构

懒得勤快的博客_全栈开发者_互联网分享精神

但是好景不长,我们发现随着系统访问量的再度增加,Web服务器的压力在高峰期会上升到比较高,这个时候开始考虑增加一台Web服务器来做负载均衡。

特征:应用程序、数据库、文件分别部署在独立的机器上。
描述:数据量增加,单台服务器性能及存储空间不足,需要将应用和数据分离,并发处理能力和数据存储空间得到了很大改善。

3. 使用缓存改善性能的系统架构

懒得勤快的博客_全栈开发者_互联网分享精神

特征:数据库中访问较集中的一小部分数据存储在缓存服务器中,减少数据库的读写次数,降低数据库的访问压力。
描述:系统访问特点遵循二八定律,即80%的业务访问集中在20%的数据上。缓存分为本地缓存和远程分布式缓存,本地缓存访问速度更快但缓存数据量有限,同时存在与应用程序争用内存的情况。

4. 使用应用服务器集群的系统架构

懒得勤快的博客_全栈开发者_互联网分享精神

在做完分库分表这些工作后,数据库上的压力已经降到比较低了,又开始过着每天看着访问量暴增的幸福生活了,突然有一天,发现系统的访问又开始有变慢的趋势了,这个时候首先查看数据库,压力一切正常,之后查看Web服务器,发现Web服务器阻塞了很多的请求,而应用服务器对每个请求也是比较快的,看来是请求数太高导致需要排队等待,响应速度变慢。
特征:多台服务器通过负载均衡同时向外部提供服务,解决单台服务器处理能力和存储空间上限的问题。
描述:使用集群是系统解决高并发、海量数据问题的常用手段。通过向集群中追加资源,提升系统的并发处理能力,使得服务器的负载压力不再成为整个系统的瓶颈。

5. 数据库读写分离的系统架构

懒得勤快的博客_全栈开发者_互联网分享精神

享受了一段时间的系统访问量高速增长的幸福后,发现系统又开始变慢了,这次又是什么状况呢,经过查找,发现数据库写入、更新的这些操作的部分数据库连接的资源竞争非常激烈,导致了系统变慢。
特征:多台服务器通过负载均衡同时向外部提供服务,解决单台服务器处理能力和存储空间上限的问题。
描述:使用集群是系统解决高并发、海量数据问题的常用手段。通过向集群中追加资源,使得服务器的负载压力不在成为整个系统的瓶颈。

6. 反向代理和CDN加速的系统架构

懒得勤快的博客_全栈开发者_互联网分享精神

特征:采用CDN和反向代理加快系统的访问速度。
描述:为了应付复杂的网络环境和不同地区用户的访问,通过CDN和反向代理加快用户访问的速度,同时减轻后端服务器的负载压力。CDN与反向代理的基本原理都是缓存。

7. 分布式文件系统和分布式数据库的系统架构

懒得勤快的博客_全栈开发者_互联网分享精神

随着系统的不断运行,数据量开始大幅度增长,这个时候发现分库后查询仍然会有些慢,于是按照分库的思想开始做分表的工作
特征:数据库采用分布式数据库,文件系统采用分布式文件系统。
描述:任何强大的单一服务器都满足不了大型系统持续增长的业务需求,数据库读写分离随着业务的发展最终也将无法满足需求,需要使用分布式数据库及分布式文件系统来支撑。分布式数据库是系统数据库拆分的最后方法,只有在单表数据规模非常庞大的时候才使用,更常用的数据库拆分手段是业务分库,将不同的业务数据库部署在不同的物理服务器上。

8. 使用NoSQL和搜索引擎的系统架构

懒得勤快的博客_全栈开发者_互联网分享精神

特征:系统引入NoSQL数据库及搜索引擎。
描述:随着业务越来越复杂,对数据存储和检索的需求也越来越复杂,系统需要采用一些非关系型数据库如NoSQL和分数据库查询技术如搜索引擎。应用服务器通过统一数据访问模块访问各种数据,减轻应用程序管理诸多数据源的麻烦。

9. 业务拆分的系统架构

懒得勤快的博客_全栈开发者_互联网分享精神

特征:系统上按照业务进行拆分改造,应用服务器按照业务区分进行分别部署。
描述:为了应对日益复杂的业务场景,通常使用分而治之的手段将整个系统业务分成不同的产品线,应用之间通过超链接建立关系,也可以通过消息队列进行数据分发,当然更多的还是通过访问同一个数据存储系统来构成一个关联的完整系统。

纵向拆分:将一个大应用拆分为多个小应用,如果新业务较为独立,那么就直接将其设计部署为一个独立的Web应用系统纵向拆分相对较为简单,通过梳理业务,将较少相关的业务剥离即可。
横向拆分:将复用的业务拆分出来,独立部署为分布式服务,新增业务只需要调用这些分布式服务横向拆分需要识别可复用的业务,设计服务接口,规范服务依赖关系。

10. 分布式服务的系统架构

懒得勤快的博客_全栈开发者_互联网分享精神

特征:公共的应用模块被提取出来,部署在分布式服务器上供应用服务器调用。
描述:随着业务越拆越小,应用系统整体复杂程度呈指数级上升,由于所有应用要和所有数据库系统连接,最终导致数据库连接资源不足,拒绝服务。

Q:分布式服务应用会面临哪些问题?

(1) 当服务越来越多时,服务URL配置管理变得非常困难,F5硬件负载均衡器的单点压力也越来越大。
(2) 当进一步发展,服务间依赖关系变得错踪复杂,甚至分不清哪个应用要在哪个应用之前启动,架构师都不能完整的描述应用的架构关系。
(3) 接着,服务的调用量越来越大,服务的容量问题就暴露出来,这个服务需要多少机器支撑?什么时候该加机器?
(4) 服务多了,沟通成本也开始上升,调某个服务失败该找谁?服务的参数都有什么约定?
(5) 一个服务有多个业务消费者,如何确保服务质量?
(6) 随着服务的不停升级,总有些意想不到的事发生,比如cache写错了导致内存溢出,故障不可避免,每次核心服务一挂,影响一大片,人心慌慌,如何控制故障的影响面?服务是否可以功能降级?或者资源劣化?

11. 产品线的架构

还有一种就是上面也有提到的业务拆分。现在我们需要做一个产品线,我们只需要一个数据层,一个通用业务逻辑层,前面还有各种应用和界面层,不需要对外部系统(外部公司的系统)提供服务的情况以前我们一般会选择用EJB等来构建分布式应用,但是现在我们可以使用dobbo、thrift、avro、hessian这类RPC框架来构建分布式应用实现不同应用和数据来源的交互。这种结构模式下我们需要对其他公司提供服务,可以专门写一个应用对外部系统提供rest服务。一般大多数互联网服务背后都要访问十几个甚至几百个内部服务,它们之间的通信方式一般都是RPC:就像访问一个远程方法那样,输入参数后等待返回结果。这对于构建复杂系统是最容易理解的方式。

如下图的模型,文件系统,缓存那些没有画出来,大家理解就行。

懒得勤快的博客_全栈开发者_互联网分享精神


结语:

不管哪种架构我们都需要做好模块化(尽量做到模块复用)。
不要为了架构而架构导致过度设计。
不管何种架构都是为了更好满足业务需求,架构应该跟随业务的发展而发展。
当前的架构如果可以满足当前的业务发展,就可以考虑下一步的扩展了,不用一下子考虑3步4步甚至更多。

文章历史版本:

修改次数:1 次 查看历史版本

版权声明:

本文仅用于学习、研究和交流目的,欢迎非商业性质转载。本文链接:https://masuit.com/144

l  博主在此发文(包括但不限于汉字、拼音、拉丁字母)均为随意敲击键盘所出,用于检验本人电脑键盘录入、屏幕显示的机械、光电性能,并不代表本人局部或全部同意、支持或者反对观点。如需要详查请直接与键盘生产厂商法人代表联系。挖井挑水无水表,不会网购无快递。

l  文章内容部分来源于互联网,不代表本人的任何立场;涉及到的软件来源于互联网,仅供个人下载使用,请勿用于商业用途,版权归软件开发者所有,下载后请于24小时内删除,如有真实需要请支持正版!因下载本站任何资源造成的损失,全部责任由使用者本人承担!如果你是版权方,认为本文内容对您的权益有所侵犯,请联系博主,并参照侵删联系的说明提交相应的证明材料,待博主进行严格地审查和背景调查后,情况属实的将在三天内将本文删除或修正。

l  博主的文章没有高度、深度和广度,只是凑字数。由于博主的水平不高(其实是个菜B),不足和错误之处在所难免,希望大家能够批评指出。

l  博主是利用读书、参考、引用、抄袭、复制和粘贴等多种方式打造成自己的纯镀 24k 文章,请原谅博主成为一个无耻的文档搬运工!

l  博主只是一名普通的互联网从业者,不懂修电脑,不会卖电脑,不会帮你盗号,不会破解开机密码,找不回你丢失的手机等,如有这样的想法请绕道!

相关推荐:

盗版软件界传奇一哥,思杰马克丁大起底 思杰马克丁软件微博运营博主,独自舌战群雄不落下风!
"2345联盟"通过流氓软件推广挖矿工具 用户电脑沦为"肉鸡" 比特币背后的技术——图解区块链技术
揭开软件行业毒瘤思杰马克丁的虚伪面纱——墨雨 思维导图 XMind 官方澄清与苏州思杰马克丁代理合作
流氓的版权,版权的流氓 三分钟让你理解云计算到底是怎么一回事
关于:苏州马克丁公司破解、出售 Corel VideoStudio 2018涉嫌违法证据 业界毒瘤思杰马克丁

评论区: