查看原文
其他

听说,整个鹅厂都在卷这张表

腾讯云
2024-07-25

大伙都知道,鹅厂完成了国内最大的云原生实践

现在,客户们每次来鹅厂,必问:

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

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

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

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

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

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

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

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

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

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

不止要上云,更要全面云原生!

并且,总办领导拍板:

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

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

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

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

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

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

一是,可调度。

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

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

就像这样

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

(在资源利用层面,这相当于指哪打哪)

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

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

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

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

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

二是,微服务

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

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

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

(顾名思义,装箱率高了,资源利用率也就上去了)

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

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

三是,弹性伸缩

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

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

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

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

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

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

这种比赛,是常有的

云原生,甚至成了鹅厂的一项文化:

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

这套机制也在持续迭代:

- 半自动的弹性扩缩容,如何实现真正的自动化?

- 负载均衡、稳定性能不能再提升?

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

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

- 打造TKE Serlverless 形态,主打微服务、小核心场景,实现高效运维;

- 推出TKE原生节点,落实 FinOps 理念,助力业务降本;

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

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

修改于
继续滑动看下一个
腾讯云
向上滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存