微服务化的多组件项目，跨地域、分布式版本管理和发布方式

1.  前言：

随着容器技术的到来，我们传统的软件版本管理和发布方式也在慢慢地发生改变。它重新定义了软件开发、测试、发布和部署的流程，对版本管理的工作流程也有了更高的要求。我们交付的不再仅仅是代码文件、版本、功能；而是整个系统的运行环境，以及内外部用户在不同阶段进行部署和使用时的体验。
本文介绍了PICT项目以此为目标，在版本管理和发布方面所做的一些努力和尝试。

2.       关键词：

微服务化组件、跨地域分布

3.       背景：

ZXNP-PICT项目是一个基于容器技术，采用微服务框架实现的智能ICT融合的PaaS系统；它是由许多微服务化的组件项目组成的，这些组件项目团队分布在上海、成都、西安、南京等地。
PICT项目使用的是自己开发维护的软件仓库，对应不同的阶段，逻辑上可以分成临时库、可用库、发布库等三种不同的仓库。

3.1.  软件仓库流程：

1.      组件团队CI测试通过的组件版本会推送到 临时库；

2.      整系统CI从临时库取各组件最新版本，测试通过后推送到 可用库；

3.      交付发布
3.1 经过联调、版本验证之后，确定版本组件清单，对内发布；
3.2 交付对内测试，项目、质量审评会通过，将组件清单里的版本从 可用库 同步到 发布库，对外发布；（如果规划对外发布）

3.2.  需要考虑的问题：

·         保证各组件版本对应代码的可追溯性

·         开发人员能够清楚了解组件版本在软件仓库的状态信息

·         软件仓库的远程化

·         避免软件仓库出现集中爆发式访问导致出现性能负荷问题

·         软件仓库的容灾备份

·         各地用户能快速部署所需的版本

·         软件仓库的权限控制

4.       解决问题

·         微服务化组件在 gerrit.zte.com.cn 库中分别属于各自独立的工程。在PaaS版本构建发布时，如果照搬老经验对代码库打标签，明显是不必要、不合适的。因为多组件之间的版本号并不统一，某些组件可能一个版本对应多个PaaS项目版本；某些组件可能是非PaaS项目下的，用的是自己项目的版本号。微服务框架使得产品的灵活性、自由度比以前要大得多。结合项目运作中遇到的问题，现已对推送组件的版本号做了一定的规范要求，这样通过组件版本号就能追溯到具体代码。

    

每次推送组件的版本号要求都是唯一的，相同版本号上传会被仓库拒绝。

根据组件的内容，版本号有以下几种情况：

1. 组件内只含开源软件；

   正式版本号	补丁版本号
   开源版本号	开源版本号
   2.2.5	3.0.7

   每次推送，开源版本号要有变化

2. 组件内既有开源软件，也有PaaS项目文件；

   正式版本号	补丁版本号
   开源版本号.UniqueID	开源版本号.UniqueID
   2.2.5.228093	2.2.5.cc759a8

   注：UniqueID为gerrit changeid或七位短格式git commit id，保证在开源版本号内唯一，源码可追溯。

   每次推送，如果开源软件有变更，则变化开源版本号；如果PaaS项目文件有变更，则变化UniqueID；如果两者都有变更，则同时变化开源版本号、UniqueID。

3. 组件内包含开源软件，但是开源软件里含有PaaS开发内容；
   组件内为PaaS项目版本；

   正式版本号	补丁版本号
   PaaS项目大版本号.UniqueID	PaaS项目大版本号.pxx.UniqueID
   v1.16.20.03.228093	v1.16.20.03.p01.cc759a8

   注：pxx中的p代表patch，xx为01-99数字，每对外发布一次版本，xx增加1；

   UniqueID为gerrit changeid或七位短格式git commit id，保证在PaaS项目版本号内唯一，源码可追溯。

   每次推送，都需变化UniqueID；如果切换到了下个版本迭代，则同时变化PaaS项目大版本号、UniqueID 或者 PaaS项目大版本号、pxx、UniqueID。

4. 组件为其他项目版本

   正式版本号	补丁版本号
   其他项目版本号	其他项目版本号
   v5.10.20.b4.02.16922	v5.10.20.b4.03.24902

   每次推送，版本号要有变化

·         在某些特定场景下开发人员需要了解组件版本在软件仓库的状态信息，需要提供统一接口进行查询

curl http://10.62.40.90/shell/tempzart_upload_history -s|sh  #查询临时库组件版本上传历史记录和状态

