微服务架构的缺点

微服务 “入门易，出门难”

介绍微服务架构好处的文章比较多，最近交付的一个项目发现的缺点也比较明显，给方案设计，性能，测试，运维，问题排查，数据管理，配置管理，事务管理，研发管理都带来了不少挑战。如果使用不慎，研发成本，交付成本和运维成本都可能会大幅度上升。

自己的体会，不能简单通过技术角度看待微服务化，为了微服务而微服务潜在风险很大，不好的微服务切分会带来不必要的沟通路径，而沟通路径增加会带来更大的复杂度，这违背了微服务设计的初衷。微服务“入门容易，掌握难，出门难”。

建议的原则是业务驱动，设计保障，演进式迭代，保守治疗的方式。搞不清楚，有争议的地方先尽量不要拆，如果确实要拆，要经过业务分析后慎重设计，把真正相对独立的部分拆分出来，可以借鉴DDD的方式。拆了以后要观察微服务的接口是否稳定，针对业务需求的变更微服务的模块是否可以保持相对稳定，是否可以独立演进。

微服务的缺点

正好看了一个国外帖子，总结的不错，翻译并增加了自己的一些体会：

以下是微服务架构的缺点：

1. 团队沟通的过载：微服务架构降低了团队管理的难度，但是确不能降低团队沟通的需求。研发人员需要确保一个服务中的更新不会破坏其它功能。我们在单体应用中也会发现类似问题，但是微服务架构的应用这个问题会更加明显。

2. 正式文档的过载：每一个独立的运行部件需要持续维护其规格和接口文档，这些文档是其它团队使用这些部件的必要条件。

3. 不一致性的应用：我们可以为每一个组件选择不同的技术栈。这导致了不一致的应用设计和架构，而这会在更长期的运维期间增加系统维护成本。

4. DevOps的复杂度：我们需要拥有一支成熟的DevOps团队去处理微服务架构的应用的复杂性。由于多个应用存在多个活动部件，这种复杂度需要有高水平的经验。

5. 增加了资源使用：运行这些微服务架构的应用的初始投资会比较大，因为所有微服务应都需要拥有他们自己的运行容器，这也需要更多的CPU和内存。另外采用了中间件也会带啦一个比较大的基座投资。

6. 增加了网络通信开销：分布式系统的产生的网络开销比单机应用多很多，不能简单把内部调用简单改为分布式调用，吃亏很大。微服务架构下，独立运行的组件都需要通过网络进行互相通信。这中系统需要有更加可靠和快速的网络连接。

7. 编码和解码：这个容易理解，也会产生性能问题。

8. 网络安全：通过网络进行通信的系统更容易产生安全缺陷。

9. 测试：测试微服务架构的应用绝对比单体应用难很多，深有体会，集成测试过程是一场噩梦。

10. 产品监控：监控微服务架构应用的成本会更高，很难获得合适的工具，自研的成本也很高。

11. 其它：另外例如方案设计，研发管理，问题排查确实都有不少挑战。

Martin Fowler的观点

架构演进应该还是需要业务驱动和演进式迭代的，重新看了Martin Fowler的那篇
Microservices经典之作。再来体会一下这句话会有不同的体验：
“One reasonable argument we've heard is that you shouldn't start with a microservices architecture. Instead begin with a monolith, keep it modular, and split it into microservices once the monolith becomes a problem.”
不要一上来就以微服务架构做为起点。相反，要用一个单块系统做为起点，并保持其模块化。当这个单块系统出现了问题后，再将其分解为微服务。

微服务架构——不是免费的午餐

另外看到一篇文章《Microservices - Not A Free Lunch!》,也提出了微服务的几个潜在问题：

• 显著的运营开销
• 大量的开发运营(DevOps)技术要求
• 隐式接口
• 重复努力
• 分布式系统的复杂性
• 异步性的困难性
• 可测试挑战

参考：

微服务架构——不是免费的午餐(翻译)
Microservices - Not A Free Lunch!