下载掌阅APP，畅读海量书库
立即打开
微服务架构改造前与改造后的对比如图2-16和图2-17所示。
图2-16 微服务架构改造前
图2-17 微服务架构改造后
本节将结合图2-16和图2-17，以及微服务的定义来讲解微服务的优缺点。
1.更易于开发和维护
因为一个服务只关注一个特定的业务功能，所以它的业务清晰、代码量少。开发的独立和部署的独立都使得开发和维护单个微服务变得简单。
这里笔者补充一点，易于开发和维护是针对拆分后单独的微服务项目来说的。未拆分时需要面对一个庞大的单体应用，而拆分后只需要开发和维护一个或几个独立的微服务项目，代码量减少了，难易程度降低了很多。至于要实施和上线一个微服务架构的项目，复杂度依然很高，工作量还是很大。不过，如此庞大的工作量肯定要由整个团队去完成，较难攻克的任务有微服务架构实施前的技术选型、微服务组件的搭建和底层支撑、项目拆分时的边界和具体落地的细则，这些工作更多的是由架构师、公共服务团队、运维团队等技术人员去完成的，开发人员只需要关注自己所负责的微服务即可。
2.快速迭代+灵活
未拆分时，在巨无霸单体项目中开发、提交代码、回归测试都非常复杂。数不尽的代码分支和代码冲突，还有耗时耗力的回归测试，都会让人心力交瘁。独立开发与独立部署的微服务，可以更加快速地进行功能迭代。
服务之间的耦合低，甚至可以随时加入一个新的服务或剔除过时的服务，灵活度提升了很多。如果某个功能出现问题，针对性地修改和发版即可，不会像未拆分之前“牵一发而动全身”。开发和修改都变得更加灵活，不会出现“要等另一个开发团队先提交代码自己才能提交代码”“不同开发分支上所需的数据库结构不同”“由于不同分支下的代码合并冲突导致需要更多的回归测试和代码修改”等让人哭笑不得的事情。
3.系统的伸缩性增强
对高频访问和资源需求高的服务投入更多的资源，比如增加服务器、数据库、带宽等资源的配置。对于低频访问和资源需求相对低的服务不需要投入过多的资源。实现最优的资源利用，提升资源的利用率，并提升系统的伸缩性。
4.技术选型灵活
这一点在微服务架构的定义中已经讲明了，单个服务可以结合具体的业务和团队的特点，选择合适的编程语言和技术栈进行实现。
5.错误隔离
A服务出现了问题或宕机了，这个错误只会影响小范围的相关功能，不会影响整个系统的运行。在微服务架构中，可以使用流量控制、服务熔断、服务降级等手段来对系统进行保护，让局部的错误只影响系统的局部而不是影响系统的全部。
结合微服务架构改造前与改造后的对比图来看，可以简单理解为“微服务架构就是把原来巨无霸单体应用的复杂度和难点进行分摊”，因此就有了上述的这些优点。拆分后系统的难点和复杂度会具体和细化到每一个模块和对应的微服务团队上，开发和维护变得更加灵活。开发视角也会从项目整体聚焦到某个局部模块，开发人员的职责也更加具体和清晰。
有些人会把“微服务架构会提高团队成员的沟通效率”当作微服务架构的优点，无从考证这种说法是从哪里传出来的。笔者也理解这种说法是针对单个微服务中的开发人员，因为独立开发和部署，所以人员很精简，沟通效率会提升。但是如果把视角拉升到整个微服务架构的人员中，就会得出不同的结论。笔者结合自身过往的开发经验来谈一下对于这个“优点”的看法。沟通肯定是人与人之间的沟通，而人毕竟不是冰冷的代码，换了架构或改了技术栈并不能提高沟通效率，不同的人有不同的性格和脾气，开发习惯也有所不同。具体到微服务架构项目的开发上，有时模块越多越容易“扯皮”，依赖的层级越深越难以厘清关系，也难以沟通。当然，这不是微服务架构的问题，而是团队和人的问题。因此，沟通效率的提高和下降都不能当作微服务架构的优点和缺点，这和团队及团队中的人有关系，和微服务架构的关系并不大。
凡事都有两面性，微服务架构也不例外。讲完它的优点之后，再来列举一些它的不足之处。
1.落地一个微服务架构项目比较复杂
实施和上线一个微服务架构项目的复杂度很高，工作量很大，要考虑和解决的问题很多。微服务架构实施前的技术选型、微服务组件的搭建和底层支撑、项目拆分时的边界和具体落地的细则、微服务项目的开发和上线、后期的维护等具体的工作都摆在面前，需要一个一个地处理。在落地微服务架构项目时不仅要编码，还要考虑微服务架构的搭建和底层支撑，这件事就像“大兵团作战”，不是一个五人突击队就能够完成任务的。
2.服务依赖和调用链路更复杂
微服务架构中的单个微服务，不可避免地会出现依赖性及由此导致的问题。比如，H服务依赖S服务，S服务依赖A服务，如果A服务在线上出现问题或A服务需要修改部分逻辑，那么S服务和H服务也可能受到牵连，或者级联修改。虽然已经做了服务拆分，影响范围不大，但是这些问题还是存在的。
另外一个问题就是微服务中的调用链路复杂，调用时间相对于单体应用的调用时间肯定是要延长的。微服务在服务调用时难免要建立服务连接，不管是基于HTTP协议还是基于其他的RPC协议，都会难以避免地发生网络损耗，相对于单体应用中的服务调用是同一个项目中的方法调用，更加复杂。
3.数据一致性问题
用前文中的H服务、S服务和A服务举例来说，在调用过程中，如果遇到网络延迟或A服务出现了异常导致数据回滚，但是上游H服务和S服务的数据都已经入库了，就会导致数据不一致的问题。此时就需要做好数据一致性的解决方案，相对于单体应用中的本地事务处理，复杂度又提升了。
4.问题排查的链路加长
前文已经提到了微服务架构项目中的调用链路更复杂，链路复杂和链路的拉长会导致定位线上问题时要排查的地方增加，出现了处理一个问题要查看和定位多个服务的情况。
5.学习成本高
对于开发人员来说，微服务架构的学习和上手比较难。不像学习某一个技术栈，如想要学习和上手Spring Boot技术栈，看教程后动手做几个功能和项目也就学会了。在学习微服务架构时，需要学习很多内容，包括理念、组成部分、各个组件的功能与使用等，都需要理解，还要动手搭建和整合各个微服务组件，否则很难完完整整地掌握。到了具体编码和实战的过程中，又有很多的难点要克服。