服务端架构的演进与设计

1. 基本概念

在介绍架构之前，为了避免部分读者对架构设计中的一些概念不了解，下面对几个最基础的概念进行介绍。

1）什么是分布式？

系统中的多个模块在不同服务器上部署，即可称为分布式系统，如 Tomcat 和数据库分别部署在不同的服务器上，或两个相同功能的 Tomcat 分别部署在不同服务器上。

2）什么是高可用？

系统中部分节点失效时，其他节点能够接替它继续提供服务，则可认为系统具有高可用性。

3）什么是集群？

一个特定领域的软件部署在多台服务器上并作为一个整体提供一类服务，这个整体称为集群。

如 Zookeeper 中的 Master 和 Slave 分别部署在多台服务器上，共同组成一个整体提供集中配置服务。

在常见的集群中，客户端往往能够连接任意一个节点获得服务，并且当集群中一个节点掉线时，其他节点往往能够自动的接替它继续提供服务，这时候说明集群具有高可用性。

4）什么是负载均衡？

请求发送到系统时，通过某些方式把请求均匀分发到多个节点上，使系统中每个节点能够均匀的处理请求负载，则可认为系统是负载均衡的。

5）什么是正向代理和反向代理？

系统内部要访问外部网络时，统一通过一个代理服务器把请求转发出去，在外部网络看来就是代理服务器发起的访问，此时代理服务器实现的是正向代理；当外部请求进入系统时，代理服务器把该请求转发到系统中的某台服务器上，对外部请求来说，与之交互的只有代理服务器，此时代理服务器实现的是反向代理。

简单来说，正向代理是代理服务器代替系统内部来访问外部网络的过程，反向代理是外部请求访问系统时通过代理服务器转发到内部服务器的过程。

2. 架构演进

服务架构的演进是一个从简单到复杂、再从复杂回归简单（但内涵不同）的历程。其核心驱动力始终是：如何更高效地应对业务规模的增长、团队的扩张以及技术的变革。

以下是服务架构演进的主要阶段和核心理念：

2.1. 单体架构

这是最传统的架构模式。

• 特点：所有功能模块（如用户管理、订单处理、支付等）都打包在一个单一的应用程序中，共享同一个数据库。
• 优点 ：
  • 开发简单：初期项目搭建快，IDE支持好，易于调试和部署。
  • 测试容易：端到端测试单一。
  • 部署方便：只需打包一个WAR/JAR文件，放到一个服务器上即可运行。
• 缺点 ：
  • 维护成本高：代码膨胀后，逻辑复杂，可读性差。
  • 技术栈僵化：难以引入新的技术或框架。
  • 扩展性差：无法按需扩展某个模块，只能整体扩展，资源浪费。
  • 可靠性低：一个微小bug可能导致整个系统崩溃。
  • 阻碍持续交付：牵一发而动全身，任何修改都需要全量回归测试和部署。
• 适用场景：创业初期、小型项目、内部工具。

+---------------------------------------------------+
|                      单体应用                      |
|  +--------+  +--------+  +--------+  +--------+   |
|  | 模块A  |  | 模块B   |  | 模块C  |  | 模块D   |  |
|  +--------+  +--------+  +--------+  +--------+   |
|                                                   |
|             +----------------------+              |
|             |      共享数据库       |              |
|             +----------------------+              |
+---------------------------------------------------+

2.2. 垂直架构（也称"烟囱式架构"）

为了解决单体的扩展问题，开始按业务进行切割。

• 特点：将一个大的单体应用拆分成几个互不相干的独立应用。例如分为电商前台、商家后台、运营后台。
• 优点 ：
  • 系统拆分：实现了一定程度的解耦。
  • 可针对性扩展：可以针对访问量大的应用（如前台）独立增加服务器。
• 缺点 ：
  • 功能重复：每个应用可能都包含一套自己的用户认证、日志等通用逻辑，造成重复开发。
  • 数据孤岛：应用间数据不互通，可能形成冗余和数据不一致。
• 演进：这是从单体走向分布式的一个过渡形态。

