“金融云+Devops”，有限元科技打造自助化持续交付平台

“金融云+Devops”，有限元科技打造自助化持续交付平台

• 来源:网络
• 更新日期:2020-06-15

摘要：近年来，银行业作为金融行业的支柱行业，整体IT 投入不断加大，架构发生重大变革，系统、网络和数据的大集中，使得银行信息系统的运行效率及稳定性亦有巨幅提升。但对比以快速响应、

近年来，银行业作为金融行业的支柱行业，整体IT 投入不断加大，架构发生重大变革，系统、网络和数据的大集中，使得银行信息系统的运行效率及稳定性亦有巨幅提升。但对比以快速响应、快速发布、迭代更新为特征的新型“互联网+ 金融”，传统商业银行IT 架构的劣势已逐步显现，其主要表现如下：

一、环境准备时间过长 。应用系统运行所需要的硬件、软件环境往往需要在上线前一两个月就要申请、准备，在产品上线前就需要规划出产品今后可能用到的资源数量。

二、系统扩展、扩容难度较大。各应用系统架构不统一，难以用通用且便捷的方式应对基础资源环境和应用处理能力横向扩展的需求。

三、测试环境与生产环境差异较大。应用系统的测试环境和生产环境存在较大差异，测试案例并不能完全模拟生产环境。

四、上线过程复杂。上线过程除了开发人员外，往往需要运维人员、系统人员、DBA 等各个环节的人员共同参与，或修改配置、或部署应用、或执行数据库脚本，加大了上线人力成本的投入，降低了上线投产的效率，增加了手工操作风险。

五、建设周期长、成本高。技术标准遵循不一，软件定制效率不高，系统间交互接口复杂，实施推广需要大量的人力完成。同时，硬件设备使用趋于高成本、低效率。

金融云发展趋势

金融云是运用云计算技术提供的创新服务。系统上云的诉求背后是，近年来资产回报率走低，加之新兴金融业态冲击，银行业转型压力越来越大，且银行需要应对的互联网金融或者说金融互联网应用场景越来越多，小额交易频发，交易量不可预知，“秒杀”成为新常态。

多变的客户需求和快速的金融产品创新也对IT资源的弹性供给和业务快速上线提出更高的要求，银行IT系统峰值处理能力需达到过去的n倍，如果单笔交易IT成本不变，总成本将大幅增长。

而云计算作为新的IT建设、采购、使用模式，通过对标准且相对廉价的服务器、存储和网络等硬件资源进行虚拟化，提供便捷、按需获取、可配置和可度量的IT资源供应，在成本、灵活性上有大优势。

金融云+devOps产品介绍

金融云+devOps，是北京有限元科技输出的重要组成部分，工具链和平台功能基本涵盖DevOps的主要流程阶段，帮助银行完成技术、数据准备，实现统一的移动互联网的安全准入及跨平台发布标准。建设金融云平台将作为银行主动实施向开放架构转型的关键一步，将其建设成为系统架构中重要的基础性平台，并作为科技转型的重要抓手，打通开发、测试、部署及运维等各个环节，完成DevOps 转型（开发、运维一体化）。

体系架构

如何建设一个能支撑开发、运维共同使用，实现价值交付的DevOps研发运营管理平台，选择以CMDB作为资源元数据平台，以K8S作为资源管理平台，支撑交付、变更、监控、运营等各种IT运维能力；在交付部分，支撑资源交付和应用交付的自动化能力；在变更部分，产生资源变更事件，触发对应变更动作、通知监控系统；在监控部分，支撑监控、告警系统，加强数据消费场景；在运营部分，提供完整数据支持容量、可用性等分析处理。总体架构如下图：

自助交付平台各个系统，形成闭环运维流程：

1． 容器云

以Kubernetes为基础，打造多机房、多集群管理能力，以自助方式为交付团队提供平台能力：

 多租户；

 应用仓库；

 提供容器web ssh访问能力；

 提供容器日志实时跟踪能力；

 应用自助部署及快速访问能力；

 应用自动扩缩容能力；

 环境资源自助、配置管理能力；

 环境脚本化创建能力-基于namespace；

 环境冻结及恢复能力-基于namespace；

2.CICD

