为什么要使用微服务架构

本节结合系统架构的演进来谈一谈为什么要使用微服务、微服务有哪些优缺点。

“为什么要使用微服务？” 这个问题其实包含了好几个问题，比如 “哪些原因导致系统架构往微服务架构方向上演进？”、“微服务架构解决了哪些痛点？”、“微服务架构有哪些优点？”、“微服务架构这个概念流行之前的微服务叫什么？” 或者换一个说法：“微服务架构的雏形是什么？”

带着这些问题，开始本节内容的学习吧！

架构的演进

好的架构不是设计出来的，而是演进出来的。

系统立项之初，就想着设计一个大而全的架构，期待着它能够解决各个阶段的各种问题，这是不可能的。因为在初期很难预估后期业务的变化，如果在初期就落地一个大而全的项目，那么人力成本和时间成本都会很高。同时，架构并不是千篇一律的，千万不能在不同的业务和系统中生搬硬套同一个架构。先快速落地，并关注业务的变化和系统的健壮程度，在不同阶段对当前架构所面临的问题进行复盘和处理，选择一个更适合自身的方向进行优化和改进，这才是常规的做法。

在每个阶段，找到对应该阶段网站架构所面临的问题，在不断解决这些问题的过程中，系统的架构在不断地朝着正确的方向演进。这里笔者引用了李智慧老师在《大型网站技术架构：核心原理与案例分析》这本书中的案例来介绍系统常见的演进过程。

初始阶段的网站架构

初始阶段的网站架构比较简单，通常一台服务器就可以搞定一个网站的部署，此时的网站架构如图 2-4 所示。

Figure 1. 图2-4 初始阶段的网站架构

应用服务和数据服务分离

随着网站业务的发展，一台服务器逐渐不能满足需求，这时就需要将应用和数据分离来提升系统的性能，此时的网站架构如图 2-5 所示。

Figure 2. 图2-5 应用服务和数据服务分离的网站架构

使用缓存改善网站性能

80% 的业务访问会集中在 20% 的数据上，网站基本上都会使用缓存来优化访问性能，通过缓存层的接入，减少对数据库部分的直接压力，提升网站的响应性能，此时的网站架构如图 2-6 所示。

Figure 3. 图2-6 使用缓存改善网站性能的网站架构

使用应用服务器集群改善网站的并发处理能力

因为单一应用服务器能够处理的请求连接有限，在网站访问高峰时期，应用服务器会成为整个网站的瓶颈。因此，使用负载均衡调度服务器势在必行。通过负载均衡调度服务器，可将大量的请求分发到应用的集群中的任何一台服务器上，进一步将系统压力分散处理，此时的网站架构如图 2-7 所示。

Figure 4. 图2-7 使用应用服务器集群的网站架构

数据库读写分离

当用户数量达到一定规模后，数据库因为负载压力过高而成为网站的瓶颈，而目前主流的数据库都提供主从热备功能，通过配置两台数据库的主从关系，可以将一台数据库的数据更新并同步到另一台服务器上，网站利用数据库这个功能实现数据库读写分离，从而减轻数据库负载压力，此时的网站架构如图 2-8 所示。

Figure 5. 图2-8 数据库读写分离的网站架构

使用反向代理和CDN加速网站响应

随着系统规模越来越大，需要响应全国甚至全球各区域的访问，但是各区域的访问速度差别巨大。为了提高网站的访问速度，可以使用反向代理和 CDN 加速网站响应，此时的网站架构如图 2-9 所示。

Figure 6. 图2-9 使用反向代理和 CDN 的网站架构

使用分布式文件系统和分布式数据库系统

任何强大的单一服务器都满足不了大型网站持续增长的业务需求。分布式文件系统和分布式数据库系统可以进一步提升系统的可用性，并提升系统的响应速度，此时的网站架构如图 2-10 所示。

Figure 7. 图2-10 使用分布式文件系统和分布式数据库系统的网站架构

使用NoSQL和搜索引擎

某些系统可能会出现海量数据存储和检索的需求，此时可以使用 NoSQL 产品分布式部署来支持海量数据的查询和存储，此时的网站架构如图 2-11 所示。

Figure 8. 图2-11 使用 NoSQL 和搜索引擎的网站架构

业务拆分和分布式服务

大型网站为了应对日益复杂的业务场景，通过使用分而治之的手段将整个网站业务拆分成不同的产品线，通过分布式服务来协同工作，此时的网站架构如图 2-12 所示。

Figure 9. 图2-12 业务拆分和分布式服务的网站架构

常见的网站架构演进过程如图 2-13 所示。

Figure 10. 图2-13 《大型网站技术架构：核心原理与案例分析》书中常见的网站架构的演进过程

李智慧老师的《大型网站技术架构：核心原理与案例分析》一书于 2013 年 9 月出版，整理书稿的时间肯定更早一些，因此书中并没有近几年较流行的微服务架构、领域驱动及服务网格 ServiceMesh 相关的描述，这些也是分布式服务的一些网站架构演进方向。

微服务架构并不是石头缝里蹦出的孙悟空

微服务架构并不是神话故事中的孙悟空，某一天忽然从石头缝里蹦出来了。

微服务架构并不神秘，在 “微服务架构” 这个概念 “火” 起来之前，微服务架构叫什么？或者换一个说法：“微服务架构的雏形是什么？”