+-------------------+      +-------------------+      +-------------------+
|     垂直应用1      |      |     垂直应用2     |      |     垂直应用3      |
|  +--------------+ |      |  +--------------+ |      |  +--------------+ |
|  |  功能模块     | |      |  |  功能模块    | |      |  |  功能模块     | |
|  +--------------+ |      |  +--------------+ |      |  +--------------+ |
|         |         |      |         |         |      |         |         |
|  +--------------+ |      |  +--------------+ |      |  +--------------+ |
|  |  数据库1      | |      | |   数据库2     | |      |  |  数据库3      | |
|  +--------------+ |      |  +--------------+ |      |  +--------------+ |
+-------------------+      +-------------------+      +-------------------+

2.3. SOA 架构

为了解决"重复造轮子"和数据孤岛问题，提出了面向服务的架构(SOA，Service Oriented Architecture)思想。

• 特点 ：
  • 服务化：将共同的、可复用的功能抽取成独立的"服务"，如上文提到的用户服务、订单服务。
  • 企业服务总线 ：核心是ESB，所有服务都通过ESB进行通信和集成。ESB负责消息路由、协议转换、服务编排等。
• 优点 ：
  • 系统集成：有效解决了企业内部异构系统之间的互通问题。
  • 服务复用：提高了功能复用性。
• 缺点 ：
  • 中心化瓶颈：ESB成为中心节点，容易造成性能瓶颈和单点故障。
  • 复杂度高：ESB本身非常重，协议和标准复杂（如SOAP/WS-*），开发测试困难。
• 理念贡献：首次明确了"服务"作为基本组件的概念。

+----------+      +----------+      +----------+
|  服务A   |      |  服务B    |      |  服务C   |
+----------+      +----------+      +----------+
      |                |                |
      +----------------+----------------+
                       |
               +----------------+
               |      ESB       |
               |  (企业服务总线) |
               +----------------+
                       |
      +----------------+----------------+
      |                |                |
+----------+      +----------+      +----------+
| 数据库A   |      | 数据库B  |      | 数据库C   |
+----------+      +----------+      +----------+

2.4. 微服务架构

这是当前的主流架构范式，可以看作是SOA的去中心化、精细化演进。

• 特点 ：
  • 彻底的服务化与自治：一个服务就是一个独立的、可部署的业务单元，拥有自己的独立数据库（数据库也完成拆分）。
  • 去中心化治理：没有ESB，服务间通过轻量级通信机制（如HTTP/REST, gRPC）直接调用。服务注册与发现（如Eureka, Nacos）取代了中心化的路由。
  • 技术多样性：每个服务可以根据自身需求选择最合适的技术栈（Polyglot）。
  • 围绕业务能力组织团队（康威定律的体现）。
• 优点 ：
  • 高内聚、低耦合：服务边界清晰，独立开发、部署、扩展。
  • 弹性与容错：单个服务故障不会导致整个系统瘫痪。
  • 技术选型灵活。
  • 更适合持续交付和DevOps。
• 缺点 ：
  • 分布式系统复杂性：引入了网络延迟、服务发现、负载均衡、配置管理、分布式事务、链路追踪等一系列挑战。
  • 运维和监控复杂度陡增。
  • 测试难度大。
• 技术生态：Spring Cloud, Dubbo, Kubernetes (作为部署和编排平台) 等。

+-------------+    +-------------+    +-------------+
|  微服务A     |   |  微服务B     |    |  微服务C     |
|  +--------+ |    |  +--------+ |    |  +--------+ |
|  | 业务逻辑| |   |  | 业务逻辑| |    |  | 业务逻辑| |
|  +--------+ |    |  +--------+ |    |  +--------+ |
|       |     |    |       |     |    |       |     |
|  +--------+ |    |  +--------+ |    |  +--------+ |
|  | 数据库A | |    | | 数据库B | |    |  | 数据库C | |
|  +--------+ |    |  +--------+ |    |  +--------+ |
+-------------+    +-------------+    +-------------+
       |                  |                  |
       +------------------+------------------+
                          |
                  +-----------------+
                  |  服务注册与发现  |
                  | (如Eureka/Nacos)|
                  +-----------------+
                          |
       +------------------+------------------+
       |                  |                  |
+-------------+    +-------------+    +-------------+
|    API网关  |    |  负载均衡器  |    |  配置中心    |
+-------------+    +-------------+    +-------------+

2.5. 云原生与服务网格架构

这是微服务架构在云环境下的自然演进和"升华"。

