微服务架构-基础篇：微服务架构的优缺点和适用场景

微服务架构的优缺点

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

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

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

微服务架构的适用场景

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

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

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

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