光大银行基于微服务架构的Devops实践

白凡

今天我分享的主题是《光大银行基于微服务机构的DevOps实践》。主要是从我们光大银行DevOps开展背景，整体实践方案以及核心业务设计思路这几个方面进行总结和分享。简单来讲就是为什么做以及怎样做。

1. 现状和问题

首先我来讲讲我们为什么要做DevOps？谈到项目背景主要分为几个方面的原因，首先生产效能，光大银行还有我们光大集团，大部分公司、大部分团队采用的还是一种传统的开发模式，项目经历了需求、开发、测试以及上线这四个阶段，这四个阶段的时间点划分清晰。产品经理、开发人员、测试人员和运维人员这4个角色也基本上没有交集。

这样带来的问题就是我们的一个整体研发效率比较低，我们项目投产周期长。

第二个原因是IT资源分散，我们光大集团、光大银行有很多IT资源平台，我们各个部门都有很多自己的IT资源和平台，但是很多平台和资源整体利用率比较低。
第三个原因就是我们的公司战略，光大银行近几年的发展战略就是数字化转型，其中持续集成、持续交付是我们今年非常重点的一个项目，因此做好DevOps，使DevOps能在银行和我们传统行业落地，这是我们团队今年非常重要的一个任务。

我现在介绍一下在我们当前的这种开发模式和流程下，我们从开发到投产，我们的交付路径有多少长。首先在开发阶段，开发人员首先需要到需求中心去拿需求，然后进行开发。在开发完毕之后他需要到我们的测试平台提一个测试单，测试单的内容包括他这次的需求、编号以及与需求关联的一个代码、文件、清单。
接下来我们的配置管理员将会根据代码文件清单进行一个代码库的合并，他会把这部分代码从我们的开发库合并到我们的测试库。到了测试环节，相关的测试人员会到我们的测试库去拉取代码，本地进行编译、部署以及测试。

当然还会到我们的各个平台，比如说自动化测试平台，去进行回归测试。到压力测试平台进行压力测试，还有到代码扫描平台进行代码扫描等等，最后他会汇总这些测试数据。
项目进展到了我们的预投产阶段，这时候我们项目经理会新建一个预投产制版单，预投产制版单有我们这次要投产的一些需求。配置管理员会根据预投产制版单，再将我们的代码从我们的测试库再合并到预投产库。
相关验证人员会到我们的预投产库继续拉取代码，在本地进行编译、部署以及相关的验证测试，还有安全测试等等，最后进行打包，上传到我们的FTP，到了我们的生产阶段，这时候我们配置管理员继续将这部分代码合并到我们的生产库，然后运维人员会到我们的FTP上拉取我们的投产包，进行一个环境的部署，还有运维上线流程。
大家可以看到，在我们当前的一个模式下，我们这些平台，我们这些工具在一定程度上一定是保证了我们的开发质量，但是也在另外一个程度上增加了我们项目的一个繁琐度和复杂性，有大量的人工交互处理事件，从而在一定程度上延长了我们的投产周期。

我们和现在很多互联网公司在DevOps领域、在敏捷领域都有比较深入的研究，当然我们也和很多互联网公司，还有相关的同业进行过一些交流，包括一些相关产品的适用和实施部署，但是效果并不是很好。
其中一个主要的原因是我们传统银行和外界的生态有着比较大的区别，很难直接套用一些成型的产品方案，区别主要表现在我们传统银行采用的是一种稳态的投产模式，我们的每个月进行定期的按月投产上线。在需求投产前我们会有大量的审批，有审批流程还有监管环节。

