微服务中预发布环境的部署及思考

• • 背景
  • 预发布环境搭建的思考
  • 搭建过程
  • 总结

在快速迭代的互联网项目中，如果只有测试环境，测试完就直接上线风险还是比较大的，所以为了保险起见，很多公司就有了预发布环境、灰度环境等多个环境。由于目前公司没有预发布环境，所以打算搭建一套

1. 是否需要外部流量转发到预发布环境？
   不需要，这里搭建预发布主要是为了解决的问题是：部分需求在测试环境没法测试，比如一些三方接口等。或是测试环境数据不正确，影响测试结果，也有一些环境与线上不一致问题等，比如为了节约成本在测试环境的redis是单机，而实际线上是集群。主要是给自己和测试使用
2. 数据库与线上是否保持一致？
   这里为了简单起见就保持与线上一致，使用同一份数据库，并没有隔开，所以在操作灰度环境的时候实际也算是操作线上，不同的灰度的新版本不会暴露给用户使用。如果想和线上数据库保持一致，但是数据写入又不影响线上，我们可以使用类似全链路压测中的影子表
3. 三方中间件的隔离
   1. redis：redis主要是作环境使用，预发布和线上不用隔离开，使用同一份即可(如果要完全隔开，也是可以单独的redis的，但是感觉不是很有必要，根据自己实际需求选择)
   2. mq：mq这里还是希望和线上隔开，预发布不要消费线上的消息，预发布发送的消息也不要被线上消费。所以解决方案就是使用同一个mq，但是通过配置文件订阅不同的topic将预发布和线上隔离开
   3. 定时任务(xxl-job)：定时任务这里为了与线上隔离，所以还是单独部署。实际也不是很影响，定时任务即使不上预发布我们直接在上线测试感觉影响也不是很大

1. 由于数据库、redis都是使用线上的所以不用改，mq由于要区分线上还是预发布，所以需要自己手动去建立不同的topic和消费组来区分(这里的mq使用的RokcetMq)，xxl-job由于也是隔开的，所以需要再部署一个xxl-admin
2. 由于我们的配置中心使用的apollo，所以在配置文件中搭建一套预发布的配置文件即可，根据上面的改动作一些修改
3. 后端每个服务需要部署单独部署一套预发布的服务，同时也要准备预发布的域名
4. 前端页面也是要准备预发布的域名，同时需要改动调用的接口为预发布的接口
5. Jenkins添加预发布自动化部署，添加部署完成通知
6. k8s添加预发布容器相关查看页面

基于上面的思考一套预发布环境就搭建完成了，总的来说要考虑的点也不算特别多。有了预发布对我们快速发版的测试更有把握。如果后续需要搭建灰度，也可以基于预发布的的搭建过程去搭建。预发布与灰度主要的不同在于是否允许外部流量进来。总的来说我们无论搭建预发布还是灰度，都要根据公司的实际业务场景和预算来搭建。