SOA与微服务架构下编排位置的根本差异

架构范式决定了流程编排应该发生在”哪里”。SOA蓝图推崇一个包含工作流引擎的集中式BPM平台，通过集中式企业服务总线（ESB）与各服务通信——这正是[[BPM与SOA时代集中式工具失败的具体教训]]所描述的集中式痛点的技术根源；SOA环境下依然可以成功落地流程自动化，但要格外注意流程定义的归属权应属于关心业务逻辑的开发团队，而不是独立的BPM团队。微服务架构定义了”运行在一起的小型、自治服务群”（Sam Newman定义），关键是”自治”：团队对自己的服务拥有完全控制权，可自由选服务的技术栈、自主部署运维。这直接改变了编排的位置——微服务架构不允许业务逻辑存在于微服务之外，所以编排业务流程必须发生在拥有这段业务逻辑的微服务内部，而不是像SOA那样在服务外面通过BPM平台拼接；服务间只通过API通信，是否在内部用工作流引擎自动化流程，是这个微服务团队自己的实现细节，对外部完全不可见。

结构图：

flowchart TD
    subgraph SOA["SOA：编排在服务外部"]
        ESB[集中式ESB / BPM平台] --> S1[服务A]
        ESB --> S2[服务B]
        ESB --> S3[服务C]
    end
    subgraph MS["微服务：编排在服务内部"]
        M1[用户入网微服务<br/>内含流程模型+工作流引擎] -->|API调用| M2[计费微服务]
        M1 -->|API调用| M3[SIM卡配置微服务]
    end
    SOA -.痛点:归属不清+集中式瓶颈.-> X[6.2.2节:流程定义应归属业务团队]
    MS -.优势:自治+对外不可见的实现细节.-> Y[编排决策是微服务团队内部决定]