Architect 201508

2020-03-01 55浏览

  • 1.
  • 2.Docker背后的容器集群管理 从Borg到Kubernetes 微服务架构综述 2015年4月，传闻许久的Borg论文总算出现在了Google Research的页面上。虽然传言Borg作为G家的“老”项目一 直是槽点满满，而且本身的知名度和影响力也应该比不上当年 的“三大论文”，但是同很多好奇的小伙伴一样，笔者还是饶 有兴趣地把这篇“非典型”论文拜读了一番。 微服务架构（Microservice Architect）是一种架 构模式，它提倡将单块架构的应用划分成一组小 的服务，服务之间互相协调、互相配合，为用户 提供最终价值。 多范式编程语言 以Swift为例 Swift即支持面向对象编程范式，也支 持函数式编程范式，同时还支持泛型编 程。Swift支持多种编程范式是由它的目 标决定的。 Oracle专家谈 MySQL Cluster如何支持 200M的QPS Andrew Morgan是Oracle MySQL首席 产品经理。 近日，他撰文介绍了MySQL Cluster如何支持200M的QPS。 创业公司的产品开发 与团队管理 创业公司由于管理层次简单，很少受到官 僚作风的困扰，但也不能想当然地认为万 事大吉，高枕无忧了。其实创业公司也有 创业公司的局限性，这些局限性常常被忽 略，从而影响到产品的开发。 架构师 8月刊 联系我们 本期主编 郭蕾 提供反馈 feedback@cn.infoq.com 流程编辑 丁晓昀 商务合作 sales@cn.infoq.com 发行人 内容合作 editors@cn.infoq.com 霍泰稳
  • 3.马晓宇 卷首语 环信CTO，18年的老程序员,先后从事过IC设 计软件，短信网关、电信网管、中间件、手 机操作系统和手机App的研发 。 扁平的组织结构 技术团队的管理目标是打造高效的自组织团 队，也就是老子提出的“无为而治”。做为 一个从业 20 年的老程序员，从自身出发，我 深切知道程序员喜欢什么样的管理方式，喜 欢怎样的团队氛围。在环信，我们希望顺其 自然，发挥工程师的热情和创造力，每个成 员都能做到自我实现，最终整个团队被业界 认同。 扁平的组织结构 我们研发团队有 50 多人，没有一个专门的管 理岗位。作为 CTO，我的大多数时间在技术 上面，团队负责人会承担一部分管理工作， 但更多是靠工程师的自我驱动，自我管理。 严格的个人成长 Work for fun, constantly improve, and big rewards ahead. 在团队的宽松氛围中，其实 我们对工程师的个人成长要求很高：对年轻 工程师我们破格使用，希望尽快成长；对高 级工程师 , 要求技术深度，成为某个方面的 专家；对技术负责人，要求更多业界交流， 才能打造技术领先产品，同时建立自己的社 区影响力。 美好的远程办公 年轻人希望到世界各地体验生活；有小孩的 技术中坚天天忧虑北京的雾霾想着移民；40 多岁的同事希望每年回老家工作一段时间陪 陪父母。面对这些美好的期待，我们在不断 结果导向的日常管理 尝试协同工具和管理方法来提高团队内部配 Google 只招聘最聪明的人，这些人能很好的 合、团队间协作，及团队和客户的沟通。希 管理个人时间。做为创业公司，我们招聘最 望一两年内能成为一支高效远程开发团队。 努力的人，因为这样的工程师很珍惜时间和 到那时，团队成员每年回来参加 InfoQ 大会 成长的机会。团队里有些人每天下午才出现， 学习最新技术，也做为每年的团队聚会。 有些同事在备战马拉松比赛，有酷爱高山滑 雪的，也有业余足球运动员。努力工作，精 无为而无所不为，希望大家一起探索，把越 彩生活，结果导向是我们日常管理的原则。 来越多的团队，打造成工程师的“乐土”。
  • 4.Docker背后的容器集群管理 从Borg到Kubernetes 作者 张磊 2015年4月，传闻许久的Borg论文总算出现在了Google Research的页面上。虽然 传言Borg作为G家的“老”项目一直是槽点满满，而且本身的知名度和影响力 也应该比不上当年的“三大论文”，但是同很多好奇的小伙伴一样，笔者还是 饶有兴趣地把这篇“非典型”论文拜读了一番。 1. Borg在讲什么故事 都是比较有限的。 其实，如果这篇论文发表在两 据中心操作系统）概念的炙手 可热。容器技术令人咋舌的进 三年前，Borg 的关注度恐怕真 不过，一旦我们把 Borg 放到当 化速度很快就将一个曾经并不 没有今天这么高。作为一篇本 前这个时间点上来重新审视， 需要被大多数开发人员关注的 质上是关于数据中心利用率的 这篇本该平淡的论文就拥有了 问题摆到了台面： 半工程、半研究性的成果，这 众 多 深 层 意 义。 当 然， 这 一 个领域的关注人群来自大厂的 切 绝 非 偶 然， 从 2013 年 末 以 我们应该如何高效地抽象和管 运维部以及系统部的技术同僚 Docker 为代表的容器技术的迅 理一个颇具规模的服务集群？ 可能要占很大的比例。而对于 速兴起，2014 年 Google 容器管 绝大多数研究人员，普通开发 理 平 台 Kubernetes 和 Container 这正是 Borg 全力阐述的核心问 者，甚至包括平台开发者而言， Engine 的强势扩张，再到如今 题。 Borg 论文本身的吸引力应该说 由 Mesos 一手打造的 DCOS（数 4 架构师 2015年 8月刊
  • 5.推荐文章 Article 说得更确切一点，当我们逐步 一个面向应用的产物。 是什么？ 接纳了以容器为单位部署和运 行应用之后，运维人员终于可 那么它需要接管和运行的作业 什么叫面向应用？ 是 Job。 以从无休止的包管理，莫名其 妙的环境差异，繁杂重复的批 就是以应用为中心。系统原生 处理和任务作业的中稍微回过 为用户提交的制品提供一系列 Borg 文章里对 Job 的定义很简 一点神来，开始重新审视自己 的上传、构建、打包、运行、 单， 就 是 多 个 任 务（Task） 的 手中的物理资源的组织和调度 绑定访问域名等接管运维过程 集 合， 而 所 谓 Task 就 是 跑 在 方式：即我们能不能将容器看 的功能。这类系统一般会区分” Linux 容器里的应用进程了。这 作传统操作系统的进程，把所 应用“和”服务“，并且以平 样看起来 Job 是不是就等同于 有的服务器集群抽象成为统一 台自己定义的方式为”应用“（比 Kubernetes 里的 Pod（容器组） 的 CPU、内存、磁盘和网络资 如 Java 程序）提供具体的”服 呢？ 源，然后按需分配给任务使用 务“（ 比 如 MySQL 服 务 ）。 呢？ 面向应用是 PaaS 的一个很重要 其 实 不 然。Job 映 射 到 的特点。 Kubernetes 中的话，其实等同于 所 以， 作 为《Docker 背 后 用户提交的“应用”，至于这 的 技 术 解 析》 系 列 文 章 的 特 另 一 方 面，Borg 强 调 的 是 规 个应用运行了几个副本 Pod， 别 篇， 笔 者 将 和 读 者 一 起 从 模二字。文章通篇多次强调了 每个 Pod 里又运行着哪些容器， Borg 出发，结合它的同源项目 Google 内部跑在 Borg 上的作业 用户并不需要关心。用户只知 Kubernetes 中尝试探索一下这个 数量、以及被 Borg 托管的机器 道，我们访问这个服务，应该 问题的答案。 数量之庞大。比如我们传统认 返回某个结果，就够了。 知上的“生产级别集群”在文 2. Borg的核心概念 同大多数 PaaS、云平台类项目 宣称的口号一样，Borg 最基本 的出发点还是“希望能让开发 者最大可能地把精力集中在业 务开发上”，而不需要关心这 些代码制品的部署细节。不过， 另一方面，Borg 非常强调如何 对一个大规模的服务器集群做 出更合理的抽象，使得开发者 可以像对待一台 PC 一样方便 地管理自己的所有任务。这与 Mesos 现 在 主 推 的 观 点 是 一 致 的， 同 时 也 是 Borg 同 PaaS 类 项目比如 Flynn、Deis、C l o u d Foundry 等区别开来的一 章中基本上属于 Tiny 的范畴， 举 个 例 子， 因 为 高 可 用 等 原 而 Borg 随 便 一 个 Medium 的 因， 用 户 常 常 会 在 Kubernetes 计算单元拿出来都是一家中大 里创建并启动若干个一模 型 企 业 数 据 中 心 的 规 模（10K 一 样 的 Pod（ 这 个 功 能 是 通 个机器）。这也应证了淘宝毕 过 Kubernetes 的 Replication 玄老大曾经说过的：“规模绝 Controller 实现的）。这些一模 对是推动技术发展的最关键因 一样的 Pod“副本”的各项配 素”。 置和容器内容等都完全相同， 他们抽象成一个逻辑上的概念 Borg 里 服 务 器 的 划 分 如 下： 就是 Job。 Site = 一组数据中心（Cluster）， Cluster = 一组计算单元（Cell）， 由 于 Job 是 一 个 逻 辑 上 的 概 Cell = 一组机器。 其中计算单 念，Borg 实 际 上 负 责 管 理 和 元（Cell）是最常用的集群类别。 调度的实体就是 Task。用户的 submit、kill、update 操 作 能 够 2.1 Job，Task 个 主 要 特 征： 即 Borg， 以 及 既然 Borg 不关心“应用”和“服 Kubernetes 和 Mesos 等，都不是 务”的区别，也不以应用为中心， 架构师 2015年 8月刊 触 发 Task 状 态 机 从 Pending 到 Running 再到 Dead 的的转移， 这一点论文里有详细的图解。 5
  • 6.推荐文章 Article 值 得 一 提 的 是， 作 者 还 强 调 了 保证每个进程不会挤占其他进程 它类似的计算任务。它们的执行 Task 是通过先 SIGTERM，一定 的 资 源， 它 们 还 能 作 为 一 个 整 往往需要持续一段时间，但是最 时间后后再 SIGKILL 的方式来被 体 进 行 管 理 和 调 度。 如 果 没 有 终 都 会 停 止， 用 户 需 要 搜 集 并 杀死的，所以 Task 在被杀死前有 Kubernetes 的 话，Pod 可 以 使 用 汇总这些 job 计算得到的结果或 一定时间来进行“清理，保存状 “Docker in Docker”的办法来模 者是 job 出错的原因。所以 Borg 态，结束正在处理的请求并且拒 拟， 即 使 用 一 个 Docker 容 器 作 在 Google 内部起到了 YARN 和 绝新的请求”的工作。 为 Pod，真正需要运行的进程作 Mesos 的角色，很多项目通过在 为 Docker 容 器 嵌 套 运 行 在 这 个 Borg 之上构建 framework 来提交 Pod 容器中，这样它们之间互不 并执行任务。Borg 里面还指出， 干涉，又能作为整体进调度。 batch job 对服务器瞬时的性能波 2.2 Alloc Borg 中，真正与 Pod 对应的概念 是 Alloc。 Alloc 的主要功能，就是在一台机 器上“划”一块资源出来，然后 一组 Task 就可以运行在这部分资 源上。这样，“超亲密”关系的 Task 就 可 以 被 分 在 同 一 个 Alloc 里，比如一个“Tomcat 应用”和 它的“logstash 服务”。 Kubernetes 中 Pod 的设计与 Alloc 如 出 一 辙： 属 于 同 一 个 Pod 的 Docker 容 器 共 享 Network Namepace 和 volume， 这 些 容 器 使用 localhost 来进行通信，可以 动 是 不 敏 感 的， 因 为 它 不 会 像 另外，Kubernetes 实际上没有 Job LRS 一样需要立刻响应用户的请 这 个 说 法， 而 是 直 接 以 Pod 和 求，这一点可以理解。 Task 来抽象用户的任务，然后使 用 相 同 的 Label 来 标 记 同 质 的 比较有意思的是，Borg 中大多数 Pod 副本。这很大程度是因为在 LRS 都会被赋予高优先级并划分 Borg 中 Job Task Alloc 的做法里， 为生产环境级别的任务（prod）， 会出现“交叉”的情况，比如属 而 batch job 则会被赋予低优先级 于不同 Job 的 Task 可能会因为“超 （non-prod）。在实际环境中， 亲密”关系被划分到同一个 Alloc prod 任务会被分配和占用大部分 中，尽管此时 Job 只是个逻辑概 的 CPU 和内存资源。正是由于 念，这还是会给系统的管理带来 有了这样的划分，Borg 的“资源 很多不方便。 抢占”模型才得以实现，即 prod 任 务 可 以 占 用 non-prod 任 务 的 2.3 Job的分类 共享文件，任何时候都会被当作 Borg 中的 Job 按照其运行特性划 一个整体来进行调度。 分 为 两 类：LRS（Long Running Service）和 batch jobs。 所以，Alloc 和 Pod 的设计其实都 是在遵循“一个容器一个进程” 上述两种划分在传统的 PaaS 中也 的模型。经常有人问，我该如何 很常见。LRS 类服务就像一个“死 在 Docker 容 器 里 跑 多 个 进 程？ 循 环”， 比 如 一 个 Web 服 务。 其 实， 这 种 需 求 最 好 是 通 过 类 它往往需要服务于用户或者其它 似 Pod 这种方法来解决：每个进 组件，故对延时敏感。当然论文 程都跑在一个单独的容器里，然 里 Google 举 的 LRS 例 子 就 要 高 后这些容器又同属于一个 Pod， 大 上 不 少， 比 如 Gmail、Google 共 享 网 络 和 指 定 的 volume。 这 Docs。 样既能满足这些进程之间的紧密 协作（比如通过 localhost 互相访 而 batch jobs 类 任 务 最 典 型 的 就 问，直接进行文件交换），又能 是 Map-Reduce 的 job， 或 者 其 6 架构师 2015年 8月刊 资源，这一点我们后面会专门说 明。 对比 Kubernetes，我们可以发现 在 LRS 上定义上是与 Borg 类似 的，但是目前 Kubernetes 却不能 支 持 batch job： 因 为 对 应 的 Job Controller 还 没 有 实 现。 这 意 味 着当前 Kubernetes 上一个容器中 的 任 务 执 行 完 成 退 出 后， 会 被 Replication Controller 无 条 件 重 启。Kubernetes 尚 不 能 按 照 用 户 的需求去搜集和汇总这些任务执 行的结果。 2.4 优先级和配额
  • 7.推荐文章 Article 前面已经提到了 Borg 任务优先 优先级最高的任务则被 Borg 认 级的存在，这里详细介绍一下优 为是享有无限配额的。 先级的划分。 与 Kubernetes 类 似 的 是，Borg Borg 中把优先级分类为监控级、 的配额也是管理员静态分配 生产级、批任务级、尽力级（也 的。Kubernetes 通 过 用 户 空 间 叫测试级）。其中监控级和生产 （namespace）来实现了一个简单 级的任务就是前面所说的 prod 任 的多租户模型，然后为每一个用 务。为了避免在抢占资源的过程 户空间指定一定的配额，比如： 中出现级联的情况触发连锁反应 （A 抢占 B， B 抢占 C， C 再抢占 D） ， Borg 规 定 prod 任 务 不 能 互 相 抢 占。 如果说优先级决定了当前集群里 的任务的重要性，配额则决定了 任务是否被允许运行在这个集群 上。 2.5 名字服务和监控 与 Mesos 等 不 同，Borg 中 使 用的是自家的一致性存储项目 Chubby 来作为分布式协调组件。 这其中存储的一个重要内容就是 为每一个 Task 保存了一个 DNS 名字，这样当 Task 的信息发生变 化时，变更能够通过 Chubby 及 时 更 新 到 Task 的 负 载 均 衡 器。 这同 Kubernetes 通过 Watch 监视 001 002 003 004 005 006 007 008 009 010 011 012 013apiVersion:v1beta3kind:ResourceQuotametadata:name:quotaspec:hard:cpu:“20”memory:10Gipods:“10” replicationcontrollers:“20”resourcequotas:“1”services:“5” 尽管我们都知道，对于容器来说， CGroup 中的配额只是一个限制 到这里，我们有必要多说一句。 而并非真正割据的资源量，但是 像 Borg、Kubernetes 以 及 Mesos 我们必须为集群设定一个标准来 这类项目，它们把系统中所有需 保证提交来任务不会向集群索要 要对象都抽象成了一种“资源” 过分多的资源。Borg 中配额的描 保存在各自的分布式键值存储 述方法是：该用户的任务在一段 中，而管理员则使用如上所示的 时间内在某一个计算单元上允许 “资源描述文件”来进行这些对 请求的最大资源量。需要再次重 象的创建和更新。这样，整个系 申，配额一定是任务提交时就需 统的运行都是围绕着“资源”的 要验证的，它是任务合法性的一 增删改查来完成的，各组件的主 部分。 循环遵循着“检查对象”、“对 象变化”、“触发事件”、“处 既 然 是 配 额， 就 存 在 超 卖 的 情 理事件”这样的周期来完成用户 况。在 Borg 中，允许被超卖的是 的请求。这样的系统有着一个明 non-prod 的任务，即它们在某个 显的特点就是它们一般都没有引 计算单元上请求的资源可能超出 入一个消息系统来进行事件流 了允许的额度，但是在允许超卖 的协作，而是使用“ectd”或者 的情况下它们仍然有可能被系统 “Zookeeper”作为事件系统的核 接受（虽然很可能由于资源不足 心部分。 etcd 中 Pod 的信息变化来更新服 务代理的原理是一样的，但是由 于使用了名为“Service”的服务 代理机制（Service 可以理解为能 够自动更新的负载均衡组件）， Kubernetes 中默认并没有内置名 字服务来进行容器间通信（但是 提供了插件式的 DNS 服务供管 理员选用）。 在监控方面，Borg 中的所有任务 都 设 置 了 一 个 健 康 检 查 URL， 一旦 Borg 定期访问某个 Task 的 URL 时发现返回不符合预期，这 个 Task 就会被重启。这个过程同 Kubernetes 在 Pod 中 设 置 health_ check 是一样的，比如下面这个 例子。 这种做法的一个小缺点是 Task 中 服务的开发者需要自己定义好这 些 /healthzURL 和对应的响应逻 辑。当然，另一种做法是可以在 容器里内置一些“探针”来完成 很多健康检查工作而做到对用户 的开发过程透明。 而暂时进入 Pending 状态）。而 架构师 2015年 8月刊 7
  • 8.推荐文章 Article 001apiVersion:v1beta3 002kind:Pod 003metadata:004name:'>name: