从自身实际工作出发，结合传统银行业务系统现状，论证了在疫情重压之下如何从人的弹性、系统的弹性（系统架构和基础设施）等方面应对突如其来的变化，最后得出弹性便是一切的论点。

以下文章来源于DevOps社区Meetup ，作者刘华



作者简介：刘华（Kenneth）

• 就职于世界500强银行，负责基金服务软件系统交付和维护。

• 著有《猎豹行动 硝烟中的敏捷转型之旅》一书。

• 公众号“敏于思 捷于行”博主。

• 敏捷、精益、DevOps专家。

• 曾在GDevOps、DevOpsDays、中国软件技术大会、ArchSummit等论坛发表过主题演讲。



一场猝不及防的疫情，使所有企业面临着前所未有的困难。以我们公司为例，在以员工健康为首要的原则下，如何支持绝大多数员工都能在春节后在家上班，成为头等大事。



公司一直有支持员工在家上班的硬件和软件条件，平时也有员工轮流在家办公，但是从来没有试过几乎全体员工都在家上班的情况，现有支持员工在家办公的专线容量，完全无法支撑这么多的用户同时在线。



这是对公司基础设施弹性的一次大考。幸运的是，在公司高层和员工的共同努力下，我们很快克服了带宽不足的问题，在短短两个月内，实现了在家上班的网络体验与在办公室无异。



这里体现的，不光是基础设施的弹性，还有人的弹性——我们如何在极端情况下，在预案以外的场景里，充分调动各种能动性的能力。



下面这张图我相信大家都看过。





像疫情这样的极端情况，企业面对生死存亡了，才有足够动力去启动平时只会挂在嘴边的转型。而转型的目的和结果，便是增加弹性。因此，在这个充满不确定性的时代，弹性便是一切！



那么怎样才能提高弹性呢？我在前面提到过，弹性有两个层面——人和系统。



人的弹性



其实敏捷和DevOps要实现的，也是人的弹性。说一千道一万，敏捷和DevOps是应对变化的方法论。在面对极端环境时，我们需要：



1. 提高主观能动性，要积极、主动地在各种限制条件下想办法；



2. 先完成，再完美，聚焦在最重要的事情上；



3. 更快地行动起来。



除了前面提到的迅速实现全员在家办公的例子外，银行有大量落后的业务流程，很多业务严重依赖人工处理，人力成本高、易出错，业务风险高，也难以应对日益增长的业务量。



这次疫情对于依赖人工处理的业务也是一次巨大的考验，如何赋能业务部门也可以全员在家上班和保证他们能在家处理全部业务请求，也成为一次大考。



这次危机确实倒逼了业务部门下决心加速数字化转型。今年，业务部门在数字化转型的IT投资已经占全部预算的一半以上。像数据中台、API商店、移动前端等产品，已经进入实施和逐步上线的阶段。



通过数字化转型，不但可以提升客户体验，借助这个过程，还可以逐步通过IT系统打通各业务流程，提高自动化处理的能力，减少人工失误的业务风险。为未来业务增长增加弹性能力。



系统的弹性



系统的弹性分两部分：系统架构的弹性和基础设施的弹性。



系统架构的弹性



一个紧耦合的单体系统的弹性一定不如分布式架构。“高内聚、低耦合”是软件设计的铁律。也只有分布式的架构可以充分享受云带来的弹性。



银行的遗留系统通常都有以下的技术痛点：



大量遗留系统和非自建系统——很多系统都有十多年的历史，而且有大量的由第三方开发的非自建系统，这些系统设计陈旧、代码复杂，而且很多需要依赖第三方进行开发和维护，交付速度慢、变更风险高、运维困难，越来越难以适应瞬息万变的市场需求。



我们的核心系统就是一个由第三方开发和维护的系统。由于有超过十年的历史，难以一次性取代。



业务部门最近两年在推动客户通过 API 和我们进行数据交互，从而撬动数字化转型。我们以此契机制定了在核心系统外围搭建 API 微服务系统的策略。



微服务架构通过把复杂系统转换成繁杂架构，确保每个服务相对简单和独立，从而加快交付速度。通过部署自动化、容器等手段，大大降低了管理繁杂架构的难度。



这些微服务将从核心系统的数据库读取数据，通过 API 开放给外部客户。当越来越多客户通过API和我们交互后，传统的人工处理流程也会被逐渐取代，越来越多的数字化体验被实现。



我们的最终目标是，客户和业务部门对我们自建的 API 的依赖越来越高，对原有核心系统的依赖越来越低，核心系统逐渐坍缩成一个纯粹的数据库的作用。这种“绞杀者”模式也是业内推崇的迁移遗留系统的有效方法。



在这个过程中，我们引入了微服务开发、微服务网关、 Restful API 、分布式架构、OAuth 安全认证等新技术。



基础设施的弹性



银行原来全部采用自建机房的方式提供计算资源，自建机房无法提供即时的弹性伸缩能力，导致应用团队只能依靠未来预估的业务量来提前规划计算资源，要么不足、要么过剩。



云可以提供自建机房无法提供的经济、灵活、弹性，赋能交付团队和运维团队实现高效交付和运维。



下图是“响应式宣言”的核心。所有系统，对于用户来说，任何时候都要提供实时响应，即使是像购物节这样的高并发、高流量场景。而要实现实时响应，则需要伸缩、弹性和消息驱动作为手段。云就是提供这些抓手的存在。





但要充分享受云所带来的好处，系统的架构也必须配合，需要满足所谓的云架构的要求。



我们的核心系统是一个单体系统，而且其大部分逻辑都是通过存储过程实现的，重度依赖数据库，这样的设计很难享受到云的好处。



而我们自建的API微服务系统，由于采用了微服务架构，符合云架构的要求，可以充分享受云的优势。



因此，我们采用的策略是：





1、 核心系统将继续支撑原有的传统业务流程（包括 Swift 的自动化交易）。由于其架构是单体系统，很难享受到云的好处，将留在自建数据中心。如果第三方可以通过SaaS的方式提供服务，也是一条出路。



2、 自建系统将投向面向未来的业务形态与技术，如 API、通过 Data Mesh 实现数据中台（提供业务部门获取实时数据报表的能力）以及其他的流程自动化（ STP ）。由于其架构、设计能充分享受云的弹性伸缩和云服务，将会迁移到云上。



总结



在这个充满不确定性的时代，弹性便是一切。这种应变能力不光在于通过敏捷与DevOps、架构解耦提高应对需求变化的能力，还有通过云架构和云计算提高应对流量激变的挑战。



觉得文章不错，顺手发给朋友们吧。



近期必读：

刘华：上云还是不上云，这是一个问题

面对疫情这样的复杂问题，有什么招呢？

疫情中的员工关怀，我只服这家公司