我们为了保证投产安全，我们采用了开发库、测试库、预投产库以及我们生产库这4个库隔离的一种管理方式。
传统互联网行业采用的是敏态的生产模式，每天有非常多的需求上线，需求可以随时来上线。为了保证我们线上的安全，互联网行业由小流量上线、灰度上线，上线之后还有强大的监控，如果出了问题会有健全的回滚方案。
经过我们的实践和摸索，我们发现在我们这种传统行业要进行DevOps或者是敏捷，既不能太过于敏捷而忽略了这种流程和监管，但是也不能太过于关注这些流程监管而去固守成规，而带来我们生产效能的低下。
因为我们采用的是一种双稳态、敏态坚固的方案，我们称之为双态融合。在提取互联网先进DevOps理念的同时，保留我们传统行业对于监管流程的要求，依托工具化、平台化、服务化三位一体的技术支撑。在保证投产安全的前提下做到提高我们生产效率，做到我们DevOps传统行业的落地。

从敏捷开发到持续集成、持续部署，再到现在的DevOps，他覆盖的环节是越来越多，到现在的DevOps覆盖的环节已经是从需求计划到我们的发布、部署、运营，是一个软件开发的全生命周期，而且我们也看到了从敏捷开发到DevOps，我们传统的一个开发壁垒被逐步打开了。所以，这个就是我们在设计DevOps中参考的一个行业标准，到这里我们为什么做就讲完了。

2. 实践方案

接着我来分享一下我们怎么做？关于怎么做我想从两个方面来讲，首先从宏观上我们讲一讲我们的整体实践方案，具体到面上再讲讲我们的一个核心业务设计思路。首先我们看看我们的整体实践方案，我刚才在思想背景的时候谈到了现在我们这种传统行业在做DevOps遇到的一些问题，以及我们在开发过程中遇到的一些难点，那么我们的一个DevOps整体解决方案就是从架构、设计、功能和流程四部分逐一入手，试图把我们这些问题一一解决。

首先是架构，作为传统行业我们有一些平台，它的体系非常庞大，扩展性是比较差的，其中某一个部分的改动或者是升级会造成我们整个平台的不可用，所以作为一个服务于光大银行所有IT项目的一个DevOps平台，我们是需要具有非常好的稳定性。
另外是银行变更非常频繁，银行需求变更非常频繁。随着我们业务的深入，我们需要有一个非常好的扩展性，所以在设计上我们采用了微服务架构，减少业务箭透耦合，提高了我们的扩展性以及应对需求变化的能力、设计。

我们光大银行还有我们光大集团其实是有很多团队，不同的团队所采用的开发模式和投产模式是不一样的。举一个例子，我们大部分团队采用的是主干开发、主干发布这样的一个传统的开发模式，也有一部分团队采用的是分支开发主干发布，以及分支开发、分支发布这样的一个开发模式。
我们大部分团队采用的是从开发库到测试库，到预投产库再到生产库，是这样的一个传统的投产模式。我们也有一部分团队是一个敏捷团队，所以他其实是没有测试流程的。
对于这样的一些团队，他采用的是从开发库到预投产库，再到生产库，是这样的一个敏捷的投产模式。
另有一部分团队，当然比较少，但是他很特殊，因为他的项目是属于外购性质的团队，他们的项目都是从外面购买的，所以这样的一个产品我们是没有开发和测试流程的，直接进入我们的预投产和生产环节。

因此我们作为服务于光大银行、光大集团的一个DevOps平台，我们需要在设计上满足现在的这些开发模式和投产模式，并且我们对将来可能会有的任何变化形式也需要有一个良好的扩展能力。

下一个是功能，依据了我们集团的一个现有的IT成熟度，我们参考了DevOps标准，我们设计了一个集需求管理、代码管理、组织权限管理还有我们流水线管理的一个四位一体、持续联动的DevOps一站式平台。

最后是流程，我们作为传统行业是有很严格的监管流程，比较繁琐的监管流程从另外一个角度也影响了我们的一个整体的开发效率，因此我们需要梳理这些流程，去优化流程。
接下来我们讲讲我们的架构设计，首先我们有几个核心的业务，包括我们的流水线管理、代码管理，还有我们的需求管理和我们的组织权限管理。其中我们的组织管理中心、需求管理还有流水线管理，这三部分的业务非常独立，架构比较独立，业务也没有耦合性，比较少，那么我们就把这三部分独立出来，注册到我们的Eureka，注册中心。
这样我们的请求经由Nginx到达网关以及认证中心，经过用户认证和决策权限的分发之后，我们这个全球继续分发给我们核心微服务集群。

