分布式交易系统设计(五)

论坛 期权论坛 期权     
期权匿名问答   2023-1-25 21:14   8097   0
前4篇,主要是对行业前辈的《交易系统更新与跨越》书籍的学习记录和摘录。按笔者文章中所述,好多对交易系统的技术调研和分析应该是在2009年左右,甚至更前,那10多年过去了,笔者提到的交易系统核心技术点有没有变化呢?答案是:没有。不管是横空出世的CTP柜台,还是近几年出现的分布式系统,其实沿用的最底层的核心技术无非就是:消息总线、组播通讯、多活灾备、内存数据库等等。
但我们一定要清醒的认识到,在金融这个严肃的领域且以业务为核心的领域,我们不能偏离业务而空谈高精尖的技术,这也是为什么前辈十多年提出的技术方向,随着深交所第5代、上交所流式报盘系统上线、以及金融行业软件厂商的参与,这几年才开始向着落地的方向前进。
所以分布式在金融行业,最基本的业务出发点之一就是:解耦。
技术系统的专业化发展就是要让专业的工作由专业的系统来完成。
证券交易的核心解耦也一直是证券交易技术发展的重要关注点,证券核心交易系统从诞生开始就一直在走解耦的道路。综合目前所做的各种解耦工作来看,一般都是因为某个业务或功能需求的发展推动的,都是由于这些需求的实现多半不再可以简单的与原有核心功能合并实现,从而不得不进行解耦,分离出新的系统或子系统。
解耦的方式主要有横向和纵向两种:
横向解耦是指将单个业务指令分解成多个环节,例如从简单的C/S架构变成多层架构就是将业务实现和通讯层进行了拆分,可以说是证券交易系统的第一次解耦。网上交易等复杂终端的出现是第二次横向解耦的产物,其目的是让终端承载更多的业务指令预处理和业务结果的综合整理,为投资者提供更快、更好的服务。
而纵向解耦则是指将业务进行分类,按照一定的原则将某一类或某几类相关的业务组成一个集合与原有业务进行分离形成新的系统或子系统。例如CRM等系统的出现就是纵向业务解耦的一种场景;账户业务的分离则是集中交易后的又一次旗帜鲜明的业务纵向解耦。随着业务的发展横向解耦产生了系统的小核心大外延,而纵向解耦推动核心业务实现的高内聚和松耦合。
从上述业务解耦的发展过程我们一般认为系统解耦的推动力是业务的发展,其最终实现则依赖合适的技术引领。
下面整理几个金融行业关于分布式交易系统的成功案例。
案例1:某证券公司新一代信创分布式核心交易系统

分布式+信创,属于一步到位型。
新一代信创分布式核心交易系统将交易、清算、账户解耦,分别建设了分布式低延时交易平台、全业务集中清算平台、账户平台,并于2022年8月完成了公司全部1500万经纪业务客户的整体切换上线,首次实现证券行业核心交易系统千万级客户在信创数据库、信创中间件、信创交换机的上线投产。系统从五个方面进行了创新探索,有多个“首家”的纪录。
其一,是行业首家在技术框架上实现了交易、账户、清算几大业务模块相分离的券商。新一代信创分布式低延时交易平台建立起了具有前瞻性的证券核心交易系统IT架构,可以更好地支持公司创新业务的发展。
其二,是首家将低延时技术应用到超大规模证券公司核心交易系统的券商。该系统基于信创高可靠低延时中间件,建设了分布式低延时交易平台,提升了系统效率,可满足现代金融核心业务系统对高可用、高并发、低时延、水平扩展等特性的要求。
其三,首创的异构交易系统备份机制,解决了长期困扰行业异构备份难题。据介绍,本次系统建设中,实现了新一代信创分布式核心交易系统与传统集中交易系统异构备份机制,可在2分钟内完成无感回切,为行业核心交易系统业务连续性能力的提升提供了新的解决机制。
其四,成功探索出超大规模证券公司核心交易系统上线切换切实可行的实施路径。按照分系统客户级的灰度上线发布机制,通过选取部分典型客户在生产系统中进行充分的业务验证后,才逐步实施整体切换,成为行业首家实现新一代信创分布式核心交易系统成功上线的券商。
其五,是行业打造证券核心交易系统信创示范工程的一项成功实践案例,进一步提高了行业核心技术系统的抗风险能力。
案例2:某证券公司“分布式核心交易系统解耦实践”

