对DevOps实践的一些思考03(1.17)

今天基于实际的持续交付场景来谈下DevOps实践过程中的一些思考。

微服务模块划分

在微服务模块划分清楚后，各个微服务模块划分到不同的团队和人负责，那么每个团队对于自己负责的模块，在配置管理库和代码管理，数据库，开发项目上完全独立一套。负责A模块的团队不应该，也完全没有必要看到B模块开发的代码，而只需要关心接口即可。

微服务模块划分清楚后，实际上有个重点工作就是前期的架构设计和接口设计，需要先把各个微服务模块间的交互接口初步定下来，这个总体设计完成后再开始各个微服务模块的并行开发。而不是在开发中，想到需要什么接口就临时开发，这样很容易导致后续的接口混乱。

环境准备和微服务模块的开发

独立的项目，独立的代码管理，独立的数据库，但是不同的团队是基于相同的微服务开发框架，类似SpringCloud或其他开发框架进行微服务模块的开发。

A模块要调用B模块的接口才能够完成相应功能的开发和验证，这个时候就需要B模块提前准备好可用的接口并部署，在多模块协同下注意，一定是接口开发先行，即要确保接口提前开发出来可供其它模块测试用。

各个模块开发完成的接口不能部署在自己本机，因此要有独立的开发环境来部署这些接口，当然在开发环境还需要有类似SpringCloud中基础注册中心和管理中心的部署。

开发人员的本机在自测的时候可以调用开发环境提供的API接口服务能力，因此自测还是可以在本机完成，比如A模块调用B模块的API接口服务。但是需要B模块提前已经将可用的接口服务部署到开发环境。当然对于A模块而言如果也提供API接口给其它模块使用，也需要提前部署到开发环境并准备就绪。

A模块的开发项目里面，没有B模块的任何代码，而只是基于API接口远程调用接口能力。 而这里最好的思路是实现一个本地化的接口代理包，即代理包封装一层后实现调用的时候是本地方法，当时本地方法再转为远程API接口服务调用。

如果A模块依赖的B模块，C模块提供的API接口服务都没有准备好，按道理A模块是无法进行后续开发的。基于传统集成思路，A模块也可以自己实现了一个本地API的接口模拟，在B模块或C模块准备好后再配置为调用远程API接口服务能力。

编译构建

按持续集成思路，开发要管的就是自己开发好的代码在本地编译通过，同时在本地测试通过后，将代码Check in到源代码管理库，后续的编译构建完全是自动化的过程。例如完成通过Git + Maven + Jekins的结合来完成整个编译构建过程。

独立的源代码管理库，各个微服务模块的项目相对也要独立，各自管理并进行权限隔离。对于数据库变更脚本注意也要进行版本管理和脚本入库，实际上最难以管理的还是在数据库的变更上。

构建服务器和源代码管理服务器可以在相同服务器，也可以在不同的服务器上。

实际的编译构建过程，首先是update到最新的源代码，然后基于常规持续集成的思路，例如Maven+Jekins完成自动化编译构建，最终形成部署包。这个过程中远程API接口调用是松耦合方式调用，因此不会对组件依赖性进行检查，也不会出现编译依赖无法通过的问题。

部署过程

构建完成后形成可部署的部署包，按容器集成思路，首先要制作镜像，并推送到镜像库存储，然后再完成部署操作。部署完成后形成并发布可访问的地址信息。该过程会涉及到一些自动化脚本的编写，可以用Jekins，也可以用Puppets等各种 工具 来实现这些脚本自动化。

实际的部署操作最终由K8s来接管，包括具体的初始化部署容器数量，负载均衡设置等。

在采用微服务架构开发的时候，多个微服务模块同享一套服务注册中心，包括微服务网关等，这些基础内容需要提前部署到开发环境中，并在可用状态。

微服务模块中API接口注册到网关

如果整体架构中，所有的微服务模块都不需要和外面的业务系统打交道，那么你可能并不需要使用微服务网关，但是如果存在整个架构朝外部提供API接口服务能力，包括你的APP端也需要理解为外部。那么就一定涉及到微服务网关的使用。

微服务模块中的接口方法不是所有的都需要注册到微服务网关上面，要梳理清楚，究竟哪些接口方法要注册到微服务网关上面。而这块注册操作我们希望是完全自动化注册并运行。

即微服务模块部署-》k8s发布可访问的API地址-》微服务网关封装后暴露最终的API服务地址

而这个API服务地址是可以给外部系统或前端APP使用的一个地址。对于其它应用的开发我们可以使用该地址。如果说到DevOps支撑平台，那么在集成微服务网关能力后，最基本的就是要有服务注册和管理能力。

环境迁移能力

环境迁移难的不是单个微服务模块的环境迁移，而是相关微服务模块多个部署环境同时的自动化迁移。比如A模块调用B模块的接口发生变化，这个需要同时对A和B两个模块进行环境迁移和重新部署。按持续集成的思路，从开发-SIT-UAT-生产的多套环境，一定有一个环境看板视图，能够可视化的看到各个微服务模块在每个环境的部署版本情况。

环境迁移按道理应该进行独立的流水线设计，特别是涉及到多个模块的时候。

性能监控和日志管理

对于资源和中间件监控，对于Zabbix或Nagios等完全能够实现，最难的还是APM性能监控和服务链监控等，对于这些监控的实现，一定要提前在微服务开发框架中进行标准规范定义，相关的代理组件的植入。

如果采用标准的开发框架模型，你也可以考虑在镜像制作的时候将代理植入到镜像文件中并启动运行。