borg 论文于2015年发布，展示了borg从2005年开始的一系列工作和成果.后才有参考google参考borg开源出Kubernetes. borg和Kubernetes相同点是，都是大规模集群管理系统，区别是borg在google管理了所有的机器，包括在线和离线。而目前Kubernetes大多数管理的还是在线场景，离线场景还是hadoop系的天下。 学习 borg 可以更深入了解google的大规模集群管理经验。
特性
- 透明化资源管理和故障处理，使业务能够更专心(注：这一点就类似当今的docker，以及未来的serverless)
- 自身的高可用，运行在上面的应用也能达成高可用(注：和第一个特性其实很类似，都是通过平台蹭提供更多能力，让业务低成本实现高可用)
- 可以将负载轻松得分散到成千上万的节点中(注：开源的k8s想要扩展到这么多节点还是挺麻烦的，要考虑主从同步下，主节点的负载问题。同样的问题会出现在所有的主从模式集群下)
job 分类
- prod : prodcution job . 生产性任务,短时且延迟敏感的请求（从几微秒到几百毫秒不等）.(注:k8s中的pod 概念，似乎就来源于此)。高优先级。比如gmail web 就是prod。 属于prod的任务：google search ,gmail web ,youtube ,google docs.
- non-prod : non-prodcution job . 非生产性任务,运行时间从分钟到天,堆短期的波动不敏感. 低优先级。比如某些批处理任务就是non-prod,资源紧张时，会被kill 让出资源给prod job。
优先级
优先级分为(从高到低)： 监控（monitoring），生产（production），批处理（batch），尽力而为（best effort）（测试或免费程序）
上面的分类中，prod对应的就是监控和生产。
配额
- 在低优先级任务上启用超卖，以提升资源利用率
- 尽管鼓励用户”按需”购买配额，但是用户依然会忍不住超量购买(注：所有资源都是这样，公司内的资源，以及每个人的手机，如果不加硬性的限制，那么就一定会被消耗光)
- 没有提到类似k8s 使用的cfs 调度器
调度
调度就是一堆机器中，选出来一个”合适”的机器，部署相应的job
- 异步调度，job被加入调度器的队列中
- 通过调度器异步扫描队列，如果有足够的资源并且满足job的约束(比如非亲和性)，就将job的task部署到相应的机器上。
- 两种调度算法
- 最优匹配 : 尽可能填满机器，分配时从小到大分配。。（分配过程类似jvm cms 的free-list）
- 最差匹配 : 最小化部署任务的成本，避免负载突刺。可能会造成资源碎片。(注，比如机器上剩下了0.5core cpu,50m 内存，类似jvm mark-sweep中的内存碎片)
- 实际是混合算法（根据实践，调度中会有非常多的约束,导致调度时间比想象上久。比如常见的约束：追求高可用的服务：一个服务在同一个宿主机上最多部署n个节点、追求高性能的服务：服务上下游部署在一个苏主机上；带来的问题：弹性伸缩过程中，必须考虑调度的时间消耗）
从节点状态同步
每个从节点上部署一个borglet 服务(kubelet的亲爹啊),master 定时几秒轮询borglet 获取状态(注:pull 模式，对客户端和服务端都非常友好)。
master可以自发控制频率，避免borglet在master压力高时，继续push数据到master从而压垮master(注:背压的常见解决方案)。
扩展性
主从结构总是会出现瓶颈，borg做了以下方面的扩展以避免出现性能问题
- 拆分调度器和master,增加并行度
- 缓存
- 副本
- 增加线程以改善响应性能
- 分片
- 评分缓存
- 等效评分：按照约束条件做group，而不是针对每一个task单独做评分
- 宽松随机化 ： 严格模式下，需要抓取所有机器的状态来做评分，毕竟抓取间隔需要尽量短，这会导致状态同步和计算成本高。改进为随机抓取节点（注:这是一种类似p2c负载均衡的方式,能大小减少负载的同时，有尽量高的准确率）
可用性
- 如果borglet异常退出，对应机器上的task会继续执行，因为borglet已经挂了，所以task不会被kill，而不会被转移。反而能保证task的可用性
- cell 独立隔离部署，减小爆炸半径，降低误操作的和故障传播几率
- 多副本防止单点故障
资源利用率
borg 的终极目标就是提升google全球机房的资源率，borg给google节约了30%的机器,每年几百万美元(注:2005年的几百万美元)
评估方法
- 方法简单粗暴：不断移除cell中的机器，直到出现问题。
- 使用线上数据来进行仿真
cell 共享
- non-prod 和 prod 共同运行在一个cell中
- 必须共享才能实现资源利用率提升，如果隔离开，需要多30%-50%的机器。prod通常会预留资源，但大多数机器不需要那么多机器。这些空闲的资源可以被non-prod有效利用
大型 cell
- 专门为大型任务和减少资源碎片提供的cell。（注:这就是G1GC和ZGC中的 humongous region，条条大路通罗马）
隔离
- 使用cgroup 来隔离资源。内存带宽或者cpu l3 cache污染都会导致rt出现问题。通过设置优先级，延迟敏感型任务可以挂起其他任务。
- 资源分为可压缩资源(cpu,iops;基于速率)和不可压缩资源(mem,network,disk)。