核心微服务集群再根据他自身业务的特点去请求我们的持久化层，Redis以及数据库表。底层我们对接了Cpass容器云，全面实现了一个容器化编译和部署。
接着介绍一下核心业务集群，它是怎么持续来互相联动工作的。首先开发人员在代码中心拉取代码，进行本地化的一个开发之后，他需要到交到我们的需求中心去进行需求和代码的关联。

需求和代码关联之后，开发人员就会把代码提交到远端仓库，这样就会触发我们开发阶段的流水线。
开发阶段的流水线是由开发人员自行来配置的，通常包括BNE、单元测试等。在开发阶段结束之后，开发人员会到我们的需求中心去挑选需求，然后进行需求的提测。需求提测之后，这部分代码会自动从我们开发库合并到我们的测试库，进而触发我们测试阶段的流水线构建。测试阶段的流水线通常包括BNE部署、自动化测试、代码扫描等等。

到了预投产阶段，那项目经理可以到我们的需求中心去挑选需求，然后进行投产制管单兴建。接着这个代码就自动地从我们的测试库合并到了我们的预投产库，这样会触发我们预投产阶段的流水线构建。

预投产阶段流水线通常包括BNE部署，还有我们的回归测试，还有安全测试，最后再进行打包。这个包就会被上传到制品库里，这个环节通过之后就会触发我们运维一个线上部署流程，这就是我们一个DevOps全站式交付流水。
这里我们介绍一下我们核心的这几个微服务单体，从我们整体来看看它们的功能是什么。
首先需求中心，需求中心顾名思义，它就是去管理需求的平台。在需求中心里，我们能够很清晰地看到全生命周期内的需求，它所处于的状态。因此，我们能够发现项目的一些质量、进度、风险的一些问题。
流水线中心，我们的流水线是以需求构建为维度的。需求构建结果，我们是以流水灯式样，可视化地展示在我们流水线中心。并且流水线中心支持流水线构建的日志的实时拉取，还有流水线构建历史的一个展示等等。
管理中心，我们主要是进行一个组织权限管理，那么它做的事情就是首先用户的认证和用户角色权限的分配，以及我们项目的初始化配置，还有我们代码库的创建，还有我们跟代码库的一个团队的管理等等这样的功能。
最后，代码中心，我们的代码中心主要是为了我们这几个核心的业务提供了一个接待口头，它主要的功能就是在于我们的分支管理。我们可以去创建分支、分支合并，以及代码能够在各个库之间流转。我们说我们的代码可以在开发库、测试库、预投产苦流转，这种流转是我们代码中心来做的。另外就是我们的代码除库管理、冲突管理，还有入库策略等等。

刚才我们从整体的角度讲了我们的一个整体架构，那么这张图我们是从一个内部逻辑的角度，讲一讲我们的逻辑架构设计。
首先我们平台分为展示层、网关层，还有认证中心层、注册中心层、核心业务层，以及我们的数据库层。其中各个层级他们的职责，还有他们的功能是非常清晰的。
比如说网关层，我们就负责流量否认，还有权限校验。
认证中心层我们负责用户认证、角色校验、权限分配。
注册中心层我们负责服务注册和服务发现。

核心业务层这几个组织管理中心、流水线中心、需求中心和代码中心，它们持续联动，构成了我们DevOps一站式平台。

