延续第一篇的双态架构，本章主要针对双态中涉及到通讯集成和服务调用进行展开。
传统银行稳态架构中我们一般采用ESB作为系统内联总线，外联通过通用网关实现内外通讯连接。
敏态微服务弹性架构则引入了APIGateway，APIGateway一方面暴露在系统之外，对外提供API给外部系统调用，一方面部署在系统内容，以访问系统内的各种服务。
随着云原生架构的不断演进，ServiceMesh把业务和应用网络解耦，让开发人员主需要关注业务实现，不需要关注服务和网络的各种集成控制逻辑。
APIGateway，ServiceMesh由于在功能上有重叠的部分，目前业界也在对其融合或是替代在做一些尝试，喜欢深入研究的同学可以去看一下蚂蚁的API Gateway Mesh。这里就此跳过。
ESB、APIGateway、ServiceMesh的具体定义和各种逻辑图请各位同学自行脑补，我们直接上干货。
银行数字化转型双态IT架构
一、我们来明确在双态IT架构中ESB、APIGateway和ServiceMesh的定位和职责边界：
ESB、APIGateway和ServiceMesh对比
二、从整体双态架构层面明确东西、南北流量接入场景：
敏态，由API网管负责南北流量，由ServiceMesh负责东西流量。
稳态，由ESB负责东西流量
敏态与稳态之间通过把ESB的服务暴露在APIGateway上，形成东西流量访问
三、服务组成、组合和服务对外暴露方式
敏态
稳态
ESB（集中式）
ESB分布式
（分布式ESB是在集中式ESB的基础上，吸收了微服务架构（如spring boot/Dubbo），通过注册中心对服务进行注册，通过在应用服务app上安装Agent的方式，把服务信息同步到Agent上，并且把其他功能（网络、弹性、安全等）也同步的对应分布式ESB上，形成一个在应用服务app独立部署的的进程，应用服务app中的api范围就可以实现点对点访问，采用分布式ESB的银行，一般使用混合部署模式，分布式ESB部署在分核心应用，核心应用如核心系统、ECIF还是采用集中式部署。）
四、双态架构下的服务集成方式
对于银行系统来说微服务最大的问题是服务粒度划分的粗细问题，但是不管服务划分粒度如何，对外暴露的API一定要收敛，不能把所有微服务都暴露出去，于是流程编排（BPMN）至关重要。
在稳态实施ESB的时候大部分机构均未采用BPMN流程编排平台，应为流程编排平台在架构定位上比较模糊，做不好又做成一个大前置。在没有服务编排的情况下应对服务流程编排比较常用的是谁调用谁组合的原则。
举个栗子
场景描述，该场景服务划分不是太严谨，仅说明双态下服务组合使用
如图，API-CORE1，API-ZF1均发布到APIGateway上。
在BPMN流程编排组合平台上对客户信息检查api，客户账户合法性检查和余额检查API与聚合支付API（聚合支付API原来就是由API-CORE1和API-ZF1组合而成）进行组合。
最终发布出账户转账API供外部系统使用
五、最后……
我也还在不断的学习中，其中有些例子就是为了说明问题。
在设计过程发现分布式ESB与ServiceMesh从设计思路和架构上很像，分布式ESB和ServiceMesh的融合估计以后后成为后银行续稳态改造上云的一个关键点。
