下载掌阅APP，畅读海量书库
立即打开
本节结合系统架构的演进来谈一谈为什么要使用微服务、微服务有哪些优缺点。
“为什么要使用微服务？”这个问题其实包含了好几个问题，比如“哪些原因导致系统架构往微服务架构方向上演进？”“微服务架构解决了哪些痛点？”“微服务架构有哪些优点？”“微服务架构这个概念流行之前的微服务叫什么？”或者换一个说法：“微服务架构的雏形是什么？”
带着这些问题，开始本节内容的学习吧！
好的架构不是设计出来的，而是演进出来的。
系统立项之初，就想着设计一个大而全的架构，期待着它能够解决各个阶段的各种问题，这是不可能的。因为在初期很难预估后期业务的变化，如果在初期就落地一个大而全的项目，那么人力成本和时间成本都会很高。同时，架构并不是千篇一律的，千万不能在不同的业务和系统中生搬硬套同一个架构。先快速落地，并关注业务的变化和系统的健壮程度，在不同阶段对当前架构所面临的问题进行复盘和处理，选择一个更适合自身的方向进行优化和改进，这才是常规的做法。
在每个阶段，找到对应该阶段网站架构所面临的问题，在不断解决这些问题的过程中，系统的架构在不断地朝着正确的方向演进。这里笔者引用了李智慧老师在《大型网站技术架构：核心原理与案例分析》这本书中的案例来介绍系统常见的演进过程。
1.初始阶段的网站架构
初始阶段的网站架构比较简单，通常一台服务器就可以搞定一个网站的部署，此时的网站架构如图2-4所示。
图2-4 初始阶段的网站架构
2.应用服务和数据服务分离
随着网站业务的发展，一台服务器逐渐不能满足需求，这时就需要将应用和数据分离来提升系统的性能，此时的网站架构如图2-5所示。
图2-5 应用服务和数据服务分离的网站架构
3.使用缓存改善网站性能
80%的业务访问会集中在20%的数据上，网站基本上都会使用缓存来优化访问性能，通过缓存层的接入，减少对数据库部分的直接压力，提升网站的响应性能，此时的网站架构如图2-6所示。
图2-6 使用缓存改善网站性能的网站架构
4.使用应用服务器集群改善网站的并发处理能力
因为单一应用服务器能够处理的请求连接有限，在网站访问高峰时期，应用服务器会成为整个网站的瓶颈。因此，使用负载均衡调度服务器势在必行。通过负载均衡调度服务器，可将大量的请求分发到应用的集群中的任何一台服务器上，进一步将系统压力分散处理，此时的网站架构如图2-7所示。
图2-7 使用应用服务器集群的网站架构
5.数据库读写分离
当用户数量达到一定规模后，数据库因为负载压力过高而成为网站的瓶颈，而目前主流的数据库都提供主从热备功能，通过配置两台数据库的主从关系，可以将一台数据库的数据更新并同步到另一台服务器上，网站利用数据库这个功能实现数据库读写分离，从而减轻数据库负载压力，此时的网站架构如图2-8所示。
图2-8 数据库读写分离的网站架构
6.使用反向代理和CDN加速网站响应
随着系统规模越来越大，需要响应全国甚至全球各区域的访问，但是各区域的访问速度差别巨大。为了提高网站的访问速度，可以使用反向代理和CDN加速网站响应，此时的网站架构如图2-9所示。
7.使用分布式文件系统和分布式数据库系统
任何强大的单一服务器都满足不了大型网站持续增长的业务需求。分布式文件系统和分布式数据库系统可以进一步提升系统的可用性，并提升系统的响应速度，此时的网站架构如图2-10所示。
图2-9 使用反向代理和CDN的网站架构
图2-10 使用分布式文件系统和分布式数据库系统的网站架构
8.使用NoSQL和搜索引擎
某些系统可能会出现海量数据存储和检索的需求，此时可以使用NoSQL产品分布式部署来支持海量数据的查询和存储，此时的网站架构如图2-11所示。
图2-11 使用NoSQL和搜索引擎的网站架构
9.业务拆分和分布式服务
大型网站为了应对日益复杂的业务场景，通过使用分而治之的手段将整个网站业务拆分成不同的产品线，通过分布式服务来协同工作，此时的网站架构如图2-12所示。
图2-12 业务拆分和分布式服务的网站架构
常见的网站架构演进过程如图2-13所示。
图2-13《大型网站技术架构：核心原理与案例分析》书中常见的网站架构的演进过程
李智慧老师的《大型网站技术架构：核心原理与案例分析》一书于2013年9月出版，整理书稿的时间肯定更早一些，因此书中并没有近几年较流行的微服务架构、领域驱动及服务网格Service Mesh相关的描述，这些也是分布式服务的一些网站架构演进方向。
微服务架构并不是神话故事中的孙悟空，某一天忽然从石头缝里蹦出来了。
微服务架构并不神秘，在“微服务架构”这个概念“火”起来之前，微服务架构叫什么？或者换一个说法：“微服务架构的雏形是什么？”
其实，前文中网站架构演进的过程已经给出了答案。在微服务架构这个概念变得流行之前，技术架构也在不断优化和演进，只是那时关于架构的讨论并不多，毕竟当时有很多开发人员连前后端分离的概念都还没搞懂，前端开发人员还自嘲为“切图仔”，有些系统甚至是用JSP+Servlet进行开发的。另外，当时的技术论坛也比较沉闷，很少有人发布博客，如果不是技术大咖，根本不敢在论坛里“高声言语”。不像现在，技术人员在互联网上的“声音”越来越大，技术论坛也异常活跃，各种技术的原理、实践都会被翻来覆去地讨论和讲解。比如架构方面的知识（如微服务、云原生、DDD领域驱动、Service Mesh服务网格），可能很多在校大学生都已经耳濡目染，能够谈一谈这方面的知识和体会了，因为这些知识点会通过论坛、邮件、群聊、公众号、App通知等各种渠道定时定点地“轰炸”IT行业的从业者和将要进入IT行业的从业者，想不了解都不行。
笔者记得很清楚，在微服务架构这个概念“火”起来之前，人们会用“分布式服务”或“服务化”来概括这种将大系统拆分为小系统的架构模式，与微服务架构的方式很像，也是对巨无霸的单体应用进行拆分，并结合RPC协议进行服务通信和调用。常见技术有Dubbo、DubboX、CXF、gRPC、HSF、Motan等。当然，其实各个互联网大厂也都有各自的自研技术框架，这些是不对外开放的。当时流行的都是一些开源的技术框架，笔者实际上手开发实践过的就有基于Dubbo的后端项目，也有基于Hessian的后端项目，而这些框架也通常被叫作分布式服务框架。
所以，之前并不是没有微服务架构或微服务架构的雏形，只是彼时的叫法不同而已。随着微服务概念的流行、微服务生态的完善和微服务架构落地规则的细化，现在业内人士都默认将这种架构方式称为微服务架构了。从笔者进入行业工作到2017年的这段时间，关于微服务架构的讨论在国内有很多，不过更多的还是叫“分布式服务”或“服务化”。从2017年至今，“微服务架构”这个概念一统江湖，人们都会以“微服务”来描述这种大型分布式服务的架构了。以上是笔者的个人感受，可能在具体的时间点或具体的名称上有一些偏差，但是微服务架构并不是凭空出现的，它的雏形其实早就存在了。
前文已经对网站架构演进做了总结。这个演进过程比较常见，不过，在不同的业务和技术团队中，优化和演进肯定不会完全相同，中间可能会有微小的差异。不过总结下来，网站架构演进主要包括三个原因，如图2-14所示。
图2-14 网站架构演进的原因
随着业务的增长和技术团队的完善，系统在逐渐优化。在优化方案应用后，业务量还在不断增长，此时为了应对日益复杂的业务场景，就要使用分而治之的手段进行服务化拆分。将整个网站业务拆分成不同的产品线，通过分布式服务来协同工作。
导致系统架构向微服务架构方向演进的原因如图2-15所示。
图2-15 向微服务架构方向演进的原因总结
（1）从业务规模来说，初始的系统架构肯定无法支撑越来越复杂的业务场景，此时就需要进行系统优化，优化手段有缓存、集群、前后端分离、动静分离、读写分离、分布式数据库和分布式文件系统等。若这些系统优化手段都已经用上，还是不能满足业务的成长速度，就要进行业务梳理和系统拆解。
（2）从沟通成本和敏捷开发的角度来说，当技术团队中的成员已经有成千上万个，技术小组也有成百上千个的时候，如果还在一个巨无霸的单体项目上开发，都在一个工程里提交代码、修改Bug、切换不同的分支，这就是灾难了。系统的分工不明确、责任不清晰，导致沟通成本高、研发效率低，也无法做到快速迭代。毕竟不是在项目刚开始的阶段，当时可能只有一个技术团队和少量的开发人员。
（3）从团队的技术储备来说，项目刚开始的阶段，技术团队人数比较少，团队人员主要是以开发人员为主。但是随着业务规模和企业规模的扩大，在项目架构的不断优化过程中，各种人才的储备已经充足。技术团队也日趋完善，前端技术团队、后端技术团队、测试团队、公共服务团队、DBA团队、运维团队、架构团队等都已经存在，此时再进行业务拆分和架构的完善就有了足够的底层支撑。
（4）从“微服务架构”的发展来说，微服务架构的实践并不是空中楼阁，可以实际落地了。近几年的时间里，微服务架构已经由最初的理论派逐渐落地和完善，与微服务相关的生态已经建立起来，开源框架和企业内部自研的框架都已投入生产，技术实践也不再是遥不可及的了。比如Spring Cloud框架及与之相关配套的微服务组件为行业提供了一站式的解决方案，解决了很多企业和技术团队关于架构选型和维护方面的困难。
当然，此时可能有读者会继续思考下去，难道只能往微服务架构的方向上演进吗？答案肯定不是，在前面的架构演进图中，演进方向是一条笔直的线。而现实情况中肯定是有不同分支的，微服务架构也只是众多技术架构中的一个，适合自身业务系统和技术团队的才是最好的架构。