其实，前文中网站架构演进的过程已经给出了答案。在微服务架构这个概念变得流行之前，技术架构也在不断优化和演进，只是那时关于架构的讨论并不多，毕竟当时有很多开发人员连前后端分离的概念都还没搞懂，前端开发人员还自嘲为 “切图仔”，有些系统甚至是用 JSP+Servlet 进行开发的。另外，当时的技术论坛也比较沉闷，很少有人发布博客，如果不是技术大咖，根本不敢在论坛里 “高声言语”。不像现在，技术人员在互联网上的 “声音” 越来越大，技术论坛也异常活跃，各种技术的原理、实践都会被翻来覆去地讨论和讲解。比如架构方面的知识（如微服务、云原生、DDD 领域驱动、Service Mesh 服务网格），可能很多在校大学生都已经耳濡目染，能够谈一谈这方面的知识和体会了，因为这些知识点会通过论坛、邮件、群聊、公众号、App 通知等各种渠道定时定点地 “轰炸” IT 行业的从业者和将要进入 IT 行业的从业者，想不了解都不行。

笔者记得很清楚，在微服务架构这个概念 “火” 起来之前，人们会用 “分布式服务” 或 “服务化” 来概括这种将大系统拆分为小系统的架构模式，与微服务架构的方式很像，也是对巨无霸的单体应用进行拆分，并结合 RPC 协议进行服务通信和调用。常见技术有 Dubbo、DubboX、CXF、gRPC、HSF、Motan 等。当然，其实各个互联网大厂也都有各自的自研技术框架，这些是不对外开放的。当时流行的都是一些开源的技术框架，笔者实际上手开发实践过的就有基于 Dubbo 的后端项目，也有基于 Hessian 的后端项目，而这些框架也通常被叫作分布式服务框架。

所以，之前并不是没有微服务架构或微服务架构的雏形，只是彼时的叫法不同而已。随着微服务概念的流行、微服务生态的完善和微服务架构落地规则的细化，现在业内人士都默认将这种架构方式称为微服务架构了。从笔者进入行业工作到 2017 年的这段时间，关于微服务架构的讨论在国内有很多，不过更多的还是叫 “分布式服务” 或 “服务化”。从 2017 年至今，“微服务架构” 这个概念一统江湖，人们都会以 “微服务” 来描述这种大型分布式服务的架构了。以上是笔者的个人感受，可能在具体的时间点或具体的名称上有一些偏差，但是微服务架构并不是凭空出现的，它的雏形其实早就存在了。

哪些原因导致系统架构往微服务架构的方向演进

前文已经对网站架构演进做了总结。这个演进过程比较常见，不过，在不同的业务和技术团队中，优化和演进肯定不会完全相同，中间可能会有微小的差异。不过总结下来，网站架构演进主要包括三个原因，如图 2-14 所示。

Figure 11. 图2-14 网站架构演进的原因

随着业务的增长和技术团队的完善，系统在逐渐优化。在优化方案应用后，业务量还在不断增长，此时为了应对日益复杂的业务场景，就要使用分而治之的手段进行服务化拆分。将整个网站业务拆分成不同的产品线，通过分布式服务来协同工作。

导致系统架构向微服务架构方向演进的原因如图 2-15 所示。

Figure 12. 图2-15 向微服务架构方向演进的原因总结

从业务规模来说，初始的系统架构肯定无法支撑越来越复杂的业务场景，此时就需要进行系统优化，优化手段有缓存、集群、前后端分离、动静分离、读写分离、分布式数据库和分布式文件系统等。若这些系统优化手段都已经用上，还是不能满足业务的成长速度，就要进行业务梳理和系统拆解。
从沟通成本和敏捷开发的角度来说，当技术团队中的成员已经有成千上万个，技术小组也有成百上千个的时候，如果还在一个巨无霸的单体项目上开发，都在一个工程里提交代码、修改 Bug、切换不同的分支，这就是灾难了。系统的分工不明确、责任不清晰，导致沟通成本高、研发效率低，也无法做到快速迭代。毕竟不是在项目刚开始的阶段，当时可能只有一个技术团队和少量的开发人员。
从团队的技术储备来说，项目刚开始的阶段，技术团队人数比较少，团队人员主要是以开发人员为主。但是随着业务规模和企业规模的扩大，在项目架构的不断优化过程中，各种人才的储备已经充足。技术团队也日趋完善，前端技术团队、后端技术团队、测试团队、公共服务团队、DBA 团队、运维团队、架构团队等都已经存在，此时再进行业务拆分和架构的完善就有了足够的底层支撑。
从 “微服务架构” 的发展来说，微服务架构的实践并不是空中楼阁，可以实际落地了。近几年的时间里，微服务架构已经由最初的理论派逐渐落地和完善，与微服务相关的生态已经建立起来，开源框架和企业内部自研的框架都已投入生产，技术实践也不再是遥不可及的了。比如 Spring Cloud 框架及与之相关配套的微服务组件为行业提供了一站式的解决方案，解决了很多企业和技术团队关于架构选型和维护方面的困难。

当然，此时可能有读者会继续思考下去，难道只能往微服务架构的方向上演进吗？答案肯定不是，在前面的架构演进图中，演进方向是一条笔直的线。而现实情况中肯定是有不同分支的，微服务架构也只是众多技术架构中的一个，适合自身业务系统和技术团队的才是最好的架构。