2024 年全球终端用户在公有云服务上的支出预计将达到 6788 亿美元，基于云原生的大量创新正在为行业带来强劲的发展势头，同时也越来越多地被视为云战略和数字化转型工作的核心原则。Gartner 预测，到 2027 年，超过 70%的中国大型企业将建

　　这些宏观趋势之下，云原生技术在持续实践和发展中。2023 年底，CSDN NPCon 系列主题技术峰会——NPCon 2023 云原生实践峰会12月9日在北京成功举办。

　　本次峰会由 CSDN、《新程序员》、腾讯云联合主办，邀请腾讯云高级开发工程师赵奇圆，作业帮基础架构、内核&k8s 专家、资深架构师张浩然，去哪儿网高级 Java 开发工程师沙丹丹，天翼云资深研发专家刘超等 4 位大咖，在 CSDN 云计算主编宋慧的主持下，针对宏观云原生应用的稳定性、k8s 集群预测技术、云原生与测试的结合以及传统行业的云原生实践等方面进行深入探讨。

　　该主题由赵奇圆分享，分为三点：1、云上 K8S 集群架构介绍；2、K8S 数据面常见的稳定性问题和挑战；3、针对上述挑战都做了哪些优化。

　　K8S 集群包含控制面和数据面。控制面是运行在管控节点的 master 管控组件，包含 apiserver，调度器和 controller-manager。数据面是运行在用户节点上的服务。包含运行时，网络和存储等系统组件，以及调度能力增强，可观测能力增强等扩展组件，还有提供业务服务的业务组件。

　　把问题治理分成了问题的发现和预防，问题的定位和止损以及问题的修复三个阶段。

　　问题发现的挑战在于云上 K8S 数据面严重依赖了云 IAAS 能力，对于依赖的 IAAS 能力限制和底层架构不熟悉导致潜在风险考虑不周。

　　问题定位和止损的挑战在于云原生场景下数据链路长，有效数据收集慢导致问题定位和止损效率低。问题修复的挑战在于缺少健全的升级机制，导致系统组件升级风险高和效率低下。

　　在问题发现和预防层面，构建了云探系统，进行 IaaS 层面、K8S 架构和业务架构全方面巡检，进而发现潜在问题风险点。增强系统可观测性，它通过使用系统内的监控/日志/事件/审计日志等信息，并结合点检、诊断、巡检等全方位检查能力，对集群内的隐患问题，故障资源进行检查/自愈，提升客户集群的稳定性，提升运维效率和产品体验。

　　云探会定期对整个集群做全面检查，如云产品资源水位，集群控制面组件/系统组件/节点/业务负载及健康状态，CVE 漏洞等。当检测到集群中存在异常时，系统会将异常信息推送到 EB 平台，用户可以在 EB 平台订阅自己关注的事件。同时，云探也支持通过标准的 K8S API 来暴露异常信息，用户可以使用云原生的方式来获取诊断结果。

　　除了定期巡检之外，用户也可以通过 K8s API 来主动触发云探巡检，并且可以自定义巡检的内容。根据不同的检测项，用户可以配置不同的 action，例如通过 K8S event 暴露，为节点添加 condition，驱逐节点，回调用户 webhook 等。

　　该主题由张浩然分享，分为五点：1、调度器的作用；2、调度遇到的问题；3、如何优化；4、展望。

　　为任务或者服务快速匹配合适资源，调度的任务和服务能稳定运行，提高资源使用密度。快速准确实现以上的这种能力。但是快速和准确两个目标在资源有限场景下往往产生矛盾，所以需要两者权衡。

　　1、周期性高低峰及高低峰差距明显的特性使得request难以设置合理的值。设置低会影响高峰均衡性、设置高则会拉低部署密度。

　　球王会app

　　2、往往集中在低峰期的迭代和扩缩，导致当下的资源使用情况难以顾及未来高峰期的均衡性。

　　2、负载间的相互干扰。影响一个业务运行的因素非常多，涉及到操作系统的任何一项都有可能造成异常。不同业务形态对资源的需求量不同：磁盘、cpu、网络等，可能存在相互干扰

　　3、集群中大量 Cronjob 任务，定时任务并非时刻运行，但是常态下却需要保持全量的容量，带来的问题是密度忽高忽低，整体装箱率低，除容量问题外，大量定时任务导致频繁的cgroup创建回收还会影响节点性能。

　　4、周期性集中扩缩和大量cronjob 相撞导致的吞吐量不足，影响定时任务的创建和调度时延。

　　5、趋于复杂的业务场景、gpu资源类型和使用方式，cpu和gpu混部、在离线混部、推理训练混用；gpu资使用方式多样化。

