您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
互联网时代,我眼中的架构变迁
 
   次浏览      
 2018-5-4 
 
编辑推荐:

本文来自于segmentfault.com,文章把互联网的架构演进过程分为三个时代,探讨了技术架构的演进过程及其优缺点。

单机时代

互联网早期,好比杭研某个产品团队初创之时,资源有限,人力不足,为了快速开发一个产品,或上线一个网站,单机往往是一个不错的选择,此时会将应用程序、文件服务、数据库服务等资源集中在一台 Server 上。其中应用程序通常整体打包和部署,具体格式依赖于应用的语言和框架 , 例如 Java 的 WAR 文件、Rails 的目录文件,此种架构通常称为单体架构。

单体架构

其系统架构图往往长这个样子:

图-1: 单机时代-ALL IN ONE

优点:如上文所述,简单快速,易于开发,易于测试,易于部署

缺点:也非常显著,只适合早期项目,变大后不易维护,且存在单点,升级需要停服

分层架构

明眼的人很快发现,此时的应用程序架构显得杂乱无章,这在早期的 Web 开发中可能存在,比如使用 JSP+JDBC,ASP+ADO,但这显然不是一个友好的标准架构,于是分层架构应运而生,分层架构如下图所示,一般分为表现层(presentation )、业务层( business )、持久层( persistence )和数据库( database )。这其实也是最常见的 MVC 架构了。

图-2: 单机时代-软件架构-分层架构

改造之后的系统架构图如下:

图-3: 单机时代-分层架构

优点:结构简单,分工明确,分层测试,如果你不知道用什么软件架构时,推荐用它

缺点:扩展性差,迭代开发效率低,有时候层次过多导致流程复杂

数据分离

添加了分层架构,应用上好看点了,团队的开发效率有了一定的提升。此时业务量进一步增大,并且有了一定的用户规模,逐渐发现一台主机上应用和数据资源争夺的非常厉害。因为每种服对硬件资源的要求是不同的,应用服务器需要更快的CPU,文件服务器需要更大的硬盘,数据库服务器需要更大的内存和硬盘,于是决定把应用和数据服务分离,形成了如下架构:

图-4: 单机时代-数据分离

优点:资源分散,提高不同服务对硬件的利用率,方便维护

缺点:增加了资源消耗和网络开销,同时还存在单点

缓存登场

产品有了一定的口碑,用户量持续增长,访问开始频繁,想提升访问速度,缓存必不可少,闪亮登场。

图-5: 单机时代-缓存登场

服务端缓存又可以分为本地缓存和远程缓存,各有优劣,本地缓存访问速度快,但数据量有限,而且后续集群化不方便共享;远程缓存可以共享,可以集群,容量不受限制,但要注意缓存更新的问题。

优点:简单有效,减少对 DB 的查询

缺点:增加逻辑判断,不适合存储大对象,此架构同样有单点

读写分离

市场反响不错,业务也在持续增长,但性能又有所下降,分析整个架构,发现数据库读写非常频繁,甚至有些业务,读大于写,单台数据库服务器又成了瓶颈,此时就可以尝试做读写分离和主从复制了。

图-6: 单机时代-读写分离

优点:降低数据库单台压力,从机的数量可以灵活变更

缺点:架构开始变得复杂,维护难度加大

自此,单机时代的架构已然成型,“麻雀虽小五脏俱全”,初期已经能很好的支撑业务的运转。但随着业务的增长,各个模块还是可能出现瓶颈。而单机时代最大的问题,就是整个架构都存在单点,这个问题将在集群时代一一解决。

集群时代

单机时代,做了不少措施来缓解数据库层的压力,包括服务器分离、引入缓存、数据分离等,但随着访问量的猛增,对高可用的要求越来越高,减轻应用层压力、解决单点问题是当务之急,这就是集群时代需要做的事情。

负载均衡

代码是架构的基础,但前期改造代码的工作量较大,如果人员变动频繁,那风险就更高了,所以提高服务器性能,常用的手段还是先将应用集群化,做负载均衡。

图-7: 集群时代-负载均衡

优点:去除应用层单点,可用性得到保证,性能有所提高

缺点:这时要注意应用之间的一致性问题,比如对缓存的访问,对Session的存储

动静分离

希望进一步降低应用服务器的压力,可以采用动静分离技术。

动静分离是让动态网站里的动态网页,根据一定规则把不变的资源和经常变的资源区分开来,动静资源做好了拆分以后,我们还可以根据静态资源的特点将其做缓存操作,以加快响应速度。

在杭研内部,常用做法还会将前后端分离,后端应用提供 API,根据前端的请求进行处理,并将处理结果通过JSON格式返回至前端

图-8: 集群时代-动静分离

优点:减轻应用服务器压力,缓存静态文件,加快响应速度,前后端分离,开发可以并行。

缺点:静态文件缓存更新失效问题,前后端沟通成本提高

CDN 加速

内容分发网络(Content Delivery Network,简称 CDN),可以进一步加快网站相应,其原理是将源内容同步到全国各边缘节点,配合精准的调度系统,将用户的请求分配至最适合他的节点,使用户可以以最快的速度取得他所需的内容。

图-9: 集群时代-CDN 加速

