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

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

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

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

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

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

（1）从业务规模来说，初始的系统架构肯定无法支撑越来越复杂的业务场景，此时就需要进行系统优化，优化手段有缓存、集群、前后端分离、动静分离、读写分离、分布式数据库和分布式文件系统等。若这些系统优化手段都已经用上，还是不能满足业务的成长速度，就要进行业务梳理和系统拆解。

（2）从沟通成本和敏捷开发的角度来说，当技术团队中的成员已经有成千上万个，技术小组也有成百上千个的时候，如果还在一个巨无霸的单体项目上开发，都在一个工程里提交代码、修改Bug、切换不同的分支，这就是灾难了。系统的分工不明确、责任不清晰，导致沟通成本高、研发效率低，也无法做到快速迭代。毕竟不是在项目刚开始的阶段，当时可能只有一个技术团队和少量的开发人员。

（3）从团队的技术储备来说，项目刚开始的阶段，技术团队人数比较少，团队人员主要是以开发人员为主。但是随着业务规模和企业规模的扩大，在项目架构的不断优化过程中，各种人才的储备已经充足。技术团队也日趋完善，前端技术团队、后端技术团队、测试团队、公共服务团队、DBA团队、运维团队、架构团队等都已经存在，此时再进行业务拆分和架构的完善就有了足够的底层支撑。

（4）从“微服务架构”的发展来说，微服务架构的实践并不是空中楼阁，可以实际落地了。近几年的时间里，微服务架构已经由最初的理论派逐渐落地和完善，与微服务相关的生态已经建立起来，开源框架和企业内部自研的框架都已投入生产，技术实践也不再是遥不可及的了。比如Spring Cloud框架及与之相关配套的微服务组件为行业提供了一站式的解决方案，解决了很多企业和技术团队关于架构选型和维护方面的困难。

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