证券公司的集中交易系统当之无愧地成为证券交易的核心系统,其业务规模和处理能力也都发展到了极致,然而业务发展不会止步,对系统的要求也不会停止,系统解耦还在路上。尤其是机构业务的蓬勃发展使得当前核心交易系统面临性能、容量、监管、营运、运维等诸多更高的要求。其根本原因是核心交易系统所服务的各个业务领域都有了较大的成长,需要重新定义和规划,解耦方式也不仅仅局限于横向和纵向,往往会是一个综合的方案
以性能为例,投资者对交易性能的要求一直是证券交易不懈的追求,现阶段整个链路时延已进入微秒级的争夺,传统集中交易的TCP通讯和传统数据库技术基础决定了其性能难以达到这个量级,再加上集中交易所综合的业务品类和控制要求也使得业务指令需要穿过层层逻辑判断才能达成业务目标。
一般情况下,只有竞价业务才会有性能要求,非竞价业务的性能要求则相对要弱一些,但传统集中交易的各种交易功能实现是紧耦合的。
因此,如果要使用新技术提升性能,就可能会同时提升了多种业务性能,显然不够经济,而且会因为链路上的功能繁多导致性能提升的空间有限。
所以我们要将传统的交易领域划分成竞价交易领域和非竞价交易领域,然后针对竞价交易领域进行专业的性能优化。
同时,鉴于机构客户的资产和交易特点,其单一账号往往资产规模较大,竞价交易频率较高,多个同类产品叠加后的交易峰值有可能会达到每秒几十万笔的情况。传统集中交易面对这样的脉冲就会产生阻塞,甚至会因为紧耦合设计而蔓延到其他业务处理功能上。
竞价交易领域与非竞价交易领域充分解耦后,不但可以有效隔断阻塞的蔓延,还会因为性能好和弹性扩容等能力从根本上减少阻塞的发生。
营运和风控管理领域亦如此,随着业务品类的增加,营运和风控的需求与日俱增,必须通过对业务的价值链和操作管理进行多层次的解耦和标准化才能做好与之匹配的业务设计。
例如竞价业务与综合业务在营运管理上就有着较大的差距,表现在权限和费用等实现上也有着非常大的区别。因此这部分营运管理可以再解耦成竞价和综业的营运管理,这也是使用高内聚的方法来进行解耦的思想体现。以费用为例,竞价业务的费用主要是佣金、印花税、过户费,种类少,算法也很稳定。
而基金的认购、申赎和分拆、要约收购、大宗交易、回购等综合业务的费率品类繁多,算法也不尽一致,会因为业务发展有较大变化,甚至不同市场的要求还有很大区别。
传统集中交易将所有品类计费模型合并在一个计费模块中实现的设计显然已不太能适应现有业务的发展。因此营运管理的业务领域也会在计费方面分成竞价计费和综业计费两类,甚至更多类的业务模型,否则频繁的修改会导致系统的不稳定,复杂的设置也会给营运管理带来很多不必要的麻烦。
解耦后,竞价业务的费用实现无需考虑综合业务的各种特点和场景,数据结构规整,业务实现稳定;而综合业务的权限和费用则可以非常灵活的满足各类需求,无需顾忌对竞价业务影响。
同样,业务权限、适当性、统计分析等营运和事前、事中、事后的风控管理等都应该遵循业务的发展而进行适当的解耦,以实现各个专业领域的专业化服务。



来源:金融电子化:业务解耦思路之一

如图,很多券商同行在积极探索的业务解耦思路之一,其设计驱动力显然都来自证券业务领域模型的细分和发展。实现后营运、运维、风控等管理业务领域不再与核心交易领域紧耦合,而是变成一个可以适当打开的外壳来支撑核心交易,这个变化是业务的横向解耦,可以将不需要的业务处理从链路中剥离掉。
同时管理业务领域和核心交易领域内部也进行了解耦,这个变化就是按照业务类型进行了纵向解耦。两者结合就可以达到如下效果:

  • 一是对性能要求高的投资终端可以直达引擎,交易链路更简洁。
  • 二是核心交易领域从传统交易中剥离出来后,交易业务的实现不再与营运、风控、运维等管理业务绑定,核心交易执行时所占用资源也将减少。
  • 三是竞价和综业引擎独立,综业发展的时候可以保持竞价稳定,竞价发展的时候修改内容少,投入少,风险可控。
  • 四是各类管理业务适当解耦后通过明确的接口进行交互,可独立部署,便于弹性扩容。
