以DevOps为基础的数字化生产线
打造敏捷转型的五横四纵体系，支撑最大化的业务产出和软件价值的快速交付：
横向端到端的工具链打通、五大环境标准化与资源流转、数字化软件生产线与科技管理各级流程融合、产物及质量门禁标准形成、引领指标形成及精益持续改进，部门间的组织融合纵向需求、开发、测试、运营的敏捷化转型，规则、标准、规范的设定，系统间复杂集成架构的构建与支撑
DevOps的本质，是在软件生产过程中是落实精益运营思想，杜绝浪费，建立数字化生产线。
金融行业在引入DevOps之前，需要先考虑以下五点建议：
小步快跑好过一蹴而就没有“银弹”数字化生产线的建设不能只依赖于工具层面精益运营思想逐步形成精细化管理
03 微服务平台：支撑企业应用系统建设
当前应用技术架构微服务化出现的问题与解决原则
从管理角度看包括：
1）过去的架构和微服务架构的关系。2）基于开源的技术众多，选型复杂、困难，并且随着开源版本的升级，企业自行维护存在困难。3）研发团队如何组织？
从技术角度看包括：
1）数据一致性问题。2）服务调用链较长，性能下降。3）系统复杂度大幅度提高，因为微服务将系统内的复杂度转移为系统间的复杂度了。4）微服务应用测试很复杂。5）没有配套工具之配套，无法快速交付。
需要我们掌握分布与聚合的原则，将面向的问题域分门别类建立起来，为各种技术实现找到明确的定位。分布与聚合这个矛盾的对立统一，我们希望达到：
服务分布、流程统一，即服务是分布式部署的，但是在业务逻辑上能够统一起来；数据是分布，但是对外呈现的信息是聚合的，事务是完整的；各分布式模块的感觉（末梢神经）是分布的，但系统的知觉（大脑）是统一的
服务分布，流程聚合：服务调用模式
服务调用分为“服务提供者”和“服务消费者”两个角色，“服务提供者”将自己的服务地址等信息登记到“服务注册中心”中，调用者（“服务消费者”）从“服务注册中心”查询到提供者的信息，根据这些信息调用服务。
服务调用有两种模式，客户端模式和代理模式：
在客户端模式下，“服务消费者”在向“服务注册中心”查询到自己需要调用的“服务提供者”地址之后，“服务消费者”就会自己根据地址去直接访问微服务，此时需要客户端自己实现负载均衡逻辑。在代理模式下，“服务消费者”通过 API Gateway 组件与微服务、“服务注册中心”连接。“服务消费者”只管去找 API Gateway 访问即可。至于去注册中心查询服务地址，以及访问服务地址的动作都由 API Gateway 代劳了，最后 API Gateway 在把结果返回给“服务消费者”即可。
服务分布，流程聚合：集中式的服务配置管理
服务运行通常要设定一些参数，这些参数以往以配置文件的形式存在。此外，我们在进行业务开发的时候，一般会有多个环境，例如开发环境、测试环境、生产环境，这是传统的配置文件无法解决的。
集中式的服务配置管理，让我们告别投产或运维手工修改配置的方式，统一管理所有微服务节点的配置，提升运维的效率。
配置文件主要有运行前的静态配置和运行期的动态配置两种。静态配置通常是在编译部署包之前设置好。动态配置则是系统运行过程中需要调整系统变量或者业务参数。要想做到集中的配置管理，需要注意以下几点：
1）配置与介质分离，这个就需要通过制定规范的方式来控制。千万别把配置放在Jar包里。2）配置的方式要统一，格式、读写方式、变更热更新的模式尽量统一，要采用统一的配置框。3）运行时需要有个配置中心来统一管理业务系统中的配置信息，这个就需要平台来提供配置中心服务和配置管理门户。
数据分布与信息聚合
数据是企业应用的核心，企业应用也是围绕着数据展开，当系统数据越来越庞大的时候，我们就需要考虑将数据拆分，分而治之。表面上使用微服务架构后，必然出现数据的分布，实际上正是由于数据需要分布，才产生了微服务架构。一方面，随着目前移动互联网、物联网的发展导致数据量越来越大，另一方面“下主机”“自主可控”等架构要求导致单机处理能力有所降低，因此需要进行数据分布。
根据 CAP 原理，一致性、可用性、分区容忍性三者无法同时满足，我们不奢望找到全能的方案，但可以应该根据不同场景归集到几种模式，制定相应的处理策略。
1．数据分布的模式
数据分布主要有两种模式，垂直拆分与水平拆分。
