写在前面的话

C站这么多大佬都讲了如何去实践Docker或者K8s简单实战，笔者也没有真实做过一些云原生实战项目，都是跟着B站大学学过一些简单概念与基本入门的命令。也就不多写这些知识了！

大家学习云原生，肯定都很少听过云原生一些真实的场景下如何去运用如何去落地，只知道Docker能干嘛干嘛，K8s能用来高效能的管理容器编排，云原生能够赋能项目如何如何减小成本等等。

那么本期文章就是笔者学习了一些腾讯云/阿里云基于云原生的产品项目开放的落地实践方案的一些感想与学习记录。后续也会多写一些云原生落地实践方案的学习记录！腾讯云和阿里云等多家大厂都有很多云原生实践落地的开放文档或文章介绍，大家感兴趣的可以去百度一下看看多学习一下。不得不说，腾讯在推动国内云原生这条路上真的是走了很远！大家有空可以多去关注阿里云、腾讯云。

前面的文章已经简单介绍了一些云原生的入门知识及简单实战。感兴趣的同学可以跳转进入：云原生学习专栏

1、容器化的落地实践

搜题APP的云上之旅

相信大家都或多或少用过或听过某帮，反正笔者在高中经常使用某帮。确实十分好用，上了大学也经常在用hhhh，答案齐全，查询速度快！在学习云原生的时候，我才发现原来云原生使得项目落地的方案离我们这么近，作业帮就是一个很好的例子。

某帮大家第一想到的业务场景需求肯定是：海量业务、海量的高并发、并且需要极低的延迟来提供广大学生的搜题等其他服务。

某帮累积的激活用户已经超过8亿，并且随着疫情的突发，某帮的系统和基础的平台架构已经无法满足快速增长的各种业务需求和场景。业务对快速发布、调用链追踪、监控日志平台、计算资源利用率等等的各种提升肯定是十分急切的。

经过沟通，腾讯云决定将某帮的核心业务迁移到腾讯云容器服务TKE。但是在这个过程中，遇到了许多技术难题：

• 1、原业务大规模使用Kubernetes原生的负载均衡和服务发现，但Kubernetes在分散的流量调度架构上存在天然的瓶颈，容易导致业务负载严重不均衡。

• 2、原业务对服务间时延依赖，部分业务连接超时时间设置为5毫秒，所以无法承担细微系统调度和
  网络波动，如果一旦在未经优化的内核和网络下，容易引起业务大面积超时。服务间访问会带来巨大的DNS并发，极易触发主机的QOS限速和引起主机的conntrack冲突。

那么腾讯云是如何解决的呢？

• 1、解决IPVS模式高并发场景下连接复用引发连接异常（对应issue:https://github.com/kubernetes/kubernetes/issues/81775，内核补丁已被Linux社区接受）；在高配节点(核数多)下IPVS规则过多引发网络毛刺问题；大Pod(占用核数多，单核占用高) 在高配节点(核数多) 场景下，CPU负载均衡引发网络毛刺的问题等。

• 2、还基于TLinux2.4（内核4.14），优化了大量容器场景网络收包软中断导致的延迟问题，大幅提升网络性能。同时，结合腾讯云卓越的网络和存储能力，以及TKE，EKS提供的稳定的容器运行时环境，为其提供了整套容器化解决方案。

• 3、将在线业务、大数据离线任务、GPU任务都进行了容器化的改造。某帮开发语言众多，通过Service Mesh实现多语言的服务治理与服务感知。同时某帮也有大量GPU服务容器化部署在TKE里，为提升GPU资源率用率与隔离性，其采用共享GPU模式，并在业务层，通过限制入口流量的方式做了不同Pod GPU使用量的隔离。利用EMR on EKS方案，某帮将紧急的大数据任务或者临时的计算任务运行在EKS弹性集群里，避免了复杂的资源规划及储备工作。
  
  那么通过容器化的云上改造，腾讯云在其开放文档中显示其成本直线下降40%左右，接口响应提升10%，稳定性从99.95%提升到99.995%；并且发布效率提升两个数量级，平稳支撑了疫情期间业务爆发式增长，快速迭代、急速扩缩容的真实业务需求。

2、Serverless的落地实践

某电商APP的Serverless改造之旅

某电商APP是一家知名度很高的互联网公司，其将购物与社区的结合收获了一大批忠实粉丝。那么这样一个大的APP，每天都会产生大量的数据，当APP产生了数据之后，就需要有一个组件获取数据，并将数据写到kafka。该APP以往的办法是，通过Lofstash、Filebeat等开源的数据存储方案处理，二是自己写代码实现这种逻辑。