至此,证券交易业务领域分解成了身轻如燕、固若金汤的竞价业务领域和多个身手敏捷、百花齐放的其他业务领域。当前一段时间内,该模型将驱动证券核心交易系统的进一步解耦。
业务领域解耦后,自然就要驱动技术进行实现。虽然事件驱动、观察者、责任链等设计模式和面向接口的编程方式仍然是系统解耦的开发技术基础,但原有基于传统数据库的集中交易,其各方面的能力受制于数据库、小机、TCP通讯等技术的限制,已经很难有效满足当下先进业务功能的迫切要求。
而新一代分布式架构采用的无锁队列、零拷贝、流水线、RDMA、可靠组播等底层技术将业务处理和通讯时延都降低到了微秒级,成功突破了传统业务处理毫秒级的性能瓶颈。
于是新一代分布式证券交易核心系统应运而生,承接了当下的技术发展使命,开始引领证券交易系统的解耦之路。
过往的经验告诉我们(PS:这一点我有非常非常深的体会,我先后经历了两个团队都倡导分布式交易团队设计,但最终都没有享受到分布式系统的好处,却带来了部署难、运维难、出问题后排查难、代码分散导致团队新人无从下手的局面,所以我们千万别局限于谈技术的好与不好,而一定要把技术合理的应用到业务上,才能解决了真正的核心问题后,而不带来新的灾难,那才是完美的目标。):

  • 没有低延时,解耦后的系统应用将会更加冗长和缓慢,随之而来的就是性能瓶颈和阻塞蔓延;
  • 没有高可用,解耦后的系统就会单薄而脆弱,随之而来的就是不稳定和难运维。
这两个技术特点是分布式技术引领系统解耦的关键技术基础,在对业务逻辑分析透彻的前提下,这两项技术的灵活运用可以使得系统解耦游刃有余。
经过多年的实践和探索,某券商选择了以低延时为核心基础的分布式高速消息总线为技术架构,其优秀的高可用特性在现有可选的消息总线中也无出其右者。
以报盘集群为例,在长期的系统运行管理工作中,深入剖析报盘运维痛点,借鉴沪深证券交易所的成熟经验,运用分布式技术的解耦特性,先将报盘部署成竞价和综业两类平台,再将竞价类的报盘按交易量进行分组,每组2~3个报盘通道形成集群,然后将综业类的报盘合并成另一组集群,终于完成了多年的愿望,极大的降低了报盘运维的复杂度,并收获了一定的业务效益。
以图2为例,报盘通道数从8个减少到6个,而且原有证券席位数量越大,可以节约的席位和通道数量就越多;报盘有效连接数从16条减少到6条,降低了应用程序监控和网络管理的复杂度;实现了报盘的热备高可用,主报盘应用服务异常后可以零丢失、无感知的自动切换到备用服务上,无需人工判断和操作;实现了通道的负载均衡,同一集群的报盘通道所承载的报盘压力是均衡的,无需根据业务量波动而人工调配;每组集群的通道数量可以根据实际需要简单的增减,运维方便快捷。



来源:金融电子化:报盘集群化

上述方案在提升报盘运维能力的同时,还实现了单个股东账号报盘容量上线的突破,客户席位与报盘通道的解耦也使得内部账号迁移时无需顾忌报盘席位的修改。并且由于完成了竞价和综业的报盘解耦,两大类业务之间的报盘再无影响,业务功能有效内聚,真正实现了竞价的稳态和综业的敏态。
因此,报盘集群应用是一次非常成功的解耦实践,是高内聚、低耦合设计思想的典型应用案例。实现集群后,竞价业务报盘集群侧重多分组均摊交易通道保障安全稳定、支持弹性扩容;综合业务报盘集群则只需要共享一组交易通道可以节约资源,并与竞价隔离支持业务的敏捷开发。
以证券交易业务领域解耦模型驱动的集中交易分布式演化之路已经全面启程。
其本质是数据流消息化后给业务解耦带来的核心价值,业务逻辑实现不再是需要数据时由应用去获取,而是数据化身为消息在各个组件之间高速流动,驱动业务的完成。



