今年 4 月，完美日记 IT 系统实现全面云原生化，保证了每一次大促活动的系统稳定性和可用性，同时利用阿里云ACK容器快速弹性扩缩容，节约服务器成本 50% 以上。
完美日记创立于 2017 年，这家公司上线不到两年即成为天猫彩妆销冠，2019 年成为 11 年来第一个登上天猫双十一彩妆榜首的国货品牌，包揽天猫 2019 全年彩妆销冠；2020 年 4 月成为首个亮相天猫超级品牌日的国货彩妆品牌，同时勇破彩妆品牌销售纪录。另外，完美日记已在全国各地开设了 100 家线下店，计划至 2022 年底开店超 600 家。截至 2020 年 4 月，品牌 SKU 超过 700 个，全网用户粉丝数量超过 2500 万，月曝光量 10 亿+。
“轻研发、重营销”是流量思维企业的通病，为了“打造互联网时代新的美妆集团”，在依靠流量和营销快速占据市场的同时，完美日记也在不断夯实其技术底座。今年 4 月，完美日记已完成IT系统全面容器化，保证了每一次大促活动的系统稳定性和可用性，同时利用阿里云ACK容器快速弹性扩缩容，节约服务器成本 50% 以上。
完美日记容器化改造之路
对于一家创业公司而言，常常有三个问题摆在面前：
1、如何高效、低成本地搭建系统，同时确保安全稳定？
2、如何敏捷构建和发布应用，满足业务需求？
3、如何提高团队开发效率，确保开发质量？
早期大部分互联网公司都是直接购买服务器，租用 IDC 机房的机架部署，应用是直接运行在物理机上，如果要扩展必须购买新的服务器。IDC 会频繁出现各种故障，如果遇到 IDC 迁移就更麻烦，必须半夜搬机器，天亮前上线，对于企业来说，在成本、服务稳定性、工作效率上都是很大的消耗。
2019 年双 11 前期，完美日记小程序刚刚上线两个月，就经历双 11 大促的磨砺。在这两个月里，传统的部署方式，特别是有部分应用需要（openrestry）在 SLB 上面配置，那么运维人员就要在 SLB 上一个个勾选服务器，这会导致发布版本的时间需要半个小时以上。如果发版过程中出现问题，往往时间还会延长到一个小时以上。
在扩容机器的时候，使用其中 2 台服务器在阿里云打 OS 镜像，采用开机自启动脚本方式启动应用，针对每次运营活动的实际情况进行扩容。为了保持系统的稳定性，运维人员就需要在每晚 23:00 点以后通过人工操作进行扩容，手工配置 SLB 。最后测试人员进行测试，平均每次扩容都需要半个小时以上。并且由于双 11 期间处于大流量、高并发的场景，整个运维人员对服务器维护、版本迭代、数据库运维等都必须格外谨慎，稍有不慎会导致线上生产事故，服务器运维压力巨大。
2019 年双 11 之后，完美日记就开始针对性测试阿里云容器服务 ACK ，并开始容器化改造。
之所以选择容器技术，是因为完美日记要构建一套现代化 IT 系统以满足快速变化的需求和挖掘更多的数据价值。具体来看，一方面，完美日记对业务的快速创新以及现有业务的实时性和交互性需求都在不断地增长；另外一方面，完美日记对数据的重视程度也在不断提高，尤其是用户数据的重要性。如何提供优于竞争对手的服务和用户体验，如何合理、有效地发掘更多的数据价值，成为完美日记迫切的需求。容器技术以其独有的高效敏捷和易于扩展的特性，加之庞大的生态系统，可以充分满足完美日记不同阶段的 IT 需求，这也是完美日记最终选择 IT 系统全面容器化改造的原因。
完美日记最开始是自建 K8s ，使用的是 K8s 开源版本，但是开源版本有很多 bug 未知，安全性也是未知，并没有一个比较友好的 Web 操作界面，还需要大量运维人员解决运行时出现突然的各种问题。从成本和效率等维度来看，并不是一条便捷的路，思虑再三，完美日记最终选择阿里云容器服务 ACK 。“我们的技术人员跟阿里云的技术人员其实非常熟悉，在双 11 期间他们也给予了很多技术层面的支持，我们遇到的问题他们基本都遇到过，我们没遇到的问题，他们也都遇到过，站在巨人的肩膀上进行容器化改造，对于当下的完美日记而言，是最合适的。”完美日记的容器化实践是按照项目区分两条线并行，第一条线是一次性前后端全部迁移，第二条线是分应用分批次前后端分别迁移。
一次性前后端全部迁移
2019 年 11 月初- 2019 年 11 月中旬，完美日记开始计划容器化改造的准备事宜以及改造方案，包括容器化改造方案初步实施，阿里云 K8s 选型，阿里云 K8s 选型后进行初步测试，结合公司情况和人员相配比情况，最终选择了阿里云托管 K8sMaster 版本进行大规模测试工作，并开始准备 UAT 环境切换前期工作等事宜。
2019 年 11 月中旬，第一次切换 UAT 环境到 K8s 中失败，因为还有部分在开发中的模块，而 K8s 中没有对应的模块，因此切换回非K8s环境。
2019 年 11 月底- 2019 年 12月初，将 UAT 环境切换到K8s中，这次切换吸取了第一次切换失败的经验，UAT 环境正式切换到 K8s 中。
2019 年 12 月初- 2019 年 12 月中，观察整个 UAT 环境是否存在有重大问题，然后进行调整。将整个 K8sUAT 环境按照双 11 量级进行四轮压力测试，将结果反馈，然后不断进行调整。2019 年 12 月中，尝试将后台正式环境切换到 K8s 正式环境中，但由于 UAT 环境中代码版本和正式环境中代码版本不一致，导致第一次尝试切换失败。
2019 年 12 月中，在第一次切换后台失败中吸取了版本不一致的教训后，经过一天的努力终于将后台正式环境切换到 K8s 正式环境中，正式环境走出艰难的容器化改造第一步。
2020 年 1 月初，经过一天努力，将正式环境顺利切换到K8s正式环境中。
分应用分批次迁移
2019 年 11 月底开始准备迁移测试环境方案， 2019 年 12 月初，后端和中间件开始新增 UAT 环境。
2020 年 1 月 2 日，后端准备完成。1 月 3 日准备开始前端，1 月 17 日前端完成、 UAT 环境正式使用。1 月 17 日开始准备正式环境迁移方案， 2 月迁移方案完成， 2 月中上旬开始迁移后端， 3 月中旬后端迁移完成，ZooKeeper、Eureka 迁移完成。3 月下旬，前端开始迁移， 4 月初前端基本迁移完成。最终在 4 月中旬，完美日记 IT 系统全部迁移完成。
至此，完美日记全面容器化改造完成。
完美日记容器化改造架构
在容器化部署过程中，利用 ACK 的快速弹性应对大促时的资源快速扩容。将完美日记 IT 系统提前接入阿里云链路追踪产品 ARMS ，用于对分布式环境下复杂的服务调用进行跟踪，对异常服务进行定位，完美日记可以在测试和生产中快速发现问题，快速修复。使用性能测试服务 PTS 进行压测，利用 PTS 的秒级流量拉起、真实地理位置流量等特性，以最真实的互联网流量进行压测。收集压测数据，分析系统强弱依赖和关键瓶颈点，对关键业务接口、关键第三方调用、数据库慢调用、系统整体负载等进行限流保护。在大促前进行 ECS/RDS/ 安全等产品扩容、链路梳理、缓存/连接池预热、监控大屏制作、后端资源保障等，帮助完美日记在大促平稳进行，保持丝般顺滑。
除了采用容器服务 ACK 之外，完美日记在一开始进行容器化改造时就使用了阿里云镜像企业版 ACR EE ，它的优势是比自建 harbor 要稳定与低成本，因为自建 harbor 需要考虑计算、数据库以及磁盘成本，如果项目很多或者镜像比较多，那么磁盘成本将比较高。镜像企业版不用考虑维护成本。另外，镜像企业版并发比自建 harbor 要高，如果大批量进行扩容，自建 harbor 往往容易出镜像 Pull 问题，但是镜像企业版就没有这种担忧。
另外，完美日记也通过 ARMS Prometheus 来监控系统可能出现的问题，并能针对性地解决问题。ARMS 还可以解决整个 K8s 底层监控（Prometheus）的维护和成本高的难题，它能监控应用每个 pod 资源使用情况，对 pod 资源进行调整。K8s 底层监控（Prometheus）可以做一个自定义大盘，将 Prometheus 全部监控信息完整显示出来。
容器化改造之后，整个系统“轻松了很多”。1 月初，在切换到 K8s 正式环境后，扩容时间只需要 90 秒左右，节约了 6~8 倍时间，减少了一名服务器运维人员。根据运营节奏进行扩容，服务器扩容成本节约 70%~90% 。同时，部署效率大幅提升，可根据文件模板秒级创建一个服务，部署时间减少 90% 以上。
另外，服务器资源自动计算部署到服务器，利用隔离技术可部署多个项目服务器，利用率提高 50% 以上。服务模块的自动负载均衡无需人工干预，工作量减少 90% 以上。服务模块伸缩容无需编写脚本，只需点击伸缩按钮即可，减少人工错误率，工作量减少 70% 以上。服务模块不可用会自动剔除，自动重启服务模块。服务器宕机时，服务器上运行的服务模块会自动转移到可用服务器上，无需人工干预，工作量减少 100% 。
容器化改造更大的挑战是在技术和人员上做好准备
当企业完成了容器化改造之后，在生产环境中应用容器技术，并计划扩大应用规模，这时企业就必须在技术和人员上做好准备：运维人员是否有足够的能力来应对大规模应用带来的挑战，研发人员是否有足够的技术准备能随时解决大规模应用带来的问题，产品的架构设计是否可以满足未来的企业需求，同时组织架构和文化是否已经适应企业新的战略发展等。
换句话说，如何让项目组和开发人员之间达成技术同频、战略同频更具挑战性，这其实也是很多在做容器化改造的企业面临的共同难题。
出现这个问题的核心是项目组的开发人员、架构师、运维人员关注点不一致。开发人员关注系统平稳运行和业务开发，而不关心生产环境底层，只要不影响到生产环境和测试环境就可以。架构师关注底层是否稳定运行，技术架构是否符合未来 3~5 年技术发展，技术是否简单高效等。运维人员关注发布版本是否简单高效，环境是否能统一，扩缩容时间成本，底层运维过程是否能有解决方案等。
正是由于三方的关注点不同，因此在迁移过程中就不可避免会花费大量的沟通成本。因为 K8s 这套系统有别于传统的部署过程，开发人员对 centOS 系统、Nginx、MQ、MySQL、查询日志等比较熟悉，但对于K8s不甚了解，Ingress、Docker 配置化、 Deployment 配置、 Service 等往往已经到了开发人员对技术认知的边界了，这就需要花费较长的时间去解答大家的疑问，才能往下一步进行。
对于这类问题，每个企业的解决方案都不同，最核心的就是把相关人员的知识边界尽量拉到同一级别，最大程度地减少沟通成本和冲突。完美日记是采用“及时同步、责任到人、内部培训”的方法，比如每次在任何环境做的调整都需要在容器化改造群内通知相关人员，保证大家的认知一致；在内部推进“谁负责谁完善”的文档制度；同时组织一些内部技术培训，让关键开发人员在公司内部对 K8s 进行培训讲解。还有就是推进企业内部新的、统一的技术文化等。
未来规划
目前各大公有云厂商都推出了容器服务，还有不少独立的容器云公司。如果企业一开始就是建立在公有云之上，推荐直接使用相应的容器服务，不仅可以快速搭建系统，还能大幅降低运维成本，提高效率，轻松实践 DevOps 。在容器环境下，很多日常操作都自动化或半自动化了，比如应用的部署和发布、扩容等，容器编排具有自愈能力，即使出现问题，也能减少人工的干预，大大减轻运维人员的工作压力。
完美日记下一步会重点关注三方面：
进行 Ingress+Gateway 单独部署；
使用 ECI+HAP+EW+AHAS（自动扩容数据来源）进一步优化成本，应对突发流量；
考虑采用服务化网格技术。
如今，云原生已经成为企业数字化转型的关键策略，由于应用需要快速开发和交付，这就促使企业采用云原生的方法来开发应用，以提高效率，并增加灵活性。
对于身处云原生时代的企业和开发者而言，不仅需要了解如何通过容器实现构建应用的新方式，更是要以开阔的视野和开放的心态去拥抱云原生生态。对于企业而言，需要具备一定的前瞻性，对于容器生态圈的主流技术和发展要有足够的把握，才能更好地将现有业务与容器技术相结合。随着企业对技术的不断探索，业务系统的逐步演进，应用规模的日渐增大，如何更好地与开源生态系统相结合，扩大企业的技术影响力，同时引入更合适的人才，是云原生时代下企业要考虑的问题。
点击“阅读原文”，了解更多阿里云容器服务ACK技术详解与客户案例。