• 核心思想 ：将微服务架构中与业务无关的通用能力（如服务通信、可观测性、安全性、流量治理）下沉到基础设施层。
• 特点 ：
  • 服务网格 ：在应用旁部署一个轻量级网络代理（Sidecar，如Envoy），所有服务间的通信都经由Sidecar代理。由控制平面（如Istio, Linkerd）统一管理这些Sidecar。实现了 "业务逻辑与网络通信的解耦"。
  • 声明式API与不可变基础设施：以Kubernetes为代表，通过YAML文件描述"期望的状态"，由系统自动实现和维护。
  • DevOps与GitOps：将基础设施即代码、持续部署流程化。
• 优点 ：
  • 极大简化了微服务开发：开发者几乎只需关注业务逻辑。
  • 提供了强大的、统一的流量控制能力（如金丝雀发布、熔断、故障注入）。
  • 基础设施标准化、自动化。
• 缺点 ：
  • 学习曲线非常陡峭。
  • 组件繁多，体系复杂。
  • 对运维团队要求极高。

+---------------------------------------------------------+
|                   服务网格控制平面                       |
|                  (如Istio, Linkerd)                     |
+---------------------------------------------------------+
                             |
+--------------------------------------------------------------------+
|                    数据平面（由Sidecar代理组成）                     |
|                                                                    |
|  +-------------+        +-------------+        +-------------+     |
|  |   微服务A    |        |   微服务B   |        |   微服务C   |      |
|  |  +--------+ |        |  +--------+ |        |  +--------+ |     |
|  |  | 业务逻辑| |        | | 业务逻辑| |         | | 业务逻辑| |     |
|  |  +--------+ |        |  +--------+ |        |  +--------+ |     |
|  |       |     |        |       |     |        |       |     |     |
|  |  +--------+ |        |  +--------+ |        |  +--------+ |     |
|  |  | Sidecar| |        |  | Sidecar| |        |  | Sidecar| |     |
|  |  | (Envoy)| |        |  | (Envoy)| |        |  | (Envoy)| |     |
|  |  +--------+ |        |  +--------+ |        |  +--------+ |     |
|  +-------------+        +-------------+        +-------------+     |
|         |                    |                    |                |
|  +--------+             +--------+             +--------+          |
|  | 数据库A |            | 数据库B |             | 数据库C |          |
|  +--------+             +--------+             +--------+          |
+--------------------------------------------------------------------+

2.6. 无服务器与函数计算

将"解耦"和"下沉"的思想推向极致，让开发者完全不用关心服务器。

• 特点 ：
  • 函数即服务：以函数为最小部署和计费单位。开发者只编写一个个独立的函数，由云平台负责其触发、运行、扩缩容（甚至缩到零）和运维。
  • 后端即服务：直接使用云数据库、云存储、云认证等托管服务。
• 优点 ：
  • 极致的开发效率与运维成本：完全无需管理服务器。
  • 极致的弹性与成本：按实际调用次数和资源消耗计费，空闲时成本为零。
• 缺点 ：
  • 冷启动延迟。
  • 状态管理困难，函数应为无状态的。
  • 供应商锁定风险。
  • 调试和监控有特殊挑战。
• 适用场景：事件驱动型、突发流量、异步处理（如图片处理、消息清洗、定时任务）。

+-----------------------------------------------------------+
|                   云平台（如AWS Lambda）                   |
|                                                           |
|  +----------------+  +----------------+  +----------------+
|  |    函数A       |  |    函数B        |  |    函数C       |
|  |  +----------+  |  |  +----------+  |  |  +----------+  |
|  |  | 代码逻辑  |  |  |  | 代码逻辑  |  |  |  | 代码逻辑 |  |
|  |  +----------+  |  |  +----------+  |  |  +----------+  |
|  +----------------+  +----------------+  +----------------+
|          |                  |                  |          |
|  +----------------+  +----------------+  +------ -----+   |
|  |   事件源1      |  |   事件源2       |  |   事件源3   |   |
|  | (如API网关)    |  | (如消息队列)    |  | (如对象存储) |   |
|  +----------------+  +----------------+  +----------------+
|                                                           |
+-----------------------------------------------------------+

+-----------------------------------------------------------+
|                   后端即服务（BaaS）                       |
|   +-----------------------------------------------+       |
|   |        云数据库      云存储      云身份认证     |       |
|   +-----------------------------------------------+       |
+-----------------------------------------------------------+

3. 分布式架构