来源:金融电子化:分布式演化

数据库不再是业务运行的核心基础,避免了系统因数据库产生单点故障和性能瓶颈;应用系统间的接口清晰,可以合理分拆独立部署,也便于合并组合适配业务模式的变更发展;应用组件可根据业务需求各自进行快速的弹性扩容;系统模块在设计之初就自带主备和负载均衡等高可用特性。展望未来,随着业务领域模型的发展和系统设计开发的成熟度提升,证券核心交易系统将在分布式技术架构基础上践行解耦之路,不断创新演化,并拓展到证券行业的其他应用领域,打破同质化竞争,助力券商行业的数字化进程。
案例3:某商业银行“分布式交易平台建设”
证券行业的“交易系统”和银行的“交易系统”从业务背景和技术角度上,有联系也有区别,所以可以对比着分析看,很有参考性。
随着银行全面贯彻“金融科技银行”的战略方针,基于移动互联网的高频访问场景将成常态,客户交易量以平均30%的比例高速增长。这些新增的交易主要来自于主流互联网企业,如蚂蚁金服、腾讯、滴滴、摩拜等,具有如下特征:

  • 一是高并发,特定时间段峰值极大、金额小、频度高,存在抢购等业务场景(如“双11”),系统需要支持短时间高并发交易量的冲击。
  • 二是实时要求高,业务处理的响应时间要短,过长则影响客户体验。
  • 三是事务的强一致要求,特别涉及到资金业务,系统的数据必须要做到准确一致。
  • 四是可用性要求极高,为了更好地支持客户服务质量,系统需支持7×24小时无间断服务。且受到监管部门的要求,对于意外宕机等时间都有着极其苛刻的要求。
传统的银行联机交易平台在支持这类交易的时候,一般使用垂直扩展,即升级主机型号的方案。该方案的缺点在于以下几个方面。

  • 一是成本高昂。每年投入巨额资金和大量人力进行相关主机的升级工作,以满足日益增长的交易需求。
  • 二是性能上限。近年来,招商银行采用的服务器已经逐步升级到了顶级机型,但在峰值来临之时仍不免捉襟见肘。
  • 三是资源浪费。在非峰值期间,又会造成主机资源的浪费,不能充分利用计算资源。
  • 四是系统封闭。大中型主机目前全部由IBM、HP等厂商垄断,缺乏竞争,一方面导致银行方议价能力不足;另一方面主机封闭的技术体系也不利于技术人员的培养和补充。
针对以上传统银行交易平台的一些限制,银行亟需开发一套新的分布式交易平台。2015年,银行启动了分布式交易平台项目建设,该平台采用了分布式微服务部署架构,包含了四个基础部分:高性能的运行框架、平台化管理的服务中心、覆盖全生命周期的设计开发管理中心、可视化的监控中心。
1.高性能的运行框架。
分布式交易平台提供了自主研发的高性能的运行框架,通过优化通讯接入、内存管理、数据库调用等技术,极大地提升单数据库服务器和单应用服务器的处理能力。
采用分布式微服务的部署架构,可以横向扩展数据库服务器和应用服务器,使用集群的方式线性提高整体处理能力。


2.平台化管理的服务中心。
分布式交易平台的应用部署采用了微服务的体系架构,将业务功能组件化和服务化,并利用统一的服务中心管理所有服务。
提供了统一的资源管理、服务注册、服务发现、数据路由功能。


