此文根据【QCon高可用架构群】分享内容，由群内【编辑组】志愿整理，转发请注明出处。
彭哲夫，芒果TV平台部核心技术团队负责人
主要负责 Docker 和 Redis Cluster 相关的基础设施开发。
前豆瓣App Engine核心主程，前金山快盘核心主程。
在系统工程方面经验丰富。彭首席，知识丰富，功底深厚，语言幽默风趣，知乎上、简书上有不少彭首席的精彩大作和回复。
我今天主要是想讲讲最近几年我做平台的一些思考，并介绍一下目前我做的这个基于 Docker 的项目的一些技术细节，以及为什么我们会那么做。
豆瓣时期
我在豆瓣工作的时候，主要是写 Douban App Engine 。大体上它和 GAE 类似，有自己的 SDK 和服务端的 Runtime。因为是对内使用，所以在 SDK 和 Runtime 实现细节上，我们并没有像 GAE 那样做太多的 Mock 来屏蔽一些系统层面的 API（比如重写 OS 库等）。对于一家大部分都是使用 Python 的公司而言，我们只做了 Python 的 SDK 和 Runtime，我们基于 Virtualenv 这个工具做了运行时的隔离，使得 App 之间是独立分割的。但是在使用过程中，我们发现有些运行时的隔离做得并不是很干净，比如说我们自己在 Runtime 使用了 werkzeug 这个库来实现一些控制逻辑，然后叠加应用自身 Runtime 的时候可能因为依赖 Flask ，因此也安装了另一个 werkzeug 库，那么到底用哪个版本，就成了我们头疼的一个问题。
一开始我们考虑修改 CPython 来做这件事，包括一些 sys.path 的黑魔法，但是发现成本太高，同时要小心翼翼的处理依赖和路径关系，后面就放弃使用这种方法了，采用分割依赖来最小化影响，尽量使得 Runtime 层叠交集最小。
然后 App Runtime 和 AppServer Runtime 就成了这样：
（插图1）
进入 2013 年，Docker 在 3 月默默地发布了第一个版本，我们开始关注起来。紧接着我就离职出发去横穿亚洲大陆了，一路上提着 AK 躲着子弹想着 Docker（大雾）并思考如何通过它来做一个或者改造一个类似 DAE 一样的 PaaS，直到我回国。机缘巧合之下，我加入到芒果TV，隶属于平台部门，有了环境便开始尝试我在路上产生的这些想法。
芒果TV 的 Nebulium Engine
加入芒果TV之后，一开始我实现了类似 DAE 架构的一个新的 PaaS —— Nebulium Engine（a.k.a NBE），只不过运行时完全用 Docker 来隔离，控制层移到了 Container 之外。除此之外，整体架构上和 DAE 并未有太多差别。
同时我遇到了一个很是头疼的问题——那就是在芒果 TV ，我们并没有一个大一统的强势语言，我们必须把 Runtime 的控制权完全交给业务方去决定。综合大半年线上运行结果来看，在资源管理和工作流整合上面，其实 NBE 做得并不是很好。
原因很多，一方面是基础设施和豆瓣比实在太糟糕，如果说豆瓣是21世纪互联网的话，我们现在还停留在19世纪的传声筒，另外一方面五花八门的语言都需要支持，放开 Runtime 之后，对资源竞争和预估我们是完全没有任何能力去做的，恰恰业务方又希望平台能 hold 住这些事。
举个例子，Python GIL 限定在非多进程模式下顶多吃死一个核，然后隔壁组上了个 Java 的 Middleware……然后我们就看到 Python 业务方过来哭天喊地了。
在这个时期，我们的架构是这样的：
（插图2）
于是在挫折的 2014 年底，我们重新回顾了一遍 Borg 和 Omega 相关的信息，开始了第二代 NBE ，也就是今天的主角—— Project Eru ——的开发。这一次我们抛弃了以前做一个 PaaS 的思路，而是决定去实现一个类似于 Borg 一样的服务编排和调度平台。
Project Eru
有了第一代 NBE 的开发经验，我们开发速度明显快了很多，第二周的时候就已经有了一个大体上能用的 demo。到目前为止，Eru 平台可以混编 Offline 和 Online 的服务（binary/script），对于资源尤其是 CPU 资源实现了自由维度（0.1，0.01，0.001等）的弹性分配，使用 Redis 作为数据总线对外进行消息发布，动态感知集群所有的 Containers 状态并监控其各项数据等。基于 Docker 的 Image Layer 特性，我们把其和 Git version 结合起来，实现了自动化的 build/test 流程，统一了线上部署环境。同时顺便解决了 Runtime 的污染问题，使得业务能快速的扩容/缩容。
然后，我们的架构变成了这个样子：
（插图3）
看上去变化不大，实际上里面的设计和反馈回路什么的和第一代已经完全不一样了。
业务层方面在逻辑上我们使用了类似于 Kubernetes 的 Pod 来描述一组资源，使得 Eru 有了 Container 的组资源控制的能力。但是和 Kubernetes 不同的是，我们 Pod 仅仅是逻辑上的隔离，主要用于业务的区分，而实际的隔离则基于我们的网络层。对于 Dockefile，我们不允许业务方自行写 Dockerfile。通过标准化的 App.yaml 统一 Dockerfile 的生成，通用化的 Entrypoint 则满足了业务一份代码多个角色的复用和切换，使得任何业务几乎都可以完全无痛的迁移上来。
另外我不知道大家发现没有，之前第一代 NBE 是个完整的闭环，一个业务有生到死都有 NBE 本身各个组件的身影。但是在第二代 NBE 中我们放弃了以前考虑的完整闭环设计。之前实现的 NBE 第一代打通了项目整个生命周期的每一个环节，但实际上落地起来困难重重，并且使得 Dot（Master）的状态太重没法 Scale Out，因为是它是单点部署，可靠性上会糟糕一些。所以 Eru 中每一个 Core 都是一个完整的无状态的逻辑核心，使得其可以 Scale Out 的同时可靠性上也比 NBE 第一代要健壮得多。所以第三幅图你们可以看到，我画了好多个 Eru-Core 来表明它是个可以 Scale out 的幺蛾子。
因此在这个体系下，我们推荐业务根据自身业务特性，通过监控自身数据，订阅 Eru 广播，调用 Eru-Core 的 API ，实现复杂的自定义的部署扩容等操作。我们并不会去强行干涉或者建立一系列规则去限定这些事情。这也是它不属于 PaaS 的原因。
细节
大体介绍完这个项目之后，我来说说实现细节。主要有几个方面，首先是项目部署结构总体技术选择，然后是网络、存储、资源分配、服务发现等等。
首先 Eru 主要分 Core 和 Agent 两个部分。Agent 和 Core 并没有很强的耦合，通过 Redis 来交互信息（依赖于我们自己的 Redis Cluster 集群技术），主要用来汇报本机 Containers 情况和做一些系统层面的操作（比如增加减少 veth）。Core 则是刚才所说无状态的逻辑核心，控制所有的 Docker Daemon 并且和 Agent 进行控制上的交互。
容器内存储上，我们目前大部分使用了 Devicemapper 小部分是 Overlay，因此我们有的 Docker Host 上使用了内核 3.19 的内核，并外挂了一个 MooseFS 作为容器间数据共享的卷。考虑到 Docker 本身大部分时间是版本越新越靠谱（但是幺蛾子的 1.4 是个杯具），因此基本上我们使用的都是最新版的 Docker。网络方面对比了若干个解决方案之后，在隧道类（Weave/OVS等）和路由类（MacVLAN/Calico等）中我们选择了后者中的 MacVLAN。
下面是我当时做的方案对比图：
(插图4)
网络
既然说到网络，那我就从网络开始说起，为啥当时我们会选择 MacVLAN 相对而言这个比较简单和冷门的方案？
相比于 Route 方案，Tunnel 方案灵活度会更高，但是会带来两个问题：
性能，比如 Weave，通过 UDP 封装数据包然后广播到其他跑着 Weaver 的 Host，封包解包的过程就会带来一些开销。另外大多数 OVS 方案性能其实都不太乐观，之前和某公司工程师交流过，大体上会影响 20%~30% 左右的吞吐性能。（所以他们都用上 FPGA了……）
Debug 困难。Tunnel 的灵活是构建在 Host 间隧道上的，物理网络的影响其实还没那么大，但是带来一个弊端就是如果现在出了问题，我怎样才能快速的定位是物理链路还是隧道本身自己的问题。
而 Route 方案也会有自己的问题：
Hook，Route 方案需要 Container Host 上有高权限进程去 Hook 系统 API 做一些事情。
依赖于物理链路，因此在公有云上开辟新子网做 Private SDN 使得同类 Containers 二层隔离就不可能了。
如果是基于 BGP 的 Calico，那么生效时间差也可能带来 Container 应用同步上的一些问题。
所以最后我们选择了 MacVLAN，一来考虑到我们组人少事多，隧道类方案规模大了之后 Debug 始终是一件比较麻烦的事情，二来 MacVLAN 从理解上和逻辑上算是目前最简单的一个方案了。
使用这种方案后，我们可以很容易在二层做 QoS，按照 IP 控流等，这样避免了使用 tc（或者修改内核加强 tc）去做这么一件事件，毕竟改了内核你总得维护对吧。因为是完全独立的网络栈，性能上也比 Weave 等方案表现得好太多，当然还有二层隔离带来的安全性。
某种意义上 MacVLAN 对 Container 耦合最小，但是同时对物理链路耦合最大。在混合云上，无论是 AWS 也好还是青云亦或者微软的 Azure，对二层隔离的亲和度不高，主要表现在不支持自定义子网上。因此选取这个方案后，在混合云上是没法用的。所以目前我们也支持使用 Host 模式，使得容器可以直接在云上部署，不过这样一来在云上灵活度就没那么高了。
存储
容器内存储我们目前对这个需求不是太高，小部分选取 Overlay 主要是为了我们 Redis Cluster 集群方案上 Eru 之后 Redis 的 AOF 模式需要，目前来看情况良好。考虑 Overlay 也是因为来自百度的一哥们告诉我们这货是 Container 杀人越货必备，尤其是小文件，所以我们的另外一个工程师也做了一个测试。
（插图5）
在 Devicemapper 和 Overlay 的性能对比上，大量小文件持续写 Overlay 的性能要高不少。然后我们就小部分上 Overlay 了。对于我们现有的 Redis Cluster 集群，我们采用内存分割的方式部署 Container。一个 Container 内部的 Redis 限制在 Host 总内存数/ Container 数这么大。举个例子，我们给 Redis 的 CPU 分配为 0.5 个，一台机器 24 Core 可以部署 48 个 Container，而我们的 Host 申请下来的一般只有 64G，因此基本上就是 1G 左右一个 Redis Container 了。
这样会有2个好处：
AOF 卡顿问题得到缓解。
数据量或者文件碎片量远远达不到容器内存储的性能上限，意外情况可控。
在这个量级下，其实 DM 和 Overlay 还是差不多的
当然如果 instance 内存上限提高了，那么 Overlay 的优势就会很明显了。
Scale
扩容和缩容，我们更加希望是业务方去定制这个组件去做。我们所有的容器基础监控数据均存储在了 influxdb 上面，虽然现在来看它不是蛮靠谱（研究 Open-falcon 中）。同时业务方也可以写自己想监控的一些数据按照自己喜欢的姿势到任何地方，然后通过读取这些数据，判断并决策，最后调取 Core 的 API 去干扩容和缩容。我们在第一代 NBE 中是我们自己定义了一套扩容缩容的规则，主要是效果不好，业务有时候要监控的并不是什么 CPU、MEM、IO，可能就是某个请求的耗时来决定是否扩容缩容。
因此 Eru 中，我们完全放开了权限。
核心宗旨就是“谁关心，谁做”
资源分配和集群调度
资源的分配和集群调度，我们在第二代 NBE 中采取了以CPU 为主，MEM 半人工审核机制。磁盘 IO 暂时没有加入到 Eru 豪华午间套餐，而流量控制交给了二层控制器。之所以这么选择主要是因为考虑到一个机房建设成本的时候，CPU 的成本是比较高的，因此以 CPU 为主要调度维度。在 QCon 上和腾讯的讲师聊过之后，关于 CPU 的利用率上我们也实现了掰开几分用这么个需求，当然，我们是可以按照 Pod 来设置的，我们不会局限于 0.1 这个粒度，0.01或者 0.5 都可以。但是内存方面明显我们的研发力量表示改内核并自行维护还不如在 520 陪女朋友看电影，所以我们没有实现腾讯讲师说的 softlimit subsystem 。主要还是通过数据判断 Host 内存余量和在上面 Container 内存使用量/申明量对比来做旁路 OOM Kill。
以 CPU 为主维度的来调度上，我们把应用申请 CPU 的数目计算为两类，一类称之为独占核，一类为碎片核。一个 Container 有且仅有一个碎片核，比如申请为 3.2 个 CPU 的话（假定一个 Cpu 分为 10 份），我们会通过 CpuSet 参数设定 4 个核给这个 Container，然后统一设定 CpuShare 为 1024*2。其中一个核会跟其他 5个 Container 共享，实现 Cpu 资源的弹性。
目前我们暂不考虑容器均匀部署这么个需求，因为我们对应的都是一次调度几台甚至几十台机器的情况，单点问题并不严重。
其实主要还是懒……
所以在应用上线时，会经过这些步骤：
申报内存最大使用量和单个 Container CPU 需求。比如 1G 1.3个 CPU。
请求在那个 Pod 上部署（权限验证）
Core 计算 Pod 中资源是否满足上线需求（CPU 申明 * 上线数目，当然这其中算法就复杂了，并不是一个简单乘的关系）。
足够的话开始锁定 CPU 资源，调度 Host 上的 Docker Daemon 开始部署。
这个 By Core 的模型当然也会带来一些浪费，比如对一些不重要的业务。
因此我们加入了一个 Public Server 的机制，不对机器的 CPU 等资源做绑定，只从宏观的 Host 资源方面做监控和限制。使得 Eru 本身可以对服务进行降级操作，目前我们主要用 Public Server 来跑单元测试和镜像打包。
服务发现和安全
上线完容器后，那么接下来要考虑的就是服务发现和安全问题了，我们把控制权交给了业务方和运维部门。一般情况下同类 Container 将会在同一个子网之中（就是依靠 SDN 的网络二层隔离，一组 Container 理论上都会在一个或者多个同类子网中），调用者接入子网即可调用这些 Container。同时我们也把防火墙策略放到了二层上，保证其入口流量安全。因而整体上，对于业务部门而言，服务基本上说一个完整的黑箱（组件），他们并不需要关心服务的部署细节和分布情况，他们看到的是一组 IP （当然使用内网 DNS 的话会更加透明），同一子网内才有访问权限，直接调用就完了。我们认为一个自建子网内部是安全的。
另外我们基于 Dnscache 和 Skydns 构建了可以实时生效的内网 DNS 体系，分别部署在了我们现有的三个机房里面。业务方可以自行定义域名用来描述这个服务（其实也是 Eru App），完全不需要关心服务背后的物理链路物理机器等，实现了线上的大和谐。
举个例子
目前我们 Redis Cluster 有 400个 instance，10个集群，按照传统方式部署。每一次业务需求到我们这边之后我们需要针对业务需求调配服务器，初始化安装环境，并做 instance 部署的操作。在我们完成 Redis instance Dockerize 之后，Redis Cluster Administrator 只需要调取 API biu 一个最小集群，交付子网入口 IP 即可（就是我们的 Proxy 地址）。遇到容量不足则会有对应的 Redis Monitor 来自动调用 Eru API 扩容，如果过于清闲也能非常方便的去缩容。现在已经实现了秒级可靠的 Redis 服务响应和支撑。
此外我们另一个服务也打算基于这一套平台来解决自动扩容问题。通过 Eru 的 Broadcasting 机制结合 Openresty 的 lua 脚本动态的更新服务的 Upstream 列表，从而使得我们这样平时 500 QPS 峰值 150K QPS 的业务不再需要预热和准备工作，实现了无人值守。
总结
总的来说，我们整个 Docker 调度和编排平台项目 Eru 的设计思路是以组合为主，依托于现有的 Redis 解决方案，通过“消息”把各个组件串了起来，从而使得整个平台的扩展性和自由度达到我们的需求。除了一些特定的方法，比如构建 Image，其他的诸如构建 Dockerfile，如何启动应用等，我们均不做强一致性的范式去规范业务方/服务方怎么去做，当然这和我们公司本身体系架构有关，主要还是为了减少落地成本。毕竟不是每个公司业务线都有能力和眼界能接受和跟上。
最后我们现在主要在搞 Redis instance Dockerize 这么一件事，又在尝试把大数据组 Yarn task executor docker 化。在这个过程中我们搞定了 sysctl 的参数生效，容器内权限管理等问题，那又是另外一个故事了……我们计划今年年末之前，业务/服务/离线计算 3个方向，都会开始通过 Eru 这个项目构建的平台开始 Docker 化调度和部署，并对基于此实现一个 PaaS。
P.S. 所有代码均公开在了 github.com/HunanTV 里面，欢迎大家围观。
Q&A
Q1：首先是已有平台迁移到Docker过程中，有没有遇到过阻力，应用适配成本高么，能否分享下典型问题和阻力？
记得我说过 NBE 第一代就是因为完整闭环落地困难所以我们才决定做 Eru 的吧。
我们是在14年开始做这件事的，当时对 Docker 的看法其实还不是很成熟。一方面业务方有很多的顾虑，另一方面我们是 AWS 大客户了，为毛要用 Docker，直接虚机起啊。
然后呢，NBE 第一代是一个纯种 PaaS 去做的，那么自然有强制性的范式和规则要求业务方遵守，其中我这边因为 DAE 带来的一些经验，比较推崇与服务拆分和微服务化。
但业务方觉得我流量现在都快撑不住了，还拆分，所以很多那种一份代码按照启动命令不同来实现线上角色的切换。
其实整体上 NBE 第一代只需要增加一个 App.yaml 就能使得大部分业务直接 Docker 化。
但是就是因为我们两方在这个业务代码角色和拆分上有重大矛盾，导致落地阻力非常大。以至于我本组的人都直接参与业务组开发里面去了。最后总结到这写现状之后，我们得出这么几个结论：
尽可能的先满足业务，再推动重构（Eru 支持一份代码多个角色）
尽可能的降低自身平台耦合，服务发现安全交给上层去做（Eru 的消息广播机制）
对于新技术的落地，不要先从制定规范开始做起，尽可能的猥琐的勾引他们落地后再去制定规范（目前平台架构部基于 Eru 在做芒果TV 自己的 PaaS）
Q2： docker平台上有没有推荐的监控系统，监控数据存储中InfluxDB上面，有没有遇到过坑？
cAdvisor 是 Google 出的一个监控 Agent，我们瞄了一眼代码后决定写到自己的 Agent 中整合进去。
说到这个其实技术细节和有意思的事情就多了，两周前我还在看 libcontainer 的代码。
首先，cAdvisor 早期的实现里面，是通过 libcontainer 中的一个 struct 读取的 container 基础信息。
但是，libcontainer 经过一次重构之后，那个 struct 没了……所以 cAdvisor 自行维护了一个版本的 libcontainer。
之前，我翻代码之后，认为 libcontainer.cgroups/fs 下面的 Manager 可以来做这件事件。但是会出问题，如果直接调用 libcontainer/cgourps/fs 下的 Manager 的话，会产生一个新的 cgroups profile，覆盖掉通过 Docker api 启动 container 的配置，导致某些设备不可读，举个例子 /dev/urandom 变为不可读状态，影响某些语言中的 random 包。
所以，目前我们自己的实现是直接通过 libcontainer 载入 /var/lib/docker/execute/native 这个目录，直接读取容器信息后找到这些 cgroups 状态文件来生成 influxdb 所需要的数据。
说到 InfluxDB 我觉得可以开一个吐槽大会了……
InfluxDB 0.88 目前可以找到的最后一个 stable 版本，集群功能基本是废的，同时会有内存泄露和丢数据的问题……
而且我们还修过他们 API 的一些边界条件问题，但是发到 InfluxDB组之后他们要我们不要管了，直接等 0.9。
然而……InfluxDB 的官网本来写的是 0.9 stable将会在4月发布……
现在已经到了 coming soon，同时 master 里面的 rc 已经到了 35还是多少来着了……
对于 0.9 rc 而言，数据格式聚合函数和 0.88 已经有了很大的不同，举个例子，derivative 这个聚合函数也就是前几天才合入的。并且 rc 之间的落到磁盘数据并不通用，因此我们经常遇到升级后 influxdb 无法启动的问题，只好清理数据。
目前因为实现问题，我们在暂时还是用 InfluxDB 但只保证一周数据有效性（其实如果不升级可以保持很久）。
同时我们在考虑第二方案，就是我前同事 laiwei 来总团队在小米大规模铺的 open-falcon 方案。
Q3:申请碎片核，对性能是否有影响相对于整数核？
对于这个问题，其实 cgroups 是这样的一个逻辑；假设一个container 有3个 CPU，其中一个共享核设定了 20% 的使用量，
那么在共享核，我们假设是 0 号核吧，没有其他 container 绑定的时候，这个 container 可以近似的看成绑定了 3个核。
它可以吃满 0 号核 100% 的用量，但是一旦 0 号还让其他4个 container 绑定后，只要在高峰期，那么它只能最多吃满 20%
等于就是说对于这个 container 而言，0号核的资源是弹性的，最少能保证 20%。
有一篇测试的文章，我给翻一下
https://goldmann.pl/blog/2014/09/11/resource-management-in-docker/
Q4: 选择aws而非阿里，可否分享一下原因 ？
其实我不是运维部的，这个问题其实没那么简单，我们在役的公有云有2家：AWS 和 Azure。
接洽过的有2家，QingCloud 和阿里云。选择 AWS，其实最大一个原因公司高层的看法是要做中国的 Netflix。
其实这很好理解，因此比较看重未来对海外的扩张。
另外一点是综合性能和价格等多个维度上，EC2 是一个比较不错的选择，前提是对于大客户。
Q5. Redis自动扩容，缩容，依据什么来判定？是业务方来控制，还是调度系统自己判定？
Redis 本身会提供很多监控信息，通过 info 命令即可，我们的 proxy 也实现了类似的原语，redis ctl daemon 通过它将整合后的集群信息发送到了 influxdb。
monitor 会通过这些信息来决定是否调用 core 的 api 上新的 redis instance 并在部署完毕后通知 redis-ctl 把 instance 配置好加入到集群中。举个简单的例子：
info 可以拿到 instance 现在使用内存量和cpu使用率，那么集群所有 instance 使用内存量接近设定上限（现在是1G/500M一个）的时候，monitor 就会开始做这件事情。
业务方对我们集群没多大的控制权，他们只需要提出申请即可。
Q6. 可以稍微介绍下芒果TV的业务么，对芒果台很熟，但对你们这个平台支撑的业务不清楚。
芒果TV 现在主要覆盖了3条线。
第一条线是湖南本地的 IPTV 内容，俗称 OTT 线，这一条线和传统互联网企业不一样的在于，拥有XXXXW真金白银的付费用户。
第二条线是内容产出，作为广电旗下的一个互联网企业，依托于自己的资源（广电的资源）。
第三条线就是网站线，因为独播策略内容为王，我们现在主要承担湖南卫视所有节目的互联网渠道转播工作。同时，我们另辟蹊径，在互联网直播技术上应该也是往前走了一大步，比如前几天的 billboard，全球同步直播。比如跨年晚会，五机位自由选择视角互联网直播等。
Q7.启用Docker后，原有AWS的EC2主机有没有减少？
其实 EC2 主机减少和启用 Docker 没太多关系。我们目前平台大多数是在我们自己的机房中的。我们 EC2 也真的减少了，但是相信我，能做到这样绝对不是架构的问题，而是程序问题。
至于有没有估算过资源利用率提升了多少，从 Redis 集群利用率来看，不太好估算。
因为什么呢，以前是业务方说我需要15w QPS，那我们就按照 Redis Cluster 性能曲线开了一堆 instance 去支撑这个业务。
说回这个 Redis，那么业务方实际上能达到多少呢？即便是跨年演唱会，我们的峰值也没过9w QPS，等于就是说大多数 redis instance 是被浪费掉的。
我们采取 Docker 之后，资源利用率是上升了的，具体多少就没估算了。对于上面那个例子，我们会采取给予一个基础性能的集群，让其自动扩容，满足业务需求，而不是一开始就给一个能撑住 15W QPS 的集群。那么多出来的资源，就给其他业务了。
毕竟预先估算和实际还是有差距的。
Q8.如何做到应用和配置分离的，同一份代码，在测试和产品上用不同的配置？
我们现在没做 UI，不过大家可以试想一下一个应用部署页面，应用需要选择运行时资源，网络，CPU/MEM（就像一个滑动条在拖动），以及启动的入口命令。
选择的资源将会以 ENV 的形式写入到 container 中，所以是一种组合搭配的节奏，项目并不会去指定资源，而资源当然也是可以自定义的，就像买车，你可以定制座椅，轮毂，电子装置一样。
Q9. 如果换云平台，比如从AWS到第三方，Eru需要多大改造？
基本不需要，Eru 支持 host 模型，只不过就得在业务层去控制端口冲突了，不过好在目前我们上云的业务还比较纯粹，不会出现混排的需求。
不过未来在这一块，我们有这样的计划：
1. push 云支持自建子网（但不跟机器绑定），Azure 表示甲方（其实我们才是乙方）您出钱我出命
2. Calico 这个方案和 MacVLAN 同时支持，这个就等我前领导 @洪强宁@宜信 那边的实现了
感谢四正的记录与整理，以及臧秀涛的公众号编辑，其他多位编辑组志愿者对本文亦有贡献。
6168
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
