微服务陷阱四：缺乏自动化与服务治理时，"轻量级"最终演变成新的ESB

微服务理念强调”快速交付”，但如果没有自动化系统支撑、全靠人工操作，不仅达不到快速交付的目的，效率反而可能比一个大而全的单体系统还低：没有自动化测试，每次测试都要人工把大量接口测一遍；没有自动化部署，每次上线要在几十台机器上逐台敲shell命令部署6~7个服务，运维人员手都要敲麻；没有自动化监控，每次故障排查都要人工去翻几十台机器、几百个微服务各自的状态和日志文件。信奉微服务的人常常拿SOA的ESB当反面教材来凸显微服务”lightweight”的优越性，但实践后会发现，随着微服务种类和数量越来越多，没有服务治理系统支撑，这份”轻量级”反而会自己变成新的问题：服务路由——假设某个微服务有60个节点、分布在20台机器上，其他依赖它的服务怎么知道这个部署布局？服务故障隔离——如果这60个节点里有5个出了故障，依赖它的服务该怎么应对？服务注册与发现——如果决定把节点从60个扩容到80个、或者从60个缩到40个，新增或减少的节点怎么让依赖它的服务及时知道？如果这些场景全靠人工去管理，整个系统必然陷入混乱，唯一的出路是引入自动化的服务治理系统去承担这些工作——但一旦走到这一步，会发现微服务当初标榜的”轻量级”，最终演变成了和ESB几乎同等复杂的东西，只是复杂性从”服务间通信这一层”转移到了”服务治理这一层”而已。

结构图：

flowchart TB
  A["缺乏自动化+服务治理时的两类问题"]
  A --> B["无自动化支撑<br/>测试/部署/监控全靠人工<br/>反而比单体系统效率更低"]
  A --> C["无服务治理<br/>随微服务数量增多而暴露"]
  C --> C1["服务路由：依赖方如何得知服务的节点分布？"]
  C --> C2["服务故障隔离：部分节点故障时如何应对？"]
  C --> C3["服务注册与发现：扩缩容时如何通知依赖方？"]
  C1 --> D["只能靠自动化服务治理系统解决"]
  C2 --> D
  C3 --> D
  D --> E["结果：微服务标榜的'lightweight'<br/>最终演变成和ESB几乎同等复杂<br/>只是复杂性转移到了服务治理这一层"]