分布式架构不是一个与单体、SOA、微服务等并列的"架构风格"，而是一个更上层的、描述系统部署和运行状态的"属性"或"模式"。

概念层级不同

• 单体架构、微服务架构 等描述的是应用代码的组织方式、模块的边界和职责划分。它们回答的是"如何切割我的代码和功能"。
• 分布式架构 描述的是系统组件部署和运行的物理（或逻辑）位置关系。它回答的是"我的组件是否运行在多个独立的、需要网络通信的进程/机器上"。

简单类比：

• 单体/微服务架构就像是房屋的结构设计（是打通的大开间，还是分成卧室、客厅、厨房等多个功能房间）。
• 分布式架构则是指这个房子是建在一块地基上，还是由多个建在不同地方、通过道路连接的小屋组成。

分布式是多个阶段的共同特征

演进主线（架构风格）： 单体 → 垂直 → SOA → 微服务 → 服务网格/云原生 → 无服务器

在演进历程中，从垂直架构开始，后续的架构几乎都具备"分布式"的特性。

• 垂直架构：如果"电商前台"和"商家后台"部署在不同的服务器上，并通过网络（如HTTP）调用，那么它就是一个简单的分布式系统。
• SOA架构：其核心ESB和服务提供者通常就是分布式部署的。
• 微服务架构 ：是分布式架构的极致体现。每个服务都是独立的进程，部署上天然就是分布式的。
• 云原生/无服务器架构：更是构建在遍布全球数据中心的分布式云基础设施之上。

分布式特性：

• 单体架构：通常是非分布式的（所有模块在一个进程内）。
• 垂直架构及以后 ：都具备分布式架构的属性。分布式程度和复杂度逐渐增加，在微服务时达到高峰，在云原生时代通过基础设施（服务网格）将复杂度下沉管理。

4. 演进总结

4.1. 演进趋势总结

架构	核心单元	通信/集成	数据库	关键目标
单体	应用	进程内调用	单一共享数据库	快速启动
垂直	独立应用	简单RPC/HTTP	分库	按业务扩展
SOA	粗粒度服务	中心化ESB	分库	服务复用，系统集成
微服务	细粒度服务	去中心化，直接调用	一服务一库	敏捷、独立、灵活
云原生	微服务+Sidecar	服务网格	一服务一库	基础设施能力下沉
无服务器	函数/事件	事件/消息	托管BaaS	零运维、极致弹性

4.2. 演进关系总览

┌─────────────────────────────────────────────────────────────┐
│                   演进时间线                                 │
│                                                             │
│  单体 → 垂直 → SOA → 微服务 → 服务网格 → 无服务器              │
│                                                             │
│  ┌─────┐    ┌─────┐    ┌─────┐    ┌─────┐    ┌─────┐        │
│  │集中 │    │ 简单 │   │ 中心 │    │去中 │    │基础  │        │
│  │化   │    │ 分布 │   │ 化   │    │心化 │    │设施 │        │
│  └─────┘    └─────┘    └─────┘    └─────┘    └─────┘        │
│                                                             │
│  ┌───────────────────────────────────────────────────────┐  │
│  │           分布式系统复杂度逐渐增加                      │  │
│  │           运维关注点逐渐上移/抽象化                     │  │
│  └───────────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────────┘

4.3. 核心思想演进

1. 从"大而全"到"小而专"：功能单元不断细化和独立。
2. 从"智能端点，笨管道"到"笨端点，智能管道"：通信的智能性从应用内部（ESB）转移到网络基础设施（服务网格）。
3. 从"关注服务器"到"关注代码"再到"关注业务逻辑"：运维负担被层层剥离。
4. 从"技术驱动拆分"到"业务驱动拆分"：康威定律日益凸显。

4.4. 关键变化维度

架构维度	单体 → 垂直 → SOA → 微服务 → 服务网格 → 无服务器
部署单元	应用 → 应用 → 服务 → 容器 → 服务+Sidecar → 函数
通信方式	函数调用 → RPC → ESB → REST/gRPC → 服务网格 → 事件
数据管理	共享库 → 独立库 → 分库 → 一服务一库 → 一服务一库 → BaaS
团队结构	功能型 → 项目型 → 服务型 → 产品型 → 平台型 → 无运维
扩展方式	垂直扩展 → 垂直扩展 → 服务扩展 → 服务扩展 → 自动扩展 → 自动扩展

