Netflix 是谁？
Netflix 是欧美地区最大的网络视频提供商，超过了 Youtube。全球每天有超过190个国家，一亿多会员在 Netflix 上观看1.2亿小时的电影，电视剧和纪录片等等。Netflix 也制作了像纸牌屋这样广受欢迎的电视剧。
为了应对巨大的并发流量，Netflix 用了7年时间，网站架构从传统巨石应用演进成为业界超前的微服务架构。目前，Netflix 的云平台上运行了500个微服务，每天会有1000次的变更部署到线上环境。线上环境部署在亚马逊3个 Region，9个可用区，为全球用户提供稳定的网络视频服务。
Netflix 为什么使用容器技术？
Netflix 在亚马逊 EC2 上已经运行了上万台虚拟机，他们的虚拟机集群非常的稳定，实现了云原生应用的转型而且非常易于扩展，为什么还需要用容器技术？
使用容器技术提升了 Netflix 的创新速度。笔者之前的文章也提到，在 Netflix 研发团队的文化里，创新是排名第一位，其次是产品的稳定性。所以 Netflix 对于应用的容错性做的非常强，这样即使创新的应用失败，也可以将失败的范围控制到最小，开发者也就更敢于做创新的尝试。Chaos Monkey 就是 Netflix 团队发布的专门做灾难性测试的工具。
使用容器可以更好的管理应用以及应用的依赖，将所有内容都打包在容器里易于管理和发布。当线上容器出现了问题，可以随时 Pull 下来到本地进行调试，让开发者更快的重现问题。
使用容器的 UseCase
1. 视频媒体转码
之前使用虚拟机进行大量视频流媒体的转码需要一个月的时间，使用容器进行高并发转码，只需要一周。
2. 统一代码构建，打包和测试系统
之前 Netflix 团队发布包之后，只会跑包本身的测试用例，并不会做上游包(UpStream)的集成测试，所以经常发布包会破坏上游包的测试，上游开发者需要反复调试，修复问题。使用容器之后，Netflix 会在容器里跑上游包的测试用例，如果上游测试用例失败，这次包发布也会失败，这叫做 Fail Fast。
3. 开发者无需关心环境
例如 NodeJs 的开发者，他们完全不关心运行的系统是什么，也不想关心，所以使用容器可以让这些开发者专注于开发上，减少 APP 运维的成本。
Netflix 的容器管理平台 Titus
Netflix 最开始并没有使用 Docker，而是使用 CGruop，之后使用了 Mesos 进行容器的管理，目前推出了自行研发的 Titus 容器管理平台，实现容器的管理。
市场上已有了很多容器管理平台，为什么需要自行研发容器管理平台？由于市面上的平台多数关注于数据中心的建设，支持混合云的方案，且目前市面上的方案没有能够满足 Netflix 如此大规模的容器使用情况。
Titus 的最初是用来管理 Netflix 内部大量的 Batch 任务，主要包括视频转码，加水印，生成每日 CDN 网络流量的报表。 这些任务有些共同的特点，耗时较长，属于计算资源密集型的任务，并且不依赖于平台，比较适合用容器来运行。
后来 Titus 开始接管 Services，Services 的要求比 Batch 任务要高很多，需要实时扩容，且需要不间断的运行，服务有更多的状态管理需求，难以升级等等。对此，Titus 做了很多容器管理的改进。
网络管理
在 VPC 网络里使用 Docker。通过 Titus 的执行器，可以创建一个 Namespace，创建并启动一个 Pod root container，类似于 K8S 的 Pods。随后创建 Veth，路由的规则，iptables 等等。
Metadata Proxy
Metadata Proxy 是 Titus 基于亚马逊的 Metadata Service 实现的统一网络管理模块。它解决的是容器的安全问题，它统一管理的容器的 “whoami” 的信息，例如容器的 IP，权限，容器的宿主机 ID，域名等等，容器本身无法知道宿主机的更多信息，从而确保容器的网络安全性。将 VPC 网络和 Metedata Proxy 合起来，就是下面的这张图：
和 Spinnaker CI/CD 集成
Titus 和 Netflix 现有的CI/CD 工具 Spinnaker 进行了集成。在创建 Spinnaker 的集群时，Spinnaker 提供了 AWS 虚拟机集群的创建，和 Titus 容器集群的创建。
当某个容器 Push 到了 Artifactory Docker 注册中心，这个 tag 会实时的显示在 Spinnaker 部署的任务里供用户选择 Docker 镜像的版本。
Titus 也集成了 Chaos Monkey，在 Chaos Monkey里执行线上环境破坏性测试的时候，选择 Titus，就会随机销毁在线上运行的容器。
Fenzo 任务调度框架
Netflix 开源了任务调度框架 Fenso，它是一个可扩展的任务调度框架，用于管理所有调度任务的生命周期。
你只要给 Fenzo 一个任务列表，并且给 Fenzo 一堆可以的计算资源，Fenzo 就会自行决策，进行任务的执行。如果你给的计算资源太少，不足以执行所有任务，Fenzo 会告诉你需要多少计算资源，如何扩容。
Titus 和 Fenzo 集成
为了实现计算资源利用率的最大化，Netflix 的生产环境和 Batch 任务会共用容器资源。某些 Batch 任务会占用大量的计算资源，导致在生产环境的 APP 需要扩容时，得等待 Batch 任务执行完成，才能获取资源。
为了解决这个问题，Fenzo 将容器分为核心层和 Flex 层，核心层的应用会保障扩容的能力。Flex 层会将低优先级的任务进行排队执行。
Titus 的现状
之前 Titus 是和 Netflix 内部的 Mesos 的平台进行容器管理，目前已使用 ECS 替换了 Mesos 作为容器编排的平台。
Titus 支持了 OutBound 和 Inbound 的请求处理，从 OutBound 可以实现 ECS 里容器的启动和停止。如果容器停止，CloudWatch 会监测到 ECS 的变化，并且通知 Titus 里任务的状态变化。
未来 Titus 将会专注于基于：
1. 服务的自动扩容，以及跨数据中心的容器负载均衡。
2. 实现核心层任务的 SLA 保障，当核心层的计算资源达到上限时，会将 Flex 层的资源抢占过来，保障核心层任务的 SLA。
3. 更好的支持动态扩容。
欢迎转载，但转载请注明作者与出处。谢谢！
原文地址：http://jfrogchina.blog.51cto.com/13458615/1982028
