最近的Heroku大客户暴走风波引发了云计算领域的又一波争论。在云平台和云平台上的用户规模不断增加时，困扰了各种企业架构、互联网架构的伸缩性问题也被摆在了云服务提供商和用户的面前。
\我们能从Heroku的事件中学习到什么？大规模的PaaS架构应该如何设计？如何确保及时的发现问题、响应问题？开发者如何保证自己在使用云服务的时候不被忽悠？云计算的架构设计者能否借鉴传统企业级架构和互联网架构的一些经验？
\为了寻求这些问题的答案，InfoQ从今天开始会组织一系列主题为《云服务如何面临业务增长的挑战》的虚拟座谈会。本期为第一期，主要讨论如下两个话题：
\- Heroku本次反映出来的路由系统延时问题，背后究竟有哪些方面的原因？\
- 对于路由系统的架构设计与集群扩展，在座的嘉宾们有哪些思路和经验可以分享？\
下面先简单介绍一下本期参与虚拟座谈会的几位嘉宾：
\- 丛磊（@kobe），新浪云平台首席架构师，骨灰级码农+深度技术控，负责Sina App Engine整体架构和技术研发。\
- CodeBox（@CodeBox-腾讯），效力于腾讯云平台。\
- 杜熙（@raregogogo），百度云平台架构师。\
- 郭理靖（@郭理靖），京东商城云计算研发部资深工程师。\
- 陆林青（@openshift），效力于红帽，专注于OpenShift布道。\
另外，本次我们还邀请了程辉（@程辉）和邓侃（@邓侃）的参与，两位在仔细研究了这个问题之后，认为这个问题看起来虽然简单，但背后的信息量却很大，需要掌握更多的信息后再进行评论。因此，我们会在本次虚拟座谈会的未来几期，或者其他更加合适的时机，再来邀请他们过来分享。
\另一方面，通过一次虚拟座谈会，对上面两个问题也并不一定能产生完美的解答。根据目前跟一些嘉宾们的沟通，后续仍有更多的反馈和内容补充，因此我们决定将本次的话题延续到下周继续讨论，让真理越辩越明。
\以下是本期嘉宾们的观点。
\丛磊：
\\\其实随机不是大问题，关键是要有一套良好的健康检查机制，另外对于等级用户需要做隔离。
\为什么这么说呢，其实路由规则里面随机是个不错的选择，不一定非要用优先队列什么的，但问题的关键是一定要有健康检查，后端出现故障要能避开，后端出现延迟要能绕开，否则，这种随机只能被定义为不合格了。
\SAE目前日PV达到10亿，SAE的路由实现是经过长时间高访问并发考验的，非常有效。其实路由分成两种，一类是从外到内（如heroku文中所指），一类是从内到外（SAE内部叫SocketProxy）。
\从外到内：SAE拥有一套自己开发的健康检查和redispatch机制，能够当后端出现故障时绕开，并在出现临时情况时通过适当的redispatch解决。其实健康检查是一个很大的话题，如何判断“挂不挂”，如何最快速的判断，都是一个可以深入讨论的话题。此外，SAE目前的三个语言平台，PHP、Python、Java在路由细节上还有所 不同，SAE Python平台的路由规则非常像Heroku文中描述的智能路由，经过我们Python平台长时间运行检验，其实现是可靠的。
\从内到外：SAE内部所有3层以上的对外网络请求都是经过我们的代理（SocketProxy服务）路由的，我们这套网络路由有以下几个特点：
\
- 完全做在系统内核层，无需语言runtime关心，支持TCP/SSL/HTTP/HTTPS\
- 可以针对目的地址的不同选择代理加速\
- 拥有健康检查机制，防止阻塞\
- 拥有针对来源地址和目的地址的统计、配额、限速功能，防止从内到外的网络攻击（如恶意抓站等）\
最后就是，针对企业用户，需要做隔离，避免runtime的互相干扰，也要避免路由代理之间的互相干扰，在这方面，SAE通过在其上运行的2000家付费企业积累了大量的经验。这方面以后有时间我会再详细讨论。
\
CodeBox：
\\\说说我的个人观点吧，不代表公司意见。我先介绍一下我们的PaaS平台的类似系统的设计。
\\
腾讯PaaS平台CEE处理用户请求时，是通过TGW和tnginx共同来完成routing和load balance。
\
- 用户请求发到 TGW的vip上，TGW跟据域名和负载均衡策略，选择一台合适的RS机器，将请求转过去。 TGW是工作在内核里面，本质上是个Syn Proxy，因为要hook域名，所以必须自己跟客户端完成握手并处理一部分应用层数据。而不能像NAT代理一样透传syn包。 从工作原理上来讲，TGW扫在前面可以处理一部分安全威胁，如半连接攻击等。\
- RS上的tnginx后再根据域名做二次转发，到应用容器里面去。 tnginx工作在RS中，也就是vm host，与guest中的fastcgi框架的通信是通过unix socket时行的。\
- 整个过程中没有排队，硬要说有的话也是系统层面的backlog。如果有突然的流量增加，由于监控和调试系统来扩容。\
我们解决问题的思路跟Heroku的思路不太一样，我们一般从底层（系统层面）去解决问题，而不针对特定的语言。如我们的内外网负载均衡都是在内核层面做的，跟语言和组件无关。看讨论，似乎是Heroku的解决特定语言和特定架构引入了路由+排队系统，而排队系统的监控又不到位，请求停留在里面时间过长也没能发现。
\我们的内网负载均衡也是在底层实现的，也跟语言和组件无关，提供最基础的的ip:port来抽象服务。
\\
我们还是比较喜欢从底层解决问题。例如，新浪SAE是在Apache和PHP上做不同用户应用层面的隔离（2011年QCon杭州了解到的，不知现在如何），CEE是在系统层面用container做的，这也体现了我们的一贯思路。两种方式各有优缺点，没有绝对的好坏，例如在底层做会有抽象程度不高等问题。方案的选择主要看你侧重什么、擅长什么。
\另，这个论文The Power of Two Choices in Randomized Load Balancing格调有点高雅，一堆公式，看起来很上流，虽不明，但觉厉。只是隐隐觉得有必要弄得这么复杂吗，我还是习惯走“简单粗暴，行之有效”的屌丝之路，哈哈。
\
杜熙：
\\\我认为这次事件的直接原因是Heroku默认的Thin服务器是单线程的（而且是非异步）。每个dyno只启动一个Thin服务器进程，应用的并发数主要受限于dyno数，在高并发请求下，不管智能还是随机路由效果都有限，智能路由只是在一定程度缓解而已。此时，应用开发者有两个选择：一是接受Heroku的排队机制，其结果是部分请求延迟会增大（本次case）；二是花更多的钱，增加dyno数。不过以通常业务系统来看，并发消耗的dyno大多在等待io，资源并未真正被有效利用，因此花费巨额的金钱增加dyno不是一个性价比高的办法。所以，Heroku提供了切换到支持并发的Web服务器。看起来一直把Thin设置成默认服务器确实是一个错误的选择。
\本质上，问题的根本原因是PaaS的提供者是否有能力为承载的应用提供保障。Heroku作为一个PaaS的提供者，应该为开发者提供一套分布式架构的Web App运行环境。将很多底层细节屏蔽，从而让开发者从这些问题中解脱出来，专注于自身业务。而Heroku显然犯了一些错误：如给了开发者太多的选择（提供多种服务器支持，而非定制一个靠谱的），给了一个错误的推荐（Thin），没有及时的通知路由策略的变化，等等。因此，开发者需要擦亮眼睛，谨慎的选择有能力、有经验的PaaS提供商，而不能仅凭费用低廉。另外，必要的SLA独立监控也是必要的，不能仅凭提供商的一面之词。
\最后说一下百度应用引擎（BAE）经验。BAE脱胎于百度十二年来积累的大规模数据和服务处理的云计算能力，目前每天为数万个应用提供运行支撑，请求量超过100亿次/天。在如此高并发的状态下，为了提高请求的处理效率，BAE对静态请求采用异步机制处理，动态请求采用多进程池处理。路由算法也是带智能的随机路由，会跳过繁忙或故障的后端节点。而且如果某个应用遇到瓶颈，BAE能够自动在短时间内增加处理进程或服务器节点，这种“弹性伸缩”才是云计算真正的优势。BAE也按照百度提供大规模搜索和在线服务的经验，对很多的底层策略和机制进行了调优，确保给应用的默认设置就是最好配置。因此，BAE能够非常好的解决类似问题。
\
郭理靖：
\\\对于PaaS平台，上层路由是必需存在的，每个APP的Instance是分布在不同机器上，不同APP的Instance又共享一台机器，需要路由来把发给APP的请求转向给具体的Instance。Heroku的核心问题是在于路由有问题。
\我们在使用CloudFoundry的过程中也发现有类似的问题，目前来看CloudFoundry的路由做的比较简单，我们目前在做的一个工作就是把DEA的负载状态以及DEA里执行的Instance的状态都上报给router，这样路由层有更多信息做更好的负载均衡。
\
陆林青：
\\对于Heroku的问题，作为另一个PaaS的代言人恐怕不便评论。不过从一个用户的角度出发，我希望Heroku能够开源，这样对解决问题、对项目发展都有利。
\OpenShift方面，对于来自App的更新、访问，利用DNS+virtual host，实现了直接联络node，而且对于scaling app，用户访问的甚至不是同一个node，大大减少了在某一个部分产生排队现象的几率。对于来自客户端（rhc，web console等等）的管理请求，OpenShift自带有broker和proxy来保证HA；队列处理方面则有ActiveMQ。RedHat为了更加完善ActiveMQ，已经收购了FuseSource，所以所以这项核心技术现在也是RedHat主导。
\OpenShift Online目前已经有百万级的大型应用在跑，比如cloud9.io——一个基于Node.js后端和HTML5/JS前端的在线IDE。
\其实OpenShift的技术和组件都是开源的，用户可以随时从upstream获得代码自行部署测试。这是OpenShift Origin的搭建文档：
\https://openshift.redhat.com/community/wiki/build-your-own
\这里跟OpenShift online用的代码有99%都是一致的，唯一的不同是少了一些商业的Cartridge，比如JBoss EAP。
\还有OpenShift Enterprise版的部署文档，目前仍然在社区中更新，已经发布了两部分：
\https://openshift.redhat.com/community/blogs/installing-enterprise-paas-part-2
\其实Enterprise版就是很多客户期待已久的on-premises版。Origin是上游代码，Online和Enterprise是公共云和私有云两个不同实现。对OpenShift的实现感兴趣的同学，欢迎多去了解我们的文档和代码。
\
3925
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