4.5. 架构选择建议

1. 初创阶段：单体或垂直架构，快速验证业务
2. 快速发展期：微服务架构，支持团队并行开发
3. 平台化阶段：服务网格/云原生，标准化基础设施
4. 事件驱动场景：无服务器，处理突发流量和异步任务
5. 遗留系统集成：SOA或API网关方式

没有最好的架构，只有最合适的架构。 架构演进的选择必须与团队规模、业务阶段、技术储备和运维能力相匹配。许多现代大型系统实际上是多种架构模式的混合体（如核心业务采用微服务，边缘计算或事件处理采用Serverless）。

5. 演进示例

参考地址：mp.weixin.qq.com/s/sVwpJIAuv...

下面以淘宝项目的架构演进进行示例。

5.1. 单机架构

在网站最初时，应用数量与用户数都较少，可以把 Tomcat 和数据库部署在同一台服务器上。浏览器往 www.taobao.com 发起请求时，首先经过 DNS 服务器（域名系统）把域名转换为实际 IP 地址 10.102.4.1，浏览器转而访问该 IP 对应的 Tomcat。

架构瓶颈：随着用户数的增长，Tomcat 和数据库之间竞争资源，单机性能不足以支撑业务。

5.2. 第一次演进

Tomcat 与数据库分开部署

Tomcat 和数据库分别独占服务器资源，显著提高两者各自性能。

架构瓶颈：随着用户数的增长，并发读写数据库成为瓶颈。

5.3. 第二次演进

引入本地缓存和分布式缓存

在 Tomcat 同服务器上或同 JVM 中增加本地缓存，并在外部增加分布式缓存，缓存热门商品信息或热门商品的 html 页面等。通过缓存能把绝大多数请求在读写数据库前拦截掉，大大降低数据库压力。

其中涉及的技术包括：使用 memcached 作为本地缓存，使用 Redis 作为分布式缓存，还会涉及缓存一致性、缓存穿透/击穿、缓存雪崩、热点数据集中失效等问题。

架构瓶颈：缓存抗住了大部分的访问请求，随着用户数的增长，并发压力主要落在单机的 Tomcat 上，响应逐渐变慢。

5.4. 第三次演进

引入反向代理实现负载均衡

在多台服务器上分别部署 Tomcat，使用反向代理软件 Nginx 把请求均匀分发到每个 Tomcat 中。此处假设 Tomcat 最多支持 100 个并发，Nginx 最多支持 50000 个并发，那么理论上 Nginx 把请求分发到 500 个 Tomcat 上，就能抗住 50000 个并发。

其中涉及的技术包括：Nginx、HAProxy，两者都是工作在网络第七层的反向代理软件，主要支持 http 协议，还会涉及 session 共享、文件上传下载的问题。

架构瓶颈：反向代理使应用服务器可支持的并发量大大增加，但并发量的增长也意味着更多请求穿透到数据库，单机的数据库最终成为瓶颈。

5.5. 第四次演进

数据库读写分离

把数据库划分为读库和写库，读库可以有多个，通过同步机制把写库的数据同步到读库，对于需要查询最新写入数据场景，可通过在缓存中多写一份，通过缓存获得最新数据。

其中涉及的技术包括：MyCat，它是数据库中间件，可通过它来组织数据库的分离读写和分库分表，客户端通过它来访问下层数据库，还会涉及数据同步，数据一致性的问题。

架构瓶颈：业务逐渐变多，不同业务之间的访问量差距较大，不同业务直接竞争数据库，相互影响性能。

5.6. 第五次演进

数据库按业务分库

把不同业务的数据保存到不同的数据库中，使业务之间的资源竞争降低，对于访问量大的业务，可以部署更多的服务器来支撑。这样同时导致跨业务的表无法直接做关联分析，需要通过其他途径来解决，但这不是本文讨论的重点，有兴趣的可以自行搜索解决方案。

架构瓶颈：随着用户数的增长，单机的写库会逐渐会达到性能瓶颈。

5.7. 第六次演进

把大表拆分为小表

比如针对评论数据，可按照商品 ID 进行 hash，路由到对应的表中存储；针对支付记录，可按照小时创建表，每个小时表继续拆分为小表，使用用户 ID 或记录编号来路由数据。只要实时操作的表数据量足够小，请求能够足够均匀的分发到多台服务器上的小表，那数据库就能通过水平扩展的方式来提高性能。其中前面提到的 MyCat 也支持在大表拆分为小表情况下的访问控制。

