案例1：云效携手 ACK 助力上海博卡 DevOps 转型 | 学习笔记

开发者学堂课程【ALPD 云架构师系列：云原生 DevOps 36计-阿里云云效出品：案例1：云效携手 ACK 助力上海博卡 DevOps 转型】学习笔记，与课程紧密连接，让用户快速学习知识。

课程地址：https://developer.aliyun.com/learning/course/772/detail/13529

案例1：云效携手 ACK 助力上海博卡 DevOps 转型

内容介绍：

一、公司介绍

二、问题与痛点

三、解决方案

四、方案效果

一、公司介绍

博卡软件于2004年在上海成立，成立以来一直专注于 “以优势技术提升美业效率”，是一个为本地美丽生活相关行业提供软件服务的SaaS软件提供商。主要产品是门店运营所需要的管理软件,智能硬件以及营销工具等。在过去16年里,我们服务了10万家门店,8000万会员消费者,以及100万手艺人。

二、问题与痛点

博卡在快速发展的过程中，随着客户数量的快速增长，原有的技术架构和交付能力逐渐形成瓶颈。过去几年里，随着技术的不断引进，云效产品迅速成为热点，我们也一直关注，并寻找适合我们的解决方案。

介绍一下 DevOps 转型之前我们的概况和核心痛点。

1.团队及产品概况

研发团队规模：30人。

运维团队：没有专职的运维人员。

客户规模：10万家门店。

细分行业：7个，覆盖美发、美容、美甲、足浴会馆等。

产品数量：超过20个。

2.核心痛点

痛点1：客户众多小商户, 性化需求较高，传统的开发部署模式成为了瓶颈，必须要打造一个快速高效的CI/CD系统。

我们的客户基本上都是小商户，行业内大多都是小规模经营，没有统一的规范；很多时候客户提出的需求必须快速满足，否则很容易丢失客户；因为我们客户基数大，所以每天收到的需求较多，也会经常出现紧急的需求，导致出现每天交付数次的情况，转型之前的传统软件开发部署模式成为了我们的瓶颈，必须要打造一个快速高效的 CI/CD 系统来解决问题。

痛点2：没有专职的运维人员，为了安全性，需要对运维有着严格的权限控制

同时我们是重业务的公司，因为各种原因，我们没有专职的运维人员，很多时候由不同的职责的开发人员来承担一部分运维工作。这种情况下，为了安全性，需要对运维有着严格的权限控制。

痛点3：在架构上，我们有数十个微服务及数十个前端应用，都需要实现零停机部署和升级。

在架构上，我们有数十个微服务及数十个前端应用，因为用户多，而且是实时在线系统，都需要实现零停机部署和升级。否则持续交付频繁，容易造成请求失败甚至导致发生业务中断。

痛点4：Kubernetes 学习门槛过高，如何通过更简单管理成本获得自动化缩容及自动运维。

我们发现 Kubernetes 适合我们团队，准备尝试用 Kubernetes 来解决问题，但是发现 Kubernetes 学习门槛过高，成本不低且需要专职运维人员，我们团队需要更简单管理成本和使用成本。

三、解决方案

开发的交付效率以及低成本的试错尤为重要，经过我们不断尝试，最终选择阿里云容器服务 ACK+云效的解决方案，代替了最初的 Spring Cloud+ECS+ +Jenkins，打造高效的 CI/CD 系统落地 DevOps，完成DevOps转型。

1.CI/CD系统步骤：

Git工作流采用的是Gitlab flow，Gitlab flow最大原则是上游优先。Git存在一个主分子Master，是所有分支的上游，只有上游分支采纳的代码变化才会应用到其它分支，我们日常环境的分支master，生成环境release,正常的发布流程是开发者完成之后，后续的master分支forker 出来的个人分支或者从master分支创建的个人分支中，再从个人分支中提交合并请求，请求合并的master分支经过代码评审后自动触发代码扫描，结果会显示在代码库上，让开发人员能很直观的看到自己在这次提交中是否有问题，从识别中会自动触发日常环境的流水线运行，进行代码检测，并一一构建日常发布建流程。

根据对应服务重要程度及可用性要求，决定代码检测是否需要设置红线，并一一构建四张代码编译后，创建 Docker 镜像并 push 到镜像服务 ACR 中。

日常发布则是把构建好的镜像升级部署到容器服务ACK对应的工作负载中，如果日常环境验证没有问题，确认要发布到生产环境时，只要从master分支提交一个合并请求到release分支中就会自动触发生产环境对应流水线运行，完成生产环境的发布。

在生产环境的交付过程中，如果有指定时间的发布要求可以指定人工卡点，以提供给相关人员验证，指定发布时间。

最后构建成功或者失败，均会推送到钉钉群中。

2.源码管理上云效的亮点：

亮点1：云效源代码管理-代码检测

在过去的源码管理中也有代码检测的要求，但基本上是在 ID 上装插件，大家自己自觉检测或者 push 代码前进行检测，自觉检测在执行过程中慢慢难以执行，我们在使用云效 Cloudup 做源码管理后，开启了阿里云p3c检测插件和依赖包漏洞检测插件，这两个插件会在 push 到分支上触发检测，并在完成检测后在代码库页面上直接显示，直观的反馈给提交者，使得监督代码规范的执行变得简单。

