原创 赵云兴、葛志刚

文｜赵云兴，葛志刚

仁励家网络科技（杭州）有限公司架构师

专注 to B 领域架构

本文 2111字 阅读5分钟

背景

人力家由阿里钉钉与人力窝共同孵化，致力于为企业提供以薪酬为核心的一体化 HR SaaS 解决方案，加速对中国人力资源服务行业数字化赋能。

人力资源软件通常由多模块组成，如人力资源规划、招聘、培训、绩效管理、薪酬福利、劳动关系，以及员工和组织管理等。随着业务发展，部分模块进入稳定期，仅需少量维护投入。例如，一个早期有 20 人研发的项目，现在拆分为 5 个应用。尽管产品成熟，但由于客户需求随竞争、业务和政策变化，仍需每年投入部分精力进行迭代。

长时间以来，我们一直面临着以下问题，而苦于没有解决方案：

• 系统资源浪费：5 个应用支撑的业务，我们在生产环境为每个应用部署了 3 台 2C4G 的 Pod，一共是 15 个 Pod 的资源。

• 迭代运维成本高：因为业务的复杂性，经常需要多个应用同时改动，部署等待周期长，单应用部署时间在 6 分钟左右。

在过去，我们已经探索过以下方案：

• 压缩工程：通过排除冗余的 jar 依赖，降低镜像大小。但空间有限，整个应用 jar 包只能从 100+M 减少到 80+M，整个镜像依然有 500M，能节省的部署等待时间有限。

• 单 ECS 上部署多应用：我们需要为这个应用做特别的定制，譬如监听端口要支持多个；部署脚本也要特别定制，要支持滚动发布，健康检测不同的端口，一段时间以后运维容易搞不清整个部署方案，容易出现运维事故。

初见成效

直到在某个月不黑风不高的夜晚，我们在最大的程序员交友网站上遇到了 Koupleless 团队。看完框架的介绍，我们立刻明白，Koupleless 就是我们要寻找的解决方案。

经过近两个月的敲敲打打，模块成功瘦身了，其中最大的模块的 jar 也只有不到 4M。应用部署的体积从 500M 一下子降到了 5M 以下，具体可见下图～

但高兴不过一天，我们在「如何把 Koupleless 部署到生产环境」上遇到了难题。因为我们没有专门的运维团队，部署都是开发人员通过阿里云的云效流水线，直接把镜像推送到 K8s 的 Pod。但这样改了以后，我们迎来了一连串待解决的问题……

• 模块要不要流量，还是直接通过基座处理流量？

• 如何在单独部署模块的时候先把基座的流量摘掉？

• 发布成功以后如何做健康检查？

• 如何重新开放基座流量？

Koupleless 的生产环境部署

在这里要特别感谢 Koupleless 团队的伙伴，给了我们很多专业的建议和方案。最终，我们选择了以下部署方案：

整体方案是，在基座上增加监听 oss 文件变化自动更新部署模块，卸载老版本模块安装新版模块，所有流量由 nginx 进入，转发到进程 tomcat (基座和多个模块复用同个 tomcat host)，并在基座上控制健康检查和流量的开关，主要工作是在基座上扩充一些能力：

1、基座支持配置自身运行的必要条件，譬如需要模块 A、B、C 都安装成功才能放流量进来；

2、检查 oss 目录，自动安装最新的模块版本，并做健康检查；

3、实现 K8s 的 liveness：用来在基座部署的时候判断基座是否成功启动。只要基座启动成功，即返回成功，这样基座可以走后续的安装模块逻辑；

4、实现 K8s 的 readiness：主要控制外部流量是否可以进来。因此这里需要判断所有必须安装的模块是否健康，并且对应的流量文件 A_status 等是否存在（该文件是一个空文件，在滚动发布的时候开关流量的时候用）。

小 Tips

目前 Koupleless 优化了静态部署和健康检查能力，能够直接满足我们的需求：

• 静态部署：在基座启动成功后，允许用户通过自定义的方式安装模块；

• 健康检查：在基座启动成功且用户自定义安装的模块启动后，Koupleless 框架将原生 SpringBoot 的 readiness 配置为 'ACCEPTING_TRAFFIC'，用户可以通过探测 readiness 决定是否让流量进入。

以下是 K8s 上的配置图：

• 就绪检查和启动探测：

• 在 Pod 上增加云存储的挂载：

模块动态部署时需要考虑两个问题：怎么感知新的模块并部署？在模块部署的前后怎么通过健康检查，控制基座流量？

我们的方案大概如下：

1、模块通过流水线，直接 jar 上传到一个 oss 目录；

2、基座上增加配置，配置基座承接流量的必须安装的模块，以及对应模块的健康检查地址；

3、基座监听 oss 文件夹的变化，来决定是否重新部署模块 （譬如有更晚的/更大的版本的模块上传到了 oss）；

4、基座部署模块前，先摘流量（可以通过删除一个空文件来实现，结合上一步 K8s 的 readiness 逻辑，空文件删除以后，readiness 检测不通过，流量就不会进来。但模块是存活的，防止有耗时的线程还在运行）；

5、安装好模块以后，把删除的文件写上，就可以开流量了；

6、集群下，基座通过 redis 来控制 Pod 不会出现并行安装，保证流量不会断；

7、基座提供就绪检查：就绪检查只需要判断基座起来了就可以。

存活检查是比较关键的一步：

a.判断第 4 步的空文件是否存在；

b.需要判断所有必须安装的模块都可以访问。

小 Tips

目前 Koupleless 优化了健康检查能力，能够在模块动态安装/卸载之前关闭流量，将 readiness 配置为 REFUSING_TRAFFIC，并允许用户配置模块卸载前的静默时长，让流量在静默时期处于关闭状态。在卸载的静默时长结束、旧模块卸载完成、全部模块安装成功后，readiness 才会配置为 ACCEPTING_TRAFFIC 状态。

总结

在以前，单个模块升级发布一次要 6 分多钟。

而改造后，升级单个模块只需要把编译后的 jar 上传到 oss 即可。

最终的效果，通过一组简单的数字对比就可以看出差异：

• 在服务器资源上，以前需要 15X2C4G，现在只需要 3X4c8G，节省了 18C36G 的服务器资源；

• 在单个模块的发布时间上，我们从之前的 6分钟降低到了3 分钟；

• 在单个模块的部署资源上，我们从 500M 降低到了 5M 。

再次感谢 Koupleless 团队伙伴的专业支持，特别是有济、立蓬。当我们在改造过程中遇到一些个性场景的兼容性问题，他们都能快速响应，让我们整个升级改造时间大大缩短。

通过升级 Koupleless 架构，人力家实现了多应用的合并部署、并行研发、轻量集中部署，大大降低了运维成本。

天下架构，分久必合，合久必分。而 Koupleless，让架构演进（分合）更丝滑🥰