本文分享自华为云社区《DTSE Tech Talk | 第64期：DTSE与开发者同行，探索云原生实践，共筑高效云优化之路》，作者：华为云社区精选。

在主题是《DTSE 与您同行，探索云原生实践，共筑高效云优化之路》的直播活动中👉（点击观看），华为云云原生 DTSE 技术布道师王逸真，与开发者们交流云原生的核心优势和关键技术，从解读企业应用云原生的“三阶段两转变”到开发者技术支持工程师（DTSE）为开发者提供全流程技术支持，并向大家剖析了客户实例，揭秘探索云原生实践，解决客户痛点。

云原生已成为企业 IT 基础设施主流选择

云原生已经成为企业 IT 基础设施的主流选择，据行业机构的调研结果，在 2023 年，全球容器的数量已经超过虚拟机数量，且后续两者的差距会越来越大。目前，全球各行业约 80%的应用完成了云原生化改造。

云原生给企业带来的价值

从整体架构上看，企业应用云原生化可以让企业从垂直烟筒式的技术平台变成敏捷高性能开放的云原生基础设施，从多机房割裂式的资源池变成统一，标准云原生混合云架构。

从具体场景来看，云原生技术在对资源利用效率、对业务弹性的价值最为明显，随着云原生技术在各行业的普及，不同行业对云原生应用的核心诉求存在一定差异，相对而言，资源利用率，弹性与多云是核心诉求和技术价值。

如何选择云原生技术厂家？

华为云长期投入云原生技术与产业，是全球云原生领域的领导者。华为云在 2017 年就成为 CNCF 初创会员，是容器标准的制定者，在随后更是不断地发展云原生技术，落地云原生实践，目前已经成为云原生产业发展的先行领导者。

企业应用云原生的“三阶段两转变”

企业怎么走到云原生，通常面临“三个阶段，两个转变”。

阶段 1，一般以硬件设备为中心，应用在线下机房中，自动化程度低，没有统一的设备和应用管理能力。后期随着虚拟化软件的出现，在资源利用率、扩缩容灵活性上得到一定程度的提升，但并未从根本上解决基础设施与软件割裂、且运维复杂的难题。阶段 2，为了进一步追求资源的自动化，将基础设施和业务软件解耦，企业将应用放在云上，进入云化阶段。计算、存储、网络等各类基础资源得到池化，通过云资源管理平台，实现资源管理能力的自动化，屏蔽部分基础设施的差异，但是各个云资源管理平台差异化较大应用还是无法以完全标准化的模式构建，此阶段还是以资源为中心。

阶段 3，为了进一步追寻应用的自动化，企业开始使用云原生平台，企业的关注点从资源移到应用上面。开始考虑如何将基础设施与业务平台融合，为业务应用提供标准的运行、监控、治理等接口，通常在这一阶段，企业还会将业务的通用能力下沉到平台侧，进一步实现应用的自动化。

开发者技术支持工程师（DTSE）：为开发者提供全流程技术支持

DTSE 全称开发者技术支持工程师，为开发者提供全流程的技术支持服务，截止 23 年底，已经服务了 2700 多家企业，解决了 1100 多个开发者需求。另外，DTSE 本身面向云原生、大数据、AI、鸿蒙等多个技术领域，其中云原生是我们重点的支持方向之一。

DTSE 跟普通技术支持相比的优势是可以提供线下的贴身服务，提供代码级技术支持，而且 DTSE 不仅围绕华为云 240+云服务，还围绕各类主流的开源技术栈，帮助开发者上好云，用好云。更重要的是，DTSE 具有诸多从传统应用到云原生应用转型的案例和经验。

客户案例实证，探索云原生实践，共筑高效云优化之路

以下是我们在实例拓展中遇到的一个客户，客户多次遇到业务流量陡增，弹性跟不上业务变化的情况，DTSE 了解到客户诉求，从代码到架构跟客户一起梳理规划，短短 2 个月完成了初步的应用云原生化。

