乘云而上,提质增效——《云原生 降本增效》读后感

云原生技术现在越来越受到重视，其简便、快捷、弹性的特性，在降低企业成本的同时，也极大的提高了企业的效率。由于工作关系最近比较关注云原生的话题，特别是比较关注如何运用云上弹性计算资源构建现代化应用之类的话题。有幸获取到由腾讯云和csdn 联合出品的《云原生 降本增效》电子书，仔细研读后受益匪浅。

电子书基本概况

本书分为十个章节，每一章都由有多年研究成果和开发经验的大咖就某一主题进行分享，条理清晰，内容系统全面，资料翔实，偏重于实例分享，涵盖了多个行业的最新研究动态，既有系统的理论分析，又有实际的落地案例。

印象深刻的几个点及引发的个人思考

接下来对受益颇丰的几处，聊聊自己的收获，也说说自己的想法。
首先是几个数据，给我留下了很深刻的印象。第一个数据是书中引用了Flexera 2021 年云状态报告数据，数据显示企业上云后平均浪费了 30％的云支出，云成本预算处于失控状态。这个数据足以让所有的云从业者引发警觉，进而将“如何提升资源利用率，实现降本增效？”提上日程。书中总结了企业用云成本优化面临三大挑战，及解决办法。在解决办法中，提到了应用混部，也就是业务应用弹性混部，回收波谷冗余。这让我想起，大该半年前参加过的一次分享会，会中就有大咖提到，云原生的弹性能力以及自我恢复的能力。第二个印象深刻的数据是作业帮基于云原生进行了一系列改造，最终实现了降本增效，整体的降本服务度已达到 40%。第三个印象深刻的数据是Eunomia 云原生资源编排优化后，成果显著。通过对某一集群做资源编排优化，可以在成本及稳定性等多个方面实现较大提升，如平均 CPU 利用率峰值可从 28% 增长至 75%，告警可由 88 个 / 周降低至 3 个 / 周。此外，节点CPU 利用率的周峰值均可达到80% 以上。
这些成效数据让人感到欣喜，这些成功案例打造了数字化转型范本，有一定的参考价值。对于数据体量大、资源消耗多的各行各业，都可以在自主可控的前提下摸索出一条具有可复制性的转型之路。
书中，腾讯云的孟凡杰老师以《我所经历的云原⽣降本增效最佳实践案例》为主题，介绍了以腾讯某部门集群优化为例，用优化之前和之后进行数据对比，显示出云原⽣的降本增效效果，特别是“全⾯上线⼀个⽉内，⼤盘总核数缩减 25%”的数据，真是让人感到欣喜。开源项目地址 https://github.com/gocrane/crane

除了这些成效数据以外，还有一些技术思路也给我留下深刻印象。比如由资源使用的痛点、难点在 突发流量洪峰导致资源不足、 资源维度有限。接下来，也记一记关于云原生这个话题的随想。云原生是基于分布部署和统一运管的分布式云 ，以容器、微服务、DevOps等技术为基础建立的一套云技术产品体系。书中，关于腾讯 Light 云计算平台负责人魏巍老师的分享内容中提到，他们认为：“上云的过程中并没有新技术，更多是一种新部署理念的产生。”对于这个理念，我相信大家都应该是认同的。因为，云原生并不是具体指某一个框架或用某个技术实现的一个产品或功能，相反，它是一个方法论，来帮助大家构建现代化应用的一种手段和方式。 现代化改造涉及到几个方面，比如成本、性能、可靠性等，每一个方面都有其独特的理念及实践。整个的开发者市场对于云上计算资源的需求，也是与整个应用的发展进程成正比的。最初，大多开发者会利用云上EC2的计算资源来部署应用，这种方式较为常见。在早期阶段，大多开发者更关注资源容量及其管理的方式和手段，这些开发者具有比较丰富的维护经验。随着他们对于云上计算资源的不断扩展，对产品功能的迭代开发，逐渐发现大家对于计算资源的弹性能力提出了新的要求，比如如何在不增加开发者的负担的前提下，动态的根据计算资源弹性的扩展资源。此时，容器就应运而生，它能够帮助我们节省大量管理机器的时间和成本。Docker 的兴起将容器技术带入高速发展期。从2013年Docker发布 , 到2015 年谷歌组建CNCF 再到开源容器编排系统Kubernetes 出现，容器云已在全球范围内获得广泛应用。各家技术路线各有侧重，利用到kubernetes把容器编排以及部署单元管理的更有效率，目前 kubernetes 已经成为容器编排系统的事实标准。目前很多云提供商还会给开发者提供无服务器架构，以此运行其应用负载。之前，我还看到一组 IDC 的 调 研结果，中国容器基础架构市场规模在 2020 年达到近 2 亿美元，并预测到 2025 年仍将保持 40% 以上的复合增长率，这说明容器技术目前正处于技术发展的爆发期。
另一个我比较感兴趣的点，是腾讯云的宋翔老师，对“Kubernetes 集群利用率提升实践”的分享。学习之后，很想再深入研究研究，找找相关资料学习学习。于是上知网搜索了一些相关资料。找到一篇《自动化与仪器仪表》2022 年第 10 期(总第 276 期)关于《基于 Kubernetes 的云原生数据库集群部署方案》的论文。大家如果想学习也可以一起研究。这篇文章是针对气象结构化数据在单机数据库环境下存在缺乏灵活扩展和资源利用率低下的问题,提出了一种基于Kubernetes 的云原生数据库部署方案,将MySQL 数据库运行在 Kubernetes+容器的环境，通过集群部署调优，形成分布式云原生数据库服务能力。 该方案利用Shared Everything + Shared Storage 的存储计算分离架构实现资源池化高效管理；利用Shared Nothing 的分布式架构，实现数据水平分片、水平扩展。文章正好和我目前的工作有关，感到找到了宝。文章里总结了数据水平拆分算法，包括枚举(list)算法、范围(Range)算法、HAsH 算法、字符串 HAsH 算法、日期算法、混合算法。还写了是如何完成集群部署调优。在此也稍做记录（方便自己再回看，哈哈）。
略跑题的笔记：
HAsH 算法
HAsH 算法是对字段值进行二进制求模运算,得到结果再通过范围指定节点索引。 求模运算的基数为 par-titionCount∗ partitionLength,默认为 1 024，此时相当于取字段值的低 10 位用 1024 作为基数进行求模运算，即二进制字段值 &1111111111。 HAsH 算法可将接近的值分到连续的分片，减少插入事务的控制难度。 随机分布的字段都可以通过特定算法转换成数字之后进行固定HAsH 拆分，HAsH 拆分规则配置如下:

