微服务的好处是什么？
前言
在团队要把单体应用改造成微服务时， 最好先评估下微服务带来的好处是什么？
自治
在采用微服务架构时，开发团队拥有交付特性所需的整个技术栈的控制权，好处是可以减少与其他团队之间的协调工作，互不影响。
开发团队可以专注某些领域
在采用单体架构时，开发任务的分配是不固定的，任何人都有可能分配到任意的任务。但如果每个团队可以拥有自己的服务，就可以在特定业务领域积累专业知识，理解特定领域的业务规则和需求。他们对自己的技术栈十分了解，在做出变更时更有信心。
伸缩性
在采用微服务时，开发者可以根据每个服务的性能需求进行伸缩。而在采用单体架构时，虽然也可通过添加更多服务器进行水平伸缩，但却不能让单体的每个组件进行独立伸缩。此外，细粒度的微服务可以更容易根据需要进行垂直伸缩。例如，有时可能希望多处理一些负载，而在处理性能问题时又需要一些额外的机会。
更容易回滚
如果回滚某个功能，只需要修改单个微服务就可以直接回滚，不会影响其他团队的工作。此外，微服务架构有助于降低因单个微服务故障导致整个系统宕机的风险。
更高的发布频率
如果是一个大型系统，每次版本发布都很耗时，且伴随着风险。回归测试需要覆盖很多东西，从而限制发布节奏。开发人员可能需要经过很多人准许，并在所有参与版本发布的团队之间进行协调。微服务缩小了变更范围，减少了团队之间的协调工作量。开发团队可以根据自己的时间表发布版本，而不是被一个整体的节奏所束缚。
使用最合适的技术
微服务的各个团队可以为要解决的问题选择最合适的技术，可以使用最新的技术，而单体系统则很难升级，只能停留在过时的技术平台上。
升级更简单
给大型应用程序升级框架从来都不是件有趣的事情，而且通常都伴有风险。当需要在多个团队间协调相互关联的变更时，一切都变得更加困难。而在采用微服务架构时，可以只升级必要服务，每次只让一个团队升级一个服务。
缩小变更影响范围
应用程序的不同部分以不同的速度发生变化，大部分组件可能几个月甚至几年都不需要改动，将很少发生变化的代码与频繁发生变化的代码分开可以降低意外回归带来的风险。
易于重构
较小的服务更容易理解。一个服务只由一个团队负责开发，服务的设计风格就能够保持一致。小巧的微服务更容易进行重构。相比之下，单体架构可能会出现不一致，因为随着时间的推移，不同的团队会向单体系统中加入不一样的设计想法。