3.覆盖全生命周期的设计开发管理中心。
分布式交易平台配套开发了覆盖软件过程全生命周期的设计开发管理中心。
涵盖了设计管理、开发管理、编译构建、发布管理等功能。
4.可视化的监控中心。
微服务的设计思想使得一个业务功能被拆分成一组服务来实现,每个服务只完成一个简单的功能,一笔完整业务请求被拆分成多次服务调用,这给业务运行及系统运维带来了一定的复杂度。
分布式交易平台为每一笔业务请求分配全局统一的请求标识号,并在服务调用时进行传递,有效地将多次独立的服务调用串联成一笔完整的业务请求。通过对请求标识号的采集,可以实现交易链路跟踪,方便业务人员了解业务数据在系统间的流转,同时方便开发人员分析定位系统异常,大幅提高了系统管理水平
分布式交易平台为业务应用统一提供了系统异常告警功能。监控中心利用大数据智能化的算法分析,及时发现系统的异常行为,如交易量的异常波动,错误率的突然提高,错误码的动态变化等,并通过短信和招乎向应用负责人员发送告警消息,方便运维人员及时发现系统异常,防患于未然。
分布式交易平台建立统一的监控中心。监控中心采集平台的性能数据及运行状态数据,实时通过图表等可视化的形式直观展示系统的运行情况。监控中心的分析结果支持多种终端展示,包括电视、电脑、手机、PAD等,其中手机和PAD的监控展示集成在移事通办公平台中。方便运维人员及时查看系统运行情况,特别是运维人员不在行内时,可以通过手机快速了解系统运行情况。监控中心实现了告警消息推送机制。监控中心通过分析系统的交易量、成功率及响应时间等数据,识别异常波动,自动通过短信、招乎等方式发送告警消息至相关产品负责人,及时发现系统异常,保障系统稳定运行。
案例4:顶点软件“证券核心交易系统A5

由顶点软件与东吴证券联合研发的分布式、全自主证券核心交易系统——A5信创版在行业中首次成功实现以国产自研“飞驰”内存数据库HyperDB全面替代国外商业数据库,并让数百万投资者交易速度全面跃入微秒级,享受极速交易体验。这标志着证券行业核心系统发生了跨时代的变革,具有里程碑式的意义。
20多年前,顶点率先将国外关系型数据库、C/S架构引入国内证券核心交易系统,引领了交易系统从文件系统时代迈向大型数据库的集中交易时代;现在,顶点又再次超越创新,采用完全自主可控的“飞驰”内存数据库HyperDB与分布式架构,开启了中国证券行业核心交易系统新的发展阶段。
新技术浪潮与金融变革扑面而来,但传统的大集中式交易系统面对高并发、大容量、专业化的市场需求,已难以承受行业互联网化、机构化、智能化发展之重。在国家信创发展战略、市场需求多样化与金融科技蓬勃发展等多重因素的驱动下,证券行业的交易体系必将迎来变革。A5信创版的面世,正是这一变革的集中体现。A5信创版从顶层设计的战略角度出发,在交易体系、技术平台、业务体系上有诸多变革性创新。
A5信创版采用了分布式、蜂窝化、云化、微服务化、多活、灰度升级等创新理念和技术,是应用“飞驰”内存数据库、实时多活架构、智能化服务治理等一系列核心自主技术而构建的新一代分布式交易系统,在硬件平台(鲲鹏芯片、泰山服务器)、操作系统适配上均可实现去IOE国产或自研的要求,在整体技术生态上实现了自主可控,开行业之先河。
案例5:恒生电子“新一代低延时分布式技术平台LDP”和“投资交易管理系统O45”

恒生电子发布了自主研发的新一代低延时、分布式、高可用技术平台LDP,为金融机构的经纪业务、机构服务、资产管理、自营做市等业务领域提供极速交易、极速行情、极速风控以及基础技术平台等解决方案。LDP平台支持插件开发、组件开发等多种开发模式
从2009年研发第一代内存交易系统UFT1.0开始,多年来,恒生电子深耕低延时、分布式、高可用技术领域,致力于满足金融行业对交易速度、系统扩展、个性响应、资源对接的“更快”要求。在这个过程中,恒生电子对性能的思考路径从“穿透时延”向“全链路时延”方向演进,解决方案从纯软件向软件+硬件、专用硬件的多元化方向发展,并且更加重视由“点”到“面”、技术和业务的综合能力提升。
恒生电子新一代低延时、分布式、高可用技术平台LDP采用软硬件结合方案,支持使用多个FPGA组成计算网络,具备低延时、高并发、高可用、开放等特性,助力金融机构业务快速迭代。最新数据显示,LDP平台可实现端到端延时SHM小于250纳秒,网络延迟小于2.3微秒,TPS大于1500万,并支持业务方案秒级切换,RPO为0。
在开放性层面,LDP平台支持插件开发、组件开发等多种开发模式,能提供丰富的开发工具和公共组件,包括恒生电子针对金融行业自主研发的本地内存数据库,帮助金融机构开发人员提升开发效率。LDP平台还支持丰富的API接口,可无缝对接策略、算法、智能路由、数据等周边资源,让高性能场景开发变简单。
作为构建金融核心业务系统的底座平台,LDP平台与云原生分布式平台JRES一起,共同支撑恒生电子在各个业务领域的产品与解决方案。目前,基于LDP平台的极速交易、极速行情、极速风控等解决方案已陆续在多家券商上线,助推高性能场景应用规模化、生态化。
再来整理下恒生电子“投资交易管理系统O45”。


