开发者学堂课程【ALPD 云架构师系列-云原生 DevOps36计：案例1：云效携手 ACK 助力卡上海博卡 DevOps 转型】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/82/detail/1302
案例1：云效携手 ACK 助力卡上海博卡 DevOps 转型
内容介绍：
一、内容简介
二、博卡公司转型经历
三、核心痛点
四、云效源码管理
五、云效流水线
六、容器服务 ACK
七、方案效果
一、内容简介
如何利用云效+ACK 持续提升交付效率，提高产品质量，降低维护成本，拥抱云原生技术后企业从传统架构升级为云原生架微服务架构，并结合云校实时持续交付，以最快的速度满足客户需求完成转型。
二、博卡公司转型经历
1、公司介绍
博卡软件于2004年在上海成立，成立以来一直专注于“以优势技术提升美业效率”，是一个为本地美丽生活相关行业提供软件服务的 SaaS 软件提供商。主要产品是门店运营所需要的管理软件，智能硬件以及营销工具等。在过去16年里，我们服务了10万家门店，8000万会员消费者，以及100万手艺人。
博卡在快速发展过程中，随着客户数量快速增长，原有的技术架构和交付能力逐渐成为了瓶颈，再过去几年里，随着技术的不断演进，云原生迅速成为了业界热点，本公司也开始关注云原生相关技术，并寻找适合我们的解决方案，首先给大家介绍一下 DevOps 转型之前我们团队的概况以及核心痛点。
2、团队的概况
研发团队规模大概在30人左右，基本上是没有专门的运维人员，大概十万家门店，七个行业，美容美甲，足浴会馆等七个行业，产品包括管理中心、智慧前台、博卡云端、智慧小秘书等大大小小超过20个产品。
三、核心痛点
1、核心痛点一
服务众多小商户，客户需求高井发时必须每天交付数次。传流的开发部预式成为购物，必须打迈高效的心 CI/CD 系统。
本公司的客户基本都是小商户，行业内大多数都是小规模经营，没有统一的规范，个性化需求比较多因为是突出业务，客户提出的需求很多时候必须快速满足否则很容易丢失客户，因为客户基数大所以每天收到的需求都会比较多，紧急的需求也会经常出现，导致出现每天交付宿舍的情况，转型之前的传统软件开发部署模式成为了本公司瓶颈，必须要打造一个快速高效的 CI/CD 系统来解决问题。
2、核心痛点二
没有专职的运维人员，不同职责的开发人员都相对承担了一部分运维的工作，但是为了安全性必须进行权限管理。
同时，本公司做业务的公司，因为各种原因没有专职人员，很多时候不同职责的开发人员来承担一部分工作。在承担整体的运维这种情况下，为了安全性必须进行权限管理。
3、核心痛点三
架构复杂，数十个微服务以及数十个前端应用，都需要实现零停机部署和升级。
在架构上，本公司有数十个微服务以及数十个前端应用。因为用户多而且是实时在线系统，都需要实现零停机部署和升级。否则持续交付频繁的时候，容易造成请求失败，甚至导致业务中断的发生。
4、核心痛点四
Kubemnetes 学习门槛过高，如何通过更简单的管理成本获得自动化扩缩客以及自动运维。
在云原生的架构中发现，Kubemnetes 的特性很适合本团队，本团队就准备尝试使用 Kubemnetes 来解决问题，但是Kubemnetes 学习门槛过高，如果自己开始，则需要比较高级别的运维人员来维护，而且成本不低，本团队需要更简单的管理成本和使用成本，这个时候开发的交付效率以及低成本的试错尤为重要，经过不断的尝试，最终选择了解决方案，完成对了二次转型，下面来看解决方案。
5、解决方案
SaaS 公司要在竞争中拔得头筹，就需要快速响应客户需求，同时保持较高的稳定性。要快速占领市场，就需要不断推出新产品不断创新，这个时候开发的交付效率以及低成本试错就尤为重要。
经过我们的不断尝试，最终选用阿里云容器服务 ACK+云效的解决方案，替代了最初的SpringCloud+ECS+Gitlab+Jenkins，打造完整高效的 CI/CD 系统落地 DevOps，完成 DevOps 转型。
我们的 CI/ CD 图所示，Gitlabg 工作流采用的是 Gitlabg+flow,最大原则叫做上游优先，即存在一个主分支 master，它是所有其它分支的上游，只有上游分支采纳的代码变化才会应用到其他分支。本公司的日常环境的分支是 master，生产环境的分支是不是历史正常的发布流程是由开发者完成后续的 master 分支复刻出来的个人分支，或者从 master分支创建的个人分支中，再从个人分支提交合并请求，请求合并到 master 的分支，经过代码评审完成后，自动触发代码扫描。结果会显示代码故障，这让开发人员能很直观的知道自己在此次提交中是否有问题，会自动触发对应的日常环境中的流水线运行，进行代码检测，编译构建日常流程，根据对应服务重要程度以及可用性要求，决定代码检测是否需要设置红线，编辑构建是将代码编译后，创建 DevOps 镜像。
然后日常发布则是把构建好的镜像升级部署到连续服务 ACK 对应的工作负载中，如果日常环境验证没有问题，确认要发布到生产环境时，只要从 master 分支提交一个合并之中，就会自动触发生产环境，对于流水线运行完成生环境的发布，在生产环境的发布过程中，如果要指定发布时间的要求，可以加上人工卡点已提供给相关人员验证，已控制发布时间，最后构建或者发布成功或者发布失败，都会推送到钉钉群中。
四、云效源码管理
1、云效源码管理-代码检测
我们再来谈谈源码管理上云效的一些亮点。在公司的源码管理中，有代码自然检测的要求，但基本上是在 ID上装插件。
大家自己自觉检测或者在复制代码前进行检测，这种自觉检测行为在运行一段时间后慢慢的执行不下去，在使用云效作管理后，开启了阿里云 p3c 检测的插件和漏洞检测插件，两个插件会在复制上触发检测并完成检测后在代码页面上直接显示出来，直观的反馈提交使得监督规范的执行变得简单起来。
2、云效源码管理-代码评审
第二个亮点，在代码评审时，在云效之前，虽然也有强调经常要代码评审，但实际上，代码评审无法做到强制执行，也没能留下记录，通过云效的分支保护设置，控制所有非管理员的开发者都不能直接复制代码到 master 之上，必须能够评审后才能合并到 master 分支，这样就实现了强制评审很好的保护了 master 分支，很大程度防止了 master分支的污染，甚至可以配置提交合并请求，必须通过自动化检测提高评审效率，而且评审的时候可以很直观的评论和提交者可以直接回复十分方便。
五、云效流水线
云效流水线，使用下来感觉最大的优点就是，一用开箱即用，而且在对接阿里云其它服务时非常便利，默认工具，各种语言各种场景，基本都有默认的流水线模板也支持自己添加的企业模板，我们就添加了后端前端流水线一套模板，配置新流水线的时候，效率就非常高，基本两分钟内就能完成。
上面的图中展示了两种情况下流水线的配置，一种是日常环境自动集成的场景，第二种是需要指定人员确认部署的生产环境场景。
流水线的步骤配置非常简单，每一个步骤都很清晰，配置细节就不多讨论，接下来讨论使用过程中的一些亮点，第一个要说的就是缓存，在使用不同语言构建工具时都会有相关的依赖缓存存在，flow 提供了我们配置缓存目录的地方，主流的各种语言缓目录都已经默认配置好，自己选择是否开启即可，有的时候构建会出现缓存异常导致构建失败的情况，这个时候只要在缓存设置中删除缓存重新构建就能解决问题。
1、云效流水线-环境区分
通过一个分支对应条流水线的方式来区分部署环境，因为是同一个源码库，所以不同环境使用的镜像都是相同的，镜像组仓库中的镜像通过构建的镜像标签来区分环境，通过变量和变量和变量组的功能，可以构建环境变量构建时通过脚本来实现配置文件变量替换，从而实现构建产物的环境区分。流水线较多的情况下，推荐使用变量组配置一套生产环境变量一套日常环境变量再配置流水线的时候，添加对应变量组即可，甚至可以保存在流水线模板中。刚刚flow 流水线的时候，因为要设置流水线比较多，自动功能十分便利，大大的节约了我们配置流水线的时间。
2、云效流水线——消息通知
内置的钉钉群通知实现了构建结果通知开发团队的功能。同时，通知消息点击还能进入流水线，详情查看成功或者失败的原因，如查看代码扫描结果构建失败结果的，在手机上也可以查看有权限的账号，可以进行重回系统的操作，使得非工作时间出现问题的时候，可以通过手机操作干预比较便利。
六、容器服务 ACK
通过实施用系统中要做到持续交付，零停机升级部署就必不可少，业务系统中如果不是零停机部署。只有可能造成请求失败或者业务中断的。使用容器服务 CK 利用 Kubemnetes 的健康检测和就绪检测，配合物体的健康检测接口则可以很简单的实现零停机升级部署，不过在并发比较高的情况下，这种配置还是有一些请求失败的可能，当然，想做个最佳实践的话，最好的升级到2.3以上版本。该版本更新了 Kubemnetes 健康检测和就绪检测专用的接口，配合和停止用前睡眠一定时间可以真正实现零停机部署。
并且通过健康检测和就绪检测，以及重启策略配置之后，Kubemnetes 可以实现容器启动异常情况下自动重启重试。容器运行中中出现异常情况时自动重启，实现一定程度的自动运维进行应用自动修复很好的解决的应用上线初期或者出现异常时无人值守情况下快速重启自动修复，让客户可以快速恢复使用，降低了影响范围，当客户做活动时，或者其他原因导致出 Kubemnetes 快速上升的时候，可以配置 Kubemnetes 的 SUV 实现自动扩缩，容器可以根据CPU或者内存来决定怎么进行扩容和缩容。
更高级的用法还是根据阿里云的产品直接用监控的参数来配置扩容和缩容，实现更合理的资源利用，也能有效的降成本提高系统的稳定性。通过配置工作负载的需求和限制 CPU 和内存，可以精确地分配和利用对应工作节点的CPU和内存，实现最大化资源利用情况，保证稳定性，当某个容器异常的时候，不会对其他人去造成影响，总体上，比原来自己在 ECS 分配多少个应用，提高稳定性，也增加了资源利用率，使得我们在使用容器服务 ACK 后成本的大幅度降低。
1、容器服务 ACK——回滚
当发生问题的时候，云效配合ACK可以进行快速回滚。通过流水线运行历史，可以回滚到任意一次构建的版本，当然也可以直接在 ACK 中根据指定工作负载的历史版本进行回滚。容器服务 ACK 的这些配置一定程度上省掉了工作，直接由 Kubemnetes 来自动完成。并且使用和学习成本非常低，非常适合本团队，本公司转型 ACK 之后，的确得到了很大的收益。
七、方案效果
1、云效提效成果
接下来来讲来谈一谈方案的效果。图上是我们实物营销后的提效成果。可以看到，发布时间由原来的十分钟降低到了三分钟以内。从很少的代码评审到合并主分支强制要求评审。
很好的提高了代码质量。构建通知也从不通知到自动执行通知，有效的做到了结果反馈。版本回滚的时长也有一个小时降低到三分钟以内，出问题时真的可以快速运动，版本回滚的时长有一个小时降低到了三分钟以内，问题真的做到了快速应对。
日常生产环境之前是代码中配置文件区分存在开发人员误修改影响环境部署的风险，在使用云效后自动注入环境变量来区分最大程度的防止代码库配置文件修改影响到环境配置。代码扫描也由原来的 ID 插件自己扫描比较随意的方式。改进成提交后自动扫描，而且结果清晰地显示出来。叫做定时部署的时候，从人工等待时间进行操作，变成了可以设定时间自动发布。以前的交付质量依赖开发人员的个人水平以及随机的检测保证，现在通过各种检测插件进行自然检测，有效的阻止了异常构建和部署。以上是我们使用云效后一些提交成果。
2、容器服务 ACK 提效成果
那么最后再来介绍一下容器服务 ack 的提效成果。再使用 ACK 之前是不支持零停机部署的，使用 ACK 后开始支持零停机部署，并且还能进行应用异常自动修复，扩缩时间由一个小时降低到一分钟。
扩容方式变成了自动扩容非常便利，云冈信息安全问题由原来的来代码自动保存，变成了配置项以及保密字典保存，大大提高了代码安全性以及配置安全性。也降低了都市的风险，十分便利。以前的应用部署可能要花费三个小时甚至半天的时间使用 ACK 后一般十分钟内就可以完成，生产环境的稳定性，以前是出现问题以后客户发现或者监控发现后手动回滚再修复问题重新发布。
影响时间长，稳定性差，使用 ACK 后，通过健康检测手段阻止异常容器接受流量，以保证上线的应用基本资料同时重启异常容器或者进行回滚，可以快速的解决异常问题。以上就是 DevOps 转型的一些心得和体验。