这种做法显著的增加了数据库运维的难度，对 DBA 的要求较高。数据库设计到这种结构时，已经可以称为分布式数据库，但是这只是一个逻辑的数据库整体，数据库里不同的组成部分是由不同的组件单独来实现的，如分库分表的管理和请求分发，由 MyCat 实现，SQL 的解析由单机的数据库实现，读写分离可能由网关和消息队列来实现，查询结果的汇总可能由数据库接口层来实现等等，这种架构其实是 MPP（大规模并行处理）架构的一类实现。

目前开源和商用都已经有不少 MPP 数据库，开源中比较流行的有 Greenplum、TiDB、Postgresql XC、HAWQ 等，商用的如南大通用的 GBase、睿帆科技的雪球 DB、华为的 LibrA 等等，不同的 MPP 数据库的侧重点也不一样，如 TiDB 更侧重于分布式 OLTP 场景，Greenplum 更侧重于分布式 OLAP 场景，这些 MPP 数据库基本都提供了类似 Postgresql、Oracle、MySQL 那样的 SQL 标准支持能力，能把一个查询解析为分布式的执行计划分发到每台机器上并行执行，最终由数据库本身汇总数据进行返回，也提供了诸如权限管理、分库分表、事务、数据副本等能力，并且大多能够支持 100 个节点以上的集群，大大降低了数据库运维的成本，并且使数据库也能够实现水平扩展。

架构瓶颈：数据库和 Tomcat 都能够水平扩展，可支撑的并发大幅提高，随着用户数的增长，最终单机的 Nginx 会成为瓶颈。

5.8. 第七次演进

使用 LVS 或 F5 来使多个 Nginx 负载均衡

由于瓶颈在 Nginx，因此无法通过两层的 Nginx 来实现多个 Nginx 的负载均衡。图中的 LVS 和 F5 是工作在网络第四层的负载均衡解决方案，其中 LVS 是软件，运行在操作系统内核态，可对 TCP 请求或更高层级的网络协议进行转发，因此支持的协议更丰富，并且性能也远高于 Nginx，可假设单机的 LVS 可支持几十万个并发的请求转发；F5 是一种负载均衡硬件，与 LVS 提供的能力类似，性能比 LVS 更高，但价格昂贵。由于 LVS 是单机版的软件，若 LVS 所在服务器宕机则会导致整个后端系统都无法访问，因此需要有备用节点。可使用 keepalived 软件模拟出虚拟 IP，然后把虚拟 IP 绑定到多台 LVS 服务器上，浏览器访问虚拟 IP 时，会被路由器重定向到真实的 LVS 服务器，当主 LVS 服务器宕机时，keepalived 软件会自动更新路由器中的路由表，把虚拟 IP 重定向到另外一台正常的 LVS 服务器，从而达到 LVS 服务器高可用的效果。

此处需要注意的是，上图中从 Nginx 层到 Tomcat 层这样画并不代表全部 Nginx 都转发请求到全部的 Tomcat，在实际使用时，可能会是几个 Nginx 下面接一部分的 Tomcat，这些 Nginx 之间通过 keepalived 实现高可用，其他的 Nginx 接另外的 Tomcat，这样可接入的 Tomcat 数量就能成倍的增加。

架构瓶颈：由于 LVS 也是单机的，随着并发数增长到几十万时，LVS 服务器最终会达到瓶颈，此时用户数达到千万甚至上亿级别，用户分布在不同的地区，与服务器机房距离不同，导致了访问的延迟会明显不同。

5.9. 第八次演进

通过 DNS 轮询实现机房间的负载均衡

在 DNS 服务器中可配置一个域名对应多个 IP 地址，每个 IP 地址对应到不同的机房里的虚拟 IP。当用户访问 www.taobao.com 时，DNS 服务器会使用轮询策略或其他策略，来选择某个 IP 供用户访问。此方式能实现机房间的负载均衡，至此，系统可做到机房级别的水平扩展，千万级到亿级的并发量都可通过增加机房来解决，系统入口处的请求并发量不再是问题。

架构瓶颈：随着数据的丰富程度和业务的发展，检索、分析等需求越来越丰富，单单依靠数据库无法解决如此丰富的需求。

5.10. 第九次演进