O45拆分了核心系统与外围系统,实现解耦合,恒生电子新一代投资交易系统O45是恒生投资交易系统O32的升级版。新一代系统在系统架构、耦合性、系统性能、系统容量、开放性等诸多方面进行了全面革新。O45不再只是一套系统,而是资产管理行业的“航母战斗群”——涵盖了投资研究、组合管理、投资交易、风险合规、资金管理、资管运营、估值核算以及信息披露等多个业务环节,并统筹考虑了资管行业各个岗位的全领域工作场景。


  • 在技术上,O45基于恒生电子先进的JRES3.0技术平台,通过技术中台、数据中台、业务中台链接前台和后台的核心资源,赋予整个平台更强的灵活度和更为快速的响应。
  • 在资产管理核心业务环节,O45还采用了内存交易技术,可满足多产品管理、日内高频交易等场景的高并发、低延时性能需求。
基于O45强大的技术内核,

  • 日间交易可容纳千万级交易笔数。
  • 实时风控采用内存数据库技术,1秒之内可完成一个300只股票篮子的交易及风控判断。
  • 此外,O45还真正做到了清算和交易的有效分离,实现了7*24小时无间断下单,并将日终清算时间控制在10分钟内。
恒生O45引入了全球领先的金融科技公司Finastra在投资决策业务方面的经验,以助力投研管理更快实现从how-to-buy到what-to-buy再到auto-buy的跨越。



来源:恒生电子资料

与O32设计理念不同,恒生电子投资管理系统O45是一个松耦合的产品功能群。
1)O45按产品功能划分为权益子系统、固收子系统、衍生品子系统等不同业务子系统。
2)无法拆分的模块按统一规范整体协调,也拆分了中央风控中心、综合业务处理子系统、人员账户权限子系统、基础数据子系统等子系统。所有子系统可以分开独立部署,单独升级,通过接口交互,高效协作。
4)业务品种、业务流程双维解耦,业务品种可独立部署、单独升级。其中每个业务子系统都包含客户端、指令、风控、交易管理、报盘、清算全流程的业务处理、数据交互接口。


案例6:华锐“低延时分布式交易平台”

