生于阿里的“技术中台”，如何在券商行业落地发芽？

“中台”这一词，随着阿里不遗余力的宣传，成为近两年的现象级趋势。不止是互联网行业，非互联网行业机构也在推进中台化，以期快速响应前端用户需求，快速进行创新迭代，其中也包括金融行业。

在互联网化、智能化的浪潮下，金融业发生了许多新变化，其一更加要求个性化场景服务能力，二要求打破原来以产品为中心推动的金融服务，提高迭代和应变能力，其三是在保证性能的基础上，改进架构实现弹性配置，其四是利用智能技术提高生产力。

在5月16日的JRES3.0发布会上，恒生公司总裁刘曙峰告诉雷锋网， 为了满足以上这些需求，金融机构的前进方向也变得更加清晰——一个基础技术平台，在此之上需要有业务共性抽取提炼出来的业务中台，和基于大数据和算法支撑的数据中台。

据雷锋网了解，该发布会由恒生电子联手蚂蚁金服、阿里云共同举办，JRES3.0是分布式服务开发平台，服务对象包括金融产品开发、运维、运营人员等，可提供完整的金融企业级应用开发套件，从而降低业务开发人员技术要求，提升开发效率以及系统稳定性。

值得注意的是，JRES3.0主要面向券商行业，现场也有数十家券商代表出席。 恒生公司研发中心总经理许欣芃告诉雷锋网，比较起来，银行的人力、资金投入都更高，自研技术和架构也更成熟，对ISV的需求不高。而券商则不同，资金、人力等各方面投入都更小，又有2000年到2009年长期重度依赖ISV的历史，所以券商的需求更迫切，案例更多。

在发布会上，兴业证券信息技术部副总经理王伟强受邀进行了一次极为干货的演讲，剖析了证券技术架构变迁的历程，分享了兴业证券的中台架构变革实践、困难和建议。

根据演讲与PPT内容，雷锋网(公众号：雷锋网)进行了不改变原意的编辑：

一、技术架构演变

随着业务范围的不断扩张以及信息化的深入，企业应用架构经历了四个阶段的变迁。

2000年以前，所有证券公司都有自己的开发力量，不管是柜台还是各种应用。那个时候大家要求很低，只要能够交易股票就可以了，所以2000年以前大家基本上都有自己的开发能力，在单体架构中实现所有的业务和逻辑。

2000年开始，随着以恒生为代表的行业IT厂商成长，大家觉得有一棵大树可以抱了，因为自己开发确实很辛苦，成本上也不合适，慢慢都转向大型厂商，采用垂直架构的大型信息化系统。这个过程是所有证券公司自主开发能力慢慢被边缘化、剥夺的过程。

2008年，整个市场发生较大变化，我们和客户的交流中碰到很多个性化问题，那个时候互联网也在发展，个性化应用在恒生这样大的体量中反应不够，当时恒生主要能力都在中后台，所以大智慧等公司崛起。证券公司都在思考如何提高服务客户前端的能力，可以肯定的是，要有自主的能力。2009年开始，兴业证券重新考虑恢复自己的自研力量，SOA架构出来以后，我们认为这是一个比较好的切入点。

2008年之后，互联网快速发展，他们率先碰到了应用的天花板，在技术领域上比券商早很多就意识到了很多解耦和前后台抽象的问题，慢慢形成了新的一种技术架构。2015年微服务架构和中台出现。

这几年的实践来，我们总结了四点技术中台的价值：

• 第一，降低技术复杂度，实现前端业务的快速响应。

• 第二，提供企业级的能力复用，所有颗粒度的服务完全都可以在每一个前端的应用中进行复用，大大降低了很多开发量。

• 第三，打造数字化运营能力，带来服务时效性提升。以前仅仅是运维而已，没有任何个性化东西。

• 第四，带来个人和团队技术能力提升。曾经一段时间每一个证券公司技术人员都很迷茫，纯粹是熟练的技术工人，没有太多的成就感，而这几年中有一些团队就成长起来了。

二、技术中台实践