引入 NoSQL 数据库和搜索引擎等技术

当数据库中的数据多到一定规模时，数据库就不适用于复杂的查询了，往往只能满足普通查询的场景。对于统计报表场景，在数据量大时不一定能跑出结果，而且在跑复杂查询时会导致其他查询变慢，对于全文检索、可变数据结构等场景，数据库天生不适用。因此需要针对特定的场景，引入合适的解决方案。如对于海量文件存储，可通过分布式文件系统 HDFS 解决，对于 key value 类型的数据，可通过 HBase 和 Redis 等方案解决，对于全文检索场景，可通过搜索引擎如 ElasticSearch 解决，对于多维分析场景，可通过 Kylin 或 Druid 等方案解决。

当然，引入更多组件同时会提高系统的复杂度，不同的组件保存的数据需要同步，需要考虑一致性的问题，需要有更多的运维手段来管理这些组件等。

架构瓶颈：引入更多组件解决了丰富的需求，业务维度能够极大扩充，随之而来的是一个应用中包含了太多的业务代码，业务的升级迭代变得困难。

5.11. 第十次演进

大应用拆分为小应用

按照业务板块来划分应用代码，使单个应用的职责更清晰，相互之间可以做到独立升级迭代。这时候应用之间可能会涉及到一些公共配置，可以通过分布式配置中心 Zookeeper 来解决。

架构瓶颈：不同应用之间存在共用的模块，由应用单独管理会导致相同代码存在多份，导致公共功能升级时全部应用代码都要跟着升级。

5.12. 第十一次演进

复用的功能抽离成微服务

如用户管理、订单、支付、鉴权等功能在多个应用中都存在，那么可以把这些功能的代码单独抽取出来形成一个单独的服务来管理，这样的服务就是所谓的微服务，应用和服务之间通过 HTTP、TCP 或 RPC 请求等多种方式来访问公共服务，每个单独的服务都可以由单独的团队来管理。此外，可以通过 Dubbo、SpringClou 等框架实现服务治理、限流、熔断、降级等功能，提高服务的稳定性和可用性。

架构瓶颈：不同服务的接口访问方式不同，应用代码需要适配多种访问方式才能使用服务，此外，应用访问服务，服务之间也可能相互访问，调用链将会变得非常复杂，逻辑变得混乱。

5.13. 第十二次演进（SOA）

引入企业服务总线(ESB，Enterprise Service Bus)屏蔽服务接口的访问差异

通过 ESB 统一进行访问协议转换，应用统一通过 ESB 来访问后端服务，服务与服务之间也通过 ESB 来相互调用，以此降低系统的耦合程度。

这种单个应用拆分为多个应用，公共服务单独抽取出来来管理，并使用企业消息总线来解除服务之间耦合问题的架构，就是所谓的 SOA（面向服务）架构，这种架构与微服务架构容易混淆，因为表现形式十分相似。

个人理解，微服务架构更多是指把系统里的公共服务抽取出来单独运维管理的思想，而 SOA 架构则是指一种拆分服务并使服务接口访问变得统一的架构思想，SOA 架构中包含了微服务的思想。

架构瓶颈：业务不断发展，应用和服务都会不断变多，应用和服务的部署变得复杂，同一台服务器上部署多个服务还要解决运行环境冲突的问题，此外，对于如大促这类需要动态扩缩容的场景，需要水平扩展服务的性能，就需要在新增的服务上准备运行环境，部署服务等，运维将变得十分困难。

5.14. 第十三次演进

引入容器化技术实现运行环境隔离与动态服务管理

目前最流行的容器化技术是 Docker，最流行的容器管理服务是 Kubernetes(K8S)，应用/服务可以打包为 Docker 镜像，通过 K8S 来动态分发和部署镜像。Docker 镜像可理解为一个能运行你的应用/服务的最小的操作系统，里面放着应用/服务的运行代码，运行环境根据实际的需要设置好。把整个"操作系统"打包为一个镜像后，就可以分发到需要部署相关服务的机器上，直接启动 Docker 镜像就可以把服务起起来，使服务的部署和运维变得简单。

在大促的之前，可以在现有的机器集群上划分出服务器来启动 Docker 镜像，增强服务的性能，大促过后就可以关闭镜像，对机器上的其他服务不造成影响。

