写点什么

基于证券云服务的总体架构设计应该怎么做?

用户头像
Jason Tien
关注
发布于: 2021 年 02 月 22 日
基于证券云服务的总体架构设计应该怎么做?

金融科技发展,已经是未来金融行业下一步发展的重要领域,以云计算、大数据、物联网、人工智能为基础的高科技技术正在向传统证券业迁移。本文结合金融行业的特点和存在的问题,总结了云服务的理解和架构原则,并且以具体设计实践为例,描述了整个架构设计的全流程、流程中的具体细节,通过对本文观点和实践的阐述,将有助于金融科技工作者的云服务架构设计和对未来云架构的思考。

近年来证券行业的经营模式有了巨大的改变,从营业部到网络金融,从经纪业务到财富管理,从通道业务到信用业务,从资管、投资银行到资本中介,从产品发行商到服务供应商等等。这些发展过程的背后都离不开数字化能力的辅助。金融科技为证券公司提供了业务转型与能力重塑的新机遇,加大金融科技平台建设,重塑业务条线商业模式,加速金融科技领域布局已成为趋势。其中以云计算技术在金融业的应用逐步落地,彻底颠覆证券业务的开展和运作,深入券商日常管理的各个方面,并逐步在金融企业软硬件架构中落地应用。

一、存在的问题


公司在经营工作会议强调“积极拥抱金融科技,加速向智能化、数字化券商转型”。金融业的未来与金融科技的进步息息相关,公司应主动顺应时代潮流,全面加快金融科技的创新步伐,努力建设智能化、数据化、精准化和专业化的金融服务体系。公司在积极应对的过程中,主要存在的问题:

公司内系统众多,而部分系统之间由于建设管理部门不同等原因呈分散状态,如需同时调用几个系统间的信息或对信息进行综合管理,难度较大,系统间未互联互通,易形成信息孤岛;由于历史原因,公司的系统中涉及大量外购系统,供应商纷杂,造成技术规范不一致,数据标准不统一的现象。创新性、差异化竞争很难落地,整个技术架构相对笨重,难以敏捷、快速地响应数字化时代的需求。

业务与技术知识结构和工作视角不同,尚未形成业务、技术、管理互相成就的合理机制,难以实现跨条线、跨职能的深度协同。券商的组织架构多以牌照为中心,组织灵敏度相对较低,流程复杂冗余,效率低,协同差,尤其是经纪业务与其他业务间的协同作战能力低,浪费了券商禀赋,如部分流程未得到固化和规范,部分流程尚有冗余,业务板块间存在割裂,跨部门职责边界不清晰等等。

共享包含信息共享、技术共享、资源共享、知识共享等,企业也应具备“共享”的能力,尤其是对资源的共享,实现资源的最大复用,最大限度发挥其价值,实现资源共享可以有效减少资源浪费,促进资源流通,提高资源利用率,但公司客户、业务、数据、技术以及工具等资源尚未实现共享,资源价值未得到充分发挥,公司在模块化、平台化管理上仍有提升空间,在资源的协同共享道路上仍需要有作为。

二、证券云服务的设计理解


维基百科中对软件体系结构的定义中可以看出,软件的体系结构类似建筑的体系结构,包括基本构件、构件之间的关系和组合规则,由此可以看出,软件架构也有类似的概念,包括软件元素、结构和连接,以及相应装配规则。其中软件元素可以包括各个子系统、模块、应用软件,结构根据不同的场景为元素配置相关的关系和属性,而连接则是通过对元素和结构进行规范的定义。

云技术是指在广域网或局域网内将硬件、软件、网络等系列资源统一,从而实现数据的计算、储存、处理和共享的一种托管技术。在证券行业,可将业务、财务、风控等系统数据在云平台进行整合存储计算,进行集约化的数据管理,进而提升企业的运作效率。在云计算环境下的架构设计思想对我们提出了新的挑战,云服务架构设计则在更大角度考虑实现软件元素的虚拟化、结构的动态可扩展,支持部件深层对应用的支撑能力、连接按照应用场景灵活的按需分配和部署能力、整体架构的高可靠性和高性价比。

面向云服务架构设计主要从系统业务设计、系统数据设计、系统产品设计、系统应用设计和系统技术设计五个方面考虑。通过对战略的理解展开对业务的熟悉,梳理出系统的业务,再根据设计出的业务架构分解,设计与业务架构相适应的应用和数据架构,最终通过技术架构落地。其中应用架构是中间层,起着承上启下的作用。

三、证券云服务架构设计原则


云服务架构的设计不是只重视单个系统的能力,在设计之处就应该有与生俱来的可持续迭代、可持续进化和不断可以进行创新的平台。既满足企业对于 IT 高可用、高安全、可扩展等一系列要求,也要满足创新 IT 所具有的快速、灵活、可伸缩的各项挑战。主要的基本原则有以下三方面:

1、兼容设计原则

企业的公有云和私有云建设进入了快车道,有很多企业数据和应用需求都在往公有云迁移,其中私有云开发建设企业的关键业务、内部数据、交易平台,公有云部门开发交互类应用、创新和数字化应用。两者逐步可以进行平滑迁移。

2、高可靠设计原则

根据具体的业务需求、按照地理位置、不同机房、不同服务器的同一个服务具有可持续性的服务提供能力,防范各种级别的故障隔离,围绕访问控制、网络安全、数据冗余、系统并发等各方面展开,当一个故障出现,另一节点能够实时运行,最大限度的确保业务服务的连续性,实现相同标准、相同服务、统一管理。

