架构系列（八）优化改进自动化，本地一键安装以及生产蓝绿与灰度

首语

目前大部分公司，涉及到自动化，基本就是使用jenkins这类工具，然后打通与服务器的网络，执行shell脚本开始自动化编译、部署、运行。但是这还远远不够。本地环境、线上蓝绿灰度、流量切换等等。

本篇博客不涉及到自动化的脚本代码，因为团队原因，博主暂时不透漏脚本，博主从流程上来为大家展现针对本地以及服务器上的自动化，所涉及到的脚本或者代码，也是及其简单的样例

软件包的概念

博主这里提出一个概念：软件包
无论是微服务、单服务、前端、编译环境、运行时环境等等，如果打成一个包（这里包是一个虚拟概念，不是一个zip包），然后一键“解压”使用，一键“压缩”发布，是不是很简单，这就是：软件包的概念

本地自动化

本地自动化并不高大上，其实为了解决环境不一致、代码不一致、时间成本等问题

优势

本地自动化，可以统一开发环境、快速建立开发环境，并且对服务器的启动和停止等都可以一键操作

本地自动化对新入职或者新电脑等等场景，有着非常大的好处，利用组件化模块化的思维，将本地自动化进行拆分重组，就又可以变成qa、demo、prod等环境的发布构建脚本。

架构图

我们通过docker镜像配合docker-compose等脚本，组成自动化本地脚本，执行一个脚本（软件包执行），就可以快速搭建整套本地开发环境。

通过本地代码与镜像挂载，实现修改本地代码，镜像环境和服务也会改变。但是要注意，一旦删除images，在本地docker中修改过的一些环境变量都会被清除

脚本

博主这里就暂时不透漏脚本代码以及docker配置，但是博主可以给出响应参考

• 执行安装包脚本：拉取指定docker镜像（包括服务、数据库等相关所有镜像）
• 执行代码脚本：获取相关所有的代码（这里指定好代码的目录）
• 执行docker与代码挂载脚本：将docker内部服务（比如jar、python的django项目）与代码进行挂载
• 一键启动脚本：一键启动所有相关服务（这里可以通过compose配置启动顺序和依赖）
• 一键停止脚本
• 单服务的启动或者停止（这里可以通过compose配置启动顺序和依赖）
• 日志挂载脚本：挂载相应的输出日志（也可以docker logs查看）

生产环境自动化

生产自动化（云，排除docker）并不是简简单单的使用docker搭建一个集群即可。这其中涉及到服务器等资源。目前博主团队和前团队，因为使用云服务，所以直接将服务器作为docker使用，让jar服务与服务器1对1

蓝绿及灰度发布

市面上有N多解决方案，这里博主只分享团队的解决方案，并且不会涉及到自动化的脚本代码。只是提供自动化的思想。

前端

博主之前博客有简单介绍一个炒鸡简单的前端发布。其实前端并没有类似后端一样那么疯狂的发布流程。但是从自动化思想上面，应该更加偏向由项目自己发起自动化，而不是依赖外部工具，外部工具只是执行你自动化的一个工具，仅此而已。这里博主就不画图了

以下例子作为参考，我们以版本v1.0.1为例

• 开始打包：打包整个前端资源，版本为v1.0.1(那么上个版本为v1.0.0)，这里以vue为例，npm run build 打包之后，mv dist dist-v1.0.1
• 修改ngxin配置，之前映射路径为dist-v1.0.0，在下面继续加一条路径是v1.0.1 这个时候，访问路径也改变，不去动之前的路径（灰度测试） 配置可以参考博主：https://blog.csdn.net/zl592886931/article/details/89790077
• 打包文件发送：这里其实分两种：第一种，文件直接送到s3（对象存储OSS），带版本号，然后执行脚本让服务器自己拉取（这样的方式在国外比较流行），第二种直接送到对象服务器上。解压到相应之后，restart nginx
• 测试：开始测试v1.0.1路径的web，所以做一个人工卡点。卡着流程，开始测试，测试各个功能模块
• 蓝绿切换：测试没任何问题之后，将正式连接切换至v1.0.1，并且保留v1.0.0，如果出错，1s内立即切换回来

