文/微众银行基础科技产品部?卢道和?陈广胜
众所周知，中间件基本上都是有状态的应用，在整个IT架构中承担了非常核心的职责，对于IO、性能、稳定性的要求都非常高，所以一直以来中间件的容量管理、交付、运维、容灾都是业界难题。
云原生的出现，为中间件的探索与实践带来了一种新的建设思路和开发模式。从技术特征来看，云原生所具备的极致弹性能力、服务自治、故障自愈能力、大规模可复制能力，极大地发挥了云的优势，加速了数字基础设施升级的进程。然而，云原生技术的落地门槛非常高。经过市场几年的炒作和洗礼，技术也经历了蛰伏期，云原生出现了新形态，将成为驱动业务增长的重要引擎，迎来规模化落地的进程。
微众银行基础科技产品部总经理卢道
应“云”而生，生生不息
作为国内最早成立的数字银行，微众银行依托云的技术优势，结合银行的业务特点，设计并实践了基于XML（X86服务器、MySql、Linux）的金融级分布式架构，该架构具有低成本、高可用性、高弹性、高规范性、高性能、低风险的特点，支持了亿级用户量、日均亿级交易量。微众银行在中间件领域探索出了一条独具特色的架构实践之路。
从应用的视角来看，微众银行的服务演进大致分为以下几个阶段：分布式服务、多活服务、容器化服务、云原生服务。
分布式服务，作为我们的设计初衷，也是为了满足业务增长需要。业务应用需要从传统的集中式单体应用开发模式转向分布式开发模式，改造的过程需要接入分布式中间件及服务治理体系。
首先应用系统需要按照职能、业务功能等维度进行拆分，形成了子系统，按业务类型划分出不同的服务，根据服务类型进行同步异步区分。当子系统作为服务提供方时，需要定义自己提供哪些服务，作为服务消费方时，需要定义消费哪些服务。当子系统作为事件订阅方时，需要定义自己需要订阅哪些事件，作为事件发布方时，需要发布哪些事件。当作为服务提供方和事件订阅方时，子系统也需要定义部署在哪些单元化DCN里面，方便中间件对服务消费方和事件发布方进行动态化路由选择。这些调用关系及部署信息都会登记注册到服务治理系统里面进行管控。
服务形态的演变，必然伴随着中间件架构的演进，在这个服务模型的定义下，微众银行中间件的演进经历了几个阶段：消息总线1.0、消息总线2.0、EventMesh、ServiceMesh。
消息总线1.0版本，服务和事件均以消息主题（topic）的形式存在，提供了同步RPC（request/reply）和异步MQ（pub/sub）的通信能力，二者都是基于MQ实现。对于应用来说，只需要引入一套开发框架即可，给开发带来了便利。整个分布式应用架构引入了单元化DCN设计，中间件需要动态地将交易路由到对应的DCN里面。由于系统组件与应用松耦合，消费者出现任何问题（升级停服、宕机、不可用等），都不会影响生产者的业务。遇到突发的海量消息压力，消费者还可以持续平稳且高效地处理消息，系统可用性效率高。消息总线具备持久化机制，系统发生故障时不会丢失消息。
1.0版本中间件虽然很好地解决了海量分布式服务的通信问题，但在实际生产运营过程中，也发现了一些问题。中间件主节点硬件发生故障时，会触发HA切换，恢复过程会有几十秒的中断；同时，SAN存储故障也会导致中间件短暂不可用。另外由于中间件跨节点消息通过Bridge转发，网络异常的情况会导致Bridge不稳定。这些因素都可能直接导致一组或多组DCN应用的短暂不可用，在早期还没有做多活架构的情况下，这样的中断在金融交易场景，尤其交易量大的时段是不能接受的。在运维便利性上，由于业务的扩张带来DCN的增多以及调用关系的复杂，使得中间件的扩容以及bridge路由策略的配置变得更加复杂，尤其是在DCN和IDC切换的时候，运维人员对配置工具的准确性和稳定性的依赖程度很高，毫无疑问这些都不利于生产的稳定运营。
随着业务发展的突飞猛进，对中间件提出的要求越来越高，这些问题的优化刻不容缓。更重要的是，由于中间件核心是闭源的，即便发现了问题，也无法进行修改和改进，这更加坚定了自主研发的决心。早在年，开源中间件技术方兴未艾，我们就深度参与到了开源社区，并基于开源版本深度定制开发了中间件2.0版本。
2.0版本中将同步异步区分开，同步采用“Active-Active”+Master模式，异步采用“Active-Active”+“Master-Slave”模式，全网无单点。该架构完全自主设计开发，近30万行代码，累计处理了万亿级消息。机器故障及断网情况下，最快秒级、最慢1分钟自动隔离；TPS交易场景下，耗时略有增加，在途交易失败小于笔，成功率几乎不变。此外，还实现了在线流量治理的工具自动化，变更操作都可以让应用无感，大大降低生产故障风险和操作风险，保障业务稳定。
为了实现服务多活，进一步提升架构可用性和可靠性，在单IDC集群高可靠的基础上，消息总线继续探索支持多中心多活能力。应用可在多中心灵活部署，当需要进行IDC切换时，中间件可以自动将交易流量在多中心之间进行调拨，不需要对应用进行人为干预。中间件多活能力的上线，盘活了资源，使原先备节点可以参与支撑交易流量，大大提升了资源利用率。
生于“云”、长于“云”
微服务架构下容器技术的兴起，进一步提高了部署效率，具备资源弹性和服务化能力的云原生技术逐渐成为服务平台的基础。金融业务在安全稳定的核心原则下，容器技术解决了服务及中间件自身的运维、交付问题，帮助使用者屏蔽了底层的运行环境差异，降低了运维复杂度。使用者通过标准化的API就可以完成对中间件的调用，其好处在于让中间件逐渐基础设施化，开发者可以更