记一次部署方式及部署环境的切换

前期介绍

项目主要是做机器人调度系统：主要分为云平台web端、APP端（融合联网部分功能-与web端共用同一服务端及离线部分功能-连接机器人wifi局域网功能）
项目前期项目刚起步，环境比较少只要3台服务器；后面新来的领导第一件事就是申请服务器，重新申请了6台服务器，用于部署相关服务；
本次主要记录一下部署环境的迁移以及部署方式的变化；

一、前期环境
前期环境；开发环境147,测试环境147，预留环境146，共计三台服务器；
前期部署方式1：通过jinkens部署，从gitlab上拉取代码到服务器的jinkens工作目录空间，然后执行编译程序，编译为jar包，然后执行java -jar的方式运行程序，采用的是单个应用部署的方式；这种单个应用部署的程序的复杂性非常高，每次代码的改动都会

牵一发而动全身，很容易堵了西墙漏了东墙；扩展能力差，无法根据业务模块进行伸缩；技术债务累积，随着时间的推移，需求的变更和技术人员的更替，形成应用程序的技术债务；

前期部署方式2：方式2是方式1的升级版本，使用的微服务部署，将单个应用程序进行业务拆分，拆分为不同业务模块，每个模块为一个微服务，使用docker部署的方式；还是使用的jinkens部署的方式，

每个模块在jinkens中创建一个构建工程；

这是微服务部署方式的微服务列表

 每个工程构建的时候将代码从gitlab拉取到jinkens工作空间，然后将对应的文件复制到对应的docker容器中；

这个方式有两个弊端就是：

a、每个环境都必须部署一套jinkens，开发环境、测试环境都必须的部署一套，导致了构建的工程数量特别多，特别的繁琐；

二、现在环境
后期环境：开发环境147，测试环境147，预留环境146，另外6台服务器，共计9台；
后期部署方式：现在项目采用的是敏捷开发模式，项目管理工具使用的是微软的Devops，项目管理、代码管理全部转移到devops上，代码管理使用pipline进行部署，采用的是微服务docker部署的方式，使用的是K8s的编排工具；

三、环境切换准备

1、环境准备

 a、集群环境的准备

 

 

 

b、每个组件的版本

 

 2、代码迁移

将gitlab上的代码迁移到devops工具上的repo仓库

3、代码修改

a、修改相关配置文件；

b、代码改造-抽离公共组件

线程池工具类封装；redis、MongoDB功能封装；mysql版本管理；配置中心优化；

c、不同业务模块持久化方案

d、服务端与设备的通讯协议

　　设备MQTT认证、注册流程设计、梳理

1. 设备注册；
2. 设备认证信息下发；
3. 签名方式；
4. key/id,deviceId规则；

e、服务端与设备的传输方式的改造

maqtt协议pyload中使用的是json格式；后续考虑改造未google的protocol buffer二进制的方式进行传输；

4、代码构建

使用pipline进行版本构建可以多套环境使用同一套代码；