大涛学长
- 浏览: 122119 次
- 性别:
- 来自: 北京
-
最新评论
引言
==
不知道大家有没有过这样的经历：当我们拥有了一套 Kubernetes 集群，然后开始部署应用的时候，我们应该给容器分配多少资源呢？
这很难说。由于 Kubernetes 自己的机制，我们可以理解容器的资源实质上是一个静态的配置。
* 如果我发现资源不足，为了分配给容器更多资源，我们需要重建 Pod；
* 如果分配冗余的资源，那么我们的 worker node 节点似乎又部署不了多少容器。
试问，我们能做到容器资源的按需分配吗？接下来，我们将在本次分享中和大家一起进行探讨这个问题的答案。
生产环境中的真实挑战
==========
首先请允许我们根据我们的实际情况抛出我们实际生产环境的挑战。或许大家还记得 2018 年的天猫双 11，这一天的总成交额达到了 2135 亿。由此一斑可窥全豹，能够支撑如此庞大规模的交易量背后的系统，其应用种类和数量应该是怎样的一种规模。
在这种规模下，我们常常听到的容器调度，如：容器编排，负载均衡，集群扩缩容，集群升级，应用发布，应用灰度等等这些词，在被“超大规模集群”这个词修饰后，都不再是件容易处理的事情。规模本身也就是我们最大的挑战。如何运营和管理好这么一个庞大的系统，并遵循业界 dev-ops 宣传的那样效果，犹如让大象去跳舞。但是马老师曾说过，大象就该干大象该干的事情，为什么要去跳舞呢。
Kubernetes 的帮助
==============
大象是否可以跳舞，带着这个问题，我们需要从淘宝、天猫等 APP 背后系统说起。
这套互联网系统应用部署大致可分为三个阶段，传统部署，虚拟机部署和容器部署。相比于传统部署，虚拟机部署有了更好的隔离性和安全性，但是在性能上不可避免的产生了大量损耗。而容器部署又在虚拟机部署实现隔离和安全的背景下，提出了更轻量化的解决方案。我们的系统也是沿着这么一条主航道上运行的。假设底层系统好比一艘巨轮，面对巨量的集装箱---容器，我们需要一个优秀的船长，对它们进行调度编排，让系统这艘大船可以避开层层险阻，操作难度降低，且具备更多灵活性，最终达成航行的目的。
理想与现实
=====
在开始之初，想到容器化和 Kubernetes 的各种美好场景，我们理想中的容器编排效果应该是这样的：
* 从容：我们的工程师更加从容的面对复杂的挑战，不再眉头紧锁而是更多笑容和自信；
* 优雅：每一次线上变更操作都可以像品着红酒一样气定神闲，优雅地按下执行的回车键；
* 有序：从开发到测试，再到灰度发布，一气呵成，行云流水；
* 稳定：系统健壮性良好，任尔东西南北风，我们系统岿然不动。全年系统可用性 N 多个 9；
* 高效：节约出更多人力，实现“快乐工作，认真生活”。
然而理想很丰满，现实很骨感。迎接我们的却是杂乱和形态各异的窘迫。
杂乱，是因为作为一个异军突起的新型技术栈，很多配套工具和工作流的建设处于初级阶段。Demo 版本中运行良好的工具，在真实场景下大规模铺开，各种隐藏的问题就会暴露无遗，层出不穷。从开发到运维，所有的工作人员都在各种被动地疲于奔命。另外，“大规模铺开”还意味着，要直接面对形态各异的生产环境：异构配置的机器、复杂的需求，甚至是适配用户的既往的使用习惯等等。
除了让人心力交瘁的混乱，系统还面临着应用容器的各种崩溃问题：内存不足导致的 OOM，CPU quota 分配太少，导致进程被 throttle，还有带宽不足，响应时延大幅上升...甚至是交易量在面对访问高峰时候由于系统不给力导致的断崖式下跌等等。这些都使我们在大规模商用 Kubernetes 场景中积累非常多的经验。
直面问题
====
稳定性
---
问题总要进行面对的。正如某位高人说过：如果感觉哪里不太对，那么肯定有些地方出问题了。于是我们就要剖析，问题究竟出在哪里。针对于内存的 OOM，CPU 资源被 throttle，我们可以推断我们给与容器分配的初始资源不足。
资源不足就势必造成整个应用服务稳定性下降。例如上图的场景：虽然是同一种应用的副本，或许是由于负载均衡不够强大，或者是由于应用自身的原因，甚至是由于机器本身是异构的，相同数值的资源，可能对于同一种应用的不同副本并具有相等的价值和意义。在数值上他们看似分配了相同的资源，然而在实际负载工作时，极有可能出现的现象是肥瘦不均的。
而在资源 overcommit 的场景下，应用在整个节点资源不足，或是在所在的 CPU share pool 资源不足时，也会出现严重的资源竞争关系。资源竞争是对应用稳定性最大的威胁之一。所以我们要尽力在生产环境中清除所有的威胁。
我们都知道稳定性是件很重要的事情，尤其对于掌控上百万容器生杀大权的一线研发人员。或许不经心的一个操作就有可能造成影响面巨大的生产事故。
因此，我们也按照一般流程做了系统预防和兜底工作。
* 在预防维度，我们可以进行全链路的压力测试，并且提前通过科学的手段预判应用需要的副本数和资源量。如果没法准确预算资源，那就只采用冗余分配资源的方式了。
* 在兜底维度，我们可以在大规模访问流量抵达后，对不紧要的业务做服务降级并同时对主要应用进行临时扩容。
但是对于陡然增加几分钟的突增流量，这么多组合拳的花费不菲，似乎有些不划算。或许我们可以提出一些解决方案，达到我们的预期。
资源利用率
-----
回顾一下我们的应用部署情况：节点上的容器一般分属多种应用，这些应用本身不一定，也一般不会同时处于访问的高峰。对于混合部署应用的宿主机，如果能都错峰分配上面运行容器的资源或许更科学。
应用的资源需求可能就像月亮一样有阴晴圆缺，有周期变化。例如在线业务，尤其是交易业务，它们在资源使用上呈现一定的周期性，例如：在凌晨、上午时，它的使用量并不是很高，而在午间、下午时会比较高。
打个比方：对于 A 应用的重要时刻，对于 B 应用可能不那么重要，适当打压 B 应用，腾挪出资源给 A 应用，这是个不错的选择。这听起来有点像是分时复用的感觉。但是如果我们按照流量峰值时的需求配置资源就会产生大量的浪费。
除了对于实时性要求很高的在线应用外，我们还有离线应用和实时计算应用等：离线计算对于 CPU 、Memory 或网络资源的使用以及时间不那么敏感，所以在任何时间段它都可以运行；实时计算，可能对于时间敏感性就会很高。
早期，我们业务是在不同的节点按照应用的类型独立进行部署。从上面这张图来看，如果它们进行分时复用资源，针对实时性这个需求层面，我们会发现它实际的最大使用量不是 2+2+1=5，而是某一时刻重要紧急应用需求量的最大值，也就是 3 。如果我们能够数据监测到每个应用的真实使用量，给它分配合理值，那么就能产生资源利用率提升的实际效果。
对于电商应用，对于采用了重量级 Java 框架和相关技术栈的 Web 应用，短时间内 HPA 或者 VPA 都不是件容易的事情。
先说 HPA，我们或许可以秒级拉起了 Pod，创建新的容器，然而拉起的容器是否真的可用呢。从创建到可用，可能需要比较久的时间，对于大促和抢购秒杀-这种访问量“洪峰”可能仅维持几分钟或者十几分钟的实际场景，如果我们等到 HPA 的副本全部可用，可能市场活动早已经结束了。
至于社区目前的 VPA 场景，删掉旧 Pod，创建新 Pod，这样的逻辑更难接受。所以综合考虑，我们需要一个更实际的解决方案弥补 HPA 和 VPA 的在这一单机资源调度的空缺。
解决方案
====
交付标准
----
我们首先要对解决方案设定一个可以交付的标准那就是—— “既要稳定性，也要利用率，还要自动化实施，当然如果能够智能化那就更好”，然后再交付标准进行细化：
* 安全稳定：工具本身高可用。所用的算法和实施手段必须做到可控；
* 业务容器按需分配资源：可以及时根据业务实时资源消耗对不太久远的将来进行资源消耗预测，让用户明白业务接下来对于资源的真实需求；
* 工具本身资源开销小：工具本身资源的消耗要尽可能小，不要成为运维的负担；
* 操作方便，扩展性强：能做到无需接受培训即可玩转这个工具，当然工具还要具有良好扩展性，供用户 DIY；
* 快速发现 & 及时响应：实时性，也就是最重要的特质，这也是和HPA或者VPA在解决资源调度问题方式不同的地方。
设计与实现
-----
上图是我们最初的工具流程设计：当一个应用面临很高的业务访问需求时，体现在 CPU、Memory 或其他资源类型需求量变大，我们根据 Data Collector 采集的实时基础数据，利用 Data Aggregator 生成某个容器或整个应用的画像，再将画像反馈给 Policy engine。 Policy engine 会瞬时快速修改容器 Cgroup 文件目录下的的参数。
我们最早的架构和我们的想法一样朴实，在 kubelet 进行了侵入式的修改。虽然我们只是加了几个接口，但是这种方式确实不够优雅。每次 kubenrnetes 升级，对于 Policy engine 相关组件升级也有一定的挑战。
为了做到快速迭代并和 Kubelet 解耦，我们对于实现方式进行了新的演进。那就是将关键应用容器化。这样可以达到以下功效：
* 不侵入修改 K8s 核心组件；
* 方便迭代&发布；
* 借助于 Kubernetes 相关的 QoS Class 机制，容器的资源配置，资源开销可控。
当然在后续演进中，我们也在尝试和 HPA，VPA 进行打通，毕竟这些和 Policy engine 存在着互补的关系。因此我们架构进一步演进成如下情形。当 Policy engine 在处理一些更多复杂场景搞到无力时，上报事件让中心端做出更全局的决策。水平扩容或是垂直增加资源。
下面我们具体讨论一下 Policy engine 的设计。Policy engine 是单机节点上进行智能调度并执行 Pod 资源调整的核心组件。它主要包括 api server，指挥中心 command center 和执行层 executor。
* 其中 api server 用于服务外界对于 policy engine 运行状态的查询和设置的请求；
* command center 根据实时的容器画像和物理机本身的负载以及资源使用情况，作出 Pod 资源调整的决策；
* Executor 再根据 command center 的决策，对容器的资源限制进行调整。同时，executor 也把每次调整的 revision info 持久化，以便发生故障时可以回滚。
指挥中心定期从 data aggregator 获取容器的实时画像，包括聚合的统计数据和预测数据，首先判断节点状态，例如节点磁盘异常，或者网络不通，表示该节点已经发生异常，需要保护现场，不再对Pod进行资源调整，以免造成系统震荡，影响运维和调试。如果节点状态正常，指挥中心会策略规则，对容器数据进行再次过滤。比如容器 CPU 率飙高，或者容器的响应时间超过安全阈值。如果条件满足，则对满足条件的容器集合给出资源调整建议，传递给executor。
在架构设计上，我们遵循了以下原则：
* 插件化：所有的规则和策略被设计为可以通过配置文件来修改，尽量与核心控制流程的代码解耦，与 data collector 和 data aggregator 等其他组件的更新和发布解耦，提升可扩展性；
* 稳定，这包括以下几个方面：
* 控制器稳定性。指挥中心的决策以不影响单机乃至全局稳定性为前提，包括容器的性能稳定和资源分配稳定。例如，目前每个控制器仅负责一种 cgroup 资源的控制，即在同一时间窗口内，Policy engine 不同时调整多种资源，以免造成资源分配震荡，干扰调整效果；
* 触发规则稳定性。例如，某一条规则的原始触发条件为容器的性能指标超出安全阈值，但是为避免控制动作被某一突发峰值触发而导致震荡，我们把触发规则定制为：过去一段时间窗口内性能指标的低百分位超出安全阈值；如果规则满足，说明这段时间内绝大部分的性能指标值都已经超出了安全阈值，就需要触发控制动作了；
* 另外，与社区版 Vertical-Pod-Autoscaler 不同，Policy engine 不主动驱逐腾挪容器，而是直接修改容器的 cgroup 文件；
* 自愈：资源调整等动作的执行可能会产生一些异常，我们在每个控制器内都加入了自愈回滚机制，保证整个系统的稳定性；
* 不依赖应用先验知识：为所有不同的应用分别进行压测、定制策略，或者提前对可能排部在一起的应用进行压测，会导致巨大开销，可扩展性降低。我们的策略在设计上尽可能通用，尽量采用不依赖于具体平台、操作系统、应用的指标和控制策略。
在资源调整方面，Cgroup 支持我们对各个容器的 CPU、内存、网络和磁盘 IO 带宽资源进行隔离和限制，目前我们主要对容器的 CPU 资源进行调整，同时在测试中探索在时分复用的场景下动态调整 memory limit 和 swap usage 而避免 OOM 的可行性；在未来我们将支持对容器的网络和磁盘 IO 的动态调整。
调整效果
----
上图展示了我们在测试集群得到的一些实验结果。我们把高优先级的在线应用和低优先级的离线应用混合部署在测试集群里。SLO 是 250ms，我们希望在线应用的 latency 的 95 百分位值低于阈值 250ms。
在实验结果中可以看到：
* 在大约90s前，在线应用的负载很低；latency 的均值和百分位都在 250ms 以下；
* 到了 90s后，我们给在线应用加压，流量增加，负载也升高，导致在线应用 latency 的 95 百分位值超过了 SLO；
* 在大约 150s 左右，我们的小步快跑控制策略被触发，渐进式地 throttle 与在线应用发生资源竞争的离线应用；
* 到了大约 200s 左右，在线应用的性能恢复正常，latency 的 95 百分位回落到 SLO 以下。
这说明了我们的控制策略的有效性。
经验和教训
=====
下面我们总结一下在整个项目的进行过程中，我们收获的一些经验和教训，希望这些经验教训能够对遇到类似问题和场景的人有所帮助。
1. 避开硬编码，组件微服务化，不仅便于快速演进和迭代，还有利于熔断异常服务。
2. 尽可能不要调用类库中还是 alpha 或者 beta 特性的接口。 例如我们曾经直接调用 CRI 接口读取容器的一些信息，或者做一些更新操作，但是随着接口字段或者方法的修改，共建有些功能就会变得不可用，或许有时候，调用不稳定的接口还不如直接获取某个应用的打印信息可能更靠谱。
3. 基于 QoS 的资源动态调整方面：如我们之前所讲，阿里集团内部有上万个应用，应用之间的调用链相当复杂。应用 A 的容器性能发生异常，不一定都是在单机节点上的资源不足或者资源竞争导致，而很有可能是它下游的应用 B、应用 C，或者数据库、cache 的访问延迟导致的。由于单机节点上这种信息的局限性，基于单机节点信息的资源调整，只能采用“尽力而为”，也就是 best effort 的策略了。在未来，我们计划打通单机节点和中心端的资源调控链路，由中心端综合单机节点上报的性能信息和资源调整请求，统一进行资源的重新分配，或者容器的重新编排，或者触发 HPA，从而形成一个集群级别的闭环的智能资源调控链路，这将会大大提高整个集群维度的稳定性和综合资源利用率。
4. 资源v.s.性能模型：可能有人已经注意到，我们的调整策略里，并没有明显地提出为容器建立“资源v.s.性能”的模型。这种模型在学术论文里非常常见，一般是对被测的几种应用进行了离线压测或者在线压测，改变应用的资源分配，测量应用的性能指标，得到性能随资源变化的曲线，最终用在实时的资源调控算法中。在应用数量比较少，调用链比较简单，集群里的物理机硬件配置也比较少的情况下，这种基于压测的方法可以穷举到所有可能的情况，找到最优或者次优的资源调整方案，从而得到比较好的性能。但是在阿里集团的场景下，我们有上万个应用，很多重点应用的版本发布也非常频繁，往往新版本发布后，旧的压测数据，或者说资源性能模型，就不适用了。另外，我们的集群很多是异构集群，在某一种物理机上测试得到的性能数据，在另一台不同型号的物理机上就不会复现。这些都对我们直接应用学术论文里的资源调控算法带来了障碍。所以，针对阿里集团内部的场景，我们采用了这样的策略：不对应用进行离线压测，获取显示的资源性能模型。而是建立实时的动态容器画像，用过去一段时间窗口内容器资源使用情况的统计数据作为对未来一小段时间内的预测，并且动态更新；最后基于这个动态的容器画像，执行小步快跑的资源调整策略，边走边看，尽力而为。
总结与展望
=====
总结起来，我们的工作主要实现了以下几方面的收益：
* 通过分时复用以及将不同优先级的容器（也就是在线和离线任务）混合部署，并且通过对容器资源限制的动态调整，保证了在线应用在不同负载情况下都能得到足够的资源，从而提高集群的综合资源利用率。
* 通过对单机节点上的容器资源的智能动态调整，降低了应用之间的性能干扰，保障高优先级应用的性能稳定性
* 各种资源调整策略通过 Daemonset 部署，可以自动地、智能地在节点上运行，减少人工干预，降低了运维的人力成本。
展望未来，我们希望在以下几个方面加强和扩展我们的工作：
* 闭环控制链路：前面已经提到，单机节点上由于缺乏全局信息，对于资源的调整有其局限性，只能尽力而为。未来，我们希望能够打通与 HPA 和 VPA 的通路，使单机节点和中心端联动进行资源调整，最大化弹性伸缩的收益。
* 容器重新编排：即使是同一个应用，不同容器的负载和所处的物理环境也是动态变化的，单机上调整 pod 的资源，不一定能够满足动态的需求。我们希望单机上实时容器画像，能够为中心端提供更多的有效信息，帮助中心端的调度器作出更加智能的容器重编排决策。
* 策略智能化：我们现在的资源调整策略仍然比较粗粒度，可以调整的资源也比较有限；后续我们希望让资源调整策略更加智能化，并且考虑到更多的资源，比如对磁盘和网络IO带宽的调整，提高资源调整的有效性。
* 容器画像精细化：目前的容器画像也比较粗糙，仅仅依靠统计数据和线性预测；刻画容器性能的指标种类也比较局限。我们希望找到更加精确的、通用的、反映容器性能的指标，以便更加精细地刻画容器当前的状态和对不同资源的需求程度。
* 查找干扰源：我们希望能找到在单机节点上找到行之有效的方案，来精准定位应用性能受损时的干扰源；这对策略智能化也有很大意义。
Q & A
=====
**Q1：**直接修改 cgroup 容器一定会获得资源吗？
**A1：**容器技术隔离的技术基础就是 cgroup 层面。在宿主机腾出足够资源的情况下，给 cgroup 设置更大的值可以获取更多的资源。同理，对于一般优先级不高的应用，设置较低的 cgroup 资源值就会达到抑制容器运行的效果。
**Q2：**底层是如何区分在线和离线优先级的？
**A2：**底层是无法自动获取谁是在线，谁是离线，或者谁的优先级高，谁的优先级低的。这个我们可以通过各种 Kubernetes 提供的扩展实现。最简单的是通过 label，Annotation 标识。当然通过扩展 QoS class 也是一种思路。社区版本的 QoS class设置太过于保守，给予用户发挥的空间不大。我们通过这些方面也进行了增强。在合适的时候或许会推向社区。自动感知是个方向，感知谁是干扰源，感知谁是某种资源型应用，这块我们还在研发中。做到真正的动态，肯定是具备自动感知的智能系统。
**Q3：**“与社区版 Vertical-Pod-Autoscaler 不同，Policy engine 不主动驱逐腾挪容器，而是直接修改容器的 cgroup 文件”，想问一下，不主动驱逐的话，如果 Node 的资源达到上线了会怎么处理？
**A3：**这是一个好问题。首先这里要先区分是哪种资源，如果是 CPU 型的，我们可以调整低优先级容器的 cgroup 下 cpu quota 的值，首先抑制低优先级的容器对于 CPU 的争抢。然后再适当上调高优先级容器的相关资源值。如果是内存型资源，这个不能直接去缩小低优先级容器的 cgroup 值，否则会造成 OOM，对于学习内存型资源的调整，我们会在其他分享中继续讨论。这个技术比较特殊。
**Q4：**只修改 cgroup，怎么保证 K8s 对单个物理机能够分配更多的容器？
**A4：**文字直播有了一定说明，容器的资源消耗并非是一成不变的，很多时候它们的资源消耗呈现潮汐现象，相同的资源条件下部署更多应用，完成更多作业就是达到资源利用的最大化的效果。资源出现超卖才是我们这个主题讨论的最大价值。
**Q5：**也就是说，低优先级的容器，request 设置的比 limit 小很多，然后你们再动态的调整 cgroup？
**A5：**在现有 QoS 场景下，你可以理解被调整的 Pod 都是 burstable 的。但是我们并不是直接调整 Pod 元数据的 limit 的值，而是调整 limit 在 cgroup 反映的值，这个值在资源竞争缓和的时候还会被调整回去的。我们并不建议单机的 cgroup 数据和 etcd 的中心数据割裂太久。如果长期偏离，我们会像 VPA 发出警报，联动 VPA 做调整。当然在容器运行的高峰期，任何重建容器的操作都是不明智的。
**Q6：**整体的理解就是你们开始就让物理机超配了一定比例的 pod，然后通过策略动态调整容器的 cgroup 值？
**A6：**如果资源完全是富足冗余的，这个动态调整也有一定意义。就是并非资源用满场景下，高优先级应用会被干扰，实际上，当主机的 CPU 达到一定比例，打个比方例如 50%，应用的时延就变大。为了完全确保高优先级应用的 SLO，牺牲低优先级的 CPU 正常运行也是有价值的。
**Q7:**Policy engine 有没有考虑开源？
**A7：**有计划进行开源，Policy engine 更多的是和自身的应用属性相关，电商应用或者大数据处理应用的策略都是不相同的，我们开源会首先开源框架和附带一些简单的策略，更多的策略可以用户自定义。
**Q8：**我之前遇到的大部分应用都无法正确感知 cgroup 的配置，因此很多情况都需要在启动参数里面根据 cpu 或者 mem 设置参数，那么也就是说即使改变了 cgroup 对于他们来说都无效，那么使用场景也就有限了
**A8：**限制容器的资源使用这个还是有价值的。限制低优先级应用本身也可以提升高优先级应用的 SLO，虽然效果没有那么明显。稳定性的考量同样也很重要。
**Q9:**Policy engine 目前在阿里的使用如何？在生产上有多上的规模使用这种方式进行动态调整？是否和社区的 HPA VPA 配合使用？
**A9: **Policy engine 在阿里某些集群已经使用。至于规模暂时无法透漏。涉及到很多组件之间的联动，社区的 HPA 和 VPA 目前都不太能满足我们的需求。因此阿里的 HPA 和 VPA 都是我们自行开发的，但是和社区的原理是一致的。阿里 HPA 的开源可以关注 Openkruise 社区。VPA 开源计划我这里还没有确切消息。
**Q10：**当单机节点资源不足以提供容器扩容时，目前是否可以进行 HPA 或 VPA 扩容呢？
**A10：**单机节点不足的时候，应用可以通过 HPA 进行增加副本应对。但是 VPA 如果选择原节点进行更新的话，是失败的。只能调度到其他资源丰富的节点。在流量陡升的场景下，重建容器未必能满足需求，很可能导致雪崩，即重建过程中，整个应用其他未升级的副本接受更多流量，OOM 掉，新启动的容器再瞬间被 OOM，所以重启容器需要慎重。快速扩容（HPA）或者快速提升高优先级资源，抑制低优先级容器资源的方式效果更明显。
本文作者：张晓宇（衷源） 阿里云容器平台技术专家
[原文链接](https://link.zhihu.com/?target=https%3A//yq.aliyun.com/articles/719845%3Futm_content%3Dg_1000079633)
本文为云栖社区原创内容，未经允许不得转载。
==
不知道大家有没有过这样的经历：当我们拥有了一套 Kubernetes 集群，然后开始部署应用的时候，我们应该给容器分配多少资源呢？
这很难说。由于 Kubernetes 自己的机制，我们可以理解容器的资源实质上是一个静态的配置。
* 如果我发现资源不足，为了分配给容器更多资源，我们需要重建 Pod；
* 如果分配冗余的资源，那么我们的 worker node 节点似乎又部署不了多少容器。
试问，我们能做到容器资源的按需分配吗？接下来，我们将在本次分享中和大家一起进行探讨这个问题的答案。
生产环境中的真实挑战
==========
首先请允许我们根据我们的实际情况抛出我们实际生产环境的挑战。或许大家还记得 2018 年的天猫双 11，这一天的总成交额达到了 2135 亿。由此一斑可窥全豹，能够支撑如此庞大规模的交易量背后的系统，其应用种类和数量应该是怎样的一种规模。
在这种规模下，我们常常听到的容器调度，如：容器编排，负载均衡，集群扩缩容，集群升级，应用发布，应用灰度等等这些词，在被“超大规模集群”这个词修饰后，都不再是件容易处理的事情。规模本身也就是我们最大的挑战。如何运营和管理好这么一个庞大的系统，并遵循业界 dev-ops 宣传的那样效果，犹如让大象去跳舞。但是马老师曾说过，大象就该干大象该干的事情，为什么要去跳舞呢。
Kubernetes 的帮助
==============
大象是否可以跳舞，带着这个问题，我们需要从淘宝、天猫等 APP 背后系统说起。
这套互联网系统应用部署大致可分为三个阶段，传统部署，虚拟机部署和容器部署。相比于传统部署，虚拟机部署有了更好的隔离性和安全性，但是在性能上不可避免的产生了大量损耗。而容器部署又在虚拟机部署实现隔离和安全的背景下，提出了更轻量化的解决方案。我们的系统也是沿着这么一条主航道上运行的。假设底层系统好比一艘巨轮，面对巨量的集装箱---容器，我们需要一个优秀的船长，对它们进行调度编排，让系统这艘大船可以避开层层险阻，操作难度降低，且具备更多灵活性，最终达成航行的目的。
理想与现实
=====
在开始之初，想到容器化和 Kubernetes 的各种美好场景，我们理想中的容器编排效果应该是这样的：
* 从容：我们的工程师更加从容的面对复杂的挑战，不再眉头紧锁而是更多笑容和自信；
* 优雅：每一次线上变更操作都可以像品着红酒一样气定神闲，优雅地按下执行的回车键；
* 有序：从开发到测试，再到灰度发布，一气呵成，行云流水；
* 稳定：系统健壮性良好，任尔东西南北风，我们系统岿然不动。全年系统可用性 N 多个 9；
* 高效：节约出更多人力，实现“快乐工作，认真生活”。
然而理想很丰满，现实很骨感。迎接我们的却是杂乱和形态各异的窘迫。
杂乱，是因为作为一个异军突起的新型技术栈，很多配套工具和工作流的建设处于初级阶段。Demo 版本中运行良好的工具，在真实场景下大规模铺开，各种隐藏的问题就会暴露无遗，层出不穷。从开发到运维，所有的工作人员都在各种被动地疲于奔命。另外，“大规模铺开”还意味着，要直接面对形态各异的生产环境：异构配置的机器、复杂的需求，甚至是适配用户的既往的使用习惯等等。
除了让人心力交瘁的混乱，系统还面临着应用容器的各种崩溃问题：内存不足导致的 OOM，CPU quota 分配太少，导致进程被 throttle，还有带宽不足，响应时延大幅上升...甚至是交易量在面对访问高峰时候由于系统不给力导致的断崖式下跌等等。这些都使我们在大规模商用 Kubernetes 场景中积累非常多的经验。
直面问题
====
稳定性
---
问题总要进行面对的。正如某位高人说过：如果感觉哪里不太对，那么肯定有些地方出问题了。于是我们就要剖析，问题究竟出在哪里。针对于内存的 OOM，CPU 资源被 throttle，我们可以推断我们给与容器分配的初始资源不足。
资源不足就势必造成整个应用服务稳定性下降。例如上图的场景：虽然是同一种应用的副本，或许是由于负载均衡不够强大，或者是由于应用自身的原因，甚至是由于机器本身是异构的，相同数值的资源，可能对于同一种应用的不同副本并具有相等的价值和意义。在数值上他们看似分配了相同的资源，然而在实际负载工作时，极有可能出现的现象是肥瘦不均的。
而在资源 overcommit 的场景下，应用在整个节点资源不足，或是在所在的 CPU share pool 资源不足时，也会出现严重的资源竞争关系。资源竞争是对应用稳定性最大的威胁之一。所以我们要尽力在生产环境中清除所有的威胁。
我们都知道稳定性是件很重要的事情，尤其对于掌控上百万容器生杀大权的一线研发人员。或许不经心的一个操作就有可能造成影响面巨大的生产事故。
因此，我们也按照一般流程做了系统预防和兜底工作。
* 在预防维度，我们可以进行全链路的压力测试，并且提前通过科学的手段预判应用需要的副本数和资源量。如果没法准确预算资源，那就只采用冗余分配资源的方式了。
* 在兜底维度，我们可以在大规模访问流量抵达后，对不紧要的业务做服务降级并同时对主要应用进行临时扩容。
但是对于陡然增加几分钟的突增流量，这么多组合拳的花费不菲，似乎有些不划算。或许我们可以提出一些解决方案，达到我们的预期。
资源利用率
-----
回顾一下我们的应用部署情况：节点上的容器一般分属多种应用，这些应用本身不一定，也一般不会同时处于访问的高峰。对于混合部署应用的宿主机，如果能都错峰分配上面运行容器的资源或许更科学。
应用的资源需求可能就像月亮一样有阴晴圆缺，有周期变化。例如在线业务，尤其是交易业务，它们在资源使用上呈现一定的周期性，例如：在凌晨、上午时，它的使用量并不是很高，而在午间、下午时会比较高。
打个比方：对于 A 应用的重要时刻，对于 B 应用可能不那么重要，适当打压 B 应用，腾挪出资源给 A 应用，这是个不错的选择。这听起来有点像是分时复用的感觉。但是如果我们按照流量峰值时的需求配置资源就会产生大量的浪费。
除了对于实时性要求很高的在线应用外，我们还有离线应用和实时计算应用等：离线计算对于 CPU 、Memory 或网络资源的使用以及时间不那么敏感，所以在任何时间段它都可以运行；实时计算，可能对于时间敏感性就会很高。
早期，我们业务是在不同的节点按照应用的类型独立进行部署。从上面这张图来看，如果它们进行分时复用资源，针对实时性这个需求层面，我们会发现它实际的最大使用量不是 2+2+1=5，而是某一时刻重要紧急应用需求量的最大值，也就是 3 。如果我们能够数据监测到每个应用的真实使用量，给它分配合理值，那么就能产生资源利用率提升的实际效果。
对于电商应用，对于采用了重量级 Java 框架和相关技术栈的 Web 应用，短时间内 HPA 或者 VPA 都不是件容易的事情。
先说 HPA，我们或许可以秒级拉起了 Pod，创建新的容器，然而拉起的容器是否真的可用呢。从创建到可用，可能需要比较久的时间，对于大促和抢购秒杀-这种访问量“洪峰”可能仅维持几分钟或者十几分钟的实际场景，如果我们等到 HPA 的副本全部可用，可能市场活动早已经结束了。
至于社区目前的 VPA 场景，删掉旧 Pod，创建新 Pod，这样的逻辑更难接受。所以综合考虑，我们需要一个更实际的解决方案弥补 HPA 和 VPA 的在这一单机资源调度的空缺。
解决方案
====
交付标准
----
我们首先要对解决方案设定一个可以交付的标准那就是—— “既要稳定性，也要利用率，还要自动化实施，当然如果能够智能化那就更好”，然后再交付标准进行细化：
* 安全稳定：工具本身高可用。所用的算法和实施手段必须做到可控；
* 业务容器按需分配资源：可以及时根据业务实时资源消耗对不太久远的将来进行资源消耗预测，让用户明白业务接下来对于资源的真实需求；
* 工具本身资源开销小：工具本身资源的消耗要尽可能小，不要成为运维的负担；
* 操作方便，扩展性强：能做到无需接受培训即可玩转这个工具，当然工具还要具有良好扩展性，供用户 DIY；
* 快速发现 & 及时响应：实时性，也就是最重要的特质，这也是和HPA或者VPA在解决资源调度问题方式不同的地方。
设计与实现
-----
上图是我们最初的工具流程设计：当一个应用面临很高的业务访问需求时，体现在 CPU、Memory 或其他资源类型需求量变大，我们根据 Data Collector 采集的实时基础数据，利用 Data Aggregator 生成某个容器或整个应用的画像，再将画像反馈给 Policy engine。 Policy engine 会瞬时快速修改容器 Cgroup 文件目录下的的参数。
我们最早的架构和我们的想法一样朴实，在 kubelet 进行了侵入式的修改。虽然我们只是加了几个接口，但是这种方式确实不够优雅。每次 kubenrnetes 升级，对于 Policy engine 相关组件升级也有一定的挑战。
为了做到快速迭代并和 Kubelet 解耦，我们对于实现方式进行了新的演进。那就是将关键应用容器化。这样可以达到以下功效：
* 不侵入修改 K8s 核心组件；
* 方便迭代&发布；
* 借助于 Kubernetes 相关的 QoS Class 机制，容器的资源配置，资源开销可控。
当然在后续演进中，我们也在尝试和 HPA，VPA 进行打通，毕竟这些和 Policy engine 存在着互补的关系。因此我们架构进一步演进成如下情形。当 Policy engine 在处理一些更多复杂场景搞到无力时，上报事件让中心端做出更全局的决策。水平扩容或是垂直增加资源。
下面我们具体讨论一下 Policy engine 的设计。Policy engine 是单机节点上进行智能调度并执行 Pod 资源调整的核心组件。它主要包括 api server，指挥中心 command center 和执行层 executor。
* 其中 api server 用于服务外界对于 policy engine 运行状态的查询和设置的请求；
* command center 根据实时的容器画像和物理机本身的负载以及资源使用情况，作出 Pod 资源调整的决策；
* Executor 再根据 command center 的决策，对容器的资源限制进行调整。同时，executor 也把每次调整的 revision info 持久化，以便发生故障时可以回滚。
指挥中心定期从 data aggregator 获取容器的实时画像，包括聚合的统计数据和预测数据，首先判断节点状态，例如节点磁盘异常，或者网络不通，表示该节点已经发生异常，需要保护现场，不再对Pod进行资源调整，以免造成系统震荡，影响运维和调试。如果节点状态正常，指挥中心会策略规则，对容器数据进行再次过滤。比如容器 CPU 率飙高，或者容器的响应时间超过安全阈值。如果条件满足，则对满足条件的容器集合给出资源调整建议，传递给executor。
在架构设计上，我们遵循了以下原则：
* 插件化：所有的规则和策略被设计为可以通过配置文件来修改，尽量与核心控制流程的代码解耦，与 data collector 和 data aggregator 等其他组件的更新和发布解耦，提升可扩展性；
* 稳定，这包括以下几个方面：
* 控制器稳定性。指挥中心的决策以不影响单机乃至全局稳定性为前提，包括容器的性能稳定和资源分配稳定。例如，目前每个控制器仅负责一种 cgroup 资源的控制，即在同一时间窗口内，Policy engine 不同时调整多种资源，以免造成资源分配震荡，干扰调整效果；
* 触发规则稳定性。例如，某一条规则的原始触发条件为容器的性能指标超出安全阈值，但是为避免控制动作被某一突发峰值触发而导致震荡，我们把触发规则定制为：过去一段时间窗口内性能指标的低百分位超出安全阈值；如果规则满足，说明这段时间内绝大部分的性能指标值都已经超出了安全阈值，就需要触发控制动作了；
* 另外，与社区版 Vertical-Pod-Autoscaler 不同，Policy engine 不主动驱逐腾挪容器，而是直接修改容器的 cgroup 文件；
* 自愈：资源调整等动作的执行可能会产生一些异常，我们在每个控制器内都加入了自愈回滚机制，保证整个系统的稳定性；
* 不依赖应用先验知识：为所有不同的应用分别进行压测、定制策略，或者提前对可能排部在一起的应用进行压测，会导致巨大开销，可扩展性降低。我们的策略在设计上尽可能通用，尽量采用不依赖于具体平台、操作系统、应用的指标和控制策略。
在资源调整方面，Cgroup 支持我们对各个容器的 CPU、内存、网络和磁盘 IO 带宽资源进行隔离和限制，目前我们主要对容器的 CPU 资源进行调整，同时在测试中探索在时分复用的场景下动态调整 memory limit 和 swap usage 而避免 OOM 的可行性；在未来我们将支持对容器的网络和磁盘 IO 的动态调整。
调整效果
----
上图展示了我们在测试集群得到的一些实验结果。我们把高优先级的在线应用和低优先级的离线应用混合部署在测试集群里。SLO 是 250ms，我们希望在线应用的 latency 的 95 百分位值低于阈值 250ms。
在实验结果中可以看到：
* 在大约90s前，在线应用的负载很低；latency 的均值和百分位都在 250ms 以下；
* 到了 90s后，我们给在线应用加压，流量增加，负载也升高，导致在线应用 latency 的 95 百分位值超过了 SLO；
* 在大约 150s 左右，我们的小步快跑控制策略被触发，渐进式地 throttle 与在线应用发生资源竞争的离线应用；
* 到了大约 200s 左右，在线应用的性能恢复正常，latency 的 95 百分位回落到 SLO 以下。
这说明了我们的控制策略的有效性。
经验和教训
=====
下面我们总结一下在整个项目的进行过程中，我们收获的一些经验和教训，希望这些经验教训能够对遇到类似问题和场景的人有所帮助。
1. 避开硬编码，组件微服务化，不仅便于快速演进和迭代，还有利于熔断异常服务。
2. 尽可能不要调用类库中还是 alpha 或者 beta 特性的接口。 例如我们曾经直接调用 CRI 接口读取容器的一些信息，或者做一些更新操作，但是随着接口字段或者方法的修改，共建有些功能就会变得不可用，或许有时候，调用不稳定的接口还不如直接获取某个应用的打印信息可能更靠谱。
3. 基于 QoS 的资源动态调整方面：如我们之前所讲，阿里集团内部有上万个应用，应用之间的调用链相当复杂。应用 A 的容器性能发生异常，不一定都是在单机节点上的资源不足或者资源竞争导致，而很有可能是它下游的应用 B、应用 C，或者数据库、cache 的访问延迟导致的。由于单机节点上这种信息的局限性，基于单机节点信息的资源调整，只能采用“尽力而为”，也就是 best effort 的策略了。在未来，我们计划打通单机节点和中心端的资源调控链路，由中心端综合单机节点上报的性能信息和资源调整请求，统一进行资源的重新分配，或者容器的重新编排，或者触发 HPA，从而形成一个集群级别的闭环的智能资源调控链路，这将会大大提高整个集群维度的稳定性和综合资源利用率。
4. 资源v.s.性能模型：可能有人已经注意到，我们的调整策略里，并没有明显地提出为容器建立“资源v.s.性能”的模型。这种模型在学术论文里非常常见，一般是对被测的几种应用进行了离线压测或者在线压测，改变应用的资源分配，测量应用的性能指标，得到性能随资源变化的曲线，最终用在实时的资源调控算法中。在应用数量比较少，调用链比较简单，集群里的物理机硬件配置也比较少的情况下，这种基于压测的方法可以穷举到所有可能的情况，找到最优或者次优的资源调整方案，从而得到比较好的性能。但是在阿里集团的场景下，我们有上万个应用，很多重点应用的版本发布也非常频繁，往往新版本发布后，旧的压测数据，或者说资源性能模型，就不适用了。另外，我们的集群很多是异构集群，在某一种物理机上测试得到的性能数据，在另一台不同型号的物理机上就不会复现。这些都对我们直接应用学术论文里的资源调控算法带来了障碍。所以，针对阿里集团内部的场景，我们采用了这样的策略：不对应用进行离线压测，获取显示的资源性能模型。而是建立实时的动态容器画像，用过去一段时间窗口内容器资源使用情况的统计数据作为对未来一小段时间内的预测，并且动态更新；最后基于这个动态的容器画像，执行小步快跑的资源调整策略，边走边看，尽力而为。
总结与展望
=====
总结起来，我们的工作主要实现了以下几方面的收益：
* 通过分时复用以及将不同优先级的容器（也就是在线和离线任务）混合部署，并且通过对容器资源限制的动态调整，保证了在线应用在不同负载情况下都能得到足够的资源，从而提高集群的综合资源利用率。
* 通过对单机节点上的容器资源的智能动态调整，降低了应用之间的性能干扰，保障高优先级应用的性能稳定性
* 各种资源调整策略通过 Daemonset 部署，可以自动地、智能地在节点上运行，减少人工干预，降低了运维的人力成本。
展望未来，我们希望在以下几个方面加强和扩展我们的工作：
* 闭环控制链路：前面已经提到，单机节点上由于缺乏全局信息，对于资源的调整有其局限性，只能尽力而为。未来，我们希望能够打通与 HPA 和 VPA 的通路，使单机节点和中心端联动进行资源调整，最大化弹性伸缩的收益。
* 容器重新编排：即使是同一个应用，不同容器的负载和所处的物理环境也是动态变化的，单机上调整 pod 的资源，不一定能够满足动态的需求。我们希望单机上实时容器画像，能够为中心端提供更多的有效信息，帮助中心端的调度器作出更加智能的容器重编排决策。
* 策略智能化：我们现在的资源调整策略仍然比较粗粒度，可以调整的资源也比较有限；后续我们希望让资源调整策略更加智能化，并且考虑到更多的资源，比如对磁盘和网络IO带宽的调整，提高资源调整的有效性。
* 容器画像精细化：目前的容器画像也比较粗糙，仅仅依靠统计数据和线性预测；刻画容器性能的指标种类也比较局限。我们希望找到更加精确的、通用的、反映容器性能的指标，以便更加精细地刻画容器当前的状态和对不同资源的需求程度。
* 查找干扰源：我们希望能找到在单机节点上找到行之有效的方案，来精准定位应用性能受损时的干扰源；这对策略智能化也有很大意义。
Q & A
=====
**Q1：**直接修改 cgroup 容器一定会获得资源吗？
**A1：**容器技术隔离的技术基础就是 cgroup 层面。在宿主机腾出足够资源的情况下，给 cgroup 设置更大的值可以获取更多的资源。同理，对于一般优先级不高的应用，设置较低的 cgroup 资源值就会达到抑制容器运行的效果。
**Q2：**底层是如何区分在线和离线优先级的？
**A2：**底层是无法自动获取谁是在线，谁是离线，或者谁的优先级高，谁的优先级低的。这个我们可以通过各种 Kubernetes 提供的扩展实现。最简单的是通过 label，Annotation 标识。当然通过扩展 QoS class 也是一种思路。社区版本的 QoS class设置太过于保守，给予用户发挥的空间不大。我们通过这些方面也进行了增强。在合适的时候或许会推向社区。自动感知是个方向，感知谁是干扰源，感知谁是某种资源型应用，这块我们还在研发中。做到真正的动态，肯定是具备自动感知的智能系统。
**Q3：**“与社区版 Vertical-Pod-Autoscaler 不同，Policy engine 不主动驱逐腾挪容器，而是直接修改容器的 cgroup 文件”，想问一下，不主动驱逐的话，如果 Node 的资源达到上线了会怎么处理？
**A3：**这是一个好问题。首先这里要先区分是哪种资源，如果是 CPU 型的，我们可以调整低优先级容器的 cgroup 下 cpu quota 的值，首先抑制低优先级的容器对于 CPU 的争抢。然后再适当上调高优先级容器的相关资源值。如果是内存型资源，这个不能直接去缩小低优先级容器的 cgroup 值，否则会造成 OOM，对于学习内存型资源的调整，我们会在其他分享中继续讨论。这个技术比较特殊。
**Q4：**只修改 cgroup，怎么保证 K8s 对单个物理机能够分配更多的容器？
**A4：**文字直播有了一定说明，容器的资源消耗并非是一成不变的，很多时候它们的资源消耗呈现潮汐现象，相同的资源条件下部署更多应用，完成更多作业就是达到资源利用的最大化的效果。资源出现超卖才是我们这个主题讨论的最大价值。
**Q5：**也就是说，低优先级的容器，request 设置的比 limit 小很多，然后你们再动态的调整 cgroup？
**A5：**在现有 QoS 场景下，你可以理解被调整的 Pod 都是 burstable 的。但是我们并不是直接调整 Pod 元数据的 limit 的值，而是调整 limit 在 cgroup 反映的值，这个值在资源竞争缓和的时候还会被调整回去的。我们并不建议单机的 cgroup 数据和 etcd 的中心数据割裂太久。如果长期偏离，我们会像 VPA 发出警报，联动 VPA 做调整。当然在容器运行的高峰期，任何重建容器的操作都是不明智的。
**Q6：**整体的理解就是你们开始就让物理机超配了一定比例的 pod，然后通过策略动态调整容器的 cgroup 值？
**A6：**如果资源完全是富足冗余的，这个动态调整也有一定意义。就是并非资源用满场景下，高优先级应用会被干扰，实际上，当主机的 CPU 达到一定比例，打个比方例如 50%，应用的时延就变大。为了完全确保高优先级应用的 SLO，牺牲低优先级的 CPU 正常运行也是有价值的。
**Q7:**Policy engine 有没有考虑开源？
**A7：**有计划进行开源，Policy engine 更多的是和自身的应用属性相关，电商应用或者大数据处理应用的策略都是不相同的，我们开源会首先开源框架和附带一些简单的策略，更多的策略可以用户自定义。
**Q8：**我之前遇到的大部分应用都无法正确感知 cgroup 的配置，因此很多情况都需要在启动参数里面根据 cpu 或者 mem 设置参数，那么也就是说即使改变了 cgroup 对于他们来说都无效，那么使用场景也就有限了
**A8：**限制容器的资源使用这个还是有价值的。限制低优先级应用本身也可以提升高优先级应用的 SLO，虽然效果没有那么明显。稳定性的考量同样也很重要。
**Q9:**Policy engine 目前在阿里的使用如何？在生产上有多上的规模使用这种方式进行动态调整？是否和社区的 HPA VPA 配合使用？
**A9: **Policy engine 在阿里某些集群已经使用。至于规模暂时无法透漏。涉及到很多组件之间的联动，社区的 HPA 和 VPA 目前都不太能满足我们的需求。因此阿里的 HPA 和 VPA 都是我们自行开发的，但是和社区的原理是一致的。阿里 HPA 的开源可以关注 Openkruise 社区。VPA 开源计划我这里还没有确切消息。
**Q10：**当单机节点资源不足以提供容器扩容时，目前是否可以进行 HPA 或 VPA 扩容呢？
**A10：**单机节点不足的时候，应用可以通过 HPA 进行增加副本应对。但是 VPA 如果选择原节点进行更新的话，是失败的。只能调度到其他资源丰富的节点。在流量陡升的场景下，重建容器未必能满足需求，很可能导致雪崩，即重建过程中，整个应用其他未升级的副本接受更多流量，OOM 掉，新启动的容器再瞬间被 OOM，所以重启容器需要慎重。快速扩容（HPA）或者快速提升高优先级资源，抑制低优先级容器资源的方式效果更明显。
本文作者：张晓宇（衷源） 阿里云容器平台技术专家
[原文链接](https://link.zhihu.com/?target=https%3A//yq.aliyun.com/articles/719845%3Futm_content%3Dg_1000079633)
本文为云栖社区原创内容，未经允许不得转载。
分享到：
发表评论
相关推荐
内容概要：本文详细介绍了如何利用Matlab构建、优化和应用决策分类树。首先，讲解了数据准备阶段，将数据与程序分离，确保灵活性。接着，通过具体实例展示了如何使用Matlab内置函数如fitctree快速构建决策树模型，并通过可视化工具直观呈现决策树结构。针对可能出现的过拟合问题，提出了基于成本复杂度的剪枝方法，以提高模型的泛化能力。此外，还分享了一些实用技巧，如处理连续特征、保存模型、并行计算等，帮助用户更好地理解和应用决策树。 适合人群：具有一定编程基础的数据分析师、机器学习爱好者及科研工作者。 使用场景及目标：适用于需要进行数据分类任务的场景，特别是当需要解释性强的模型时。主要目标是教会读者如何在Matlab环境中高效地构建和优化决策分类树，从而应用于实际项目中。 其他说明：文中不仅提供了完整的代码示例，还强调了代码模块化的重要性，便于后续维护和扩展。同时，对于初学者来说，建议从简单的鸢尾花数据集开始练习，逐步掌握决策树的各项技能。
《营销调研》第7章-探索性调研数据采集.pptx
Assignment1_search_final(1).ipynb
美团优惠券小程序带举牌小人带菜谱+流量主模式，挺多外卖小程序的，但是都没有搭建教程 搭建： 1、下载源码，去微信公众平台注册自己的账号 2、解压到桌面 3、打开微信开发者工具添加小程序-把解压的源码添加进去-appid改成自己小程序的 4、在pages/index/index.js文件搜流量主广告改成自己的广告ID 5、到微信公众平台登陆自己的小程序-开发管理-开发设置-服务器域名修改成
《计算机录入技术》第十八章-常用外文输入法.pptx
基于Andorid的跨屏拖动应用设计实现源码，主要针对计算机相关专业的正在做毕设的学生和需要项目实战练习的学习者，也可作为课程设计、期末大作业。
《网站建设与维护》项目4-在线购物商城用户管理功能.pptx
区块链_房屋转租系统_去中心化存储_数据防篡改_智能合约_S_1744435730
《计算机应用基础实训指导》实训五-Word-2010的文字编辑操作.pptx
《移动通信(第4版)》第5章-组网技术.ppt
ABB机器人基础.pdf
《综合布线施工技术》第9章-综合布线实训指导.ppt
很不错的一套站群系统源码,后台配置采集节点，输入目标站地址即可全自动智能转换自动全站采集!支持 https、支持 POST 获取、支持搜索、支持 cookie、支持代理、支持破解防盗链、支持破解防采集 全自动分析,内外链接自动转换、图片地址、css、js，自动分析 CSS 内的图片使得页面风格不丢失: 广告标签，方便在规则里直接替换广告代码 支持自定义标签，标签可自定义内容、自由截取、内容正则截取。可以放在模板里，也可以在规则里替换 支持自定义模板，可使用标签 diy 个性模板，真正做到内容上移花接木 调试模式，可观察采集性能，便于发现和解决各种错误 多条采集规则一键切换，支持导入导出 内置强大替换和过滤功能，标签过滤、站内外过滤、字符串替换、等等 IP 屏蔽功能，屏蔽想要屏蔽 IP 地址让它无法访问 ****高级功能*****· url 过滤功能，可过滤屏蔽不采集指定链接· 伪原创，近义词替换有利于 seo· 伪静态，url 伪静态化，有利于 seo· 自动缓存自动更新，可设置缓存时间达到自动更新，css 缓存· 支持演示有阿三源码简繁体互转· 代理 IP、伪造 IP、随机 IP、伪造 user-agent、伪造 referer 来路、自定义 cookie，以便应对防采集措施· url 地址加密转换，个性化 url，让你的 url 地址与众不同· 关键词内链功能· 还有更多功能等你发现…… 程序使用非常简单，仅需在后台输入一个域名即可建站，不限子域名，站群利器，无授权，无绑定限制，使用后台功能可对页面进行自定义修改，在程序后台开启生 成功能，只要访问页面就会生成一个本地文件。当用户再次访问的时候就直接访问网站本地的页面，所以目标站点无法访问了也没关系，我们的站点依然可以访问， 支持伪静态、伪原创、生成静态文件、自定义替换、广告管理、友情链接管理、自动下载 CSS 内的图。
【自然语言处理】文本分类方法综述：从基础模型到深度学习的情感分析系统设计
基于Andorid的下拉浏览应用设计实现源码，主要针对计算机相关专业的正在做毕设的学生和需要项目实战练习的学习者，也可作为课程设计、期末大作业。
内容概要：本文详细介绍了一个原创的P2插电式混合动力系统Simulink模型，该模型基于逻辑门限值控制策略，涵盖了多个关键模块如工况输入、驾驶员模型、发动机模型、电机模型、制动能量回收模型、转矩分配模型、运行模式切换模型、档位切换模型以及纵向动力学模型。模型支持多种标准工况（WLTC、UDDS、EUDC、NEDC）和自定义工况，并展示了丰富的仿真结果，包括发动机和电机转矩变化、工作模式切换、档位变化、电池SOC变化、燃油消耗量、速度跟随和最大爬坡度等。此外，文章还深入探讨了逻辑门限值控制策略的具体实现及其效果，提供了详细的代码示例和技术细节。 适合人群：汽车工程专业学生、研究人员、混动汽车开发者及爱好者。 使用场景及目标：①用于教学和科研，帮助理解和掌握P2混动系统的原理和控制策略；②作为开发工具，辅助设计和优化混动汽车控制系统；③提供仿真平台，评估不同工况下的混动系统性能。 其他说明：文中不仅介绍了模型的整体架构和各模块的功能，还分享了许多实用的调试技巧和优化方法，使读者能够更好地理解和应用该模型。
内容概要：本文详细介绍了基于ADMM（交替方向乘子法）算法在电力系统分布式调度中的应用，特别是并行（Jacobi）和串行（Gauss-Seidel）两种不同更新模式的实现。文中通过MATLAB代码展示了这两种模式的具体实现方法，并比较了它们的优劣。并行模式适用于多核计算环境，能够充分利用硬件资源，尽管迭代次数较多，但总体计算时间较短；串行模式则由于“接力式”更新机制，通常收敛更快，但在计算资源有限的情况下可能会形成瓶颈。此外，文章还讨论了惩罚系数rho的自适应调整策略以及在电-气耦合系统优化中的应用实例。 适合人群：从事电力系统优化、分布式计算研究的专业人士，尤其是有一定MATLAB编程基础的研究人员和技术人员。 使用场景及目标：①理解和实现ADMM算法在电力系统分布式调度中的应用；②评估并行和串行模式在不同应用场景下的性能表现；③掌握惩罚系数rho的自适应调整技巧，提高算法收敛速度和稳定性。 其他说明：文章提供了详细的MATLAB代码示例，帮助读者更好地理解和实践ADMM算法。同时，强调了在实际工程应用中需要注意的关键技术和优化策略。
内容概要：本文深入研究了交错并联Buck变换器的工作原理、性能优势及其具体实现。文章首先介绍了交错并联Buck变换器相较于传统Buck变换器的优势，包括减小输出电流和电压纹波、降低开关管和二极管的电流应力、减小输出滤波电容容量等。接着，文章详细展示了如何通过MATLAB/Simulink建立该变换器的仿真模型，包括参数设置、电路元件添加、PWM信号生成及连接、电压电流测量模块的添加等。此外，还探讨了PID控制器的设计与实现，通过理论分析和仿真验证了其有效性。最后，文章通过多个仿真实验验证了交错并联Buck变换器在纹波性能、器件应力等方面的优势，并分析了不同控制策略的效果，如P、PI、PID控制等。 适合人群：具备一定电力电子基础，对DC-DC变换器特别是交错并联Buck变换器感兴趣的工程师和技术人员。 使用场景及目标：①理解交错并联Buck变换器的工作原理及其相对于传统Buck变换器的优势；②掌握使用MATLAB/Simulink搭建交错并联Buck变换器仿真模型的方法；③学习PID控制器的设计与实现，了解其在电源系统中的应用；④通过仿真实验验证交错并联Buck变换器的性能，评估不同控制策略的效果。 其他说明：本文不仅提供了详细的理论分析，还给出了大量可运行的MATLAB代码，帮助读者更好地理解和实践交错并联Buck变换器的设计与实现。同时，通过对不同控制策略的对比分析，为实际工程应用提供了有价值的参考。
《综合布线施工技术》第8章-综合布线工程案例.ppt
内容概要：本文详细介绍了基于STM32F103C8T6的K型热电偶温度控制仪的设计与实现。硬件部分涵盖了热电偶采集电路、OLED显示模块、蜂鸣器电路、风扇控制电路以及EEPROM存储模块。软件部分则涉及ADC配置、OLED刷新、PID控温算法、EEPROM参数存储、风扇PWM控制等多个方面的具体实现。文中不仅提供了详细的代码示例，还分享了许多调试经验和注意事项，如冷端补偿、DMA传输优化、I2C时钟配置、PWM频率选择等。 适合人群：具有一定嵌入式系统开发经验的工程师和技术爱好者。 使用场景及目标：适用于需要进行温度监测与控制的应用场景，如工业自动化、实验室设备等。目标是帮助读者掌握STM32F103C8T6在温度控制领域的应用技巧，提升硬件设计和软件编程能力。 其他说明：本文提供的工程文件包含Altium Designer的原理图PCB文件，便于二次开发。此外，文中还提到了一些扩展功能，如加入Modbus通信协议，供有兴趣的读者进一步探索。