我们实现了DevOps一站式平台，这里我们讲一讲它的工具链。首先我们DevOps一站式平台包含两个部分，一部分是持续集成，另外一部分是持续部署。
在持续集成中我们覆盖的功能有需求管理、开发阶段，以及构建阶段，还有我们的测试阶段。那在需求管理中，我们开发了我们自己的一个需求中心，用来去管理需求。同时为了服务于光大集团的各个公司能够有更好的通用性，我们也对接了confluence和jira，进行我们需求的一个全生命周期的管理。
版本管理，那么我们在开发中，我们支持了版本管理工具gitlab/gitee，以及我们国内的版本工具码云。在构建阶段我们支持maven、ant和gradle的构建。测试阶段我们对接了junit单元测试框架，以及selenium自动化测试框架，还有我们压力测试中心jmeter，以及代码扫描工具sonarQube。
在持续部署阶段我们包含了线上发布，以及我们的运维监控。那在线上发布我们采用了Nexus搭建了我们的制品中心，制品中心用来去管理我们的制品产出包，用来管理产出包的上传，以及产出包的下载。还有运维监控部分我们对接了运维的监控工具zabbix、Elk。那整体我们的DevOps工具链是采用Jenkins作为底层调度。

3. 核心业务设计思路

刚才从整体的角度我们已经介绍了我们的整体实践方案，接下来我们就具体到面上，讲讲我们的核心业务设计思路。核心业务我们认为在我们的DevOps平台里面，其中需求中心，还有我们的流水线中心是我们设计中的重点和难点，所以我们就着重讲讲这两部分。
首先讲讲需求中心，我们先来看看需求中心整体的功能。需求中心整体的功能就包括我们的需求的管理、需求的新建，以及测试管理，还有预投产管理。当然也包括别的功能，包括一些变更集的查看，还有我们的需求合并。
当然我为了整合光大银行现有的一些IT资源，我们也支持了对接了光大银行有的一个需求管理平台EASP进行了一个需求全生命周期的一个管理。

那这个需求展板，这是我们的一个需求中心的入口。通过这个入口，我们能够看到全生命周期内的需求。那其中各个阶段的需求，开发阶段、测试阶段、预投产阶段，以及投产阶段需求，我们都能够很清晰地看到。因此产品的一个进度、项目开发的质量，我们都能够一目了然。
同时，我们如果点击每一个需求展板，我们还能够看到每一个需求的细节，包括这个需求的开发人员、测试人员，以及这个需求关联的一些bug，以及我们这个需求构建的流水线。

我们说我们的需求中心、代码中心，还有流水线中心，我们是持续联动的。那么这几部分持续联动，它的基础就是我们需求和代码的一个关联。那对需求和代码关联之后，对需求进行提测，提交预投产，可以使需求相关的代码在我们的开发库、测试库、预投产库，还有生产库进行流转。
那么我要提到的是，因为我们银行，还有我们集团，各种开发模式和投产模式，那这种不同会造成我们提测、提交预投产它的代码流向是不一样的，所以这部分设计是我们设计中重要要考虑的部分。

我们提供了两种解决方案，第一是我们的一个IDE插件，这个IDE插件运行在开发人员的开发工具中，比如说Inklpss里面，开发人员在进行代码的提交就会弹出他的一个需求列表，选择这个需求就会进行需求和代码的关联。
另外一个方案，我们的需求中心中就有我们需求关联的功能，开发人员在需求中心中可以去选择他的需求以及提交的历史版本，进行需求和代码的关联。
在需求和代码关联以后，我们的代码就可以在我们的各个库进行流传。我还是以传统投产模式为例，开发人员提交代码，与需求相关的代码是在我们的开发库中，开发人员进行代码的提测，那么这个代码就会流转到我们的测试库，进行我们预投产单的新建，这个代码会自动的流转到预投产库，那么这个代码上线，代码就会流转到我们的生产库。

