0.背景
总结一些无需保密的经验作为总结
1.DevOps相关特性总结
监听代码变动
打包环境容器化
平滑关机
健康检查
流量路由
多环境打包
配置中心
一般每个独立动作称作action，一次独立完整的流程称作pipeline，一条pipeline由多个action编排组成
pipeline可人为指定触发条件，可以选择手动触发、定时触发、git事件触发等
action之间可串行并行随意组合，action节点可选择自动执行、定时执行、人工执行、人工二次确认等选项。action节点的类型不同平台略有差异。
2.代码变动监听
代码变动监听一般使用git hooks，配置在git server上，可以监听包括但不限于push、merge requests、tag等动作事件并回调给指定的api
一般配合分支和tag规范来共同管理开发到上线的全流程，例如feature分支->dev分支->master分支三层结构或更细化的多层分支结构。在不同类型的分支上触发的pipeline有所区别，例如feature分支可能额外触发代码检查pipeline流程，dev分支额外触发单元测试pipeline流程，master分支或tag触发上线pipeline流程。
3.打包环境容器化
打包的环境通常不在开发机而是专用的打包机，打包机的环境除非特殊需求一般使用docker容器通过镜像统一管理打包环境，一般会选择包含docker环境的docker作为打包基础环境，在此基础上定制各种打包的环境依赖、调整打包依赖的缓存文件夹共享策略，以此来保证打包环境的稳定和可控。通常还会配套使用私有镜像中心（如docker registry）和私有包管理中心（如jfrog）来加速打包过程排除网络的影响
4.平滑关机
对于重要的服务不仅需要滚动重启，还必须实现平滑关机来保证服务滚动重启的过程中的稳定性，一般思路是程序自行实现平滑关机流程并允许通过监听SIGTERM、SIGKILL等信号或单独实现http或rpc接口触发。在上线的pipeline或控制器或上级调度程序提前调整网络流量后，再通知对应的节点执行平滑关机流程并自行退出，在一定时间超时后强行杀死，因此通常配合健康检查和流量路由使用。
5.健康检查
健康检查一般也由应用程序自行实现，可分为可达性检查和可用性检查，其中可达性检查主要用于探测网络链路是否通畅，不关心程序本身是否可用，可用性检查在可达性检查的基础还必须满足可用的定义。
可用的定义在不同的场景下定义不同，对web服务来说比较简单的定义就是可接收http请求并成功回应，再严格一点的是要同时满足依赖的数据库服务、缓存服务、队列服务同时可用，但严格的定义会导致底层服务故障时无法让带有降级逻辑的程序执行降级导致服务彻底不可用，因此一般不轻易采用，而是让程序自行选择是执行降级逻辑还是直接认为服务不可用。
6.流量路由
流量路由主要负责处理流量的流向，上一篇总结的路径上的流量通常被称作是南北向流量或者纵向流量，应用程序之间的通信通常被称作东西向流量或横向流量
对某个服务集群来说一般通过网络层路由、客户端或服务器服务发现、负载均衡来完成精确的控制流量流向。特别的对于云原生的服务网格来说主要处理的是东西向流量。
7.多环境打包
针对同一份代码需要运行在多个数据中心、多个公司、多个环境，因此需要通过某种方式来区分运行环境。可选策略一般有几个思路，一种是用同一份产物通过配置中心、配置文件、环境变量等做出区分来改变程序能感知的环境，另一种是打包时根据需要直接按不同环境组合生成多种环境运行的产物。
对于使用配置中心、配置文件、环境变量来处理的方案，需要额外注意启动时候的传入参数和配置中心的设置，方便集中管理但很容易出意外
对于使用直接打包多种产物来处理的方案，虽然不用担心环境参数错误，但需要额外考虑环境参数的保密问题也就是产物的保密问题
0 Comments