一文读懂金融行业如何做云原生

过去两年，金融行业IT人员对“云原生”充满了疑惑甚至误解。我们一直在不同场合听到关于云原生的各种不同定义

有人说，云原生就是Kubernetes和容器；也有人说，云原生就是“弹性可扩展”；还有人说，云原生就是Serverless。

其实云原生本身就是“哈姆雷特”，因为每个人的理解都不一样。

CNCF和kubernetes技术生态定义的云原生概念中指出云原生的本质是一系列最佳实践的结合。换句话说云原生为实践者指定了一条低心智负担，能够以可扩展、可复制的方式最大化地发挥云的价值的最佳路径。

所以，云原生应当是一种“以应用为中心”的思想。

何为云原生应用

目前，云原生技术已被大家认可。那么何为云原生技术？

首先，所有技术都是为业务服务，云原生技术诞生的背后也是业务驱动。随着软件的发展，业务越来越复杂、庞大，但软件用户却希望可以得到更快的需求响应、更稳定的运行状态，所以互联网企业开始大量使用云原生技术。

云原生主要围绕着3个目标：加速创新、降低成本、提高效率。 基于云原生技术开发的应用就是云原生应用，那么云原生应用就意味着统一：

• 统一架构标准： 通常以微服务架构进行服务开发，服务之间使用标准的API契约进行通信。松耦合的架构方式会减轻因需求变更导致的系统迭代成本，并加快交付速度；
• 统一交付标准： 标准容器化的打包方式实现了真正的应用可移植性，不依赖于特定的基础架构（虚拟机，混合云等）。而容器基于进程粒度的资源使用方式，也会降低系统的资源开销；
• 统一流程标准： DevOps强调软件全研发周期的管理，从软件需求到最终生产的全流程的改进和优化，然后结合统一工具链，实现文化、流程、工具的一致性，本质解决的是加快软件交付速度的同时，提升软件产品质量。

  

金融行业的应用是否需要云原生的改造？

传统的金融软件架构存在很多难以解决问题。在巨石型的应用中，每个系统数据都是一座孤岛，没有接口可以对外服务，如果客户有创新需求想实现多个系统配合，几乎不可能。各业务系统采用的交付方式部署安装的硬件标准不一，导致金融机构运维超级复杂，成千上百台机器以及上百个应用需要一个庞大运维团队支撑。金融软件的交付周期目前是按月交付的，研发流程更多还是传统的瀑布或者敏捷方式，导致了很多客户需求被延误。

为满足用户快速多变的投资理财诉求，金融行业的软件架构升级已经迫在眉睫，云原生架构则成为最佳选择。

云原生应用演进路径

作为金融行业全领域的软件提供商，恒生所有业务系统在过去两年全面往云原生架构升级，积累了不少经验。

总体而言，云原生应用演进面临着三大难题：微服务拆分、容器化交付、DevOps改造。

微服务拆分之路

从单体应用到SOA再到微服务，软件架构一直在追求不同的拆分维度。微服务架构更强调的是按照业务能力垂直架构划分，即每个微服务完成一种特定功能，可以独立运行、独立部署。

微服务拆分的依据一般为两个原则：一是业务独立性，维持微服务业务内部的权责单一原则；二是团队自主性，维持微服务团队内部的地沟通成本原则。

业务层面的逻辑梳理，可以根据团队成员大小以及团队间的沟通成本来检验业务拆分是否合理。一般建议一个微服务开发团队10人左右比较合适，这样可以快速迭代用户的需求。

想把微服务拆分做得十分合理往往比较困难。拆分是一个持续工作，随着业务上线，通过升级部署等运维方式就可以校验微服务划分是否合理。

以恒生的理财销售系统为例，系统的第一轮拆分包括了交易、支付结算、账户、清算等7个微服务，当业务系统在客户端上线时发现部分拆分还是过大，影响到了很多业务升级，于是进行了第二轮拆分迭代。第二轮拆分把支付结算拆成独立支付微服务，把清算拆为交易清算以及资金清算等。按照实践经验来看，微服务的拆分一开始可以粗粒度一些，随着生产校验的推进可以逐步细化和合理化。

最近两年，另外一个与微服务拆分的相关的理念开始火起来了，这就是起源于2004的DDD（领域驱动设计）。目前业内倾向于认为DDD是微服务划分的终极解决办法，也是托了微服务的福，DDD才有流行的土壤。