同时我们的开发模式就是主干开发、主干发布，分支开发、主干发布以及分支开发、分支发布，这种开发模式的不同会造成我们代码流向对应的主干或者是分支。
在需求在各个库流转的同时，我们需求的状态也从未关联、开发中、测试中到已投产，这样他自动的去更新、自动变更。
需求和代码关联之后，另外一部分就是我们的需求和流水线，构建就自动的去联动了。开发人员进行代码的提交就能够触发我们开发阶段一个流水线的构建。
开发人员进行代码的提测，触发我们测试阶段流水线构建，最后开发人员提交预投产会触发我们预投产阶段流水线的构建。
作为需求中心最后一部分我想讲讲我们流程的优化，因为我们作为一个传统行业，对监管、流程有相当严格的要求，所以这就决定了我们没有办法直接去套用现在的一些比较成型的方案。

我们的审批环节主要集中在测试环节，预投产环节以及变更环节。我们对我们的流程进行了梳理和调研，发现其实在现在这个阶段，测试阶段的审批实际上没有了太多的意义，所以我们就做了优化，然后把我们测试阶段的审批给去掉了。

另外，对于有些项目，比如说他涉及到了线上交易，比如说光大银行、手机APP，这样的项目跟线上交易是有关的，对于这种项目他是有比较严格的监管流程来保证他的上线安全。
但是也有一部分项目是内部研发项目，他面向的可能是内部少量的用户，对于这种项目我们就没有必要有这么多的审批流程，我们可以把它的审批流程给去掉。
还有一部分项目开始的时候可能需要很严格的审批，但是在这个项目不断的迭代、优化之后，他上线已经趋于稳定，线上基本上没有什么太多的投产风险，对于这部分项目我们对他的流程、审批层级进行了删减，他的审批流程进行优化，所以作为一个通用性的平台，我们的审批一定是可以配置的。

接下来我就讲到我们另外一个重点，就是我们流水线中心的设计思路。我们来整体看一看流水线的功能，流水线中心的功能实际上是比较清晰、直观的，他的功能包括一个流水线的配置，流水线的展示还有流水线历史查看以及我们相关机器的监控。

首先看看流水线配置功能，我们说我们以传统投产模式为例，他会支持开发阶段的流水线配置，测试阶段流水线配置以及预投产阶段流水线配置，对于不同的开发模式，主干开发、主干发布，以及分支开发、分支发布，我们会同样支持主干流水线的配置以及分支流水线的配置。同时我们还需要支持每一个项目，每一个分支可以配置多条流水线，运行的时候由开发人员自行选择流水线，开发人员自行输入一些运行时的参数等等。

为了配置简单性的、易用性的，我们还设计了流水线复用功能，在各个项目之间他们都可以共用，共同去复制一些流水线，减少他们的一个配置的工作量。
流水线中心是我们DevOps的一个核心重点，流水线中心需要有一个非常强大的工程能力，比如说常见的，我们有代码编译、扫描，还有我们的部署，还有我们的单元测试等等。
在我们的设计上，我们是将每一步功能都做了一个插件单独设计的，这样做的好处是我们这每一部分都可以单独去管理，并且我们的流水线是有一个强大的扩展能力。

在今后我们会去增加我们的功能，比如说我们接入自动化测试、安全测试。我们会对接光大银行、光大集团现有的一些IT工具，我们购买的IT工具，或者我们已经开发的IT工具，我们都把它接过来，作为一个IT的资源整合，同时也方便了我们的使用。

最后一部分我想讲一讲流水线展示，流水线展示的功能也是比较清晰的，首先我们流水线运行的一个可视化，流水线日志的拉取以及流水线历史的查看，还有我们流水线构建各个阶段任务的一个展示。

这张图就是我们的一个流水线图，流水线运行中的一个截图。中间这部分就是我们流水线构建的一个可视化，在中间这部分我们能够清楚的看到构建到各个阶段的一些时间、状态等等。

下面这部分就是我们流水线的一个构建历史面板，在流水线构建历史中我们可以看到历次的构建情况以及各个阶段的数据。
这个是我们的构建日志的一个拉取，同时我们的流水线支持我们构建日志的一个实时的拉取。

