微服务基础设施是把ESB的复杂度转移而非消除，及搭建的四层优先级

大部分人关注微服务的”small”和”lightweight”，但真正决定微服务能否落地成功的，恰恰是最容易被忽视的”automated”——如果服务粒度划分不合理，团队遇到问题后自然会想办法拆服务或合服务来纠正；但如果”automated”相关的基础设施不健全，微服务就会变成一个焦油坑，让研发、测试、运维都陷进[[微服务陷阱四：缺乏自动化与服务治理时，”轻量级”最终演变成新的ESB]]描述的各种困境。完整的微服务基础设施体系看起来阵仗很大，很容易让人怀疑：”这么多基础设施，还好意思说自己’轻量级’？”——确实如此，微服务并没有真正减少复杂度，只是把原本集中在ESB里的复杂度转移分散到了这一整套基础设施里：”服务发现”“服务路由”这些能力本质上就是ESB原本承担的功能，只是在微服务架构里被剥离出来，各自变成了独立的基础系统。不过团队规模小、公司体量不大也不必因此对微服务望而却步，原因有两点：一是已经有成熟的开源微服务基础设施全家桶可以直接用（比如Spring Cloud，涵盖服务发现、服务路由、网关、配置中心等能力）；二是微服务数量不多的情况下，并非每一层基础设施都是刚需，可以按优先级分阶段搭建。建议的优先级是：第一层，服务发现、服务路由、服务容错——这是最基本、无论如何都需要的微服务基础设施；第二层，接口框架、API网关——主要是为了提升开发效率，接口框架提升内部服务间的开发效率，API网关提升和外部系统对接的效率；第三层，自动化部署、自动化测试、配置中心——主要是为了提升测试和运维效率；第四层，服务监控、服务跟踪、服务安全——主要是为了进一步提升运维效率。第三层和第四层的重要性会随微服务节点数量增加而水涨船高，但在节点数量还不多的阶段，靠人工方式支撑虽然效率不高，也基本能顶住，不必一开始就追求把四层基础设施全部一次性建齐。

结构图：

flowchart TB
  A["微服务基础设施的真相：<br/>把ESB的复杂度转移而非消除"]
  A --> A1["服务发现/服务路由等<br/>本质就是ESB功能的独立化拆分"]
  A1 --> B["搭建优先级(可按需分阶段)"]
  B --> C["第一层(必须)：服务发现/服务路由/服务容错"]
  B --> D["第二层：接口框架(内部效率)/API网关(外部对接效率)"]
  B --> E["第三层：自动化部署/自动化测试/配置中心(测试运维效率)"]
  B --> F["第四层：服务监控/服务跟踪/服务安全(进一步提升运维效率)"]
  E --> G["第三/四层重要性随节点数增加而上升<br/>节点少时可先靠人工支撑"]
  F --> G
  A1 --> H["缓解方案：可直接采用成熟开源全家桶<br/>如Spring Cloud"]