2008年开始我们做了一个规划，提出SOA的架构建设，我们是行业中最早一批做ESB的，当时做的比较彻底。但是当时行业很多厂商都还是紧耦合单体架构，很难配合我们的推进，所以只是在自己内部的管理系统应用。一直到2011年以后，我们开始做了一些从ESB到后来开源的技术出来以后，引入了更好一些解耦的架构，开始做整个自己的架构标准，开始规划应用域，整个自研那部分东西全面往新的技术架构上进行转型。

这两年整个技术平台也基本上成型了。上图是我们目前的概念图，按照6层架构来做，这也是大家能够看到的所有微服务架构比较标准的东西。目前我们技术中台有两个中坚力量：JRES和lisa。Lisa是自研部分，支持自研业务，比如投顾、办公等，JRES是交易区域里的中台。中台是一个逻辑概念，在这样的架构下会慢慢往两边扩，服务多了以后治理就是问题了，包括前端应用开发速度快了以后，包括部署、性能、容器、监控，两端的事情全部带起来了。

这个架构下形成了两块：第一，自主研发的支撑，就是技术平台和lisa。第二，公共服务的领域。公共服务所有的域可以往下分成目前四个域。我们公司这两年一直在推集团化管理，要整合很多子公司的协同、办公的东西，所以都是通过技术中台去对接他们，这样整个速度会快一点。

交易服务类主要是以JRES为主，我们认为没有必要花太多的时间，抱好恒生这棵大树就可以，所有交易相关的尽量都是在JRES上面做开发，与lisa严格区分开。

上图是lisa的结构，目前还不是完全的微服务的架构，接入、路由、传输模块这些传统的东西做好了，而治理还在不断的完善，包括容器化。这个架构主要还是为了两个考虑：第一，要兼容以前老系统，减少迁移成本。第二，我们要把通讯层和逻辑层做强，因为其他应用层好办一点。

上图是JRES的简单架构，我们目前用到的基本上是这些模块，用来支撑整个自主研发的交易终端和给客户提供交易服务方面的内容。

我们有两个实际案例，SmartTrader和7×24小时基金申购。

总结应用效果，经过将近9年的实践，现在整个技术中台架构已经基本上成型了，而且能够在账户、产品、资讯、订单一系列业务运营商做快速的开发和集成，我们每天对中台请求量已经到了千万级。

三、面临的挑战

微服务的中台架构是不同的方法论，也没有谁对谁错，只不过业务发展这个时候为了快速、为了便捷，应用了这样一种新的方法论，对原来的单体架构来讲，对所有的技术人员都是一种挑战。从整个系统的设计阶段到开发阶段、到发布阶段、运维阶段都有一些不同的要求。

以前一组开发人员在自己脑子里就形成闭环，现在所有事情不可能在体系中闭环，一定要和不同的系统、不同的中台技术平台打交道，所以对他们整个理念上有很大的挑战。发布阶段也是一样，中台快速发布，而且需要大量的复制，对业务人员带来了挑战，包括自动化的运维、容器化的部署等。

从单体应用到微服务过渡，挑战的是整个IT体系。性能和可用性是现在我们碰到最大的问题，因为现在整个技术中台成为整个技术系统的一个腰，整个中台会越来越臃肿和庞大，在这个过程里，治理和性能以及可用性是我们重点关注的，这一段如果不可靠的话整个业务连续性都得不到保障，这是我们认为中台应用普及以后要特别关注的一个点。

另外是运维监控，微服务架构带来整个运维复杂度的提升，开发人员的思维方式和人的沟通和团队之间的协同也会有很大的改变，团队架构需要按照新的组织架构来进行重新做。

四、对未来的思考

对未来我们也想和恒生提出几个建议：第一，形成开放的接入标准。第二，形成协作共享。JRES和lisa算是同构的技术平台，在这上面很多共性的东西，像服务治理类、监控、部署运维有技术共性的东西，我们是可以一起来进行推动的。第三，推动行业进步。恒生现在是行业的领头羊，应该有更多的职责推动行业的进步，通过开放形成生态来变革整个行业，不要让整个证券行业的技术和形象那么老土。

。