2.3.1 微服务架构的优点

1.更易于开发和维护

因为一个服务只关注一个特定的业务功能，所以它的业务清晰、代码量少。开发的独立和部署的独立都使得开发和维护单个微服务变得简单。

这里笔者补充一点，易于开发和维护是针对拆分后单独的微服务项目来说的。未拆分时需要面对一个庞大的单体应用，而拆分后只需要开发和维护一个或几个独立的微服务项目，代码量减少了，难易程度降低了很多。至于要实施和上线一个微服务架构的项目，复杂度依然很高，工作量还是很大。不过，如此庞大的工作量肯定要由整个团队去完成，较难攻克的任务有微服务架构实施前的技术选型、微服务组件的搭建和底层支撑、项目拆分时的边界和具体落地的细则，这些工作更多的是由架构师、公共服务团队、运维团队等技术人员去完成的，开发人员只需要关注自己所负责的微服务即可。

2.快速迭代+灵活

未拆分时，在巨无霸单体项目中开发、提交代码、回归测试都非常复杂。数不尽的代码分支和代码冲突，还有耗时耗力的回归测试，都会让人心力交瘁。独立开发与独立部署的微服务，可以更加快速地进行功能迭代。

服务之间的耦合低，甚至可以随时加入一个新的服务或剔除过时的服务，灵活度提升了很多。如果某个功能出现问题，针对性地修改和发版即可，不会像未拆分之前“牵一发而动全身”。开发和修改都变得更加灵活，不会出现“要等另一个开发团队先提交代码自己才能提交代码”“不同开发分支上所需的数据库结构不同”“由于不同分支下的代码合并冲突导致需要更多的回归测试和代码修改”等让人哭笑不得的事情。

3.系统的伸缩性增强

对高频访问和资源需求高的服务投入更多的资源，比如增加服务器、数据库、带宽等资源的配置。对于低频访问和资源需求相对低的服务不需要投入过多的资源。实现最优的资源利用，提升资源的利用率，并提升系统的伸缩性。

4.技术选型灵活

这一点在微服务架构的定义中已经讲明了，单个服务可以结合具体的业务和团队的特点，选择合适的编程语言和技术栈进行实现。

5.错误隔离

A服务出现了问题或宕机了，这个错误只会影响小范围的相关功能，不会影响整个系统的运行。在微服务架构中，可以使用流量控制、服务熔断、服务降级等手段来对系统进行保护，让局部的错误只影响系统的局部而不是影响系统的全部。

结合微服务架构改造前与改造后的对比图来看，可以简单理解为“微服务架构就是把原来巨无霸单体应用的复杂度和难点进行分摊”，因此就有了上述的这些优点。拆分后系统的难点和复杂度会具体和细化到每一个模块和对应的微服务团队上，开发和维护变得更加灵活。开发视角也会从项目整体聚焦到某个局部模块，开发人员的职责也更加具体和清晰。

有些人会把“微服务架构会提高团队成员的沟通效率”当作微服务架构的优点，无从考证这种说法是从哪里传出来的。笔者也理解这种说法是针对单个微服务中的开发人员，因为独立开发和部署，所以人员很精简，沟通效率会提升。但是如果把视角拉升到整个微服务架构的人员中，就会得出不同的结论。笔者结合自身过往的开发经验来谈一下对于这个“优点”的看法。沟通肯定是人与人之间的沟通，而人毕竟不是冰冷的代码，换了架构或改了技术栈并不能提高沟通效率，不同的人有不同的性格和脾气，开发习惯也有所不同。具体到微服务架构项目的开发上，有时模块越多越容易“扯皮”，依赖的层级越深越难以厘清关系，也难以沟通。当然，这不是微服务架构的问题，而是团队和人的问题。因此，沟通效率的提高和下降都不能当作微服务架构的优点和缺点，这和团队及团队中的人有关系，和微服务架构的关系并不大。