3、服务标准化原则

云服务设计体系架构是分层的,层与层之间、用户用服务之间、服务与服务之间都应该遵循相应的接口规范和标准,而且应具备对外部服务标准进行扩展的支持能力。再者,引入微服务、云计算等业界标准,例如 docker、Hadoop、NewSQL 等服务标准,保证平台的先进性。

四、证券云服务架构设计实践

首先,业务架构设计需要从业务的需求出发,需求的产生有可能是一个部门提出的需求,也可能是总裁的一段语言描述或者一句话,列出需要解决的核心需求、未来待要解决,且具备迭代和优化的的问题域。例如:

1、公司有哪些方面的交易风险?

2、如何识别这些交易风险?

3、怎么样处置这些风险?

根据这些问题论证解决这些问题实现的业务目标,在解决这些问题的过程中,整理出初步答案,形成一个不太成熟的对产品的理解。


然后,对初步形成的问题域得到模糊的产品方向和功能范围,找出所核心目标、依赖的系统、产品用户,并且画出业务流程图。通过对业务流程进行分析,分析出业务功能矩阵,把具有独立功能职责的需求进行垂直拆分,通过对业务功能矩阵进行分层,拆解成用户层、功能层、数据层,明确不同信息层级的边界和同一层模块之间的边界,通过业务间的关系明确系统间的边界,把关于信息流动的路径标示出来,最终整理出产品架构图翻译成在公司交易模式中的工作闭环。在产品架构过程中,模块功能边界划分要清晰、标准化、独立化抽象后的功能模块、各层之间也要边界清晰且分层合理,具备优化迭代能力。

之后,从领域模型提取数据架构,数据架构的重要输出交付就是 E-R 图,它包含了数据的实体对象、关系和属性等重要内容,可以通过 ER 图建立业务对应的数据模型,数据模型的建立有赖于业务架构的输出,通过对业务域的模型分析逐步提取出云服务的数据架构。在这个过程中首先在原流程图基础上把涉及到的角色、业务对象、业务规则、模型、异常事件和事务等内容整合进来,定义出领域模型的骨干模型,并且对骨干模型进行丰富和迭代,整理出领域四色模型。实体和联系中的一对一、一对多和多对多约束表现在图中,最终输出 ER 图。


再之,对云服务的架构应用设计依据产品架构的输出,分析产品架构中子系统间的关系和可复用的模块予以下沉作为基础模块,最终输出哪些应用系统和各系统中的集成关系。具体做法就是在在产品架构的基础上做水平和垂直的维度划分。通过水平划分确定应用间的边界、通过垂直划分确定应用内模块边界。在云服务中,各应用是通过服务的形式进行相互调用,这也是 SOA 的架构思路,在这套体系中就涉及到服务的注册、治理、发现,SOA 体系中要体现外部系统与产品间的调用关系和应用内部的调用关系,在应用架构设计过程中,要注意应明确应用之间的调用关系和应用边界、输入系统与输出系统必须成对出现,并且能清晰描述出整各应用架构的全局关系。

最后,技术架构过程通过技术分层、开发框架的选择、非功能技术、资源池化等实现产品需求的实现。这个过程会面临很多不确定性的问题,包括选择最新技术还是熟悉的技术?以后技术演进过程是怎么样的?顶层设计要求在技术选型中不要一味追求最新的技术,不要为了证明自己而重复造轮子,要具体了解应用场景,选择在够用的基础上有一定扩展性的架构设计。“简单就是美”一直适用于程序架构设计,不要试图做复杂度太高的设计,规模庞大、层次结构多会引起各模块之间不稳定因素上升。由此,开发、维护、运维、测试等各个环节工作量都会成倍的增长。

技术框架设计具体考虑以下几方面的内容,包括服务化的演进、服务的拆分、消息队列、异构系统和数据、缓存设计、服务降级、快速回滚等几个方面的内容。

五、结论

本文从金融行业特点和存在问题出发,讲述了对云服务架构的理解,然后对云服务框架的设计提出了云服务设计的三原则,通过具体系统业务架构、系统产品架构、系统产品架构、系统数据架构、系统应用架构、系统技术架构五部分的实践设计,并通过具体的框架图描述整个框架设计过程。通过我们的设计发现,架构的预先规划和框架在之后的迭代演化同样重要,没有好的规划就很难有一个演化的空间,没有演化,再好的规划也会慢慢被淘汰。在整个软件生命周期中就要不断的调整自己的设计,优化和迭代自己的框架体系,兼顾考虑系统各老旧、异构系统,通过各个分层之间资源、组件、框架、服务的池化,做到云架构中快速进行扩容、软件资源的复用。


参考文献

[1] Zhu JX, Zhou MH, Mei H. Multi-extract and multi-level dataset of mozilla issue tracking history. In: Proc. of the 13th Int’l

Workshop on Mining Software Repositories. ACM, 2016. 472–475.

[2] Siegmund J, Siegmund N, Apel S. Views on internal and external validity in empirical software engineering. In: Proc. of the 2015

[3] 王启军 著.持续演进的 Cloud Native:云原生架构下微服务最佳实践.电子工业出版社; 第 1 版 2018 年 10 月 1 日.

[4] 李林锋 著.分布式服务框架原理与实践. 北京:电子工业出版社,2016.1


用户头像

Jason Tien

关注

好好学习,天天向上 2019.10.10 加入

中泰证券科技研发部高级经理

评论

发布
暂无评论
基于证券云服务的总体架构设计应该怎么做?