微服务开发实践流水账2019-04-10

        从去年从单体架构向微服务架构转型以来，一直都想做一些系统的总结，现在计划陆陆续续以流水账形式总结一下，后续再慢慢提炼吧。

一、项目背景

        去年开始一直在使用springcloud进行开发“SC”项目，前端使用了vue，实现了前后端分离，我们团队有20人左右，包括需求、UI、前端、后端、APP、测试。与传统互联网架构不同，我们的内外网环境是隔离的，并且开发环境、测试环境与正式环境也是隔离的，每种环境都要做内外网的交互，我想体制内的开发模式都差不多吧。

       这么大的团队在以月为交付周期的项目中代码的管理、版本发布成了最头疼的问题，我们的整个团队基本都是后端的，兼职做了前端，而真正的2个前端在项目里只是负责样式的调整。git版本冲突问题数不胜数，每次版本发布都成了灾难，我们也是第一次尝试基于docker进行部署，遇到了不少的坑。 假设我们开发、测试、正式环境是能够互通的，我以往传统架构、手工部署的方式，貌似也无法减轻我的版本发布压力。因为我们springcloud的一些组件，包括服务发现与注册eureka、网关gateway，还有用户权限管理admin、以及业务服务组件8个左右，整个“SC”项目一共11个服务。

二、遇到的一些悲剧事

    （1）vue前台打包，我们居然采用dev模式进行打包，然后再打到镜像里，我的天呐，每次几个G要手工上传到管理严格的正式环境进行版本发布。后面知道用prod模式，然后才几MB上传到服务器生成镜像后发布。

   （2）版本管理的混乱这里就不说了，多人协同开发各种覆盖、冲突，最后对发布分支指定了管理人员进行merge request才会好一些。有些童鞋几周才push一次，我觉得这里是我管理不善，应该对任务再分解细致一点，尽量让push频繁一些。

   （3）开发环境、测试环境、正式环境部署，每次手工搞一堆docker镜像进行部署，并且我们居然没有使用springcloud config进行配置管理，每次部署三个环境要改三次配置，各种参数配置错误，通宵真是活该呀。一般来说，我们docker部署会以挂载配置文件的方法进行，那我们三种环境其实用同样的镜像就可以了，只是容器启动时-v 配置文件要根据环境变化而切换。如果我们临时需要更换一台数据库服务器，假如我们有1000个服务，按现在这个方法，那我们岂不是要上1000个配置文件中修改数据库地址，我们的application中的环境变量如何使用呢？

（4）纯手工部署的方式真的很2，没有人有时间对每次的版本合并进行检查，除非那天要进行一个大的部署，这样会导致问题会在部署那一天集中爆发。每次惶急火燎的部署后，测试人员的手工测试根本就没时间开展。不仅仅需要停机部署，还可能部署延迟、部署后一堆问题。

（5）居然会遇到docker时间与jvm时间不一致的问题，导致时间会有7或8小时差异，详情请了解“夏令时”

（6）我们对自己框架的服务调用服务还加了鉴权（jwt+oauth2），真是画蛇添足。鉴权在网关中加就行了，用户认证(还可以配合白名单)可以解决独立的项目鉴权问题，但是如果存在多个子系统使用统一鉴权时候又该如何处理呢，使用统一的权限管理模块即可；但如果还要给第三方应用提供服务呢，如何保证安全性的同时保证通用性？   建议对所有第三方配置client并配置url访问权限，第三方应用先获取authorization code，与token原理一样，也需要定时刷新。

三、引起的反思

（1）这么多服务，是否有办法在一台机上跑起来方便调试，因为你不可能一直在开发环境上进行开发，万一开发人员在现场就需要临时开发呢？除非合并成一个服务，个人的PC机无论啥配置都不可能能起这么多服务、还有redis,mq,mysql这些中间件，甚至还需要elk。

（2）CI/CD这么多年了，从版本合并就自动编译、自动测试、自动发布与部署想想都跟我这一大堆手工部署形成了鲜明的对比，如何确保每次merge都会自动编译到自动部署？直接返回本次merge状态，如果未通过则merge回滚，所有人可以看到此处不通过的原因。如果部署成功，应该自动建立版本。每次版本的合并到发布的历史都是可视化的，包括源代码版本号、测试脚本版本号、发布版本号。

（3）服务之间的依赖基本都是松耦合的，但是少量的服务还是存在一些依赖关系，比如服务器从0开始部署，那必然要先部署eureka，再部署其他服务。那这个依赖在CI/CD中如何管理呢？