微服务其实是一种架构风格，而DDD是一种思想，微服务定义的九大核心特质跟 DDD的原则是完全一致的，这在某种程度上也是业界愿意在微服务上下文中采用 DDD 方法和实践的原因 。

目前已经有很多DDD如何结合微服务的技术文章和演讲开始流行，相信有朝一日DDD能成为真正微服务拆分的解决之道。

容器化交付之路

IT基础设施往云上迁移是大势所趋。在云平台竞争激烈的市场环境里，在金融机构对成本、厂商锁定的担忧下，包含公用云、私有云和本地部署组合的混合云诞生了。

混合云时代，容器依靠自身标准化、一次构建随处运行的能力开始大行其道。

金融机构的交付方式往往存在严重不统一的问题，在不下于几十家开发商产品提供的情况下，每种软件的安装部署都是不一样的标准和操作方式，容器就可以很好的解决这个问题。

容器类似于集装箱，金融机构只需要部署好混合云底座就具备了存放集装箱的基础，然后所有开发商按照统一安装集装箱的方式提供交付。此时金融机构的运维人员进行简单罗列排布即可，升级的时候进行简单替换即可。这将大大减少金融机构机房内运维人员数量，就好比一个码头，全是自动化集装箱卸载、排放、运输、调度，实现真正的智能运维。

如果通过容器把金融机构的机房变成一个全智能的“码头”，对容器云平台需要做好以下几点：

• 统一的交付规范。针对容器交付要有一定的规范要求，譬如操作系统版本，安全漏洞、中间件版本等。这些基本要求是所有交付物要进入这个“码头”需要首先做到的；
• 统一的编排规范。针对所有容器编排，形成一个应用要有统一的约束和要求，譬如：配置中心各自分区约束，日志中心统一采集要求，编排文件格式要求等，这是所有容器可以自动运行运维的基础；
• 统一的调度管理界面。所有容器需要按照应用维度去管理，所有应用中用到的技术中间件需要通过统一的PaaS平台管理和获取。业务运维人员需要从应用视角展示管理界面，包括：指标监控告警、应急切换操作、日志查看操作等。

DevOps改造之路

DevOps（Development和Operations的组合词，开发即运维）涉及整个软件生命周期中的持续开发、持续测试、持续集成、持续部署和持续运维与反馈，目的是实现短周期内的高质量软件开发与交付，确保软件的持久稳定，为企业带来运营能力和效能的持续提升。

实际上，DevOps是一种实践，更是一种文化理念，它强调的是合作、自动化、精益、度量、共享。 正是依托微服务架构以及容器化的交付，DevOps才变得更加流行起来。

重塑原来的软件研发交付流程和软件研发过程主要体现在研发交付流程、参与角色的重塑。DevOps强调按照需求进行持续的集成、测试、交付、部署、监控全自动化化流水线，通过每个环节设置质量卡点，确保交付效率与质量。此外，所有角色的统一操作视图、一站式体验、数据全部汇总打通，提供全研发链路的直观展示以及每个过程数据汇总分析，提供后续改进的可能性也是DevOps强调的内容。

除了流程的调整梳理之外，DevOps会进一步要求通过工具链的统一来完成流程的固化和落地。工具统一的过程可借助开源也可以购买商业产品，但核心是需要通过统一视图以及流水线的引擎来完成交互以及数据统一。

恒生云原生应用平台

恒生公司业务系统的云原生改造开始于2015年，经历这样几个阶段：

2017年，技术平台选型统一的阶段，完成了JRES3.0技术中台的确定；2019年，业务系统完成微服务拆分，核心重点产品全部改造完成上线；2019年，完成对所有金融业务中共用的业务模块提取，进一步发展形成业务中台、数据中台。

**至此，恒生整体的大中台架构就真正形成。**从微服务拆分到中台形成，恒生公司也完成了对应的组织结构调整。

作者介绍：许欣芃

恒生公司平台业委会负责人、研发中心总经理。十多年的金融行业技术平台的设计开发经验，参与交易、风险、清算等金融业务系统设计和研发，目前负责恒生公司统一技术中台的研发管理工作。对云原生技术有比较深入的研究，对微服务、容器、Devops相关技术有一定实战经验。

更多金融科技文章请见恒生LIGHT云社区