新零售标杆 SKG 全面拥抱 Serverless，实现敏捷交付

Posted 2022-09-13 阿里云云栖号

项目背景

SKG 公司是一家专注于高端健康产品的研发、设计与制造的企业。专注为消费者提供精致、时尚的高端产品，以及极致的按摩仪产品体验。

随着市场需求的迅速变化，SKG 的 IT 系统也逐渐面临着库存不准确、线上线下渠道无法协同、部署架构不灵活、IT 响应速度过慢等问题，为了能适配销售拓展、提高效率、加强规模化运营，SKG 同阿里云达成战略合作，打造基于线上线下打通，并覆盖全渠道应用场景的渠道中台项目。本次渠道中台建设面向 SKG 线上、线下、礼品等渠道的营销管理，打通经销商、导购、后端 SAP 多端业务数据，同时整合面向 C 端会员数据和渠道零售终端销售数据，以全新的互联网架构云化系统能力支撑业务快速发展。

基于底层渠道中台构建的营销运营管理平台、经销商门户、导购终端小程序，需要有多端触达能力，同时满足不同端的个性化业务诉求和访问特点，要求中台有灵活的扩展定制能力、以及适配不同渠道流量需求的弹性能力。

现状问题&分析

在渠道中台建设之前、SKG 主要是租用 IDC 机房部署应用，也有业务跑在云上，整体是 IDC 机房+ECS 自建应用配套 RDS 等云产品的混合云架构。整套系统架构需要手工维护的地方比较多，比如：应用发布、开源产品搭建接入、云服务集成、集群维护等基本都是单点管理、手工操作。老系统交付过程中和转维后痛点有：

• 敏捷协同、DevOps 等的成熟度低：过去项目迭代缺少全生命周期管控，对问题和任务进度的跟进主要靠线下沟通、缺少在线化追踪工具；DevOps 流程缺少自动化的工具支撑，如业务应用的发布上线，基本都是人肉发布，发布耗时长、流程低效、且容易产生线上安全故障。
• 应用上线部署繁琐：上线需进行资源评估、应用服务器购买、安装配套软件初始化等操作流程较长；此外还需要搭配集群监控、发布&调度脚本服务治理、配置管理、日志备份等能力，都需要单独部署配套组件或系统。
• 自行实施容器化存在上手成本：开发对 K8s 等容器管理平台底层细节不熟悉、相对比较黑盒，出现问题排查进度较慢。
• 弹性伸缩不方便：业务侧有一定的峰谷，而在低谷期资源利用率很低；扩容需要重新走一套上线流程、且扩容后不容易下机器; 后续中台上线之后、预计会拆出更多的微服务应用、但这些应用因承接的业务场景不同流量不均匀，需要有更灵活的弹性策略。
• 后期运维成本高：不单需要维护应用本身、还需要维护整套基础设施及对应的配套系统；需要投入较多的额外人力

技术选型&对比

基于以上痛点以及其他中台项目的实施经验，项目组在渠道中台项目前期做技术选型、架构设计时，一开始就否决了在 ECS 或 K8s 上直接部署应用的方案，希望有一个省事的“容器托管平台”。尽量减少运维成本、屏蔽底层细节，对开发上手友好、且能较大化提高部署发布效率，具体来说，主要希望达到以下几个目标：

1. 希望有统一的管理平台进行在线化交付，全生命周期管控，以此来提高项目实施效率，该平台需具备敏捷协同、DevOps、质量保障等能力，尤其是具备 CI/CD 流水线自动化部署至选型的容器托管平台的能力，用于保障项目交付质量、提升项目交付效率、同时降低交付成本。

2. 项目采用基于 Spring Cloud 的微服务架构、需要容器平台能无缝兼容。

3. 希望平台能屏蔽底层 ECS 和 K8s 的运维工作，开发大部分工作可以在控制台完成，不需要投太多精力在运维上面，可以专注在业务功能开发上。

4. 有一定的弹性伸缩能力、扩缩容比较方便、能够定制性的做一些资源优化。