我们的DevOps平台还包括一些别的模块，他们比较独立，所以我把他们单拎出来讲，他们也是我们设计中比较重要的一个部分，首先是数据仓库，我们DevOps平台在运行中有非常多有价值的数据，包括我们有流水线的一个构建数据，还有代码扫描的数据，还有项目的一些数据，我们的需求中心、代码中心，我们流水线中心的这些数据其实是非常有价值的。
通过对这些数据的整合和分析，我们可以反推出项目的一些质量，进度问题，从而正向的推动我们这个项目的进度，提升我们整个光大集团的开发效率，所以我们搭建了我们的数据仓库。
我们的数据仓库包含两部分的数据，第一部分就是项目的基本数据，基本数据里包括我们项目构建的数据，代码扫描的一些数据还有缺陷管理的数据，项目进度、投产这样的数据。
另外一部分就是我们的项目评比数量、度量数据，我们把它叫做我们的度量数据。实际上是这些基本数据采用一定的模型、公式推导出来的一些数据，我们会给每一个项目进行一些打分、评选，我们会根据一定的构建情况给大家做一个趋势图，这样的数据就是我们的度量数据。

这一张图就是我们的一个基本的构建数据，流水线的构建数据，我们可以看到流水线的构建次数、编译成功率，还有我们的编译部署差等等。
这个就是我们的一个统计图，能够看到我们流水线在执行中统计的一些数据，这部分就是我们各个团队的构建趋势图，还有我们一个团队的打分情况，我们有数据仓库里的数据。

另外就是我们的流水线在构建中，各个阶段的产出物都是非常有价值的，因此这些产出物可以帮助我们追溯问题。现场出了问题之后我们也能够及时的进行一个回滚，所以就保留了我们流水线构建中的测试阶段还有预投产阶段的流水线，流水线构建的产出物，那么这些产出物呢，我们采用了Nexus进行了一个制品库的管理，这些产出物会直接上传到我们制品库相应的目录下。

后续的部署步骤会直接从制品库去拉取产出包进行部署，如果是我们预投产阶段的流水线，那么这个产出包会直接提供给运维作为一个线上部署的产出包。
最后一部分就是我们的缺陷管理平台，代码扫描实际上是我们软件开发中非常重要的一部分，因为代码扫描的工具非常好用，所以我们软件开发中基本上都会用到代码扫描。就是因为我们流水线的一个插件式的设计才让我们的代码扫描很容易就集成到了我们的流水线中，这样也让我们更加方便的去使用代码扫描，我们不用专门到我们的平台去进行代码扫描，流水线构建中是世界就可以扫的。

这样的话，对于代码扫描的结果，我们其实是需要搭建我们的缺陷平台，是需要去统一管理的。我们的缺陷平台统一管理了我们各种扫描的工具，比如说我们的sonar扫描工具，还有我们的一个安全扫描工具，还有我们自己别的一些扫描工具。
对各种扫描出来的问题会进行统一分类展示，依据问题的等级来展示。对问题的统一处理使得我们扫描出来的问题能够真正达到一个闭环，有效的提高我们整体的一个工程能力。

4. 总结和展望-收益

到这里我的主要部分就讲完了，现在我们就对我们的项目进行一个总结，我们这个项目现在已经推广到了光大银行科技部，还有我们光大科技公司以及光大集团的部分企业，接下来我们会继续推广到光大集团的各个公司。

我们的项目在构建中、使用中也受到了比较好的一些评价，比如说我们的开发人员、测试人员，还有PMO对我们的项目还是非常认可的，确实也省掉了大部分的时间，我们做到了代码以及构建还有流水线的一个持续联动，因此让大家觉得有很好的体验，也减少了很多效率，提高了我们的投产周期，这个项目并且获得了光大银行科技部各级领导的一致好评，所以可以不太谦虚的说我们这个项目是我们光大银行科技部做的非常好的一个项目之一。