共计 11418 个字符，预计需要花费 29 分钟才能阅读完成。
简介：近期，来自 Koordinator 社区的两位技术专家从我的项目的架构和个性登程，分享了 Koordinator 是如何应答混部场景下的挑战，特地是晋升混部场景下工作负载的运行的效率和稳定性，以及对后续技术演进的思考与布局。咱们也将本次直播的核心内容进行了整顿，心愿能给大家带来一些深刻的启发。作者：张佐玮 李涛 2022 年 4 月，阿里云原生混部零碎 Koordinator 发表正式开源。通过了几个月的迭代，Koordinator 目前曾经陆续公布了 4 个版本，能够无效帮忙企业客户改良云原生工作负载运行的效率、稳定性和计算成本。昨天（6 月 15 日），在阿里巴巴云栖直播间中，来自 Koordinator 社区的张佐玮 (佑祎)、李涛(吕风) 两位技术专家从我的项目的架构和个性登程，分享了 Koordinator 是如何应答混部场景下的挑战，特地是晋升混部场景下工作负载的运行的效率和稳定性，以及对后续技术演进的思考与布局。咱们也将本次直播的核心内容进行了整顿，心愿能给大家带来一些深刻的启发。点击链接，立刻查看直播回放！https://yqh.aliyun.com/live/d… 关注阿里云云原生公众号，后盾回复【0615】获取残缺 PPT 混部技术的介绍和倒退 混部的概念能够从两个角度来了解，从节点维度来看，混部就是将多个容器部署在同一个节点上，这些容器内的利用既包含在线类型，也包含离线类型；从集群维度来看，混部是将多种利用在一个集群内部署，通过预测剖析利用个性，实现业务在资源应用上的错峰填谷，以达到晋升集群资源利用率的成果。基于以上的了解，咱们就能够明确混部须要解决的指标问题以及技术计划。实质上，咱们施行混部的初衷是源自对数据中心资源利用效率的不懈谋求。埃森哲报告显示，2011 年私有云数据中心的机器利用率均匀不到 10%，意味着企业的资源老本极高，而另一方面随着大数据技术的倒退迅速，计算作业对资源的需要越来越大。事实上，大数据通过云原生形式上云已成为了必然趋势，据 Pepperdata 在 2021 年 12 月的调查报告，相当数量的企业大数据平台曾经开始向云原生技术迁徙。超过 77% 的受访者反馈预计到 2021 年底，其 50% 的大数据利用将迁徙到 Kubernetes 平台。于是，抉择批处理类型工作与在线服务类型利用混合部署，就牵强附会的成为了业界通用的混部计划选型。公开数据显示，通过混部，相干技术当先企业的资源利用率失去了大幅晋升。面对混部技术，在具体关注的问题上，不同角色的管理人员会有各自的侧重点。对于集群资源的管理员来说，他们冀望能够简化对集群资源的治理，实现对各类利用的资源容量，调配量，使用量的清晰洞察，晋升集群资源利用率，以达到升高 IT 老本的目标。对于在线类型利用的管理员来说，他们则更关注容器混合部署时的相互烦扰的，因为混部会更容易产生资源竞争，利用响应工夫会呈现长尾（tail latency），导致利用服务质量降落。而离线类型利用的管理员更冀望混部零碎能够提供分级牢靠的资源超卖，满足不同作业类型的差异化资源品质需要。针对以上问题，Koordinator 提供了以下机制，能够充沛满足不同角色对混部零碎的技术需要：面向混部场景的资源优先级和服务质量模型稳固牢靠的资源超卖机制细粒度的容器资源编排和隔离机制针对多种类型工作负载的调度能力加强简单类型工作负载的疾速接入能力 Koordinator 简介 下图展现了 Koordinator 零碎的整体架构和各组件的角色分工，其中绿色局部形容了 K8s 原生零碎的各个组件，蓝色局部是 Koordinator 在此基础上的扩大实现。从整个零碎架构来看，咱们能够将 Koordinator 分为核心管控和单机资源管理两个维度。在核心侧，Koordiantor 在调度器外部和内部别离都做了相应的扩大能力加强；在单机侧，Koordinator 提供了 Koordlet 和 Koord Runtime Proxy 两个组件，负责单机资源的精细化治理和 QoS 保障能力。
Koordinator 各组件的具体性能如下 Koord-ManagerSLO-Controller：提供资源超卖、混部 SLO 治理、精细化调度加强等外围管控能力。Recommender：围绕资源画像为利用提供相干的弹性能力。Colocation Profile Webhook：简化 Koordinator 混部模型的应用，为利用提供一键接入的能力，主动注入相干优先级、QoS 配置。Koord extensions for Scheduler：面向混部场景的调度能力加强。Koord descheduler：提供灵便可扩大的重调度机制。Koord Runtime Proxy：作为 Kubelet 和 Runtime 之间的代理，满足不同场景的资源管理需要，提供插件化的注册框架，提供相干资源参数的注入机制。Koordlet：在单机侧负责 Pod 的 QoS 保障，提供细粒度的容器指标采集，以及烦扰检测和调节策略能力，并反对一系列的 Runtime Proxy 插件，用于精细化的隔离参数注入。在 Koordinator 的设计模型中，一个外围的设计概念就是优先级（Priority），Koordinator 定义了四个等级，别离是 Product、Mid、Batch、Free，Pod 须要指定申请的资源优先级，调度器会基于各资源优先级总量和调配量做调度。各优先级的资源总量会受高优先级资源的 request 和 usage 影响，例如已申请但未应用的 Product 资源会以 Batch 优先级再次调配。节点各资源优先级的具体容量，Koordinator 会以规范的 extend-resource 模式更新在 Node 信息中。下图展现了一个节点各资源优先级的容量状况，其中彩色的直线 total 代表了节点的物理资源总量，红色折线代表了高优先级 Product 的实在使用量，蓝色折线到彩色直线之间反映了 Batch 优先级的资源超卖变动状况，能够看到当 Product 优先级处于资源耗费的低谷时，Batch 优先级能够取得更多的超卖资源。事实上，资源优先级策略的激进或激进，决定了集群资源的超卖容量，这点咱们也能够从图中绿色直线对应的 Mid 资源优先级超卖状况剖析看出。
如下表所示，Koordinator 以 K8s 规范的 PriorityClass 模式对各资源优先级进行了定义，代表 Pod 申请资源的优先级。在多优先级资源超卖状况下，当单机资源缓和时，低优先级 Pod 会被压抑或驱赶。此外，Koordinator 还提供了 Pod 级别的子优先级（sub-priority），用于调度器层面的精细化管制（排队，抢占等）。
Koordinator 的设计中另一个外围的概念是服务质量（Quality of Service），Koordinator 将 QoS 模型在 Pod Annotation 级别进行了扩大定义，它代表了 Pod 在单机运行过程中的资源品质，次要体现为应用的隔离参数不同，当单机资源缓和时会优先满足高等级 QoS 的需要。如下表所示，Koordinator 将 QoS 整体分为 System（零碎级服务），Latency Sensitive（提早敏感性的在线服务），Best Effort（资源消耗型的离线利用）三类，依据利用性能敏感水平的差别，Latency Sensitive 又细分为 LSE，LSR 和 LS。
在 Priority 和 QoS 的应用上，二者整体是正交的两个维度，能够排列组合应用。不过受模型定义和理论的需要状况影响，局部排列组合存在束缚。下表展现了混部场景中常常应用到的一些组合，其中“O”示意罕用的排列组合，“X”示意根本应用不到的排列组合。
各场景的理论应用举例如下。典型场景：Prod + LS：典型的在线利用，通常对利用时延要求较高，对资源品质要求较高，也须要保障肯定的资源弹性能力。Batch + BE：用于混部场景中的低优离线，对资源品质有相当的忍受度，例如批处理类型的 Spark/MR 工作，以及 AI 类型的训练任务 典型场景的加强：Prod + LSR/LSE：比拟敏感的在线利用，能够承受就义资源弹性而换取更好的确定性（如 CPU 绑核），对利用时延要求极高。Mid/Free + BE：与“Batch + BE”相比次要区别是对资源品质要求的高下不同。非典型的利用场景：Mid/Batch/Free + LS：用于低优先级的在线服务、近线计算以及 AI 推理类等工作，这些工作相较于大数据类型工作，它们无奈承受过低的资源品质，对其余利用的烦扰也绝对较低；而相较于典型的在线服务，它们又能够忍耐绝对较低的资源品质，例如承受肯定水平的驱赶。Quick Start Koordinator 反对多种工作负载的灵便接入混部，这里咱们以 Spark 为例，介绍如何应用混部超卖资源。在 K8s 集群中运行 Spark 工作有两种模式：一种是通过 Spark Submit 提交，也就是在本地应用 Spark 客户端间接连贯 K8s 集群，这种形式比较简单快捷，不过在整体的治理能力上有所不足，罕用于开发自测；另一种形式是通过 Spark Operator 提交，如下图所示，它定义了 SparkApplication CRD，用于 Spark 作业的形容，用户能够通过 kubectl 客户端将提交 SparkApplication CR 到 APIServer，随后由 Spark Operator 负责作业生命周期以及 Driver Pod 的治理。
凭借 Koordinator 能力的加持，ColocationProfile Webhook 会主动为 Spark 工作的 Pod 注入相干混部配置参数（包含 QoS，Priority，extened-resource 等），如下所示。Koordlet 在单机侧负责 Spark Pod 在混部后不会影响在线利用性能体现，通过将 Spark 与在线利用进行混部，能够无效晋升集群整体资源利用率。# Spark Driver Pod example
apiVersion: v1
kind: Pod
metadata:
labels:
koordinator.sh/qosClass: BE…
spec:
containers:
-
args:
- driver
…
resources:
limits:
koordinator.sh/batch-cpu: "1000"
koordinator.sh/batch-memory: 3456Mi
requests:
koordinator.sh/batch-cpu: "1000"
koordinator.sh/batch-memory: 3456Mi… 关键技术介绍 资源超发 – Resource Overcommitment 在应用 K8s 集群时，用户很难精确的评估在线利用的资源应用状况，不晓得该怎么更好的设置 Pod 的 Request 和 Limit，因而往往为了保障在线利用的稳定性，都会设置较大的资源规格。在理论生产中，大部分在线利用的理论 CPU 利用率大多数时候都比拟低，高的可能也就百分之十几或者二十几，节约了大量曾经被调配但未应用的资源。
Koordinator 通过资源超发机制回收复用这部分调配但未被应用的资源。Koordinator 依据指标数据评估在线利用的 Pod 有多少资源是能够回收的（如上图所示，标记为 Reclaimed 的局部就是可被回收的资源），这些可回收的资源就能够超发给低优先级的工作负载应用，例如一些离线工作。为了让这些低优先级工作负载方便使用这些资源，Koordinator 会把这些超发资源更新到 NodeStatus 中（如上面所示的 node info）。当在线利用有突发的申请须要解决时要求应用更多的资源，Koordinator 通过丰盛的 QoS 加强机制帮忙在线利用拿回这些资源以保障服务质量。# node info
allocatable:
koordinator.sh/bach-cpu: 50k # milli-core
koordinator.sh/bach-memory: 50Gi
pod info
annotations:
koordinator.sh/resource-limit: {cpu:“5k”}resources:
requests
koordinator.sh/bach-cpu: 5k # milli-core
koordinator.sh/bach-memory: 5Gi 负载平衡调度 - Load-Aware Scheduling 超发资源能够极大的晋升集群的资源利用率，但也会凸显集群内节点之间资源利用率不平均的景象。这个景象在非混部环境下也是存在的，只是因为 K8s 原生是不反对资源超发机制，节点上的利用率往往不是很高，肯定水平上覆盖了这个问题。但当混部时，资源利用率会回升到比拟高的水位时就裸露了这个问题。利用率不平均个别是节点之间不平均以及呈现部分的负载热点，部分的负载热点会可能影响工作负载的整体运行成果。另一个是在负载高的节点上，在线利用和离线工作之间可能会存在的重大的资源抵触，影响到在线利用的运行时品质。
为了解决这个问题，Koordinator 的调度器提供了一个可配置的调度插件管制集群的利用率。该调度能力次要依赖于 koordlet 上报的节点指标数据，在调度时会过滤掉负载高于某个阈值的节点，避免 Pod 在这种负载较高的节点上无奈取得很好的资源保障，另一方面是防止负载曾经较高的节点持续好转。在打分阶段抉择利用率更低的节点。该插件会基于工夫窗口和预估机制躲避因霎时调度太多的 Pod 到冷节点机器呈现一段时间后冷节点过热的状况。
利用接入治理 – ClusterColocationProfile 咱们在 Koordinator 我的项目开源之初就思考到，须要升高 Koordinator 混部零碎的应用门槛，让大家能够简略疾速的灰度和应用混部技术取得收益。因而 Koordinator 提供了一个 ClusterColocationProfile CRD，通过这个 CRD 和对应的 Webhook，能够在不侵入存量集群内的组件的状况下，按需针对不同的 Namespace 或者不同的工作负载，一键开启混部能力，Webhook 会依据该 CRD 形容的规定对新创建的 Pod 主动的注入 Koorinator 优先级、QoS 配置和其余混部协定等。apiVersion: config.koordinator.sh/v1alpha1
kind: ClusterColocationProfile
metadata:
name: colocation-profile-example
spec:
namespaceSelector:
matchLabels:
koordinator.sh/enable-colocation: "true"selector:
matchLabels:
sparkoperator.k8s.io/launched-by-spark-operator: "true"qosClass: BE
priorityClassName: koord-batch
koordinatorPriority: 1000
schedulerName: koord-scheduler
labels:
koordinator.sh/mutated: "true"annotations:
koordinator.sh/intercepted: "true"patch:
spec:
terminationGracePeriodSeconds: 30 举个例子，下面是 ClusterColocationProfile 的一个实例，示意所有带有 koordinator.sh/enable-colocation=true 标签的 Namespace 和该 Namespace 下 SparkOperator 作业创立的 Pod 都能够转为 BE 类型的 Pod（BTW：SparkOperator 创立的 Pod 时会减少标签 sparkoperator.k8s.io/launched-by-spark-operator=true 示意这个 Pod 是 SparkOperator 负责的）。只须要依照如下步骤就能够实现混部接入：$ kubectl apply -f profile.yaml$ kubectl label ns spark-job -l koordinator.sh/enable-colocation=true
$ # submit Spark Job, the Pods created by SparkOperator are co-located other LS Pods. QoS 加强 – CPU Suppress Koordinator 为保障在线利用在混部场景下的运行时品质，在单机侧提供了丰盛的 QoS 加强能力。首先向大家介绍 CPU Suppress（CPU 动静压抑）个性。后面向大家介绍了，在线利用大多时候并不会齐全用完申请到的资源，会有大量的闲暇资源，这些闲暇资源除了能够通过资源超发给新创建的离线工作应用外，还能够在节点上还没有新的离线工作须要执行时，尽可能的把闲暇的 CPU 资源共享给存量的离线工作。如这个图中所示，当 koordlet 发现在线利用的资源闲暇，并且离线工作应用的 CPU 还没有超过平安阈值，那么平安阈值内的闲暇 CPU 就能够共享给离线工作应用，让离线工作能够更快的执行。因而在线利用的负载的高下决定了 BE Pod 总共有多少可用 CPU。当在线负载升高时，koordlet 会通过 CPU Suppress 压抑 BE Pod，把共享的 CPU 还给在线利用。
QoS 加强 – 基于资源满足度的驱赶 CPU Suppress 在线利用的负载升高时可能会频繁的压抑离线工作，这尽管能够很好的保障在线利用的运行时品质，然而对离线工作还是有一些影响的。尽管离线工作是低优先级的，但频繁压抑会导致离线工作的性能得不到满足，重大的也会影响到离线的服务质量。而且频繁的压抑还存在一些极其的状况，如果离线工作在被压抑时持有内核全局锁等非凡资源，那么频繁的压抑可能会导致优先级反转之类的问题，反而会影响在线利用。尽管这种状况并不常常产生。
为了解决这个问题，Koordinator 提出了一种基于资源满足度的驱赶机制。咱们把理论调配的 CPU 总量 与 冀望调配的 CPU 总量的比值成为 CPU 满足度。当离线工作组的 CPU 满足度低于阈值，而且离线工作组的 CPU 利用率超过 90% 时，koordlet 会驱赶一些低优先级的离线工作，开释出一些资源给更高优先级的离线工作应用。通过这种机制可能改善离线工作的资源需要。QoS 加强 – CPU Burst 咱们晓得 CPU 利用率是一段时间内 CPU 应用的平均值。而且咱们大多数时候都是以一种较粗的工夫单位粒度察看统计 CPU 利用率，这个时候察看到 CPU 利用率的变动是根本稳固的。但如果咱们以较细的工夫单位粒度察看统计 CPU 利用率，能够看到 CPU 应用的突发特色非常明显，是不稳固的。如下图以 1s 粒度察看利用率（紫色）和 100ms 粒度察看的利用率（绿色）比照。
细粒度数据观测表明 CPU 突发和压抑是常态。Linux 内核中通过 CFS 带宽控制器 cgroup CPU 的耗费，它限度了 cgroup 的 CPU 耗费下限，因而常常会遇到一些突发流量下业务短时间内被狠狠地 throttle，产生长尾提早，造成服务质量降落，如下图所示，Req2 因为 CPU 被压抑，延期到第 200ms 才失去解决。
为了解决这个问题，Koordinator 基于 CPU Burst 技术帮忙在线利用应答突发状况。CPU Burst 容许工作负载在有突发申请解决应用 CPU 资源时，应用日常的 CPU 资源。比方容器在日常运行中应用的 CPU 资源未超过 CPU 限流，空余的 CPU 资源将会被积攒。后续当容器运行须要大量 CPU 资源时，将通过 CPU Burst 性能突发应用 CPU 资源，这部分突发应用的资源来源于已积攒的资源。如下图所示，突发的 Req2 因为有积攒的 CPU 资源，通过 CPU Burst 性能得以防止被 throttle，疾速的解决了申请。
QoS 加强 – Group Identity 在混部场景下，Linux 内核尽管提供了多种机制满足不同优先级的工作负载的调度需要，但当一个在线利用和一个离线工作同时运行在一个物理核上时，因为在离线工作都共享雷同的物理资源，在线利用的性能不可避免的会被离线工作烦扰从而性能降落。Alibaba Cloud Linux 2 从内核版本 kernel-4.19.91-24.al7 开始反对 Group Identity 性能，Group Identity 是一种以 cgroup 组为单位实现的调度非凡优先级的伎俩，简略讲，当在线利用须要更多资源时，通过 Group Identity 能够临时压抑离线工作保障在线利用能够疾速的响应。要应用这个个性比较简单，能够配置 cpu cgroup 的 cpu.bvt_warp_ns 即可。在 Koordinator 里，BE 类离线工作对应配置为 -1，即最低优先级，LS/LSR 等在线利用类型设置为 2，即最高优先级。
QoS 加强 – Memory QoS 容器在应用内存时次要有以下两个方面的束缚：本身内存限度：当容器本身的内存（含 Page Cache）靠近容器下限时，会触发内核的内存回收子系统，这个过程会影响容器内利用的内存申请和开释的性能。节点内存限度：当容器内存超卖（Memory Limit>Request）导致整机内存不足，会触发内核的全局内存回收，这个过程对性能影响较大，极其状况甚至导致整机异样。为了进步利用运行时性能和节点的稳定性，Koordinator 引入 Memory QoS 能力，为利用晋升内存性能。当性能开启时，koordlet 根据自适应配置内存子系统（Memcg），在保障节点内存资源偏心的根底上，优化内存敏感型利用的性能。
后续演进打算 精细化 CPU 编排 – Find-grained CPUOrchestration 咱们正在设计和实现精细化 CPU 编排机制。咱们为什么要提供这个编排机制呢？随着资源利用率的晋升进入到混部的深水区，须要对资源运行时的性能做更深刻的调优，更精密的资源编排能够更好的保障运行时品质，从而通过混部将利用率推向更高的程度。咱们把 Koordinator QoS 在线利用 LS 类型做了更粗疏的划分，分为 LSE、LSR 和 LS 三种类型。拆分后的 QoS 类型具备更高的隔离性和运行时品质。通过这样的拆分，整个 Koordinator QoS 语义更加准确和残缺，并且兼容 K8s 已有的 QoS 语义。而且咱们针对 Koordinator QoS，设计了一套丰盛灵便的 CPU 编排策略，如下表所示。
Koordinator QoS 对应的 CPU 编排策略 另外，针对 LSR 类型，还提供了两种绑核策略，能够帮忙用户均衡性能和经济收益。SameCore 策略：更好的隔离性，但弹性空间小。Spread 策略：中等的隔离性，但能够通过其余隔离策略优化；应用切当能够取得比 SameCore 策略更好的性能；有肯定的弹性空间。
Koordinator 的这套精细化 CPU 编排计划兼容 K8s 已有的 CPUManager 和 NUMA Topology Manager 机制的。也就是说存量集群应用 Koordinator 时不会影响存量的 Pod，能够平安释怀的灰度应用。资源预留 – Resource Reservation 资源预留是咱们另一个正在设计的个性。资源预留能够帮忙解决资源管理的痛点。例如有时候像大家相熟的互联网业务场景，都有十分强的峰谷特色。那么咱们能够在峰值达到前预留资源确保肯定有资源满足峰值申请。另外像大家在扩容时可能也会遇到的问题，发动扩容后因为没有资源 Pod 就 Pending 在集群里，如果能在扩容前提前确认是否资源，没资源时加新机器就能有更好的体验。还有像重调度场景，能够通过资源预留保障被驱赶的 Pod 肯定有资源能够用，能够极大的升高重调度的资源危险，更平安释怀的应用重调度能力。Koordinator 的资源预留机制不会侵入 K8s 社区已有的 API 和代码。并反对 PodTemplateSpec，模拟一个 Pod 通过调度器找到最合适的节点。并反对申明所有权的形式反对 Pod 优先应用预留资源，例如当一个真正的 Pod 调度时，会优先尝试依据 Pod 的特色找到适合的预留资源，否则持续应用集群内闲暇的资源。上面是一个 Reservation CRD 的例子（最终以 Koordinator 社区通过的设计为准）kind: Reservation
metadata:
name: my-reservation
namespace: default
spec:
template: … # a copy of the Pod’s spec
resourceOwners:
controller:
apiVersion: apps/v1
kind: Deployment
name: deployment-5b8df84ddtimeToLiveInSeconds: 300 # 300 seconds
nodeName: node-1
status:
phase: Available
… 精细化 GPU 调度 – GPU Scheduling 精细化 GPU 调度是咱们将来冀望提供的一种能力。GPU 和 CPU 在资源特色上差别比拟大，而且在像机器学习的模型训练场景中，一个训练作业会因为不同的拓扑构造导致不同的性能差别，例如依据机器学习作业内 worker 之间不同的拓扑组合，会失去不同的性能，这不仅体现在集群内节点之间，而且即便单个节点上，GPU 卡之间也因为像是否应用 NVLINK 也会有微小的性能差别，这让整个 GPU 的调度调配逻辑变的十分复杂。而且 GPU 和 CPU 的计算工作在集群内混部时，怎么防止两种资源的节约，也是须要思考解决优化的问题。
规格举荐 – Resource Recommendation 后续 Koordinator 还会提供基于画像的规格举荐能力。后面也提到，用户是很难准确评估应用程序的资源应用状况的，Request 和 Limit 到底是什么关系，到底该怎么设置 Request/Limit，对于我这个利用来说哪种组合才是最合适的？常常高估或者低估 Pod 资源规格，导致资源节约甚至稳定性危险。Koordinator 会提供资源画像能力，采集并加工剖析历史数据，举荐更精确的资源规格。
社区建设 目前为止，咱们在最近两个多月公布了四个版本。后面几个版本次要提供了资源超发、QoS 加强的能力，并且还开源了新的组件 koord-runtime-proxy。在 0.4 版本中，咱们开始在调度器上发力，首先凋谢了负载平衡调度能力。目前 Koordinator 社区正在实现 0.5 版本，在这个版本中，Koordinator 会提供精细化 CPU 编排和资源预留的能力，在之后的布局中，咱们还会在重调度、Gang 调度、GPU 调度、弹性 Quota 等实现一些新的翻新。
十分期待您在应用 Koordinator 踊跃的反馈遇到的任何问题、帮忙改善文档、修复 BUG 和增加新性能 If you find a typo, try to fix it!If you find a bug, try to fix it!If you find some redundant codes, try to remove them!If you find some test cases missing, try to add them!If you could enhance a feature, please DO NOT hesitate!If you find code implicit, try to add comments to make it clear!If you find code ugly, try to refactor that!If you can help to improve documents, it could not be better!If you find document incorrect, just do it and fix that!… 此外，咱们还于周二 19:30 至 20:30 操办了社区定期双周会，欢送宽广气味相投的搭档增加交换群理解更多信息。
微信群
钉钉群 点击此处，立刻理解 Koordinator 我的项目！原文链接：http://click.aliyun.com/m/100… 本文为阿里云原创内容，未经容许不得转载。
