​案例丨​从“中间件”到“中台”——技术架构与应用架构的演进

文 / 招商证券股份有限公司信息技术中心  郑继翔 赵江涛 赖伟威 戴子毅

招商证券股份有限公司信息技术中心总经理    郑继翔

随着金融科技的快速发展，中间件逐渐不作为一个独立的技术概念被提起，而是在应用架构中扮演更重要的角色，也就是现在普遍应用的“中台”，但无论是“技术中台”还是“业务中台”，都离不开中间件技术的发展。在中间件技术发展的同时，企业应用系统越来越多、交互越来越复杂，中间件需要解决的问题慢慢地从“提升单个应用系统的开发效率”上升到“提升企业级不同应用系统的整体交互效率”，从“单个应用系统的开发框架”上升到“企业级应用的连接平台”，开始承载公共业务能力，助力企业搭建“业务中台”。“业务中台”是另一种意义上的“中间件”，它屏蔽的不是技术复杂度，而是将公共服务能力进行抽象、实现、加强，通过组合多个独立的、明确的公共服务，把业务实现变得更为简单。传统中间件解决了业务实现的技术复杂性，而业务中台则解决了业务实现的“业务复杂性”。

证券行业的技术和业务特点

证券行业的技术特点是瞬时并发大、系统错误容忍度低、系统运行压力大，且专业客户对系统在大并发下的处理性能要求高。因此，证券信息系统的复杂度和技术难度甚至超过了银行业和互联网业，在满足高并发的前提下，还需要保证数据的强一致性，并且瞬间即逝的行情让投资者对系统的连续性运行要求非常高，错误容忍度极低。所以，证券行业核心系统需要有非常强大的“中间件”，或者说“技术中台”，来保证并发性、数据强一致性、弹性扩容等要求。

在业务范围上，证券业务涵盖互联网金融、财富管理、专业机构交易、托管服务、自营投资、投资银行等，业务覆盖面广、有些业务之间又有或多或少的共性，比如互联网金融和财富管理在面向客户的营销服务方面可能都需要营销活动管理、用户积分等。专业机构交易和自营投资都需要策略交易和算法执行的支持，托管服务、专业机构和投资银行可能服务于同一个客户等，这些公共能力都可以进行抽取实现复用。近年来证券行业的创新层出不穷，从股转改革、到创业板注册制等，随着经纪业务竞争加剧、佣金下滑，券商的财富管理转型也迫在眉睫，券商自身的业务也需要在不断地创新中谋求突破。

在新的技术和业务背景下，我们不仅需要一个“技术中间件”来满足特定业务的快速实现，也需要将业务能力进行封装，形成“业务中台”，屏蔽公共能力的复杂性，为前端业务提供快速实现能力。

招商证券的中间件探索

招商证券一直在“中间件”和“中台”领域不断探索。跟多数券商一样，早期建设的核心业务系统技术架构都是基于传统单体、高性能服务器的事务管理中间件，虽然此类中间件在事务保障上表现优秀，但弹性扩容能力、分布式部署能力则显得不足。并且，早期的后台交易系统多是依赖外部采购，不同实施商的技术架构、对外服务协议、会话管理方式等各不相同，给前端应用带来了很大的复杂度。

从2008年开始，我们就基于SOA的理念，探索通过可配置的Web  Service屏蔽后台的复杂协议、为前端提供一致的后端服务，极大地提高了前端对接后台的效率。但当时SOA更多的是实现对后端协议的转化，较少涉及实际业务逻辑组装处理，是一个比较“薄”的中间层，转化的协议也相对单一。后来，商业SOA中间件开始出现，比如基于MQ的IBM ESB，能高效地在多种协议之间互相转化，让服务使用方可以按照自身支持的协议接入，进一步给前端服务带来便利。但ESB仍是一个单体服务，解决不了“转化”层的弹性扩展问题，以及实际支撑SOA接口服务的业务逻辑层的有效解耦。

随着券商业务创新要求增多，对信息系统快速更新迭代的能力要求也不断提高，而传统将所有应用集成在一起的模式限制了快速升级的能力，同时也导致本身可以复用的能力不得不重复开发。2015年前后，“微服务”架构的兴起为解决传统中间件架构的短板提供了新的技术途径，而技术中间件作为系统研发的核心能力，需要有足够的自主掌控力度才能满足稳定性要求极高的证券行业应用要求。

