互联网时代，我眼中的架构变迁

拼搏现实的明天。 2022-06-09 06:23 244阅读 0赞

# https://segmentfault.com/a/1190000008016139    #

# [互联网时代，我眼中的架构变迁][Link 1] #

*  [微服务][Link 2] 
 *  [互联网][Link 3] 
 *  [架构][Link 4]

[网易蜂巢][Link 5] 1月5日发布

*  赞  |   1收藏  |  20
 *  1.4k 次浏览

作者简介：黄庆兵，[网易蜂巢][Link 6]首席技术布道师，浙大硕士毕业，从事云计算、Docker、Go等相关开发及技术布道工作；喜欢开源，乐于分享，勤于布道，折腾过开源小工具，制作过Docker课程，分享过 Gopher Meetup。欢迎一起来探讨技术！个人主页：[http://bingohuang.com/][http_bingohuang.com]

以下为正文：

互联网在变，架构也在变，架构的变迁亦是互联网的变迁。所以，我们有必要来聊聊互联网的架构及其变迁。

何为架构？往大的说，宇宙有架构，社会有架构，往小的说，建筑要有架构，软件要有架构，往玄乎的说，它由分工而来，回归整体而去，往实际的说，架构的核心就是为了解决问题，包括业务的问题、人的问题。

立足互联网行业，架构通常指的是技术架构，更具体一点的说是系统架构、软件架构，或者是最常见的网站架构。本文就来探讨一下互联网时代，技术架构的演进过程及其优缺点，其中若有不足之处，还望指正，促进交流。

为了方便表述，我姑且的把互联网的架构演进过程分为三个时代：单机时代、集群时代和分布式时代。三个时代并非按照历史时间顺序排列，更多的是由团队或产品所处的时期来决定。

## 单机时代 ##

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

### 单体架构 ###

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

![bVHNsd_w_1444_h_732][]

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

优点：如上文所述，简单快速，易于开发，易于测试，易于部署  
缺点：也非常显著，只适合早期项目，变大后不易维护，且存在单点，升级需要停服

### 分层架构 ###

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

![bVHNsq_w_750_h_561][]

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

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

![bVHNsv_w_1440_h_732][]

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

*  优点：结构简单，分工明确，分层测试，如果你不知道用什么软件架构时，推荐用它
 *  缺点：扩展性差，迭代开发效率低，有时候层次过多导致流程复杂  
    数据分离

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

![bVHNsU_w_1314_h_616][]

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

*  优点：资源分散，提高不同服务对硬件的利用率，方便维护
 *  缺点：增加了资源消耗和网络开销，同时还存在单点

### 缓存登场 ###

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

![bVHNtA_w_1296_h_630][]

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

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

*  优点：简单有效，减少对 DB 的查询
 *  缺点：增加逻辑判断，不适合存储大对象，此架构同样有单点

### 读写分离 ###

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

![bVHNtH_w_1344_h_828][]

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

*  优点：降低数据库单台压力，从机的数量可以灵活变更
 *  缺点：架构开始变得复杂，维护难度加大

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

## 集群时代 ##

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

### 负载均衡 ###

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

![bVHNtT_w_1346_h_858][]

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

*  优点：去除应用层单点，可用性得到保证，性能有所提高
 *  缺点：这时要注意应用之间的一致性问题，比如对缓存的访问，对Session的存储

### 动静分离 ###

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

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

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

![bVHNt3_w_1382_h_874][]

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

*  优点：减轻应用服务器压力，缓存静态文件，加快响应速度，前后端分离，开发可以并行。
 *  缺点：静态文件缓存更新失效问题，前后端沟通成本提高

### CDN 加速 ###

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

![bVHNux_w_1382_h_874][]

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

*  优点：解决网络带宽小、用户访问量大、网点分布不均等问题，提高用户访问的响应速度，减轻应用负载压力。
 *  缺点：显然成本上去了，CDN服务一般是按流量计费，同时也存在静态文件缓存更新失效问题。

### 冗余集群 ###

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

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

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

*  数据库服务集群
 *  文件服务集群
 *  缓存服务集群
 *  应用服务集群
 *  负载均衡调度器集群
 *  静态内容服务集群
 *  CDN服务器集群

![bVHNuL_w_1682_h_1064][]

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

*  优点：去单点，高可用
 *  缺点：数据有状态问题、数据一致性问题，资源成本、人力维护成本都上去了

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

## 分布式时代 ##

### 应用拆分 ###

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

*  优点：应用解耦，分拆团队负责，分而治之
 *  缺点：架构变复杂

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

### 消息队列 ###

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

*  优点：异步、解耦，提高吞吐量
 *  缺点：消息消费延迟等问题

### 数据分库 ###

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

*  优点：DB分压，降低耦合
 *  缺点：数据访问模块冗余、复杂

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

### 微服务架构 ###

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

![bVHNwf_w_801_h_268][]

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

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

![bVHNwl_w_750_h_460][]

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

*  优点：扩展性好，服务之间耦合性低，服务间相互独立，容易部署，易于开发，方便测试每一个服务
 *  缺点：容易过度关注服务的大小，可能拆分的很细，导致系统依赖于大量的微服务，而服务之间的相互通信也会变得复杂，系统集成复杂度增加，很难实现原子性操作。

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

*  独立性：一个容器就是一个完整的执行环境，不依赖外部任何的东西。
 *  细粒度：一台物理机器可以同时运行成百上千个容器。其计算粒度足够的小。
 *  快速创建和销毁：容器可以在秒级进行创建和销毁，非常适合服务的快速构建和重组。
 *  完善的管理工具：数量众多的容器编排管理工具，能够快速的实现服务的组合和调度。

当然，好的架构和技术，要应用于实践、让用户认可才行，这就需要在微服务架构和 Docker 技术之上有丰富的场景化应用。[网易蜂巢][Link 6]也在积极探索微服务架构和容器云平台的场景化服务，欢迎一起来实践落地。

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

## 后记 ##

对我来说，架构之路小有实践，但实属尚浅，想探讨下这个话题，一下不知从何下笔，沉思良久，想到之前读过不少业界前辈对于架构的论述，比如王概凯老师执笔的《架构漫谈》，比如 O'Reilly 免费出版的小册子《Software Architecture Patterns》，比如前人对架构的探索总结，受益匪浅，汇集成文。

[Link 1]: https://segmentfault.com/a/1190000008016139
[Link 2]: https://segmentfault.com/t/%E5%BE%AE%E6%9C%8D%E5%8A%A1/blogs
[Link 3]: https://segmentfault.com/t/%E4%BA%92%E8%81%94%E7%BD%91/blogs
[Link 4]: https://segmentfault.com/t/%E6%9E%B6%E6%9E%84/blogs
[Link 5]: https://segmentfault.com/u/wangyiyun
[Link 6]: https://c.163.com/
[http_bingohuang.com]: http://bingohuang.com/
[bVHNsd_w_1444_h_732]: /images/20220609/99d0233f123b4d4b8ee5d730426187d3.png
[bVHNsq_w_750_h_561]: /images/20220609/5d04acb7220141629d0011803cd1fc5a.png
[bVHNsv_w_1440_h_732]: /images/20220609/555e21b092bc434b9641033ae042254f.png
[bVHNsU_w_1314_h_616]: /images/20220609/298373c8d4904bbeb48982520475a4ce.png
[bVHNtA_w_1296_h_630]: /images/20220609/09b926e06bc24713afff76ce6e42ac44.png
[bVHNtH_w_1344_h_828]: /images/20220609/63bbac74e01c46c5ae31390316052b4a.png
[bVHNtT_w_1346_h_858]: /images/20220609/0f7bd8a6365f41b18ef1b591011893af.png
[bVHNt3_w_1382_h_874]: /images/20220609/4ed36cd6ed0f4f949c94a34f7e0d6bbf.png
[bVHNux_w_1382_h_874]: /images/20220609/47c951e6df00460b935c113f5a567b69.png
[bVHNuL_w_1682_h_1064]: /images/20220609/8035edcd048047fa84f6fe321a73e7d6.png
[bVHNwf_w_801_h_268]: /images/20220609/ede5983b6e09488996b0e99011523019.png
[bVHNwl_w_750_h_460]: /images/20220609/c76bf49f8ca34cfb978f1aa6aadf766c.png