后端蓝绿及灰度

后端涉及多服务器、子网、服务器备份、服务流量灰度等惨无人道的方方面面，所以这里博主给大家分享一些思想和流程，会配合图提供给大家，但是具体脚本代码博主就不提供了。

我们以云资源、java服务和服务器1对1、以及治理云服务器为基础来进行分享（以云为基础，就没必要在使用docker了）

我们使用git的方式，进行发布构建的解藕：

• 云服务器的治理，以api为主，可以构建快速拉取、备份、删除、切换等针对云服务器的操作
• 服务器预留：这里aws做的比较好（计算因子和预留服务），这里主要分蓝绿方式的服务器（自己设定tag），用于超大量的蓝绿切换（配合服务注册发现，博主这里使用的是nacos）
• 服务jar包版本，需要和服务器进行快速解藕，并以pull的模式，依据版本号路径获取相应jar
• 对象存储oss（s3）：用于jar的存储和下载
• jekins（或者自研脚本，博主这里自研）：配合将项目打成jar并且上传至oss指定目录
• 跳板机&脚本执行服务器：用于执行自动化脚本
• jgitflow：用于打版本，博主团队以master为release版本，dev为开发分支，通过gitflow等命令进行版本的构建和merge （可以参考博主这篇博客：https://blog.csdn.net/zl592886931/article/details/94395287 ）
• 自动化脚本：用于自动化构建和发布，并操作服务器等信息。（博主团队digital方面用shell脚本，电商方面使用shell、ruby等）

上面只是用到的一些东西，我们下面具体看一张图：

• 通过脚本与镜像，快速拉取一整套蓝集群（比如当前业务集群环境是绿）（镜像是个好东西，参考博主这篇博客：https://blog.csdn.net/zl592886931/article/details/89790057）
• 命令服务器开始拉取jar，并且设置好守护进程。批量启动就可以拉
• 然后配置好nginx，用新的连接开始测试。测试无误后，切换成正式环境即可（nginx的restart是毫秒，其实就是刷新）
• 切换完毕之后，不要停止老得集群，运行一段时间后在停止，万一有问题，切回老集群只需要几毫秒

灰度：蓝绿都会了，灰度其实就是起小范围的机器，然后通过网关（或者内部的nginx）进行流量的切换。脚本其实并没有差太多

脚本方面，其实博主之前写过一个炒鸡简单的restart例子，大家可以参考，然后使用本篇的思想进行扩充，最后写一个make，组合一下函数，运行就行拉（阿里云或者aws的api如果不想写shell，写java也可以）：

## 比如写一个make简单的命令。执行：make service-deploy-restart 就好了
service-deploy-%: ##  digital service prod deploy script: param app
	@echo "deploy $* ..."
	./publish/digital-publish.sh package digital-service $*
	./publish/digital-publish.sh deploy digital-service $*

dev-ops以及dev-stack

在博主团队，dev-ops是必须要掌握的，所以依据脚本和自动化，每个人都需要运维几百台服务器（so，我们轮流来）所以，博主和博主团队的另一个架构师编写了简易版本的dev-stack进行快速的运维和自动化

我们还是以软件包的思想来看整个自动化的过程

• 所有自动化脚本、服务器配置、应用配置全部在dev-stack中
• dev-stack分为本地docker（不要docker也可以）与prod生产环境两套
• 利用dev-stack一键执行（相当于安装游戏）快速安装环境、启动服务

这对于dev-ops的人员来说，避免了花费大量时间来去关注服务器运维（当然因为云的原因，服务器级别监控并没什么难度，大数据节点的监控，hadoop提供有接口，博主团队利用钉钉机器人，实时发送监控信息即可）

附上一张贼简单的图：