上图是我们最初的工具流程设计：当一个应用面临很高的业务访问需求时，体现在 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 以下。
这说明了我们的控制策略的有效性。
==========================================================================
下面我们总结一下在整个项目的进行过程中，我们收获的一些经验和教训，希望这些经验教训能够对遇到类似问题和场景的人有所帮助。
-
避开硬编码，组件微服务化，不仅便于快速演进和迭代，还有利于熔断异常服务。
-
尽可能不要调用类库中还是 alpha 或者 beta 特性的接口。 例如我们曾经直接调用 CRI 接口读取容器的一些信息，或者做一些更新操作，但是随着接口字段或者方法的修改，共建有些功能就会变得不可用，或许有时候，调用不稳定的接口还不如直接获取某个应用的打印信息可能更靠谱。
-
基于 QoS 的资源动态调整方面：如我们之前所讲，阿里集团内部有上万个应用，应用之间的调用链相当复杂。应用 A 的容器性能发生异常，不一定都是在单机节点上的资源不足或者资源竞争导致，而很有可能是它下游的应用 B、应用 C，或者数据库、cache 的访问延迟导致的。由于单机节点上这种信息的局限性，基于单机节点信息的资源调整，只能采用“尽力而为”，也就是 best effort 的策略了。在未来，我们计划打通单机节点和中心端的资源调控链路，由中心端综合单机节点上报的性能信息和资源调整请求，统一进行资源的重新分配，或者容器的重新编排，或者触发 HPA，从而形成一个集群级别的闭环的智能资源调控链路，这将会大大提高整个集群维度的稳定性和综合资源利用率。
-
资源v.s.性能模型：可能有人已经注意到，我们的调整策略里，并没有明显地提出为容器建立“资源v.s.性能”的模型。这种模型在学术论文里非常常见，一般是对被测的几种应用进行了离线压测或者在线压测，改变应用的资源分配，测量应用的性能指标，得到性能随资源变化的曲线，最终用在实时的资源调控算法中。在应用数量比较少，调用链比较简单，集群里的物理机硬件配置也比较少的情况下，这种基于压测的方法可以穷举到所有可能的情况，找到最优或者次优的资源调整方案，从而得到比较好的性能。但是在阿里集团的场景下，我们有上万个应用，很多重点应用的版本发布也非常频繁，往往新版本发布后，旧的压测数据，或者说资源性能模型，就不适用了。另外，我们的集群很多是异构集群，在某一种物理机上测试得到的性能数据，在另一台不同型号的物理机上就不会复现。这些都对我们直接应用学术论文里的资源调控算法带来了障碍。所以，针对阿里集团内部的场景，我们采用了这样的策略：不对应用进行离线压测，获取显示的资源性能模型。而是建立实时的动态容器画像，用过去一段时间窗口内容器资源使用情况的统计数据作为对未来一小段时间内的预测，并且动态更新；最后基于这个动态的容器画像，执行小步快跑的资源调整策略，边走边看，尽力而为。
==========================================================================
总结起来，我们的工作主要实现了以下几方面的收益：
-
通过分时复用以及将不同优先级的容器（也就是在线和离线任务）混合部署，并且通过对容器资源限制的动态调整，保证了在线应用在不同负载情况下都能得到足够的资源，从而提高集群的综合资源利用率。
-
通过对单机节点上的容器资源的智能动态调整，降低了应用之间的性能干扰，保障高优先级应用的性能稳定性
-
各种资源调整策略通过 Daemonset 部署，可以自动地、智能地在节点上运行，减少人工干预，降低了运维的人力成本。
展望未来，我们希望在以下几个方面加强和扩展我们的工作：
-
闭环控制链路：前面已经提到，单机节点上由于缺乏全局信息，对于资源的调整有其局限性，只能尽力而为。未来，我们希望能够打通与 HPA 和 VPA 的通路，使单机节点和中心端联动进行资源调整，最大化弹性伸缩的收益。
-
容器重新编排：即使是同一个应用，不同容器的负载和所处的物理环境也是动态变化的，单机上调整 pod 的资源，不一定能够满足动态的需求。我们希望单机上实时容器画像，能够为中心端提供更多的有效信息，帮助中心端的调度器作出更加智能的容器重编排决策。
-
策略智能化：我们现在的资源调整策略仍然比较粗粒度，可以调整的资源也比较有限；后续我们希望让资源调整策略更加智能化，并且考虑到更多的资源，比如对磁盘和网络IO带宽的调整，提高资源调整的有效性。
-
容器画像精细化：目前的容器画像也比较粗糙，仅仅依靠统计数据和线性预测；刻画容器性能的指标种类也比较局限。我们希望找到更加精确的、通用的、反映容器性能的指标，以便更加精细地刻画容器当前的状态和对不同资源的需求程度。
-
查找干扰源：我们希望能找到在单机节点上找到行之有效的方案，来精准定位应用性能受损时的干扰源；这对策略智能化也有很大意义。
==========================================================================
**Q1：**直接修改 cgroup 容器一定会获得资源吗？
**A1：**容器技术隔离的技术基础就是 cgroup 层面。在宿主机腾出足够资源的情况下，给 cgroup 设置更大的值可以获取更多的资源。同理，对于一般优先级不高的应用，设置较低的 cgroup 资源值就会达到抑制容器运行的效果。
**Q2：**底层是如何区分在线和离线优先级的？
**A2：**底层是无法自动获取谁是在线，谁是离线，或者谁的优先级高，谁的优先级低的。这个我们可以通过各种 Kubernetes 提供的扩展实现。最简单的是通过 label，Annotation 标识。当然通过扩展 QoS class 也是一种思路。社区版本的 QoS class设置太过于保守，给予用户发挥的空间不大。我们通过这些方面也进行了增强。在合适的时候或许会推向社区。自动感知是个方向，感知谁是干扰源，感知谁是某种资源型应用，这块我们还在研发中。做到真正的动态，肯定是具备自动感知的智能系统。
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！
由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新
如果你觉得这些内容对你有帮助，可以添加V获取：vip1024b （备注Java）
最后
一次偶然，从朋友那里得到一份“java高分面试指南”，里面涵盖了25个分类的面试题以及详细的解析：JavaOOP、Java集合/泛型、Java中的IO与NIO、Java反射、Java序列化、Java注解、多线程&并发、JVM、Mysql、Redis、Memcached、MongoDB、Spring、Spring Boot、Spring Cloud、RabbitMQ、Dubbo 、MyBatis 、ZooKeeper 、数据结构、算法、Elasticsearch 、Kafka 、微服务、Linux。
这不，马上就要到招聘季了，很多朋友又开始准备“金三银四”的春招啦，那我想这份“java高分面试指南”应该起到不小的作用，所以今天想给大家分享一下。
请注意：关于这份“java高分面试指南”，每一个方向专题（25个）的题目这里几乎都会列举，在不看答案的情况下，大家可以自行测试一下水平 且由于篇幅原因，这边无法展示所有完整的答案解析
一个人可以走的很快，但一群人才能走的更远。如果你从事以下工作或对以下感兴趣，欢迎戳这里加入程序员的圈子，让我们一起学习成长！
AI人工智能、Android移动开发、AIGC大模型、C C#、Go语言、Java、Linux运维、云计算、MySQL、PMP、网络安全、Python爬虫、UE5、UI设计、Unity3D、Web前端开发、产品经理、车载开发、大数据、鸿蒙、计算机网络、嵌入式物联网、软件测试、数据结构与算法、音视频开发、Flutter、IOS开发、PHP开发、.NET、安卓逆向、云计算
304bb5a486d4c3ab8389e65ecb71ac0)
AI人工智能、Android移动开发、AIGC大模型、C C#、Go语言、Java、Linux运维、云计算、MySQL、PMP、网络安全、Python爬虫、UE5、UI设计、Unity3D、Web前端开发、产品经理、车载开发、大数据、鸿蒙、计算机网络、嵌入式物联网、软件测试、数据结构与算法、音视频开发、Flutter、IOS开发、PHP开发、.NET、安卓逆向、云计算
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