华锐公司的背景,就不多说了,大家有兴趣可以自行了解下。公司的最新名称已经变更为:深圳华锐分布式技术股份有限公司(http://www.archforce.cn/),可见对于分布式系统的目标,同时公司的愿景就是:分布式低时延技术的引领者。



来源:华锐分布式技术股份公司官网

华锐自主研发的分布式低时延消息中间件AMI,提供高可靠、高并发、低时延的消息传输能力,提供完备且对上层业务逻辑透明的高可用解决方案,以及支持应用轻松实现水平扩展的分布式解决方案,能够很好地支持并增强EDA事件驱动架构。



来源:华锐分布式技术股份公司官网

AMI可用于构建高可用、高并发、低时延、水平扩展的分布式高性能关键金融应用,适用于核心交易、实时风控、高速行情、策略交易、算法交易、量化交易、投资交易等业务场景。其中容错RPO=0、可靠传输100%、吞吐>3500万消息/秒、时延60纳秒。其中官网对AMI的介绍非常详细,也可以和前面4篇文章提到的分布式核心交易系统的理论阐述进行对应。
高性能数据传输

  • 支持主题语义、面向消息的低时延数据传输(低至60纳秒)
  • 提供发送序、主题序、全局序等严格顺序保证
  • 支持异步发布订阅(Messaging)模式及请求响应(RPC)模式
  • 支持静态负载分区(Sharding)及动态负载均衡(Loadbalance)
  • 支持高可用集群间的消息同步,保证消息全局序一致
  • 支持跨数据中心(IDC)跨组播网络(VLAN)消息传输
  • 在数据传输面AMI具有高吞吐、低时延、易扩展等特点
高性能支撑技术

  • 高性能异步多线程网络框架IO-Engine
  • 面向数据中心的智能打包算法和拥塞控制算法
  • 支持UDP单播/组播、RoCE、Infiniband、SHM存等传输层
  • 无锁高性能内存管理模块,数据接收处理、发送处理零拷贝
  • 消息接收和发送的线程模型可灵活配置
  • 核心设计基于C++/C实现,全面应用高性能无锁技术
  • 核心对象、数据结构、算法流程针对体系架构深度优化
  • 全自研内存数据库,mem-SQL性能接近于C++ STL容器性能
高可用特点

  • 强一致容错(RPO=0)
  • 自动切换(RTO<1s)
  • 业务透明(高可用设计与业务解耦)
  • 容错能力灵活可配置(可用性>99.999%)
  • 强一致容错模式低时延(RTT=5.8微秒)
  • 同步高效,节省带宽
  • 主从集群,读写分离
高可用功能

  • 可靠传输
  • 全局有序
  • 故障切换
  • 脑裂预防
  • 故障隔离
  • 故障恢复(集群级/单个副本)
  • 数据持久化
  • 消息重演
  • 异地灾备
  • 应用快照
  • 软件缺陷恢复
丰富的开发接口

  • 支持 C++/C/Java/Python/C# 语言API
  • 支持异步发布订阅(Messaging)模式及请求响应(RPC)模式
  • 支持适配Grpc/Zmq/Kafka/MySQL接口
基础应用开发框架AAF

  • 命令行解析
  • 信号处理
  • 日志处理
  • 数据加载
  • 配置解析
  • 守护进程
  • 单例应用
  • AMI自动接入
  • 业务指标收集
通用业务开发框架ABF

  • 主题无关、纯粹的消息驱动架构
  • 模块化、插件化业务开发
  • 代码模块配置管理可视化
  • 支持服务间对象传输
  • 支持同步和异步RPC调用
  • 自动内存安全回收
  • Actor模型(CSP)多线程处理框架
  • 高性能数据结构和内存数据库
  • 消息过滤和异常保护
DomainServer

  • 集中配置和管理
  • 可视化数据流编排
  • 可视化属性配置
  • 指标监控仪表盘
  • 系统状态大屏展示
  • 管理节点高可用
分布式系统跟踪

  • 支持时延度量和消息轨迹跟踪
  • 安全可信的时延采样API
  • 支持有侵入和无侵入采集
  • 采集性能强、应用影响小(API时延50纳秒)
  • 支持软件和硬件校时
  • 支持实时指标计算、可视化指标和轨迹展示
  • 支持基于历史采集数据计算、统计、可视化展示
实践思考

思考1:不要为了分布式而分布式。
在金融机构,大多数的场景目前是不同厂商提供的不同业务系统,造成的“烟囱式”系统建设现状。在没有业务迫切需求下,如果单把某个单体业务系统改为分布式架构,其实工作意义不大;如果业务发展所需,必须对单体业务进行分布式改造才能支撑,那又分为两种情况,一个是只对单个业务系统改造即可,一个是可能需要对多个业务系统从整体上予以抽象设计,形成分布式交易系统,而这种投入可能会非常大,需要在实际实施前做好充分的论述和分析。
思考2:分布式核心交易系统的设计灵魂是基础设施
对交易系统的分布式设计出发点,可能和业务系统又有不同。交易系统的分布式设计前,需要做好:通讯、消息、内存、分布式锁等底层组件的设计,如果团队没有这样的人才储备,则很难在这块取的成就。
思考3:别让分布式系统成为后续运维人员的负担
一个初级程序员,通常最爱犯的错误可能是修改了一个BUG后,可能引发了另外一个或多个BUG。而一个不好的架构设计,最怕是为了解决一个顶级问题,而引入了新的问题。比较典型的是采用分布式系统后,如果没有配套的问题排查工具或系统运行监控工具支撑,则会给后续运维及问题排查带来巨大的工作量,就会出现“系统无法从开发人员手中交付出去”的困境。
关于分布式交易系统系列文章完结,祝福大家:辞旧送吉虎,迎新接玉兔~~
分享到 :
0 人收藏
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

积分:400157
帖子:80032
精华:0
期权论坛 期权论坛
发布
内容

下载期权论坛手机APP