首页天道酬勤基于bs架构的投票系统案例开发(vie架构案例)

基于bs架构的投票系统案例开发(vie架构案例)

admin 12-01 08:27 235次浏览

文/招商证券股份有限公司信息技术中心dbdgb智能煎饼严肃夜重要服饰

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

随着金融技术的快速发展,中间件逐渐不再作为一个独立的技术概念被提及,而是在应用架构中扮演了更重要的角色,也就是现在广泛使用的“中间平台”。然而,无论是“技术中间平台”还是“业务中间平台”,都离不开中间件技术的发展。随着中间件技术的发展,企业应用系统越来越多,交互也越来越复杂。中间件需要解决的问题正在从“提升单个应用系统的开发效率”慢慢上升到“提升企业级不同应用系统的整体交互效率”,从“单个应用系统的开发框架”慢慢上升到“企业级应用的连接平台”,开始承载公共业务能力,帮助企业搭建“业务中间平台”。“业务中间件”是另一种“中间件”,它不是屏蔽技术复杂性,而是抽象、实现和强化公共服务能力,通过组合多个独立、清晰的公共服务,使业务实现更加容易。传统中间件解决了业务实现的技术复杂性,而业务中间件解决了业务实现的“业务复杂性”。

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

证券行业的技术特点是瞬时并发量大,系统容错性低,系统运行压力大,专业客户对大并发下系统的处理性能要求高。因此,证券信息系统的复杂性和技术难度甚至超过了银行业和互联网行业。在满足高并发的前提下,还需要保证数据的强一致性,稍纵即逝的市场使得投资者对系统的持续运行有着极高的要求和极低的容错性。因此,证券行业的核心系统需要一个非常强大的“中间件”,或者说“技术中间件”,来保证并发性、数据一致性强、扩展灵活等要求。

业务范围方面,证券业务涵盖互联网金融、财富管理、专业机构交易、托管服务、自营投资、投资银行等。业务覆盖面广,有些业务或多或少有共性。例如,互联网金融和财富管理可能都需要营销活动管理和面向客户的营销服务的用户点。专业的机构交易和自营投资需要战略交易和算法执行的支持。托管服务、专业机构和投资银行可能为同一客户服务等。这些公共功能可以被提取和重用。近年来,从股权分置改革到创业板注册制,证券行业出现了许多创新。随着券商竞争加剧、佣金下降,券商财富管理转型迫在眉睫,券商自身也需要在不断创新中寻求突破。

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

招商证券的中间件探索

招商证券一直在“中间件”和“中间平台”领域进行探索。和大多数证券公司一样,前期搭建的核心业务系统的技术架构是基于传统单一、高性能服务器的交易管理中间件。虽然这种中间件在事务安全方面表现良好,但其灵活的容量扩展和分布式部署能力不足。而且早期的后端交易系统大多依赖外部采购,不同的实现者有不同的技术架构、外部服务协议、会话管理方法等。这给前端应用带来了极大的复杂性。

从2008年开始,我们基于SOA的概念,探索了如何通过可配置的Web Service屏蔽后台复杂的协议,为前端提供一致的后端服务,大大提高了前端与后端对接的效率。但是,当时的SOA更多的是转换后端协议,而不是实际的业务逻辑组装,而且是比较薄的中间层,转换后的协议相对简单。后来商业的SOA中间件开始出现,比如基于MQ的IBM ESB,可以在各种协议之间高效转换,允许服务消费者根据自己支持的协议进行访问,进一步给前端服务带来便利。但是,ESB仍然是单一的服务,无法解决“转换”层的弹性扩展和实际支持SOA接口服务的业务逻辑层的有效解耦问题。

随着券商对业务创新的要求越来越高,对信息系统快速更新迭代能力的要求也越来越高。然而,传统的集成所有应用的模式限制了快速升级的能力,同时,可重用的能力必须反复开发。2015年前后,“微服务”架构的兴起为解决传统中间件架构的不足提供了新的技术途径。技术中间件作为系统研发的核心能力,需要足够的自主控制,以满足对稳定性要求极高的证券行业的应用需求。

于是,我们开始自主研发“微服务”架构,并在此基础上,将前端和后端扩展到客户端开发框架、通信接入等。并逐渐形成了包括前端应用、通信访问、业务服务、数据库访问等在内的全栈技术框架(XFramework)。XFramework让SOA不仅仅停留在接口层,还涉及到基础的技术架构和业务实现,这是对应用架构和技术架构的全新变革。在前端框架上,开发了“雅典娜”,支持移动和Web的快速发展,可以与微服务框架和数据库访问无缝集成。在后台服务实现方面,开发了“宙斯”微服务框架,屏蔽了后台微服务实现的技术复杂性,采用

高性能RPC、异步消息等技术,实现轻量级、扁平化框架,支持服务自动注册、自动发现、远程调用、熔断等特性,以去中心化的业务服务独立进程运行;在接入层面,开发了“Hermes”,采用公平调度、热更新、监督树容错模型、超轻量进程等技术实现高性能、高可用接入层。这些服务都在不同层次解决了技术复杂度,让业务开发更加快捷。自投入使用以来,超过80%的自研系统利用XFramework实现了系统的快速交付,涵盖机构服务、托管业务、交易柜面、风控合规等证券业务领域。

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

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

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

中间件的未来

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

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

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

go熔断原理源码分析如何在Android设备上的TWA应用程序中隐藏“在Chrome中运行”吐司?电商应用场景 无人化智能盒子 UBox文件存储-创建文件系统 UFS
修真界布道师(消息中间件mq原理) java多线程的实现方式(linux线程数量)
相关内容