因此，我们开始自主研发“微服务”架构，并在此基础上向客户端开发框架、通讯接入等进行前后端延展，逐步形成了包括前端应用、通信接入、业务服务、数据库访问等全栈技术框架（XFramework）。XFramework让SOA理念不仅停留在了接口层，更涉及基础技术架构和业务实现方式，对应用架构和技术架构都是一次新的变化。在前端框架方面，开发了“Athena”，支持移动端、Web端的快速开发，并能与微服务框架、数据库访问等无缝集成；在后台服务实现方面，开发了“Zeus”微服务框架，将后台微服务实现的技术复杂度进行屏蔽，采用高性能RPC、异步消息等技术，实现轻量级、扁平化框架，支持服务自动注册、自动发现、远程调用、熔断等特性，以去中心化的业务服务独立进程运行；在接入层面，开发了“Hermes”，采用公平调度、热更新、监督树容错模型、超轻量进程等技术实现高性能、高可用接入层。这些服务都在不同层次解决了技术复杂度，让业务开发更加快捷。自投入使用以来，超过80%的自研系统利用XFramework实现了系统的快速交付，涵盖机构服务、托管业务、交易柜面、风控合规等证券业务领域。

中间件、开发框架或技术中台有效提升了开发效率，但随着系统越来越多、开发框架的迭代升级也越来越频繁，框架运维压力逐渐增大。因此，我们开始进一步思考，有没有可能把环境管理、部署、运维等技术细节也都“中台化”起来，让开发人员只关注业务逻辑的代码实现呢？于是我们又开始从API服务领域，探索技术“托管”服务，让开发者可以把自己的业务代码直接部署到内部的公共托管平台上，从技术框架的部署到运维都不需要关心，这可能才是真正的“中间件”，或者说是“技术中台”。

在“中台”技术架构不断优化的同时，应用架构也同样面临着解耦和重构。将所有业务逻辑实现在单一应用上的模式显然已经不能满足灵活多变的业务诉求，更不能满足不同应用系统对公共服务的复用，造成相似功能的重复开发。因此，应用架构的“服务化”治理也是我们的工作重点，需要和技术架构的演进共同推进。服务治理的第一步是将现有应用系统进行功能拆解，识别出需要提取的公共业务能力；然后是把公共业务能力进行服务化改造，使其在服务协议、服务提供方式、服务标准、技术架构等方面更强壮、更具有通用性，并将原应用系统进行对接改造；最后，还需要将公共服务进行有效监控，跟踪服务的使用频率，维护服务生命周期，及时评估服务的有效性和更新优化需要。

目前，我们已经进入攻坚阶段的新一代核心业务系统，不仅是对核心交易业务技术中台架构的重构，更是对应用架构的全面梳理和优化，将原本独立的多个交易系统的功能模块进行重新分析，抽取出共同的账户、资金、用户等模块，并把交易业务按需要进行整合或分割，让每个交易节点都更专注交易逻辑，让新交易业务能复用更多交易逻辑之外的公共服务能力。然而，应用服务化治理可能比中间件架构的升级更复杂，因为其不仅仅是将应用进行拆解和对接，其中还可能涉及运营流程的改造、甚至业务部门职责的重新定位。“业务中台”的有效运作需要与组织架构紧密结合才能发挥出最大价值。

中间件的未来

不管是解决通讯层或事务处理层的底层中间件，还是解决公共业务问题的“中台”，都在持续经历着技术实现和架构定位的演进。从国内外最新技术发展动态来看，企业级应用中间件技术的下一个趋势应该是Serverless（无服务器计算）。Serverless被Gartner称为最有潜力的云计算技术发展方向，并被赋予是必然性的发展趋势。它从底层开始变革计算资源的形态，为软件架构设计与应用服务部署带来了新的设计思路，给用户带来很具体的商业价值，包括降低运维需求、降低运营成本、缩短迭代周期和上线时间等。

靠近业务前端一侧的业务服务层非常适合Serverless的落地，我们期望通过这层“中台”建设，让开发团队尽可能地只编写业务代码，并发布到“中台”之后即可完成对业务的快速交付。其后续的运行、监控都托管到“中台”上，依靠强大的底层数据、技术、运维等能力，让开发团队实现对业务的快速开发和交付。

总之，只有坚持推动技术服务业务、业务反馈技术的良性循环，才是一个有生命力的“中间件”或“中台”应该不断探索和精进的方向。

往期精选：

（点击查看精彩内容）

关于仿冒我刊收费的声明

我刊自创刊以来，从未向投稿人收取过任何费用。任何以刊发文章为名向投稿人收取费用的行为，均属于对投稿人的欺诈行为。

我刊官网地址为 www.fcmag.com.cn。

我刊投稿邮箱为 [e-mail]。

对于仿冒我刊网站、网页的违法行为，我社将追究其侵权责任，以维护我社和投稿人的合法权益。仿冒网站、网页举报电话：[phone]

《金融电子化》新媒体部：主任 / 邝源  编辑 / 潘婧 傅甜甜