上述的原方案在数据量小的时候还可以，随着业务扩张，数据越来越多，那么原方案的可靠性、可用性、性能成本就不能够较好的支撑了。

当进行产品迭代或设计新功能时，前期需要做许多新项目的验证，这会涉及海量的数据拉取和数据分析。而这一部分的数据需求会给开发带来很大的压力。不仅需要对已有数据处理的主流程和数据结构有适配成本，需要考虑稳定性的风险，这部分需要投入大量人力和时间成本；而且由于过程时间周期比较长，会影响迭代的速度，赶不上市场上的竞品。

腾讯云使用了Serverless ETL方案来帮助该APP解决上述问题。

ETL是指：业务上需要做数据抽取 (Extract)、数据转换 (Transform)、数据加载 (Load) 的场景。

众所周知，许多大型的APP都使用Kafka做大数据分析、日志收集、流式数据处理等等。腾讯云的Ckafka也借助开源社区的力量与云函数结合，推出了许多优化功能：

• 1、基于Apache Kafka的分布式、高可扩展、高吞吐。
• 2、无需部署，直接使用Kafka所有功能。
• 3、Ckafka封装所有集群细节，无需用户运维。
• 4、对消息引擎优化，性能比社区最高提升50%。

云函数实时读取Ckafka中的消息，用来做数据转存、日志清洗、实时消费等。此外像数据转存的功能集成到了Ckafka的控制台上，可以一键开启使用，降低了使用复杂度。
而腾讯云Serverless云函数也具有许多优势，例如：

• 1、支持多语言。
• 2、无限的弹性扩容能力。
• 3、多重触发式、事件触发、定时触发、主动触发等。
• 4、腾讯云Serverless云函数 + Ckafka提供自建的UI交互界面，可进行流量告警配置，同时控制台上可进行扩容配置且安全可靠。

腾讯云通过云函数将一个实例中某个Topic的消息转储至另一个实例对应的Topic上。对比原来的Connector方案，腾讯云云函数SCF能够通过腾讯云控制台进行管理，能控制触发阈值，触发开关等，可以很方便地对每个函数进行管理。消息转储能够将Topic的详细同步至离线集群。

3、云原生TKE的落地实践

QQ相册的TKE之旅

早期，在QQ相册上云之后，架构如下：

但随着后续发展，暴露了许多问题：

• 1、社交业务有高峰期如节假日、晚高峰等，无法快速应对大量突发。
• 2、容器化部署分散在独立集群和复用集群，管理成本过高。
• 3、容器所在的workload平均利用率较低。

那么是如何解决这些问题的呢？大致举例一些如下：

• 1、通过复用集群、独立集群迁移到共享集群提升资源利用率。

复用集群因为是使用老旧机器搭建的K8s集群，在使用上会有比较多的损耗，而且经常会有资源抢占严重的情况，而独立集群的母机规格不够高，会造成一定程度的资源浪费。基于上述两点，复用集群和独立集群的系统迁移到复用集群是较好的选择。迁移后的资源利用率和错误码次数都得到了明显的改善。

同时使用 HPA 弹性扩缩容，根据 CPU 利用率，资源在业务低峰期释放，高峰期自动扩容，节约了成本。

• 2、部署策略优化

因为当前基于一个可用区的命名空间建立一个 workload 的方案没有考虑到单可用区的容灾，所以在一个集群的多个可用区都建立了 workload，同时在其他地域也建立了容灾的 workload，当有机房或者地域级别的故障发生时，可以自动切换到其他机房或者地域。

• 3、ClickHouse日志查询

随着相册业务日志量的增加，日志存储成本也在升高，所以把日志迁移到了 ClickHouse。在可接受的影响范围内，ClickHouse 所需资源只需要 ES 的30%-50%。

为顺应时代、技术的趋势，上云、云云原生已经成为了一直事实。随着相册的 TKE 业务从其他平台转到共享集群，结合部署优化策略和运营开发能力，这就是TKE的突出优点。随着QQ相册TKE业务从其他平台转到共享集群，再结合部署策略优化等，打通智研 CICD 流程，显著提升日常开发和运维效率，并且云原生成熟度有了显著的提升。

文章来源: blog.csdn.net，作者：洲的学习笔记，版权归原作者所有，如需转载，请联系作者。

原文链接：blog.csdn.net/weixin_51484460/article/details/125382778