架构设计：ESB的国产化替代

原 ESB 用的是甲骨文的 OSB 产品不同系统统一接入 ESB 总线由 ESB 完成报文转发、协议转换、路由编排等工作。请求链路大概是这样系统 A - 网络 - ESB - 网络 - 系统 B可以说ESB 就是全行的交易枢纽所有交易流量都要经过 ESB 中心节点。这种架构本质上是典型的“中心化总线架构”。但这次国产化之后我发现玩法已经完全不一样了。为了和传统 ESB 区分本文暂且把它称作ESC。传统 ESB 和分布式 ESB到底差在哪传统 ESB 的核心特征是控制面和数据面都集中在总线上。而分布式 ESB 的核心特征是控制面集中数据面分布式化。它不再像传统 ESB 一样把所有流量集中到中心节点统一转发而是把转发能力下沉到了各系统边缘。有点类似 Service Mesh 的设计。如果用一种更容易理解的说法就是以前ESB 既是“大脑”也是“手脚”现在中心只保留“大脑”真正干活的是分布在各处的 sidecarESC 会在不同系统入口处部署 sidecar 边车代理请求链路会变成这样系统 A - sidecar A - 网络 - sidecar B - 系统 B很多人看到这里会马上问一句“那 ESC 去哪了”答案是它没有消失只是不再站在所有流量的必经之路上。它更像一个控制中心sidecar 会注册到控制中心路由、策略、治理规则仍然由中心下发但真正的报文转发不再必须穿过中心节点其实 sidecar 本身就是 ESC 体系的一部分。以前的 ESB 是“中心转发”现在的 ESC 更像是“中心控制 边缘转发”。这次替换的已经不只是这一套软件且听我道来第一波冲击负载均衡的职责会重新切分在传统 ESB 时代不管应用跑在虚拟机上还是跑在 K8S 里通常都会有这样一层结构应用多副本部署前面挂一个负载均衡器作为统一入口ESB 自己是集群也要挂一层负载均衡链路大概是系统 A - 负载均衡(ESB VIP) - ESB - 负载均衡(B VIP) - 系统 BESC 时代请求会变成系统 A - sidecar A - sidecar B - 系统 B那很多原来靠集中式负载均衡器完成的事情就会被 sidecar 拿走。原因如下sidecar 知道目标服务实例列表sidecar 本身可以做服务实例级的轮询转发sidecar 具备重试、熔断、限流、路由能力也就是说传统东西向负载均衡器的部分职责会被边缘代理吃掉。这不代表负载均衡器会消失只是在在系统间的东西向调用里很多原来由 LB 承担的工作会越来越多地下沉到 sidecar但在南北向入口上LB 仍然会长期存在。第二波冲击网络权限模型变成了网状传统 ESB 时代系统 A 不直接访问系统 B只需要放通到 ESBESB 再放通去访问系统 B。网络关系大致是系统 A - ESB ESB - 系统 B这是一种典型的中心化星型结构特点是网络权限链路短谁能访问谁基本围绕总线来管理到了 ESC 时代情况会变成系统 A - sidecar a - sidecar b - 系统 Bsidecar 和应用之间处于同一资源节点无需网络开通访问权限。如果系统 A 有 5 个实例系统 B 有 10 个实例就需要开通5 * 10 50条访问权限。之前只有5 ESB应用节点数条访问权限。同时为了应用的动态伸缩网络权限得按段开否则应用服务副本增加了新的 IP但网络却没开通请求就没法过来了。第三波冲击K8S 网络模型要跟着改如果应用部署在虚拟机上这件事还相对简单。sidecar 作为代理程序和应用一起部署在同一台主机请求走 underlay 网络比较直观。但到了容器云里问题就变得复杂一些了。传统 ESB 时期K8S 集群内部服务跑在 overlay 网络上即每个服务实例是有 Calico 分配的私网 Pod IP。外部流量要进来通常会经过外部请求 - LB/VIP - Ingress 或 NodePort - 应用 Gateway这是大家很熟悉的一套玩法。到了 ESC注册、治理、寻址、转发这些需要直接地感知到各系统注册上来的服务实例这就要求必须使用 underlay 网络即应用服务要使用真实物理 IP。对于微服务架构应用来说至少入口 Gateway 这部分服务需要使用真实 IP网关后的内部各服务依然可以使用 Calico 的 overlay 网络通信。请求链路变成了外部请求 - 应用gatewaysidecar - 应用gateway- 各服务对于容器云平台来说就会提出新的要求入口网关使用 underlay 能力集群开启双网络平面即 calico macvlan提前规划真实地址段给网关类服务预留可扩展的物理 IP 资源第四波冲击微服务还得有“统一出口”这点很容易被忽略。SpringCloud 的微服务架构里Gateway 默认承担的是入站入口职责。也就是说南向流量先进 Gateway但北向流量往往是内部服务自己直接调外部系统。在传统模式下这么做问题不大。但如果你要让对外交易都纳入 sidecar 的治理链路那事情就变了。因为 sidecar 只在特定入口或特定节点旁边部署出站流量如果绕开它治理就失效了。这就意味着微服务系统得配置统一出入口进出流量必须全部过 Gateway。当然内部调用依然不需要走网关。对新核心架构设计的影响流量调度的变化如果只是一般系统改造前面的影响已经不小了。但如果是新的分布式核心还会涉及到双活建设方式。以前很多方案会考虑通过 DNS 或负载均衡 VIP 来做流量权重分配。比如一个域名对应两个机房的核心入口通过解析权重或流量策略把请求按比例导向不同机房。这套思路在传统中心化入口体系里是成立的。但现在每个机房可能都会部署几十个核心应用的 Gateway 边车外部系统直接和边车的真实 IP 交互。这种情况下为核心应用配置域名完全失去了意义。因为核心系统接收的请求都经过边车分发那双活流量的分发就只能通过边车来控制。所以 ESC 得支持以下能力按机房分流按比例分流同城优先故障时快速切换这意味着以前总线管的是交易转发现在它开始管核心双活流量治理了。多层分流叠加很多人以为双活流量治理就是给两个机房配一个 9:1 或 8:2 的比例。ESC 时代会出现一种新的情况比例叠在比例上。举个栗子假设手机银行本身就是双活部署用户请求已经先按渠道入口规则被分发到两个机房。然后手机银行再通过 ESC 去访问核心系统。请求链路就会出现生产机房用户请求 - 手机银行生产节点 - ESC生产节点 - 90% - 核心生产节点同机房流量 用户请求 - 手机银行生产节点 - ESC生产节点 - 10% - 核心灾备节点跨机房流量灾备机房用户请求 - 手机银行灾备节点 - ESC灾备节点 - 90% - 核心生产节点跨机房流量 用户请求 - 手机银行灾备节点 - ESC灾备节点 - 10% - 核心灾备节点同机房流量可以看到渠道端的流量按机房配比分发后到 ESC 后还得按照核心的双活策略要求再重新分配一次。结语分布式 ESB 的建设不只是简单的国产化替代而是整个数据中心的架构在改变交易流量的控制权从中心总线迁移到了系统边界。控制权下沉后负载均衡、网络权限、容器网络、统一出口、双活调度都会随之改变。作为牛马我们只能去做好技术上的细节迎接分布式时代带来的变化。最后奉上一张全文总结图