上图是整个产品的开发周期,产品的功能清单和产品的蓝图是整个重构的目标,需清晰明确,并有相关文档,不然重构很容易跑偏。而且要把控好重构的时间节点,重构如果遥遥无期,目标持续延后。则会影响公司营收与成本,可能实际收益反而不如不重构。
重构分为局部重构和整体重构,我们的业务场景属于整体重构,而整体重构时,很容易受到历史系统的,历史包袱的影响。不过个人认为如果整体重构,还考虑历史问题,比如从原系统抄代码、考虑兼容问题,这些都是不可取的,很容易将原来的问题延续到新系统,所以上图重构基本跟开发一个新产品没有什么区别。undefined 整个流程以B端产品为例,并省略了部分内容,如上市评估等,但是主体流程无论B端C端,大体应该是相似的。
上图是我将100多张PPT和10多个文档进行整合而成,每个环节都有具体输入,出于保密原因无法展示给各位。橘黄色部分实际是整个敏捷开发体系,为了流程清晰也省略了敏捷的内容,所以这个图内容还是挺多的,可以仔细看看。
重构之前,需想清楚整体系统架构、部署架构等内容,底层设计如果出了问题将是灾难性的,因为基于底层再进行改动,一是工作量巨大,二是可能为了妥协,做出很多兼容处理导致重构失败。无法达成目标。
因为我们服务是以后端Api的形式提供访问接口,所以前端应用有很多种,比如我们的CS客户端、官网页面、内部CM网站等。图中展示了用户访问这三种应用的过程及部署情况。
此部署策略是一个简化版本,比如未展示高可用,未实现serviceMesh,未展示后端应用依赖的服务,如kafka、mongo、es、redis等。此文是为了更容易理解,而且我们第一版服务确实也还未实现serviceMesh,其他依赖的kafka、mongo等部署策略,不同业务场景部署也不一样故省略了,只展示主体架构。
正常情况服务的路由应该是通过网关进行转发,但是我们因为一些早期设计和其他的一些原因将路由功能直接放在了nginx,网关服务Pod可以当作一个加强的BFF。(基础稍弱的同学,此处可能会有一些疑惑,可能看了战术设计,这里就明白了)
微服务的改造不是一蹴而就的,因为整个工程量还是比较大的,所以我们会面临几个问题。
,无论mysql、mongo还是啥,其迁移思路基本都是一样的。
前文我们讲述了如何从0到1建设自己企业内部使用的devops,同样的,原来的应用经过微服务改造后,被拆分成了几十上百个微服务应用,发布时不可能通过人肉进行发布,所以我们使用devops进行自动发布。
image.png
我们首先从git仓库拉取代码,然后经过代码扫描,代码分析然后生成镜像,发布到测试环境K8s集群,经过测试人员测试通过后,我们从镜像仓库拉取镜像,发布到预发环境,预发环境再进行一轮简单测试,测试通过后。从镜像仓库拉取镜像发布到正式k8s集群。
可能针对这个发布流程,大家还是有很多的疑问。比如我某个仓库代码一天部署1000次,难道我镜像仓库要保存1000个
镜像版本?那么多镜像,我正式环境怎么知道哪些是稳定发布的镜像,哪些是测试的镜像?上百个服务,我jenkinsfile每个微服务项目都一个?那如果修改维护jenkinsfile岂不是每个项目都要改?发布回滚怎么做?蓝绿、灰度怎么弄?开发分支管理怎么处理?
镜像管理.png
我们将所有非正式版的镜像都标记为Tag:latest,这样我镜像仓库就只有一个用于测试的镜像,版本为latest,避免了我镜像仓库太多镜像,也避免了我k8s集群服务器,过多的镜像导致磁盘占满。当测试通过后,我们用jenkins进行发布时,勾选“tagOfficialImage”这个勾选框,这样我们就对镜像打一个tag,tag格式为“版本.日期.git提交次数”。同时git代码上,打上相同的tag。
这样我们再预发布、正式发布时,找到git项目上最新的tag,因为git、镜像tag同名,所以我们发布的也是最新的镜像。如果要回滚,同理,jenkins上选择相应的git项目的tag,根据这个tag去镜像仓库找相同名称的镜像就可以回滚到相应的版本了。
因为git分支有很多种类型。我们是分了如下几类:迭代开发分支(12Sp2)、修复分支(hotfix)、专项分支(feature)、主分支(master)。一般,master分支作为主干分支,需要稳定安全,所以一般开发人员不允许直接推送代码到master分支。所以每个迭代开始就按迭代日期创建新的分支,比如12月第2个迭代,就增加分支12Sp2。等迭代结束时,再由SM将审核通过的12Sp2代码合并到master,这时候给客户的就是稳定的master的代码。
在测试环境用jenkins发布部署时,就用12Sp2,因为开发过程中会存在反复修改与调试的情况。如果用master分支,改一个BUG需要SM审核一次代码,合一次代码,开发测试人员还得等代码合并后,才能重新进行测试,造成很大的内部损耗。而12Sp2改一次,发布一次。真正做到持续部署,等到测试通过,就将代码合并master,并打上tag进行发布,这样只需要一次代码合并审核。
配置pipeline需要在项目中配置一个Jenkinsfile文件,存放pipeline脚本(不考虑job中直接写脚本的方式,维护起来太繁琐)。可能很多同学这个时候会想到shared
library。但是shared library只能解决功能复用的问题,解决不了jenkinsfile复用的问题。于是我参考这个
至于灰度发布,可以使用nginx,也可以直接使用k8s的ingress,本质也是nginx。蓝绿发布也只是把流量切分到不同的k8s集群。因为这块还没实践,所以先不赘述,免得误导,但是感觉这一块并不复杂,网上资料,相信聪明的你,应该足够搞定了。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。