微服务的坏味道

架构

单系统微服务大于 10 5 个的都不是好的微服务。—— w4n9hu1

17年开始接触微服务，后面经历过了2次大项目的微服务化重构/演进。

首先，并不是反对与微服务紧密相关的SOA或者DDD，再或者Docker，Azure等，反而我认为这些都是很好的思想或工具，是每个程序员都应该掌握的。

这是22年写过一篇 什么是微服务

微服务令人不适的坏味道

  1. 开发效率低：需求是订单服务加一个字段，需要改动：订单服务，BFF, UI, Gateway, Consumer，各种Dto，消息中间件Schema, 各种依赖项目的类库升级。
  2. 性能差：进程内通信变为一堆服务链间的Http调用，性能差好几个数量级。
  3. 数据冗余：为了减少跨服务频繁调用，业务表去存放一些主数据，比如用户名，仓库名，增加数据库压力，也造成主数据难以维护和统一。
  4. 架构复杂度上升：为了更纯的微服务，降低耦合，去加入各种中间层。
  5. 问题定位困难：细分带来的调用链路太长，导致问题排查耗时。
  6. 需要大量日志和监控：来协助排查问题，也带来大量的人力和基础设施成本。
  7. 数据修复困难：一旦产生脏数据，需要多个服务中逐一修复，一系列服务的回滚也是问题。
  8. 跨服务通信：Http，跨进程的请求不稳定，需要复杂的Retry机制保证消息的可靠性。
  9. 牺牲一致性：分布式事务带来的复杂度或者牺牲一定的一致性。
  10. 发布/运维麻烦：开发团队难以维护，需要专业DevOps团队。
  11. 难以完整理解业务：各种消息中间件，新人很难理解完整业务。
  12. tbd！

微服务的理论优势

  1. 容错性，高可用？实际情况是维护一套系统比维护一堆服务要容易的多，可用性也更高。
  2. 易发布，易扩展？单体系统并不等于慢系统或者老系统，CI/CD速度不比多个微服务慢，PaaS使得扩展都很容易。
  3. 局部扩容？不会节省太多成本，一般公司也没这个场景。
  4. 技术异构？常规公司单核心系统不太可能使用不同技术栈。
  5. 代码量少易重构？不够好的团队只有一坨大屎或一堆小屎的区别。
  6. 高内聚，低耦合？所以降低了多少成本，带来的多少业务价值。

就这些难以避免的坏味道，和可有可无的优势。使用微服务前是不是都该问一下，这个项目不用微服务架构可以吗？

愿更多公司早日脱离微服务的苦海，回头是岸，Peace！