微服务的优缺点和适用场景

上篇分享我们介绍了微服务的整体架构和组件，可以看到微服务架构要比单体应用的架构复杂很多，所以这篇分享学院君将在正式介绍微服务架构的具体组件和落地实践之前，给大家分析下微服务的利弊和适用场景，否则，没有权衡清楚贸然进行微服务重构的话，可能会引入很多意料之外的问题。

微服务的优缺点

关于微服务架构的优缺点我们在网络协议：RPC 部分已经简单介绍过，这里我们通过表格的形式更加直观的来对比：

对于简单项目来说，单体架构 5 胜 8 败，优势主要体现在开发效率、上手难度、运维效率、硬件需求、项目成本；对于复杂项目来说，微服务架构 11 胜 2败，优势主要体现在硬件需求、项目成本、开发效率、系统设计时的高内聚低耦合和可扩展性、需求变更响应速度、系统升级效率、代码复用性、非功能需求、职责/成就感、风险的可控性。

所以对于小型简单系统来说，使用单体架构更合适，对于大型复杂系统来说，使用微服务架构更合适，但是尽管如此，微服务也不是银弹，它也为系统引入了新的问题比如提高了系统的复杂度，这也导致了开发人员上手难度增加，需要在理解分布式系统设计的基础上才能更好的开发和维护微服务，再就是分布式服务的调用问题，服务的注册和发现、服务之间的分布式事务问题，数据库拆分之后数据报表的处理，数据库查询的复杂度增加，服务之间分布式一致性的问题，此外也为系统运维和管理增加了复杂度，这都是我们在进行微服务架构时要做好的心里准备和技术储备。

微服务的适用场景

所以微服务也不是一招鲜吃遍天，不是能够解决所有问题的万金油，它有其特定的适用场景，用之不慎很有可能带来负面作用，陷入上述提到的微服务泥淖之中无法自拔，一定要在系统进行微服务重构时认识到这一点。那么哪些场景适合使用微服务架构呢？满足以下三个条件即可考虑：

• 团队规模较大，超过10人；
• 业务复杂度高，超过5个以上的子模块（业务功能较复杂）；
• 项目需要长期迭代开发和维护（半年以上）。

以下是一个单体应用与微服务开发效率的曲线，随着业务复杂度的增加，单体应用的效率逐渐降低，甚至在某个临界点出现断崖式下跌，之后，微服务的优势就很明显了，所以很多公司在单体应用的效率低到无法接收时都会开始服务化/微服务重构：

如果一开始面临的就是一个复杂的满足上述三个条件的系统开发，我们也可以在一开始就引入微服务架构，以避免后续重构引入的额外风险和时间成本。

经过这一篇介绍，相比你应该对什么时候使用微服务架构有了一个很量化的认识，下一篇开始，我们就来介绍构成微服务架构的各个组件是如何协同工作以实现分布式服务调用的。