　　1、对于 Request 不准的问题，基于历史实际用量修正偏差，依赖历史数据去回归分析，预测未来使用量，并将这个结果作为额外的权重去修正 Request 不准的问题。

　　2、对于相互干扰项做了多因子（内存、IO、网络、日志量）参与预算的评分，根据最终评分进行调度。

　　3、对于大量定时任务的问题，解决吞吐能力是串行改并行，所以我们细化资源域，做调度分级，拆分独立小规格高密度 job 节点 和 serverless，对serverless的任务并行化调度

　　4、自定义gpu调度器，提供整机、卡级别、卡共享混合调度能力，比如当一张卡被分配在显存级的 Pod 之后，这张卡变成共享卡，这样卡级别 Pod 调度时直接过滤掉这张卡球王会app。整机也是，当有任何一个共享卡或者卡级别调度 Pod 时，整机直接过滤掉这台机器，整机的需求不会选择这台机器。提供多种混合装箱策略：卡共享优先堆叠，卡级别反亲和等

　　第一个是并行调度，当规模达到一定程度之后，并行调度就是解决这一问题的具体措施。第二个是资源抢占和重调度场景下，保证高优先级的 Pod 能够充分运行。第三个是拓扑感知，当前调度器都是节点级别，但是节点并非最小资源单位，还有比如numa、gpu、nvlink这种节点内的物理结构。第四个是动态资源分配。

　　该主题由沙丹丹分享，分享的内容是关于云原生对去哪儿网在测试领域带来的变化。

　　写接口的测试流程和读接口测试流程差不多，但是多了录制回放流程。在线上选择一台服务器去部署安装 Agent，线上的 Agent 会把线上所有这一次请求对外调用录制下来，上报数据中心，对应的 case 从这些录制的数据里去获取。拿到这些 case 之后，同样向两个测试环境发起回放请求，一个是基准环境，一个是测试环境，这两个环境收到请求之后会发现这是一次写接口的回放，会把所有的对外调用进行回放，把每个调用的调用参数都上报到数据中心，测试平台会将这两个环境上报的每个对外上报子调用数据给出 diff，最终给出测试报告。

　　目前已经接入 300 多个应用，200 多个开通拦截，每天测试接口数在 2600 多个。写接口的应用有 30 多个，有 180 多个接口。我们的回归测试周期从原来的 0.5 天下降到了 10 分钟，故障率有非常明显的下降。我们也做了调查问卷，显示 76%的用户都认为这个自动化测试工具能够在上线前帮助发现问题。我们现在已经有 80%的项目都是自测自发的，开发完全是靠这个工具来降低故障，帮助提升质量。

　　全链路压测分为压测前、压测中、压测后。压测前会创建压测场景，自动生成压测脚本，线上捞取一批压测 case，压测中发压测请求，压测后自动生成压测报告，包括本次压测覆盖全链路上的哪些应用，这个应用的覆盖度有多少，链路上接口覆盖度多少，下游接口平均响应时间是多少，保证本次压测有清晰的概念到底覆盖多少接口，以及每个接口是否压到了想压的 QPS 等等。经过一系列优化，压测成本从 1PD 降至 0.1PD，也就是 1 小时就能完成一次全链路的压测。另外，还开发了一些组合压测功能，包括并行压测和串行压测。

　　经过优化后，全司压测时长由原来的 30PD 降到 9PD，再后来降到 4.5PD。在质量方面，累计发现系统缺陷 100 多个，之前 2021 年性能故障是 28 个，2022 年之后至今，性能相关的故障每年都小于 5，流量上涨导致的故障数已经归零了。

　　第一阶段对机房演练 49 次，设置 4000 多个机器，500 多个应用，发现了 10 多个问题，这个阶段当时是 KVM 机器，进行大规模的机房级别的演练。第二阶段是应用级别的演练，应用级别的演练支持 31 种故障场景。第三个阶段进行强弱依赖的演练，我们的目标是弱依赖如果挂掉了，主流程要求不受影响，如果发现不合理的强依赖，要对这些强依赖进行降级和治理。第四个阶段，攻防演练。进行强弱演练之后发现故障率已经降低到 3‰。

　　该主题由刘超分享，分享的内容是关于云原生对去哪儿网在测试领域带来的变化。

　　很多情况下都会照搬到自己的组织内部来，一开始玩的可能也是相对比较好的。但是慢慢产生一些问题，比如哪些应该采用，哪些不应该采用？这时候不能就技术讨论技术，互联网公司用了一个什么技术，我就相应把它照搬过来用一个相同的技术。这时候往往需要考虑一个问题，就是我们要回头看，从云原生技术本源去考虑：互联网公司为什么用这些技术？这些技术给互联网公司带来什么东西？这些技术实施的前提是什么？我有没有这样的前提？从而导致我要不要采取类似的技术？