图为客户原有的技术架构

客户的业务发展过程中，架构上积累了很多的问题：

1. 首先，1 到 3 号 ECS 服务器绑定了固定的公网 IP，用于第三方服务访问，对于特定的 API 经过负载均衡解析，只路由至 1 到 3 号服务器进行访问，在流量洪峰时不支持扩容。

2. 应用集群基于 ECS 整体部署和备份，备份镜像高达 200G，既效率低下，又成本较高。

3. 基于 ECS 整个的镜像做弹性伸缩，扩容时间长，不满足突发流量的要求，且一个 ECS 部署多个组件，缺乏灵活性，管理也复杂。

4. 消息队列也由 redis 承载，在消息堆积等场景下可能会出现异常。

图为客户应用部署架构，从应用部署角度来看，1 号服务器属于有状态部署，不支持伸缩，有额外的注册中心，所有的网关节点和业务节点必须向其注册自身，存在单点故障的风险。

业务中的定时、消息消费任务是通过基本的常驻进程实现的，也不支持扩容。

双向通信的业务逻辑，只会调用当前节点的 Business Worker，无法做到集群负载均衡。

图中这个架构只是一个应用，通常在该服务器上还有其余应用系统，可能出现资源争抢的现象。

最后，我们还发现，业务代码混杂在一起，耦合严重。

CCE：高可靠高性能的企业级容器服务

为了满足客户云原生化的诉求，华为云 DTSE 提供贴身的技术服务，结合华为云产品能力，来解决客户问题。

第一款用到的产品是华为云的云容器引擎 CCE，CCE 是华为云提供的高可靠、高性能的企业级容器服务，有 CCE 标准版、CCE Turbo 版和 CCE Autopilot。

其中标准版提供插件管理、集群管理、节点管理、成本治理等功能，基于华为云上计算、存储、网络等基层资源，向上提供了原生 k8s 服务，开箱即用。

CCE Turbo 版本，采用华为云擎天软硬协同架构，在容器网络、智能调度等方面进行了增强，采用云原生网络 2.0，外部访问直通 POD，此外还提供基于裸金属服务器的安全容器。

今年新推出的 CCE Autopilot 属于 Serverless 服务，在擎天架构的基础上新增了资源统一供给层，提供了极致的弹性。

这三款产品适用场景不一致，优先推荐 CCE Autopilot

Serverless 容器：极致性能、高效运维、丰富算力

我们使用的另一款与 CCE 搭配的服务是 Severless 容器产品，此产品是基于 service 基础设施资源底座提供的极致性能、高效运维、丰富算力容器平台。

这个和刚刚的 Severless 的 CCE Autopolit 有什么区别？可以简单这么理解，CCE Autopolit 是集群性质的，能看到一个个集群，但是 Serverless 容器是 POD 级别的，没有集群的概念，直接操作容器。

此产品包含，以 POD 或 POD Group 管理维度的 CCI 服务，和新出的用于轻量应用搭建的轻量容器服务，提供极速的弹性。

在此案例用，只使用 Serverless 容器与 CCE 进行搭配，来应对突发弹性，所以我们选择 CCI 服务。

技术架构：容器化和配置中心带来产品性能和研发效能双提升

下面我们就用刚刚提到的云服务，对客户的技术架构进行了改造，使用 CCE 和 CCI 替代了 ECS 集群，将业务进行了容器化和无状态化部署。

综合考虑性能和成本，结合 CCE 和 CCI 的配置规则，弹性伸缩时，让容器优先在常驻的 CCE 节点上扩容，其次为 CCE 弹性节点，最后为 CCI，缩容反之，在保证弹性能力的情况下，成本最低。

在弹性策略方面，利用 CCE 的 prometheus 插件实现了基于请求数的弹性伸缩策略，让负载更灵敏的贴合业务变化，应对突发流量。

