微服务架构的缺点

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

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

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

建议的原则是业务驱动,设计保障,演进式迭代,保守治疗的方式。搞不清楚,有争议的地方先尽量不要拆,如果确实要拆,要经过业务分析后慎重设计,把真正相对独立的部分拆分出来,可以借鉴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!

推荐阅读更多精彩内容