基于云服务的架构设计

文/田延杰

近年来证券行业的经营模式有了巨大的改变，从营业部到网络金融，从经纪业务到财富管理，从通道业务到信用业务，从资管、投资银行到资本中介，从产品发行商到服务供应商等等。这些发展过程的背后都离不开数字化能力的辅助。

1 存在的问题

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

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

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

图1

2 云服务架构设计理解

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

图2

图3

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

3 云服务架构设计原则

3.1 兼容设计原则

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

3.2 高可靠设计原则

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

3.3 服务标准化原则

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

4 具体云服务架构设计实践

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

（1）公司有哪些方面的交易风险？

（2）如何识别这些交易风险？

（3）怎么样处置这些风险？

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

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

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

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

5 结论

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