5. 微服务应用的配套设施要完备：如灰度发布、流量控制、远程调式、监控等等，能够方便的集成。

基于以上的一些诉求，我们推荐了基于 SAE（Serverless 应用引擎）的无服务器化容器平台方案、并做了一个两者的对比（如下表格）：

项目交付进展

项目在实施过程中深度使用了阿里云飞天技术服务平台——大禹进行在线化交付，通过平台进行统一的管控和赋能。

目前 SKG 渠道中台已上线包括微服务网关、微服务中心、前台 Portal、终端小程序、前端 Node 应用等前中台所属 20 多个应用全部部署在 SAE 上；上线过程不需要花太多额外的时间做系统改造或适配，只需要在控制台做一些必要的配置即可，且上线后平台运行平稳。

渠道中台业务系统的研发态和运行态大图如下所示：

SKG 渠道中台研发态&运行态大图

项目交付过程中的直观感受

• CI/CD 自动化部署至 SAE：通过大禹提供的 CI/CD 流水线能力将业务应用自动化部署至 SAE，彻底替换原来的人工部署、人肉运维的低效方式，在提升应用部署效率的同时，也有效降低了应用发布变更的风险，实现了可控部署、安全生产的效果。
• 免运维&聚焦业务：以往类似规模的集群和应用数、至少需要配置 2 个专门的运维；使用 SAE 后基本免运维、省去专门运维投入；一些 SAE 控制台配置操作基本由开发兼职即可；以往维护应用集群、经常需要排查 K8s 集群和 ECS 底层的一些问题；使用 SAE 这块基本不用关注。
• 良好兼容各类微服务框架：对基于 Springboot、Spring Cloud、Dubbo 等微服务框架开发的应用兼容较好、同时很方便的集成了 ACM、ARMS 等云产品；屏蔽了部分底层细节，可以做到一键低配置部署。
• 弹性伸缩、快速扩缩容：弹性策略灵活、在做资源优化的时候较为方便调整。

项目交付效果

• SAE 指标

全部 20+应用初始化配置-创建-部署到 SAE 上只需要 2-3 个小时；资源成本比单独购买机器节省 30% 以上；由于 SAE 支持 0.5core 的规格，开发测试环境资源开销得以降低50%以上；扩容效率则从按天计提高到分钟级。

• 大禹指标

通过大禹平台共计交付了近 20+ 应用，提交定开代码超过 180 万+行，流水线自动化发布应用超过 3000 次，平均发布时间在 100s 内；CI/CD 自动化部署效率提升 300%，零发布故障。

产品提升建议

任何云产品都不可能 100% 满足用户的所有诉求、项目组在使用大禹&SAE 的过程中、也发现了一些可以改进和提升的点：

1. 平台开放能力：大禹平台提供更开放的能力，提供更多 OpenAPI 供用户同步项目交付过程中产生的数据，如需求、任务、缺陷、人天工时、文档等数据。
2. 微服务治理：支持基于 Feign、Dubbo、HSF 等框架微服务接口的在线调试，服务 Mock，以消费者视角查看服务等能力。
3. 监控：目前 SAE 的监控都是单应用的，但从用户视角来说、由于中台往往会包含较多拆分很细的微服务应用、希望有一个全局视角的运维监控视图；方便用户查看集群整体运行情况。
4. 同 SLB 集成优化：当 SLB 被删除或失效后、在 SAE 应用首页仍会显示、并且还可以挂载端口（有可能挂载问题已修复、但肯定还可以显示），需要手动删除。
5. 支持一定的动态热部署能力，进一步提高开发部署迭代效率。
6. 对 NAS 存储的集成优化：支持在镜像中指定账号登录访问 NAS（目前会报错）

结语

数字化是企业提升效能和创新的舞台和重大机遇，相信 SKG 将在渠道中台的赋能下，依托大禹&SAE 等 PaaS 层基础设施，通过领先的数字化云化解决方案实现价值升级，开拓更大的市场！

作者：陈列昂、昕辰、龙琛、黛忻

原文链接

本文为阿里云原创内容，未经允许不得转载。