curl http://10.62.40.90/shell/tempzart_uploadok_history -s|sh  #查询临时库组件版本成功上传历史记录

curl http://10.62.40.90/shell/tempzart_getnew -s|sh  #查询master分支上最新组件版本清单

·         临时库@上海、可用库@上海、发布库@上海已在上海IT机房托管维护，设备的安全性、稳定性有了保障，达到了研发提效对远程化的要求。

·         经过几次的版本发布，可以发现一个规律。在每个版本刚发布的一两天里，软件仓库的访问量会有明显的爆发增长。原先正常部署所需的时间被拉长了，而那些非上海环境的下载速度更是变得让人无法接受，大家的工作效率受到严重影响。于是搭建各地镜像仓库就被提了出来，最早完成的是发布库在各地镜像仓库的搭建，满足了外部用户的需求。之后针对开发团队，搭建了可用库在各地的镜像库。

在各地镜像仓库的系统上，只需增加计划任务定期执行“curl http://10.62.40.90/shell/validzart_sync -s|bash”命令，就可以轻松完成组件版本的同步。PaaS项目现在设定的同步周期是10分钟，也就是说源库的内容基本在10分钟内可以同步到镜像站点。每10分钟内的同步组件数量一般都在个位数，对源库的性能影响很小。后续如果继续增加各地镜像仓库也很方便，相同操作流程即可搞定。

这些镜像仓库就像是git里的本地库，每一个都是源库的备份，镜像站点越多，备份就越多。一旦源库版本丢失，只需选择任何一个镜像库，使用类似上面的同步脚本，即可把版本恢复到源库里去。

·         通过部署跨地域、分布式镜像仓库提升了容灾的能力，均衡了用户访问的性能负荷；但是要让各地用户能快速部署所需的版本，还需要提前做好一些准备工作。根据用户使用情景来决定使用什么仓库，用哪里的仓库。在前面的”软件仓库流程图示“我们可以看到基本有四个使用情景的部署，整系统ci测试、联调&版本验证、对内发布、对外发布。整系统ci测试对应临时库，联调&版本验证、对内发布对应可用库，对外发布对应发布库。install-pdm-cli.sh为PaaS预安装脚本，配置对应的部署版本清单；同时为用户选择对应的、有效的、最快的仓库，自动排除那些不可达的仓库。这样用户只要选对情景参数，就能便捷的部署PaaS系统。

bash install-pdm-cli.sh temp_srepo  #供PaaS整系统ci或用户自定义版本清单使用，pdm-cli取临时库最新，临时仓库

bash install-pdm-cli.sh ci_valid  #使用master最新可用ci版本清单进行部署，自动选择 可用仓库

bash install-pdm-cli.sh valid_srepo  #使用对内发布版本清单进行部署，自动选择 可用仓库

bash install-pdm-cli.sh  #使用对外发布版本清单进行部署，自动选择 发布仓库

  

·         为了保证组件版本的安全性、准确性，各类仓库对用户操作有着不同的权限限制。目前临时库和可用库对普通用户只允许上传（upload）组件版本的操作，其他包含“写”性质的操作是被禁止的；在发布库里，普通用户只有”读“性质操作的权限，其他都是禁止的。

5.       效果评价

  采用上述措施之后，项目在多方面得到了提升、改善：

• 组件版本变得更清晰直观，便于管理
  通过组件的版本号就能大致知道组件的来源归属，开源、本项目、其他项目等；
  已部署的PaaS系统，查看相关组件的版本号就能定位到具体代码；
  杜绝了以前开发人员用同一个版本号反复删除推送组件的情况，保证了组件版本来源的唯一性。

• 制品库变得更加强壮，实现了远程化、自动化
  镜像仓库的部署变得简单，均采用了远程化管理；
  随着各地镜像库数目的壮大，容灾备份点也同步增加了；
  异地仓库的组件版本同步，通过调用远程脚本，实现了统一维护，各地仓库只需调用即可，实现自动化；

• 支持多团队异地协作联调，实现节奏同步
  存在依赖关系的异地项目团队在提交各自组件版本入库后，可及时在本地获取到依赖对方的可用组件版本进行联调；

• 快速部署，仓库共享
  PaaS部署从原先的异地部署耗时半天，缩短到平均三十钟左右就能完成一次；
  各地仓库组成了共享资源池，任何几处同时出现问题都不会影响到用户部署；

6.       适用对象

微服务化的多组件项目都会面临类似的问题，相关项目可结合自身实际情况有选择性的借鉴参考；如已使用PaaS的制品库，可直接使用本文的同步方案。