优点:解决网络带宽小、用户访问量大、网点分布不均等问题,提高用户访问的响应速度,减轻应用负载压力。

缺点:显然成本上去了,CDN服务一般是按流量计费,同时也存在静态文件缓存更新失效问题。

冗余集群

以上一个中型网站架构基本成型。当中型网站继续向大型网站演进,最终的目标是要保证“三高”:高并发、高性能、高可用。以上架构基本可以满足性能需求,接下来更多的是关注“高可用”,确保“无单点”。

此时,就要对关键的服务,做冗余集群负载。

理想情况下,我们将以下服务/应用都集群化:

数据库服务集群

文件服务集群

缓存服务集群

应用服务集群

负载均衡调度器集群

静态内容服务集群

CDN服务器集群

图-10: 集群时代-冗余集群

优点:去单点,高可用

缺点:数据有状态问题、数据一致性问题,资源成本、人力维护成本都上去了

到此为止,一个大型网站的架构也基本成型了,能“加机器”的地方都加完了,是不是就终结?当然不是!伴随着 DT/分布式 时代的到来,大流量和大数据的场景的出现,对应用提出了更高的要求,接下来就需要对应用程序开刀了。

分布式时代

应用拆分

在前面,我们只是把应用程序做了分层架构,在创业初期或产品前期还是一个不错的选择。虽然应用也做了集群和负载均衡,但应用架构层面还是“集中式”的。随着业务越来越复杂,网站的功能越来越多,应用拆分势在必行了。

优点:应用解耦,分拆团队负责,分而治之

缺点:架构变复杂

应用拆分之后,还伴随着一个相互依赖、公共模块的问题,特别是依赖于相同的逻辑或功能代码。这时就可以考虑将这些共用的服务提取出来,独立部署,统一治理,提高重用度,这就是面向服务的架构(service-oriented architecture,缩写 SOA)了。

消息队列

应用拆分、服务独立部署之后,还是会出现一些通信或依赖问题,这时就可以引入消息队列,提高吞吐量。

优点:异步、解耦,提高吞吐量

缺点:消息消费延迟等问题

数据分库

应用拆分之后,DB分库理所当然,否则多个应用连接在单个数据库上,连接数、QPS、TPS、I/O处理能力都非常有限。

优点:DB分压,降低耦合

缺点:数据访问模块冗余、复杂

提到分库,不少人会想到分表,这一块我并未实践过,不好下笔。但想来会引入更复杂的数据架构和数据一致性问题,而且市面身上成熟开源的分库分表方案并没有,保不准又是一个深坑。拆或不拆,也是一个值得思考的问题。

微服务架构

微服务架构(microservices architecture)一度成为热点,在文章、博客、大会演讲上经常被提及。微服务并不是凭空出现,有人说,它是面向服务的架构(SOA)的升级,在此之前,还有诸如集中式架构、分布式的架构等。这里借用一副抽象的图来描述下常见的几种架构:

图-11: 分布式时代-微服务架构-抽象对比

微服务架构由多个微小服务构成,每个服务就是一个独立的可部署单元或组件,它们是分布式的,相互解耦的,通过轻量级远程通信协议(比如REST)来交互,每个服务可以使用不同的数据库,而且是语言无关性的。它的特征是彼此独立、微小、轻量、松耦合,又能方便的组合和重构,犹如《超能陆战队》中的微型机器人,个体简单,但组合起来威力强大。

图-12: 分布式时代-微服务架构

优点:扩展性好,服务之间耦合性低,服务间相互独立,容易部署,易于开发,方便测试每一个服务

缺点:容易过度关注服务的大小,可能拆分的很细,导致系统依赖于大量的微服务,而服务之间的相互通信也会变得复杂,系统集成复杂度增加,很难实现原子性操作。

微服务之所以这么火,另一个原因是因为 Docker 的出现,它让微服务有一个非常完美的运行环境,Docker 的独立性和细粒度非常匹配微服务的理念,Docker的优秀性能和丰富的管理工具,让大家对微服务有了一定的信息,概括来说 Docker 有如下四点适合微服务:

独立性:一个容器就是一个完整的执行环境,不依赖外部任何的东西。

细粒度:一台物理机器可以同时运行成百上千个容器。其计算粒度足够的小。

快速创建和销毁:容器可以在秒级进行创建和销毁,非常适合服务的快速构建和重组。

完善的管理工具:数量众多的容器编排管理工具,能够快速的实现服务的组合和调度。

当然,好的架构和技术,要应用于实践、让用户认可才行,这就需要在微服务架构和 Docker 技术之上有丰富的场景化应用。

至此,架构变迁的三个时代介绍完成。总的来说架构不是一成不变的,时间不停,进步不止,人如此,架构依然。

   
次浏览       
相关文章

企业架构、TOGAF与ArchiMate概览
架构师之路-如何做好业务建模?
大型网站电商网站架构案例和技术架构的示例
完整的Archimate视点指南(包括示例)
相关文档

数据中台技术架构方法论与实践
适用ArchiMate、EA 和 iSpace进行企业架构建模
Zachman企业架构框架简介
企业架构让SOA落地
相关课程

云平台与微服务架构设计
中台战略、中台建设与数字商业
亿级用户高并发、高可用系统架构
高可用分布式架构设计与实践