架构瓶颈：使用容器化技术后服务动态扩缩容问题得以解决，但是机器还是需要公司自身来管理，在非大促的时候，还是需要闲置着大量的机器资源来应对大促，机器自身成本和运维成本都极高，资源利用率低。

5.15. 第十四次演进

以云平台承载系统

系统可部署到公有云上，利用公有云的海量机器资源，解决动态硬件资源的问题，在大促的时间段里，在云平台中临时申请更多的资源，结合 Docker 和 K8S 来快速部署服务，在大促结束后释放资源，真正做到按需付费，资源利用率大大提高，同时大大降低了运维成本。

所谓的云平台，就是把海量机器资源，通过统一的资源管理，抽象为一个资源整体，在之上可按需动态申请硬件资源（如 CPU、内存、网络等），并且之上提供通用的操作系统，提供常用的技术组件（如 Hadoop 技术栈，MPP 数据库等）供用户使用，甚至提供开发好的应用，用户不需要关心应用内部使用了什么技术，就能够解决需求（如音视频转码服务、邮件服务、个人博客等）。在云平台中会涉及如下几个概念：

1. IaaS：基础设施即服务。对应于上面所说的机器资源统一为资源整体，可动态申请硬件资源的层面；

2. PaaS：平台即服务。对应于上面所说的提供常用的技术组件方便系统的开发和维护；

3. SaaS：软件即服务。对应于上面所说的提供开发好的应用或服务，按功能或性能要求付费。

6. 架构设计经验小结

1）架构的调整是否必须按照上述演变路径进行？

不是的，以上所说的架构演变顺序只是针对某个侧面进行单独的改进，在实际场景中，可能同一时间会有几个问题需要解决，或者可能先达到瓶颈的是另外的方面，这时候就应该按照实际问题实际解决。如在政府类的并发量可能不大，但业务可能很丰富的场景，高并发就不是重点解决的问题，此时优先需要的可能会是丰富需求的解决方案。

2）对于将要实施的系统，架构应该设计到什么程度？

对于单次实施并且性能指标明确的系统，架构设计到能够支持系统的性能指标要求就足够了，但要留有扩展架构的接口以备不时之需。对于不断发展的系统，如电商平台，应设计到能满足下一阶段用户量和性能指标要求的程度，并根据业务的增长不断的迭代升级架构，以支持更高的并发和更丰富的业务。

3）服务端架构和大数据架构有什么区别？

所谓的"大数据"其实是海量数据采集清洗转换、数据存储、数据分析、数据服务等场景解决方案的一个统称，在每一个场景都包含了多种可选的技术，如数据采集有 Flume、Sqoop、Kettle 等，数据存储有分布式文件系统HDFS、FastDFS，NoSQL 数据库 HBase、MongoDB 等，数据分析有 Spark 技术栈、机器学习算法等。

总的来说大数据架构就是根据业务的需求，整合各种大数据组件组合而成的架构，一般会提供分布式存储、分布式计算、多维分析、数据仓库、机器学习算法等能力。而服务端架构更多指的是应用组织层面的架构，底层能力往往是由大数据架构来提供。

4）有没有一些架构设计的原则？

a. N+1 设计：系统中的每个组件都应做到没有单点故障；

b. 回滚设计：确保系统可以向前兼容，在系统升级时应能有办法回滚版本；

c. 禁用设计：应该提供控制具体功能是否可用的配置，在系统出现故障时能够快速下线功能；

d. 监控设计：在设计阶段就要考虑监控的手段；

e. 多活数据中心设计：若系统需要极高的高可用，应考虑在多地实施数据中心进行多活，至少在一个机房断电的情况下系统依然可用；

f. 采用成熟的技术：刚开发的或开源的技术往往存在很多隐藏的 bug，出了问题没有商业支持可能会是一个灾难；

g. 资源隔离设计：应避免单一业务占用全部资源；

h. 架构应能水平扩展：系统只有做到能水平扩展，才能有效避免瓶颈问题；

i. 非核心则购买：非核心功能若需要占用大量的研发资源才能解决，则考虑购买成熟的产品；

j. 使用商用硬件：商用硬件能有效降低硬件故障的机率；

k. 快速迭代：系统应该快速开发小功能模块，尽快上线进行验证，早日发现问题大大降低系统交付的风险；

l. 无状态设计：服务接口应该做成无状态的，当前接口的访问不依赖于接口上次访问的状态。