除了弹性之外，还给客户新增了应用配置中心组件，统一管理配置，让配置可管可控可视。最后整个应用集群通过 Nat 网关实现对第三方服务进行访问，实现单 IP 外置化，不再与集群强耦合，解决了特定 API 在流量高峰不能扩容的问题。

应用层将各个模块独立，降低耦合性

在应用层面，我们将客户的各个模块进行拆分独立，降低了整体的耦合性，比如 Nginx、网关等等，允许各个模块单独弹性伸缩。外部访问路由，使用了 CCE 的 Nginx Ingress Controller 插件，同样可以在管理台界面动态更新配置信息，减少运维复杂度。

对于负载均衡则是基于 K8s Service 的能力，在 CCE 集群内部进行负载均衡。

业务容器化之后，镜像大小从原来的 200G 缩小为不到 200M，既节省了备份空间，又可以在横向扩容时，加快扩容速度。

我们还针对每个容器启用了健康检查，从 POD 层面保证了业务正常运行，加快了系统故障的回复速度。

而刚刚在技术架构中提到的应用配置中心，也作为容器独立部署，无需额外的机器，节省了费用。

经过 DTSE 的贴身服务，客户的应用在应对突发流量的弹性、业务的可靠性、运维的方便性等方面都有很大的提升，不过并没有解决在原有架构上提到的所有的问题。因为很多问题，需要应用开发者进行重构。DTSE 对于每种问题都给出了优化建议，DTSE 也会继续的贴身服务，帮忙客户在云原生化的路上走的更远。

容器化后不能直接进行灰度发布

很多场景下，减小 BUG 带来的影响，需要进行灰度发布。在原应用架构下，应用使用 ECS 集群部署，当有新的版本需要服务，客户手动的将部分机器升级为新版本，等待新版本测试稳定，再将所有机器切换到新版本。

然而在容器化之后，应用使用 Deployment 部署了多个 POD，但是 Deployment 是一个整体，其中的 POD 会完全一致，无法按照原来的模式将部分的 POD 更换为新版本。

对于这个问题，最先想到的是云原生的代表技术服务网格，可以被用于应用间的流量治理，那么华为云相关的产品就是 ASM。不过客户在测试之后并不想使用该产品，主要因为服务网格中的 Envoy 在每个 POD 中都占用很多的资源，增加了成本，而且因为弹性伸缩的 HPA 策略是关联 Deployment name 的，ASM 灰度发布后，HPA 策略就失效了，综合以上原因，客户否决了这个方案。

基于 CodeArts 实现容器的自动灰度发布

为了更好的解决客户的这个问题，我们来看一下华为云提供的软件开发生产线 CodeArts 服务，这款产品是一站式，全流程的开发工具。覆盖了从产品需求、开发部署、到产品运维等软件交付全生命周期环节，我们在此问题中主要用到了流水线 Pipeline 和部署 Depoly 两个组件。

那么是如何做的呢？整个灰度发布的流程，可以分为这几个步骤。

• 首先发布新版本，减少旧版本的副本数，此时在 POD 层面，总数量不变，部分 POD 变成了新版本，其余还是旧版本，然后进行试点测试，并进行人工审批。

• 如果新版本有 BUG，那就立刻回退，步骤与上一步相反，也就是回退旧版本副本数，删除新版本。

• 如果新版本没啥问题，那就可以把旧版本删掉，只保留新版本了，同时考虑 HPA 策略，步骤为：创建新版本弹性伸缩策略，删除旧版本，删除旧版本弹性伸缩策略。

对于上述步骤，人工操作也完全可以实现，但是为了避免紧急情况下的误操作，可以采用华为云 CodeArts 流水线，将上述步骤串起来，进行自动化，其中每个独立的步骤，可以使用 CodeArts Deploy 对接上对应的 CCE 集群下发指令完成。

此外，整个方案用到的 CodeArts 都是免费的，CodeArts 提供了 50 人的免费版本，这个是 ASM 方案没法比拟的。最终客户接受了这个方案，整个项目也顺利完成。

点击关注，第一时间了解华为云新鲜技术~