从“中间件”到“中台”

1、从中间件到中台技术架构与应用架构的演进随着金融科技的快速发展，中间件逐渐不作为一个独立的技术概念被提起，而 是在应用架构中扮演更重要的角色,也就是现在普遍应用的"中台"，但无论是 "技术中台"还是"业务中台"，都离不开中间件技术的发展。在中间件技术发展 的同时，企业应用系统越来越多、交互越来越复杂,中间件需要解决的问题慢 慢地从"提升单个应用系统的开发效率"上升到"提升企业级不同应用系统的整 体交互效率"，从”单个应用系统的开发框架"上升到"企业级应用的连接平台",

2、 开始承载公共业务能力，助力企业搭建"业务中台"。"业务中台"是另一种意义 上的"中间件"，它屏蔽的不是技术复杂度，而是将公共服务能力进行抽象、实 现、加强，通过组合多个独立的、明确的公共服务，把业务实现变得更为简单。 传统中间件解决了业务实现的技术复杂性，而业务中台则解决了业务实现的 "业务复杂性"。证券行业的技术和业努特点证券行业的技术特点是瞬时并发大、系统错误容忍度低、系统运行压力大，且 专业客户对系统在大并发下的处理性能要求高。因此，证券信息系统的复杂度 和技术难度甚至超过了银行业和互联网业，在满足高并发的

3、前提下，还需要保 证数据的强一致性，并且瞬间即逝的行情让投资者对系统的连续性运行要求非 常高，错误容忍度极低。所以，证券行业核心系统需要有非常强大的"中间件"， 或者说"技术中台"，来保证并发性、数据强一致性、弹性扩容等要求。在业务范围上，证券业务涵盖互联网金融、财富管理、专业机构交易、托管服 务、自营投资、投资银行等，业务覆盖面广、有些业务之间又有或多或少的共 性，比如互联网金融和财富管理在面向客户的营销服务方面可能都需要营销活 动管理、用户积分等。专业机构交易和自营投资都需要策略交易和算法执行的 支持,托管服务、专业机构和投资银行可能服务于同一个客户

4、等，这些公共能 力都可以进行抽取实现复用。近年来证券行业的创新层出不穷，从股转改革、 到创业板注册制等,随着经纪业务竞争加剧、佣金下滑,券商的财富管理转型 也迫在眉睫，券商自身的业务也需要在不断地创新中谋求突破。在新的技术和业务背景下，我们不仅需要一个"技术中间件"来满足特定业务的 快速实现，也需要将业务能力逬行封装，形成"业务中台"，屏蔽公共能力的复 杂性，为前端业务提供快速实现能力。招商证券的中间件探索招商证券一直在"中间件"和"中台"领域不断探索。跟多数券商一样，早期建设 的核心业务系统技术架构都是基于传统单

5、体、高性能服务器的事务管理中间件, 虽然此类中间件在事务保障上表现优秀，但弹性扩容能力、分布式部署能力则 显得不足。并且，早期的后台交易系统多是依赖外部采购，不同实施商的技术 架构、对外服务协议、会话管理方式等各不相同，给前端应用带来了很大的复 杂度。从2008年开始，我们就基于SOA的理念，探索通过可配置的Web Service屏蔽后台的复杂协议、为前端提供一致的后端服务,极大地提高了前端对接后 台的效率。但当时SOA更多的是实现对后端协议的转化,较少涉及实际业务 逻辑组装处理，是一个比较"薄"的中间层，转化的协议也相对单一。后来,商 业SOA中间件开始岀现，比如基于MQ

6、的IBM ESB ,能高效地在多种协议之 间互相转化，让服务使用方可以按照自身支持的协议接入，进一步给前端服务 带来便利。但ESB仍是一个单体服务，解决不了"转化"层的弹性扩展问题，以 及实际支撑SOA接口服务的业务逻辑层的有效解耦。随着券商业务创新要求增多，对信息系统快速更新迭代的能力要求也不断提高, 而传统将所有应用集成在一起的模式限制了快速升级的能力，同时也导致本身 可以复用的能力不得不重复开发。2015年前后，"微服务"架构的兴起为解决传 统中间件架构的短板提供了新的技术途径，而技术中间件作为系统硏发的核心 能力,需要有足够的自主掌控力度才能满足