　　我们可以观察到不同的传统企业做云原生，因为它们的组织和应用关系，面临的问题和互联网公司是不一样的，无论从微服务的层级，还是从下面基础设施的层级可能都有很多不一样。

　　第一个比较，一个大的 K8S vs.多个 K8S。K8S 我们是用云原生的容器平台，我们到底是用一个大的？还是用多个小的来做这个事情？

　　通过 K8S ETCD 优化，K8S 规模比较大会遭遇不一致，出现内存泄露、死所有、panic、性能等问题，吞吐量有一定极限，就有限流模式，比如可以用 K8S 限流参数配置，包括调度配置，ETCD 也有自己的方式，K8S 也有 API Priority and Fairness。ETCD 的优化以及限流技术应用了以后，集群规模就能够达到相应的程度了。

　　假如没有技术实力优化 K8S 本身，就需要做多 K8S 管理，多 K8S 管理现在重点有两个方案，V1 版本已经废弃，V2 利用了 CRD 实现了整体功能。APIserver 旁边还会有个 APIserver，它有自己的逻辑，它可以自己做一定的流程处理，仍然以 K8S 类似的接口方式对客户端进行服务。

　　第二个比较，服务拆分 vs.信息流梳理与重新组合。到服务这一层，拆分和信息流梳理与整合也是不一样的东西。

　　有时候微服务仍然带来相应的问题，比如“雪崩”，就是一个服务挂了就全挂了，比如一个慢了就整个链路都慢，很难定位到性能瓶颈。所以要解决这个问题，就是刚才所说的关注点分离的问题，其实每个微服务都应该有 owner，每个服务要梳理强弱关系的依赖，自己这些超时参数、限流参数应该多长时间，都应该微服务的 owner 去做。

　　球王会app

　　但是传统企业并不是这样，人少，如果“服务拆了，人不拆”，不知道参数怎么配，上下游强弱关系越复杂越梳理不清楚，因为人也不增加，不但没有关注点分离，反而更晕了。传统行业最大的痛点在于信息流并没有很好的梳理。

　　第三个比较，Service Mesh vs.API 网关。服务之间相互关系，如果有些传统的。服务之间相互关系，如果有些传统的，推荐用 Service Mesh，比如 C++改不动，又想治理，就推荐 Service Mesh。但是 Service Mesh 本身有复杂度，对传统企业来说是相对比较大的负担。所以这时候就有两种选择，Service Mesh 或者自定义的 API 网关。

　　第四个比较，流量穿梭 vs. 整体切换。因为互联网公司往往快速迭代分成了不同的部门，它可能有特别多的环境，比如有开发、测试、生产，生产有不同的单元，这时候微服务调用时，微服务特别多的时候就可能在不同的单元里穿过来、穿过去，比如在本单元或者本机房找不到这个服务的话可能需要另外一个单元去调，调完以后在下一个环节又会回来。

　　传统企业采取的模式往往是整体切换，就不需要这么细去做流量穿梭，而所有切换都在网关上去做，出现问题跨单元调用时，配置全部下发到网关，网关上的信息是一致的，服务就不要依赖这个东西了。一个单元出现错误以后，把整个都会出现错误，这时候就不用实现太多分布式事务球王会app，这个数据库做了什么样的事情，那个数据库做了什么事情。这样虽然使得业务吞吐量受到相应影响，失败的概率多了很多。但是对于切换，尤其人比较少的时候相对比较可控，看到几个大单元，并且调用所有的配置都在网关这层可以集中去做相应的控制，这是传统企业的模式。

　　在专家们深入浅出地围绕围绕云计算平台和应用的开发过程中的核心难点与解决方案。在云平台建设方面，他们重点探讨了不同架构形式的资源调度与管理机制、跨机房和跨网络的高可用保障手段，以及针对安全、合规等方面的治理与审计要求等。这为打造扛得住大流量的云计算基础设施提供宝贵参考，也为行业内的技术革新和数字化升级带来积极的推动作用。相信通过此次交流沉淀，必将催生出更多云计算平台和应用建设的突破口与新思路。

　　12月16日，NPCon 2023 容器与微服务实践峰会将在上海举办。活动将进一步深入解析容器与微服务的新技术、新应用、新实践，紧贴数字时代脉搏，共同探索未来技术发展之路。欢迎开发者关注参加↓↓↓