自助化、自动化和协作作为核心文化，通过提供便捷的基础服务，让交付团队拥有自动化的交付流水线，并通过更多的沟通协作，尽可能让每个交付团队都能够独立自主的调整自己的基础设施。然后再根据各个交付团队的实施情况和结果来对流程和服务持续改进。首先设计一个高效的持续交付流水线，让各个团队都能够嵌入到流水线中，并以基础设施即代码来沟通，通过自动化的方式实现开发与运维的连接，如下图。

1) 流水线过程：

 站在交付团队的视角，我们将基础设施构建、代码构建、部署等活动都代码化，与应用代码放在同一个代码仓库中；

 交付团队通过提交自己代码到仓库后，通过Webhook触发持续集成工具创建流水线；

 接着会进行自动构建，单元测试、代码质量、安全扫描、依赖库检查等任务，最终输出构建镜像并推送到镜像仓库，并生成测试任务；

 测试人员选择测试任务启动，自动到任务对应环境中去创建应用（组）实例，然后再进行功能测试、性能测试、接口测试及安全测试等，测试通过后创建发布任务；

 运维人员选择发布任务，进行最终的部署活动；

2) 平台能力：

为持续优化交付流程，对许多活动进行数据收集和分析，以报表的形式去分析展示代码提交频率、系统和代码质量情况、缺陷和构建情况、部署情况等，帮团队找到瓶颈或问题。

3) 技术选择：

以开源为主，选择了一种轻量级、低耦合的技术组合Ansible+Jenkins+Kubernetes,具体工具链如下图 :

考虑到基于yaml语法简洁且易读，以其定义交付团队的公有DSL模板，平台团队关注平台服务是否满足需求和DSL模板是否易用，而交付团队只用关注如何基于公有 DSL去定制自己的基础设施、环境依赖和部署等。

CMDB

1) 目标：

 管理所有资源及其拓扑关系，实现资源全生命周期管理

 通过自动化发现技术结合变更流程，有效降低资源维护成本

 作为元数据平台，给周边平台提供数据支撑

2) 原则：

 从应用的角度构建与IT资源的弹性关系

 提供应用元数据管理能力，和应用类型无关

 为应用资源、动作、状态的统一管理提供支撑

 以统一基础资源层作为基础，管理底层一切资源

 变更控制借助运维流程自动化完成

 资源使用自动发现，而不是人工维护

 资源信息必须能为上层应用提供服务

3) 支撑

 核心诉求是应用生命周期管理

 核心场景是持续交付

4) 架构

 资源模型管理主要为定义配置模型，包括配置项、属性、关联关系

 资源对象管理分成基础对象管理、PaaS对象管理及应用管理等

 拓扑管理是资源对象之间的关联关系管理，从部署拓扑、实例拓扑到基础资源拓扑是一个分层拓扑

 对于实例和关系的维护有两个重要的手段，一个是自动发现，另外一个就是基于运维流程的生命周期管理与场景化的自动化变更管理等

3.FastX统一监控

1）监控目标

2）监控4个黄金指标

 延迟：业务的具体处理时长，需区分成功耗时和失败耗时；

 流量：业务在单位时间内的调用量，如：服务的QPS、每秒订单笔数等；

 错误：调用出错数量、成功率、错误码；

 饱和度（负载／容量）：已使用资源的占比；

3）监控标准化

 事件来源-来自CMDB管理的物理及逻辑资源（主机系统、网络、基础组件、中间件、应用等）

 监控模板标准化-专人负责制定资源的监控设计、阈值设置、模板统一

 告警规则标准化-监控系统与告警系统分离，各司其责；告警根据设备等级、应用等级、严重等级区分；告警发送对象统一来源CMDB

4. DBMan

 数据查询工具：支持查询、审计、脱敏；

 数据变更工具：支持DML、DDL；

 数据库运维工具：支持集群管理、用户管理备份、恢复、巡检；

有限元科技的金融云+DevOps，一方面，将成熟的开源工具开源技术和企业内部的云管理平台相结合，实现了较高程度的开发测试流程自动化，推动了产品的持续集成和持续交付，减少了大量的重复劳动，提高了开发测试效率。

另一方面，通过使用云管理平台，将复杂异构的IaaS资源服务化，降低了使用难度；结合业务部门需求合理划分资源，减少了资源浪费，加强了资源的有效隔离，避免了误操作；自服务自运维的模式，也极大地提升了公司整体研发效率。未来，有限元科技将持续优化自助化持续交付平台，使得集中式、审批式、被动响应请求的运维团队不再是交付流程的依赖和瓶颈，逐渐转向自助化、审查式、主动优化的去中心化交付团队。