开发者学堂课程【云原生技术趋势与行业发展解读：混部开源 Koordinator 背后的故事】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1035/detail/15147
混部开源 Koordinator 背后的故事
十、Koodinator 社区
Koodinator 社区官网为https：//koodinator.sh/。在Koodinator 社区里面，未来将持续的推进双周会。目前，双周会仍处于持续筹备的过程中。
在整个Koodinator 社区中，社区会定义四种不同的角色，欢迎个人积极参与并为社区贡献，Koodinator 社区欢迎个人进行提问，个人可以在社区中提bug 与诉求等。
任何形式的贡献都会成为Koodinator 社区的Contributor。当个人在社区里面保持足够的活跃度并且能够持续进行发声，个人就可以逐渐的成为Koodinator 社区的Member。
Member 会拥有更多的权限，比如可以更好的与成员进行讨论、有权利去组织双周会等。
如果个人在某一个方向持续的沉淀，成为此方向最专业的同学，其即可成为对应方向的Maintainer。Co-Chair 主导项目的发展方向。
十一、企业混部应用经验分享
（1）混部应用的技术形态及混部产生的价值
第一个话题为结合阿里巴巴双11的场景谈论混部技术产生的价值，阿里巴巴集团的业务多样性较为丰富的，其拥有传统v 服务应用的Java 架构，例如核心的电商交易、导购、maps computer 类型的大数据、AI 的向派以及传统的搜索推荐广告，其业务包括数据库、盘古存储等。混部包含两层概念，第一层概念为大众通常提及的混部为从location 的角度出发，混部即为个人将不同的应用放到一起。随着机器计算密度的逐渐提升，从原来单机的8核提升到16核，从32核提升到64核，再到最近的96核以及目前的192核，此些都为硬件从原来摩尔定律倍的收益到目前主要通过扩展核提升收益。由此，个人实际上不得不去进行稳步的使用方式，其类似于混部的形态，其可以被称为空分的混部形态。
此类似于当前云上的ECS 以及在线类业务之间的混部，其都可以被称为空分的混部。另外一部分为混部实际上谈论的为混部弹性，即为在线应用与离线应用跑在一起，此为离线或离在线混部，其核心的逻辑为弹性的逻辑。
在线资源正确的时候，可以实时增强离线的资源，以此保证在线的HON。在多年的发展中，阿里巴巴集团具有两个比较典型的混部场景。一个即为常态化的日常，日常主要的混部再利用的为在线都具有容灾的余量，个人希望能够把容灾的余量用来跑大数据的计算，此行为能提高整体资源的利用率。
另外一部分为阿里巴巴双十一的场景，阿里巴巴双十一的场景是一个较为典型的中国电商的一种业务形态。双十一的在线流量为日常流量的十倍的量级。按照传统的准备资源的方式，则是需要准备十倍的机器来支撑大促的资源需求。在阿里巴巴集团大促的时候，集团大量使用了离在线混部资源场景，即为集团把max computer 部分进行批处理，以及非实时的部分任务，即为离线任务。在双十一大促的时候，集团通过大量的降级将资源释放给在线的业务，以此实现大促资源采购的降低。每年通过离在线巩固集团整个大促的成本下架50%以上。今年，阿里集团目标为争取做到大促的零成本，其核心为依赖混部的能力。
另外一个为谈论云计算与混部的关系，云计算和混部本质上都是通过资源磁化再提供弹性的计算能力，混部其实是云计算底层最基础的能力，此类似与ECS，ECS 就将一台整机通过不同的规格释放给不同的业务。云计算本身是一个算力、存储、磁化的一种技术。
混部弹性只是现阶段个别应用架构以及容量弹性能力不足的一种平衡，即为个人如果能做到应用秒级的自动伸缩的一种理想模式。其实从某种逻辑上，混部是不被需要的，但是当今有大量的业务带状态的英文，比如搜索推荐，则其整个英文拉群效率会较低，所以个人可以通过混部来解决待状态业务，其需要快速的服务能力时，为其提供一种弹性资源。
（2）云原生容器技术为企业基础设施带来的变化
其实注意点在于容器技术本身带来的革新的变化在什么地方，其具有两个界面上的变化。一个即为其是对底层资源的一个抽象，就是其提供的隔离以及虚拟化的技术，该隔离与技术是可以持续的使得个人能够提升部署力度并且能够持续的享受硬件迭代红利。通过此一层的资源隔离，其实个人能够解决基础设施快速迭代的需求，其类似于集团在进行5u 到7u 升级的1时候，其实个人是通过容器这层隔离很好的解决了业务对基础环境依赖的问题，然后个人也很快实现了整体计算机显收敛的事情。
另外一个界面的变化在于容器本身的镜像化以及镜像化带来的应用对基础环境部分的需求，其是做到可以描述其真实的改变了服务器及软件供应链的方式。集团在早期拥有一个较大的pp 部门，此时应用的运维实际上都是靠着运维脚本。
通过容器化与资源调度，个人可以真实的将原来pv 的角色从个人职责转移到DVoup上。通过此种模式的变化，整体的应用以及研发的效率会进行大幅的提升。此外，容器技术也带来对于基础设施的一些挑战。比如通过容器，个人要将不同的workload 放在同一个服务器上，则即为个人在同一个机型上需要兼容不同的workload对硬件的需求，此部分是对硬件提出了更高的要求。
此时，整体的硬件会从原来根据不同领域定制硬件转变为整体的机型向统一机型发展。对于专用机型和通用机型哪个可以为企业带来更高的成本优势的问题在目前阶段仍需要不断探索。
（3）混部适用的技术环境及企业应用的挑战
首先混部适用环境的企业工作负载应该为多样化的，另外其拥有规模的需求，只有拥有流量的规模以及业务的规模，其才有对资源弹性的需求。在此时，资源成本才会成为企业核心的关键点。在没有上规模之前，该技术要解决的核心的问题为业务敏捷负责任，即为其核心的精力在于关注业务需求的快速满足，技术永远为业务发展服务。到了后期，在整个规模上去过后，其会发现资源的成本会在整个企业成本里面上升到一定比例，此时个人需要考虑降本提效。
混部其实为一个系统工程。如果个人需要将硬件的性能发挥到极致，则其是一个从硬件到操作系统、调度及应用架构，都需要进行协同优化。从整个集团的资源利用率提升的阶段出发，如果整体的资源利用率从10%提到30%，则此阶段技术门槛是相对比较低的，此时个人可以简单的通过ask 调度以及基础的混部能力，其就能实现整体负载的提升。个人可以将该阶段定义为一个护佑的阶段，该阶段对于大部分企业而言都为适用的。如果要将混部的水位从30%提高到50%，则其中的挑战仍是较大的。
在其演进过程中，例如其在硬件上的计算、存储与网络其实都进行了很大的升级，在计算上个人需要解决类似于AI workload的高带宽，，其带来了对在线业务干扰的问题。
集团与硬件的厂商进行了一些深度的定制，例如英特尔DRC 内存带宽控制的能力，其也是从场景中打磨出来的。存储中单机隔离的问题难度最大的在io 电路里面，其实直到今天为止，整个io 电路的隔离问题依旧没有得到妥善解决。在硬件系统上，其现在拥有多盆腔的新播出的硬件与技术。
到目前为止，大众依然认为其不足以满足整个混部以及弹性的资源模型。此部分主要是依靠应用架构的改进，比如整体上因为其架构而去掉了本地盘，个人将io 隔离的问题转化成为了一个网络隔离的问题。此些都为全面布置需要在应用测去配合，由此个人才需要将利用率提升。类似的挑战例如在集群中，混部调度本身其实也具有很高的门槛，其基于简单的work load ，类似原来Java标准的工作负载，即为按照4核8g 或者8核16g 标准规格进行调度，由此，其分配问题才相对比较简单。随着混部的workload 垫复燃脱控，其资源规格的多样性把分配问题真正的变成了NP 的问题。要解决好装箱问题，在其中依赖一些较深的、类似于决策智能问题求解的一些算法。另外一部分为混部实际上为一个很大的系统工程，如果个人真正进行使用，则对整个应用系统要求较高，其从基础设施到应用都需要具备全站快速迭代的能力。否则个人同样也很难利用新技术的优化。由此，在整体上，如果为一个初期或者规模不大的场景，其实使用ecs 的弹性基本上即可享受到目前所提及的混部以及弹性的优势。在企业上规模的客户，其随着workload 的提升，需要引起关注点的核心为每一个大规模的ecs 和自身进行混部与买很多小系统的ecs，哪个成本相对更低。初期的门槛其实相对而言不高，当前通过开源其实也将过往混部的犯过的错误通过社区能够赋能给个人。到后期后，个人也认为要进一步提升，个人仍需要拥有一些更深度技术的支持。
