译文概述
作为当下最火的新科技，Docker以其『一次构建，处处运行』的特性，解锁了Mesos与Kubernetes等用于集群界的调度工具。这个创新成功地解决了多种运行高效网站的常见难题，同时也引进了新的挑战。
在DockerCon 2016，Yelp的工程师Evan Krall介绍了PaaSTA，一个架构于Docker，Mesos，Marathon，和Chronos等多个开源工具的PaaS平台。 PaaSTA提供的工具能让开发者快速将微服务转换为可监控与高性能的程序，并使其跨越多个数据中心与云区域间。Evan会进一步探讨Yelp是怎样利用PaaSTA去减轻开放者在处理复杂工作时的负担，同时与大家分享开发者在PaaSTA上运维服务时的工作流程。
讲师
Evan Krall是Yelp的网站可靠性工程师（Site Reliability Engineer），他从2013年开始在Yelp上构建Docker化技术。
Yelp是美国是最大的点评网站，创立于2004年，囊括各地餐馆、购物中心、酒店、旅游等领域的商户，用户可以在Yelp网站中给商户打分，提交评论，交流购物体验等。
议程
I. 介绍
PaaSTA之前的Yelp
什么是PaaS？III. PaaSTA
PaaSTA由什么构建？
我们是怎样把它架构起来的？
II. Production-Ready
什么让一个PaaS平台Production-Ready？
IV. 收尾
所学经验
今后的计划
正文
Yelp是是创立于2004年的点评网站（类似于国内的大众点评），囊括各地餐馆、购物中心、酒店、旅游等领域的商户。Yelp的目标是将人与各地的商户以点评的方式连接起来。在2015年第三季度，Yelp共有大约8千9百万移动端用户，9千万条点评，71%来自移动端的搜索量，入驻了32个国家。
为什么要搭建PaaSTA
在2012年左右，我们的开发团队开始专注于SOA（面向服务架构），起因是由于现有的网页程序堆砌，越来越多的人在同一个任务上工作，导致开发流程变慢，失败率也随之上升。于是团队做了一些调整，将基准代码拆成多份，由多个团队分开完成代码的部署与建设。
不过，在这样运作多个services一段时间后，我们遭遇了Dependency Hell这种“瓶颈”状态。
Dependency Hell（DLL地狱）是指在操作系统中由于软件之间的依赖性不能被满足而引发的问题。另一个我们遇到的问题是堆积了过多的swervices，导致我们无法将所有services放在每个services主机下。下面分享一段我在twitter上看见的话：
什么是PaaS
调度（Scheduling）：选择服务会运行在哪些主机上
交付（Delivery）：将代码放入主机并运行
服务发现（Discovery）：告诉客户端你的服务在哪里运行着
什么样的PaaS是Production-Ready的呢？
一个Production-Ready的系统能够让失误降至最小化，影响这个系统的因素共有三个：影响 = （频率X 严谨度 X 持续时间）；
并且，作为一个可信并且Production-Ready的PaaS应该可以将程序失误与PaaS失误同时降低。
可以使用稳定的软件和硬件去降低失败频率，很遗憾的是，在这个星球上无论是多么好的软件/硬件也有失败的可能。所以，除了使用稳定的产品，你也要专注于失败严重度与失败持续时间这两项因素，从而提高PaaS的整体Production-Ready程度；
NO SPOFS（SinglePoints of Failures）：学会狡兔三窟，把任务方在不同端口处理，避免完全放在单一平台上；
Graceful Degradation：缓慢降级，你的架构是建立在不同模块上的，它们都有出问题的可能，所以要及时处理每个模块的故障，避免出现一次性的鼓掌爆发；
Painless Upgrades：升级系统是常有的事情，但是升级不应该导致停机，因为这意味着频繁地停止服务。
降低失误持续时间也是至关重要的一个因素，因为失误时间越短就越不会被发现，造成的负面影响自然越小。
Self-Healing：自动从普通失误中恢复；
报警：即时通报失误情况，给别人留有补救机会
错误可视：可以对错误进行诊断
Yelp的PaaSTA
这个项目已经有一年多的时间了，它是Yelp开源的，基于Docker的PaaS。
Docker在交付方面的优势：制造一个镜像，可以用在所有Docker上，同时能便利地运行在不同软件上，有便于复制的Dockerfile，以及每个容器都有限量的CPU属性，这个资源限量让交付更加容易。
调度主要是Mesos和Maraton共同负责，Mesos是一个用于分布式系统的SDK，它不自带电池，Mesos需要一个框架 （Marathon，Chronos），它的作用是执行Docker任务。Marathon负责运行Docker镜像，并且与Mesos协作寻找集群空间，以及替代不能用的实例。
如何创建&发布Docker镜像？
作为持续集成的支持者，我们用Jenkins创建与测试Docker镜像。成功通过测验的镜像将会贴上Git标签，并推进注册表内；
我们用共享的AMAZON S3去运输Docker镜像，或者是用私有注册表分享。
如何配置Marathon
在说到具体的Maraton配置方法之前，我们先说一下Declarative Control这个要点：计划最终目标，不是路线。
这种方法可以提高失败容许度，比如 油门VS航线图的区别，选定你的目标，让路线自己画出来。这样系统会对比正在运行的东西与应该运行的东西，然后自动调整容错度。
Marathon配置：
作为保险先在Marathon周围构建一堵墙，它架构在你的集群上，所以最好不要让Marathon的API开放。
Marathon的配置如下所示，你需要在每个配置下设定最高参数：
任务数量
CPU/内存
怎样为任务做健康检查
反弹方案
指令
Service之间如何通信？
SmartStack– Airbnb攥写的开源代理工具
每个Box上的注册代理会发送信息给ZooKeeper
每个Box上的探索代理从ZooKeeper读取任何客户信息，进行HAProxy配置
用SmartStack注册：Configure_nerve.py querieslocal mesos-slave API 会读取运行的任务
注册架构图：Configure_nerve指令要求nerve去检查每个services，如果通过了健康检查则会输录进ZooKeeper内
ZooKeeper数据：nerve在ZooKeeper注册services。
Hacheck：service健康检查
服务发现：在nerve将service运输到ZooKeeper后，Snapes作为发现代理，将指定的services展现给clients。
HAProxy：如果连接不成功，HAProxy会自动重新连接，并且允许logging记录。
监控一个PaaS是不一样的
难以检测services的存在，并且不容易找到services的运行位置
无法使用传统的“Host X 运行在 Y”测试
可以检查Marathon运行在X,Y,Z的情况
可以检查所有运行在docker，mesos-slace，synapse，nerve上的nodes情况
可以知道有多少services正在运行
Sensu监控
分散式检查方法
Clients处理检查，将结果放在信息里
Sensu 处理所有的检查结果，将它们用email，jira，PagerDuty的方式导出
如果Marathon失败了，我们可以对Sensu发送信息：
try：可能会失败的事件
except: 抛出失败事件
else：发送成功事件
PaaSTA的经验之谈
接口很重要，对接良好的程序系统可以提高开发者的工作能力，避免基础架构过于膨胀。
有时候要做出大的跨越才能收获更多，Yelp花了数月的时间建立的PaaSTA的基础架构，我们之所以花费时间与经历去做创新，是因为相信创新是让我们进步的最好选择。
PaaSTA的未来