亮点2：云效源代码管理-代码评审

传统上，代码评审无法强制执行，且不能留下记录，通过云效的分支保护设置，控制所有非管理员的开发者不能直接 push 代码到 master 分支上,必须经过评审后才能合并到 master 分支这样就实现了强制评审，很好的保护了 master 分支，很大程度上防止 master 分支污染，甚至可以配置提交合并请求必须通过自动化检测提高评审员的评审效率，评审的时候可以很直观的评论，提交者可以直接回复，十分方便。

亮点3：云效流水线

最大优点是开箱即用。对接阿里云其他服务时非常便利。根据各种语言，各种场景，基本都有默认的流水线模板，也支持自己添加的企业模板，我们团队就添加了后端和前端的各一套模板配置新流水线时，效率就特别高，两分钟内就能完成。

有两种流水线配置：一种是日常环境自动集成的场景，另一种是需要指定人员确认部署松散环境场景。流水线步骤配置流程非常简单，每一个步骤都很清晰。

使用过程中亮点：

缓存：

使用不同语言构建工具时，都会有相关的依赖缓存存在。Flow提供了我们配置缓存目录的地方，主流的各种语言缓存目录都已经默认配置好，自行选择是否开启即可。

有时构建会出现缓存异常，导致构建失败的情况，此时在缓存设置中，删除缓存，重新构建就能解决问题。

亮点4：云效流水线-环境区分

我们通过一个分支对应一条流水线的方式，来区分部署环境。因为我们是同一个源码库，所以不同环境使用的镜像仓库都是相同的。镜像仓库中的镜像，通过构建的镜像标签来区分环境。通过变量和变量组功能，在构建之前注入环境变量，构建时通过脚本来实现配置文件的替换，从而实现构建产物的环境区分。

流水线较多情况下，推荐使用变量组，配置一套生产环境变量，一套日常环境变量，再配置流水线的时候添加变量组即可，甚至可以保存在流水线模板中。

因为刚刚转到Flow流水线的时候，要设置比较多的流水线，这个功能十分便利，大大的节约了我们配置流水线的时间。

亮点5：云效流水线-消息通知

内置结构的钉钉实现了构建结果通知开发团队的功能，同时点击通知消息还能进入流水线详情，查看成功或失败的原因。查看代码扫描结果，构建失败结果等，在手机上也能查看，有权限的账号还能进行回滚重试等操作。使得非工作时间出现问题时可以通过手机操作干预，比较便利。

亮点6：容器服务 ACK：

实时业务系统中，要做到持续交付，零停机升级部署就必不可少。

业务系统中如果不是零停机部署，则有可能造成请求失败或者业务中断等。使用容器服务 ACK，利用 k8s 的健康检测和就绪检测，配合 springboot 的健康检测接口，则可以很简单的实现零停机升级部署。

不过在并发比较高的情况下这种配置还是有请求失败的可能，这是因为 k8s Pot 切换和 export 下线是一步进行的。

当然想做个最佳实践，可升级springboot到2.3以上版本，该版本更新了k8s健康监测和就绪检测专用的接口和优雅关闭配置，比hance接口更适合用来进行健康检测。并且配合停止应用前，休眠一定时间，可以真正实现零停机部署。

通过健康检测和就绪检测，以及重启策略配置之后，k8s可以实现容器启动异常情况下自动重启，重试。

重试运行中出现异常情况时自动重启，实现了一定程度的自动运维，进行应用自动修复，很好的解决了应用上线初期或是出现异常时，无人值守情况下，快速重启自动修复，让客户可以快速恢复使用，降低了影响范围。

当客户做活动时，或者其他原因导致QPS快速上升的时候可以配置k8s的HPA，实现自动扩缩容。可以根据cpu或者内存阈值来决定怎么进行扩容和缩容。

更高级的用法：还可以根据阿里云的其他监控产品，应用监控的参数来配置扩容和缩容，实现更合理的资源利用，也能有效的降低成本，提高系统的稳定性。

通过配置工作负载的需求和限制cpu和内存可以精确的分配和利用对应工作节点的cpu和内存，实现最大化资源利用情况，保证稳定性。当某个容器异常的时候，不会对其他容器造成影响。

与原来自己在ECS上自行分配，提高了稳定性，也增加了资源利用率。我们在使用容器服务ACK后，成本有了较大幅度降低。

亮点7： 容器服务ACK-回滚

当发生问题的时候，云效配合ACK还能进行快速回滚，通过流水线运行历史可以回滚到任意一次构建的版本。当然也可以直接在ACK中根据指定工作负载的历史版本进行回滚。

容器服务 ACK 的些配置。一定程度上省掉了很多运维工作，直接由kps自动完成,并且使用和学习成本非常低，非常适合我们团队。

我们转型用容器服务 ACK之后，的确得到了很大的收益。

四、方案效果

云效提效成果：

容器服务ACK提效成果：