<function name= " hash" class= " Hash" >
　 <property name= " partitionCount" >8< / property>
　 <property name="partitionLength" >128</ property>
< / function>

配置说明:
partitionCount:分片个数，一般设置为节点数量。
partitionLength:分片长度，就是每个分片上散列值的数量。 一般情况下 partitionLength 设置为 1024/ parti-tionCount。 如果 partitionLength 设置为 1，则求模基数等于 partitionCount，节点索引 = 字段值% partitionCount，此时 HAs H 算法就变成了普通的求模算法。
字符串 HAsH 算法
字符串 HAsH 算法是将字符串整体或者其中一部分转换成数字,再利用 HAsH 算法求得节点索引。

<function name= " hashsrting" class= " stringHash" >
　 <property name= " partitionCount" >8< / property>
　 <property name="partitionLength" >128</ property>
　 <property name= " hashslice" >0:2< / property>
< / function>

字符串 HAsH 拆分规则配置如下:
配置说明:
partitionCount:分片个数,一般设置为节点数量。
partitionLength:分片长度,就是每个分片上的散列值的数量。 一般情况下 partitionLength 设置为 1024/ par-titionCount。 如果 partitionLength 设置为 1，则求模基数等于 partitionCount,节点索引 = 字段值% partitionCount，此时HAsH算法就变成了普通的求模算法。
hashslice：参与求模运算的字符串的起始位置格式为起始位置：结束位置，起始位置的字符在计算范围内，结束位置的字符不在计算范围内。 起始位置的 0 代表第一个字符，结束位置的 0 代表字符串长度,负数代表倒数第几个字符。 如果字符串长度小于设定的范围，则对整个字符串求模。[1]
集群部署调优部分有兴趣的可以自行在知网找这篇论文~

读后，还有点其它思考

那么，云原生的成效数据这么好，大家是不是马上应该复制路线？或者说，在转型升级目标下，企业如何借助云原生完成业务的数字化转型？我觉得，盲目采购新技术是肯定是不可取的，一定需要考虑各方要素后才能规划如何转型，万不能盲目照搬。首先是自身基建水平及现有IT架构，以及改造成本能否接受。然后是考虑所需的产品性能、灾备、安全等。最后，还得考虑哪一类的服务商适合自身的实施方案。通常，大家在选择一个适合自己的云上计算资源去部署应用负载时，一般分为以下几个步骤来确定：首先是硬件架构， CPU的处理器型号以及它的架构直接决定应用的运行方式和方法，比如说X86和ARM在硬件指令集上面就会有很多差别，对于它支持的应用种类以及类型也有一些差别，那我们的工作负载适合于哪一种首先是在底层上面它就会由CPU处理器架构决定。如果我们在满足了硬件底层的支持能力后，接下来考虑的是选择多大容量的机器来满足工作负载的要求。第三是采用怎样的形式来运行架构。比如，我们部署了一款应用，假设应用可以允许中断，或是应用本身就具备了弹性的能力以及自我恢复的能力，那么在云上就有很多种方式节省成品或提升效率。在充分考量各类因素后，才能得到更有价值的方案，进而搭建出适合自身企业的自主可控、安全合规的系统。

书中还提供了学习专题链接，可看回放，有兴趣的小伙伴们一起学习起来呗：https://marketing.csdn.net/p/6c2a12739080d8fba0fb0b529a656de1

总结

这本书有很强的可读性，通过这几天的学习和钻研，使我在较短的时间内了解和掌握了不少云原生方面的知识，也了解到了很多优秀的案例。读了书中各位前辈的经验心得，觉得不仅提高了自身的水平，也觉得可以学习或是研究的思路得到了拓展。我觉得，这本书最大的一个亮点可以用一个“新"字来概括。新的技术、新的思路，如果把它比作一道菜的化，正是因为它的新，让读者品味起来感觉鲜美异常。各位老师的经验分享很接地气。这本书做为导引，能起到开拓思路的作用，有兴趣的伙伴们可以读读，也许也会被书点一些点启发到。

总体来说云原生已经成为云经济体系下不可或缺的技术力量。云原生不仅仅是一种技术能力，更传递了面向云应用的一种设计理念。云原生的理念下，计算资源实现自动伸缩，一站式完成资源与集群弹性扩缩配置，实施展示全链路资源追踪，智能运维，实现了应用成本的优化。从“上云”到“用云”，希望同行者们在云原生能力建设中始终校准靶心，为更高效地创造业务价值而部署云能力、发展云能力，持续从云中获益、由云中进化，将云原生技术持续与新技术、新应用进行深度融合，并演进为全新的技术体系，谱写出高质量发展的新篇章。

参考文献：

[1]马　 晋,等《基于 Kubernetes 的云原生数据库集群部署方案》,自动化与仪器仪表,2022 年第 10 期(总第 276 期),56-57