7、稳定性要求极高的证券行业应用要 求。因此，我们开始自主硏发"微服务"架构，并在此基础上向客户端开发框架、通 讯接入等进行前后端延展，逐步形成了包括前端应用、通信接入、业务服务、 数据库访问等全栈技术框架(XFramework )。XFramework让SOA理念不 仅停留在了接口层,更涉及基础技术架构和业务实现方式，对应用架构和技术 架构都是一次新的变化。在前端框架方面，开发了"Athena"，支持移动端、Web 端的快速开发，并能与微服务框架、数据库访问等无缝集成；在后台服务实现 方面，开发了"Zeus”微服务框架，将后台微服务实现的技术复杂

8、度进行屏廠， 采用高性能RPC、异步消息等技术,实现轻量级、扁平化框架，支持服务自动 注册、自动发现、远程调用、熔断等特性,以去中心化的业务服务独立进程运 行；在接入层面，开发了"Hermes"，采用公平调度、热更新、监督树容错模型、 超轻量进程等技术实现高性能、高可用接入层。这些服务都在不同层次解决了 技术复杂度，让业务开发更加快捷。自投入使用以来，超过80%的自硏系统利 用XFramework实现了系统的快速交付,涵盖机构服务、托管业务、交易柜 面、风控合规等证券业务领域。中间件、开发框架或技术中台有效提升了开发效率，但随着系统越来越多、开 发框架的迭代升级也越来越频繁

9、，框架运维压力逐渐增大。因此，我们开始进 步思考，有没有可能把环境管理、部署、运维等技术细节也都"中台化"起来， 让开发人员只关注业务逻辑的代码实现呢？于是我们又开始从API服务领域， 探索技术"托管"服务，让开发者可以把自己的业务代码直接部署到内部的公共 托管平台上，从技术框架的部署到运维都不需要关心，这可能才是真正的"中间 件",或者说是"技术中台"。在"中台"技术架构不断优化的同时，应用架构也同样面临着解耦和重构。将所 有业务逻辑实现在单一应用上的模式显然已经不能满足灵活多变的业务诉求，

10、更不能满足不同应用系统对公共服务的复用，造成相似功能的重复开发。因此， 应用架构的"服务化"治理也是我们的工作重点，需要和技术架构的演进共同推 进。服务治理的第一步是将现有应用系统进行功能拆解，识别出需要提取的公 共业务能力；然后是把公共业务能力逬行服务化改造,使其在服务协议、服务 提供方式、服务标准、技术架构等方面更强壮、更具有通用性,并将原应用系 统进行对接改造；最后，还需要将公共服务进行有效监控，跟踪服务的使用频 率，维护服务生命周期，及时评估服务的有效性和更新优化需要。目前,我们已经进入攻坚阶段的新一代核心业务系统，不仅是对核心交易业务 技术中台架构的重构，更是对应

11、用架构的全面梳理和优化，将原本独立的多个 交易系统的功能模块逬行重新分析，抽取出共同的账户、资金、用户等模块， 并把交易业务按需要进行整合或分割，让每个交易节点都更专注交易逻辑，让 新交易业务能复用更多交易逻辑之外的公共服务能力。然而，应用服务化治理 可能比中间件架构的升级更复杂，因为其不仅仅是将应用进行拆解和对接，其 中还可能涉及运营流程的改造、甚至业务部门职责的重新定位。"业务中台"的 有效运作需要与组织架构紧密结合才能发挥出最大价值。中间件的未来不管是解决通讯层或事务处理层的底层中间件，还是解决公共业务问题的"中 台"，都在持续经历着技术实现和架构定位的演进。从国内外最新技术发展动态 来看，企业级应用中间件技术的下一个趋势应该是Serverless（无服务器计算）。 Serverless被Gartner称为最有潜力的云计算技术发展方向，并被赋予是必然 性的发展趋势。它从底层开始变革计算资源的形态,为软件架构设计与应用服 务部署带来了新的设计思路，给用户带来很具体的商业价值，包括降低运维需 求、降低运营成本、缩短迭代周期和上线时间等。 靠近业务前端一侧的业务服务层非常适合Serverless的落地，我们期望通过 这层"中台"建设，让开