跨境时尚电商SHEIN基于Kubernetes的DevOps实践

SHEIN PaaS参考了很多优秀的社区实践方案，最终使用了基于GitLab + Jenkins + Kubernetes + Harbor 的一套CI/CD工具集，一年多以来，总结开发出了一套公司自己的持续集成和发布的方案。本文着重介绍DevOps实践中几个比较值得分享的经验总结。
PaaS 平台介绍

PaaS 平台主要围绕 Dockerfile 和 DeployYml 这两个核心元数据，实现应用管理和流程管理等功能，目前完成了代码扫描，镜像构建，发布单审核，应用发布，流量控制，应用回滚，日志查看，运行状态查看，多集群管理 等功能。（Kubernetes 高可用集群搭建参考了优秀的社区项目：https://github.com/easzlab/kubeasz）

PaaS
对发布到PaaS的项目代码没有额外的限制（不需要在代码的指定路径包含 Dockerfile、Jenkinsfile 等构建依赖）。充分利用 Dockerfile 的多阶段构建功能，在 Dockerfile 中包含三个阶段：克隆、编译、运行（运行环境只包含构建结果，实现了镜像的最小化）。同时借助 PaaS 提供的基础镜像构建功能，开发人员可以将项目依赖添加到编译镜像中进行缓存，实现镜像构建加速。这样在保证构建灵活性的同时又保证了构建效率。

应用 Dockerfile 示例
因为 Dockerfile 多阶段构建功能的使用，很多构建逻辑不需要在 Jenkinsfile 实现，复杂度降低，为提高可扩展性，减少因为逻辑变更带来的维护成本，PaaS 支持传参触发构建，也支持更新 job xml 配置增加参数等，更重要的是使用 jenkins library 功能，项目构建 job 中只包含传参和函数入口调用等极少的代码，真正的处理逻辑在 jenkins library 中实现，这样在保证了可扩展性的同时又减少了维护成本。

jenkins-library 示例
通过图形化配置生成的 Deployment 等 yaml， 没有在 Jenkins 中发布，而是存储在数据库并直接调用 Kubernetes 接口部署，这样构建和发布分离，有很多使用方式上的考虑，比如，构建一次修改发布多次；只有构建没有发布（借助 Dockerfile 的多阶段构建，将编译结果发布到仓库，用于后续物理部署[特例]）；快速回滚（从数据库中直接取出历史版本直接发布即可实现）；蓝绿发布、流量控制等复杂逻辑（在平台代码中实现，比使用 Jenkinsfile 增加了复杂度更合适）。