谈DevOps支撑平台优化改进02(10.29)

在上一篇文章中，我主要谈了研发过程和持续集成协同，自动化测试，自动化监控运维，公有云平台适配几个方面谈了我们当前的DevOps平台改进的一些重点，今天继续谈下其它一些关键的改进点考虑。

应用和数据库两者的匹配和协同

要知道任何一个应用程序，往往都会同时涉及到应用程序部署包和数据库部署脚本两个内容，而这两个部分协同就相当重要。包括我们原来说过很多次的，对应数据库结构的变更脚本，数据初始化脚本等都必须纳入到统一的版本管理。

当前很多企业微服务架构实施还不算彻底，即上层虽然分了微服务模块，但是底层数据库并没有进行拆分。在理想化微服务架构下，底层数据库完全垂直拆分后，应用和数据库之间映射协同就很重要。数据库本身之间不能打交道，任何数据的协同都必须通过应用模块的API接口服务进行。

任何一次应用的部署，如果涉及到数据库的部署，那么一般涉及到几个关键

1. 数据库结构变更脚本本身要支持能够重复执行，因为整个持续集成过程本身是多次自动化的。

2. 数据库数据初始化脚本同样需要能够重复执行，同时还需要能够支持回退

在整个持续集成流水线设计的时候，我们需要同时将应用部署和数据库部署全部考虑进去，并设计不同的流水线编排节点进行支撑，同时还需要考虑执行失败后是否需要回滚的问题。

环境的自动化迁移能力

环境自动化迁移能力一直都是我任务很重要的贯彻持续集成核心价值观的一个关键能力，即自动化的将我们的应用从开发环境迁移到测试环境，从SIT测试环境迁移到UAT环境，如果更加理想就是能够从UAT直接迁移发布到生产环境。但是对应生产环境往往有独立的运维管控流程，一般也不会考虑到生产环境自动化迁移。

环境迁移可以确保我们测试完成的包就是最终交付给用户测试的包，也是最终部署到生产环境的包。整个迁移过程都是以编译构建完成的二进制JAR包或WAR包文件进行。各个环境不同的基础配置参数文件是独立在部署包外的一个文件。

有了环境迁移，那么就得有环境集成看板，集成看板可以用产品为维度，清楚的看到产品涉及到的各个子系统当前在各个环境所处的具体版本号，以及版本之间的关系和环境间的迁移顺序。这个在我原来讲持续集成方法论的时候谈到过多次，大家可以看下我原来的文章。

生产环境的发布，版本提取和在制品归档库

这个又是整个DevOps实践中的一个关键功能。特别是对应软件开发类企业来说更加有用，即我们最终开发或定制完成的软件，在走完内部的持续集成过程形成了最终测试通过的稳定版本后，我们还需要发布到客户现场。而客户现场本身可能又是独立的实施人员，整个发布过程就涉及到前方和后方的协同，实施人员和研发人员间的协同，这里面不仅仅是降低工作量问题，更加重要的是确保版本一致性问题。

因此在我们流水线设计的时候，还需要考虑能够讲最终测试通过的版本进行归档的能力。具体归档的内容既包括了源代码，也包括了二进制编译后部署包，还可以是我们实际的容器镜像文件。归档完成的版本就是我们测试验证通过，可以发布到客户现场的版本。而对于前方来说，执行的就是版本提取操作，能够在平台提前到后方发布并验证通过的版本，同时将提取的版本部署到客户现场环境。

与API网关之间的协同和集成能力

对于微服务架构开发以常用的SpringCloud开发框架来说，一定会涉及到服务注册中心和微服务网关两个概念，这个的区别我原来也讲过了，服务注册中心是完全去中心化的因此很难有对服务的强管控能力，而微服务网关本身是中心化的，可以增加各种脚手架的拦截，实现日志，安全，流控处理。

在微服务架构整体应用场景里面，实际我们先要进行团队划分，再来考虑接口的注册接入方式，一个团队本身就应该由一套独立的SpringCloud注册中心，团队内部各个微服务组件全部走注册中心交付。而跨团队则通过微服务网关进行，对外提供接口服务能力。

其核心原因一方面是接口管控治理需要，一方面是处于接口服务本身的性能要求。

在我们最初规划的整个DevOps支撑平台设计里面，我们是将整个API网关的能力融入到DevOps支撑平台里面，最近在我重新思考后，还是考虑将API网关单独拿出作为一个独立的平台。然后再进行两个平台间的集成和协同。那么我们就来考虑具体哪些集成和协同点。

对于一个应用，如果涉及到5个API接口服务要注册到API网关上面，那么我们可以考虑在整个应用部署完成后，自动的将5个接口服务注册到API网关上面。而需要人工在去做服务的注册和接入操作。其次这个应用本身也需要消费其它的微服务API接口，我们需要在应用部署完成后，能够通过调用一个服务目录查询的接口来获取到在对应环境的服务地址信息，而不需要应用系统手工去配置和维护地址。

服务注册自动化，实际上注册本身也是一个接口服务，因为在服务注册的时候，仍然需要我们设置基本的类似服务地址，安全，日志配置，服务类型，服务名称等基本配置信息。