现在，客户们每次来鹅厂，必问：

“你们是怎么推动全公司搞云原生的？”

其实，上云初期，鹅厂自己也走过弯路——

业务习惯把物理机原封不动搬到云上，或者直接把容器当虚拟机用。

当实例变得又大又复杂，就没法快速启停，大大影响了弹性扩缩容的效率。

因为尝不到弹性扩缩容的甜头，所以大家还是习惯「堆机器」：

业务规模越大，资源浪费的问题就越突出。

而且，不少业务的技术栈都是老黄历了——

一台机器上运行着N个进程，各种连接、缓存等都是进程级别的。连接数经常打满，链路稳定性的问题很多。

总之，单靠叠床架屋，云计算的甜头还是尝不到。

其实鹅厂内部对上云早就有明确定义——

不止要上云，更要全面云原生！

并且，总办领导拍板：

自研上云，必须基于腾讯云TKE容器服务。

如果说，上虚拟机就像换底座；那么，上容器更像脱胎换骨，得各个业务部门亲自上手，重构架构逻辑。

涉及这么多部门，「推不动」是难免的：

为了让云原生进度条持续往前走，我们拉了个「云原生成熟度」表格。

说是表格，其实更像个「评估模型」。每个季度都打分，还要抄送给总办领导。

作为一项牵引机制，它在确保业务稳定的前提下，主抓三大项：

一是，可调度。

以前，为了确保运行安全，大部分业务都是不可调度的。

甚至平台侧一旦调度，业务就会报故障单。

想要提升整体利用率，每个业务都得「可调度」。

（在资源利用层面，这相当于指哪打哪）

现在，鹅厂超过95%的集群都是公共集群。

依托腾讯云的分布式云操作系统遨驰，业务不需要关注底座，选择地域后，平台会自动调度到有资源的集群里。

实现「可调度」后，业务反而更稳定了。

以前，任务固定在指定机房里，数据中心一旦跳闸停电、网络堵塞，上层业务也受影响；

现在，底层的故障可以直接无视、无感另起，稳定性大大提升。

二是，微服务

如果业务的「颗粒度」太大，会浪费不少碎片空间。

我们推动业务把单体应用拆小、改造成微服务架构，各个模块独立运行。

这个看颗粒度的指标，在鹅厂叫装箱率：

（顾名思义，装箱率高了，资源利用率也就上去了）

更重要的是，由于每个微服务都是独立的，新的特性不需要等整个系统更新，就能快速部署到生产环境里。

一句话，通过业务架构的微服务化，实现了降本和增效的双丰收。

三是，弹性伸缩

流量来的时候，能不能快速接住？走的时候，资源有没有及时回收？

只有平台和业务两侧同时实现弹性伸缩，才算实现了应对突发、降低成本的双收益。

2021年起，「上云就上云原生」成了鹅厂街头巷尾的热词。

从那年起，我们就在通过这套模型，去量化评估每个部门的云原生成熟度。

云原生一路狂飙，也把腾讯整体的资源利用率和研发效能拉了起来。

这个表，不仅总办会看、部门之间还会比：

云原生，甚至成了鹅厂的一项文化：

答辩评审标准，也会偏向云原生落地成果，做得好的答辩还能加分。

这套机制也在持续迭代：

– 半自动的弹性扩缩容，如何实现真正的自动化？

– 负载均衡、稳定性能不能再提升？

每年，公司都会微调具体维度，推动云原生走的更深。

作为鹅厂「全面云原生」的技术底座，腾讯云TKE容器服务也在一路进化，跟这项机制打好配合：

– 打造TKE Serlverless 形态，主打微服务、小核心场景，实现高效运维；

– 推出TKE原生节点，落实 FinOps 理念，助力业务降本；

– 孵化应用管理平台，结合业务容器可调度，实现整体资源最优化运营。

我们也希望，用这条鹅厂走通了的路，帮助更多客户提升资源利用率、降本增效。