夜不能寐

前几天睡不着时写的，发在公司博客上，转过来留作纪念。
推动一个这么大的设想直接立项还是很困难的，不过可以先把一些重要模块立项开发，时间成熟以后剩下的平台工作工作量就相对较少了。所以最要紧的是要把握住，不要留下很多历史问题。
-------------------------------------------------------------

好久没这么兴奋过了。最近每天都是快一点时睡觉，六点准时醒，真是睡觉睡到自然醒，打车打到脚抽筋啊。今天是两点睡的，五点就醒了，有兴奋的事情总会睡不着。上次给外甥在网上买了个玩具，寄来之前的两天他都早晨5点就醒了，平时可是要睡到8点的。

最近几天对一个已经确定的架构越来越怀疑，之前的讨论中就发现许多问题在这个架构中都没有得到简化，我们只是在不断地打补丁，然后制造更多问题，不断地把自己拖向更深的泥潭。在一些特定情况下，证明了这个新的“强力胶合剂”在并发处理上非常有优势，它的并发能力很强，可以同时处理上万个连接，每秒可以完成10万次转调用（注1），它很容易解决协议转换的问题，也可以完成一些复杂的跨多种服务的多步骤逻辑，但它就是不漂亮、不轻量，它很容易变成新的累赘。

找出过去所有的后台事故，简单分析后发现大部分事故都是以下原因造成的：
* 下层服务器宕机造成上层短连接挂死
* 单台Cache慢影响全局
* 单台DB慢影响全局
上面三种原因造成的结果可能稍有不同，仔细分析后发现很多情况下造成的影响都是相同的——上层（一般是WEB）进程挂死，一旦出现这种情况，影响范围会成倍增加，本来理论上应该只影响1/16或者更小，但实际可能影响到1/4甚至更多！

对这种放大效应做了认真分析后得出的结论是：我们把分布式系统最重要的控制部分，交给无状态的前台简单逻辑去处理！存储系统是目前运行得较稳定的系统之一，但实际上在它上面做得工作可能是最少的，算起来只有在线状态检测和负载均衡，但它就是这么有效地工作着。除了前段时间的Cache效率低以外，还没有其它因素能够影响它。当然WEB端的问题还没有解决。存储系统的优势是伸缩能力，负载高时可以加机器上去，一般很快就可以把负载降下来。为什么中间层不方便做这个逻辑？

分布式系统的访问调度是相对复杂的逻辑，它应该是基于状态统计和监控的，我们目前广泛使用的过于简单的访问策略显然无法胜任这么重要的工作！对这部分修改会到WEB上动刀子，不过除此之外也没什么好办法。我们通过一段时间的努力让一些后台系统运行得非常稳定，但前端的短板让它看起来像是整个系统有很大缺陷，对用户来说前台还是后台的问题没什么差别，他也不关心倒底是前台还是后台的问题。总是有种“我们做后台稳定就行了，前台你们搞稳定”这种想法，其实整个系统要从前到后都做稳定了才能够有效地工作，忽然间很惊讶，从来没人禁止过我们对前台进行改造，为什么我们总是潜意识里会给自己划一个圈，让自己控制的空间很小，宁愿每次事故背上个“负责人”的称呼。又或者是对改造没信心？


花了些时间确定几个最紧要的问题后，列出了三个比较紧要的改进点。前台连接代理是最需要做的，有了它就可以完全解决挂死问题。DB慢造成的扩大效应也可以简单地使用DB访问代理来避免。Cache慢的问题却是个麻烦，之前曾经讨论过Cache跨机房冗余方案，但把这个方案和一些Cache引起的事故对照来看，它其实没解决什么问题。正常情况下它能够提供正常访问，但当Cache自身成为瓶颈时，你能够采取的措施就很有限了，问题的根源在于这个容灾机制不高效、不灵活，这些系统我们都是按单系统来设计的，这些点之间没有任何交互，不听从任何调度，不参与任何重大事故的解决过程，想指望它在灾难时自动帮你解决，无疑是幻想。这种功能需要一个逻辑上更底层、功能上更高层的平台来支撑，说到底，我们目前的系统不是纯机器在运行，我们自己成了其中一个部分，而人是不适合做7*24小时工作的，也无法适应对响应时间非常有要求的工作。

原想简单解决Cache效率问题，从存储系统上来看，多服务工作时数据迁移性能非常高，内存Cache的错误恢复和这个过程很相似，但它更快，所以单台机器挂掉时可以很快地修复Cache。不过把所有后台服务当成一个整体来看时，想法又完全不一样，为什么不让所有机器的内存连成一块来使用？这样单台机器故障时，即便不做错误恢复，它影响的范围也只是1/100之一或者更小，这几乎不是什么影响，数据库完全可以抵挡这种小幅波动。

不只是Cache有这种特性，如果所有逻辑服务都是无状态的，服务可以分散在所有机器上，没有任何单点故障。把所有系统当成一个虚拟大系统使用时，内存、CPU甚至是硬盘性能都不再是瓶颈了，还可以根据负载进行调度。过去我们把这些系统分割成各个业务，当某个业务在高峰无法负荷时，某些其它业务只是空闲地运转却无法提供帮助。

这几天对这种想法做了简单梳理，和几个同事进行了热烈的讨论，最终越来越坚定这种想法，它的架构比存储系统更完善，并且没有IO瓶颈的累赘，理论上它可以做得更出色。所以我决定把它写成文档，讨论是否可以进行实施。在文档编写过程中，不断有新的想法冒出来，原来一些模糊的想法渐渐变成可操作的小模块，在架构上变得越来越轻量，写到最后时只剩下一个薄薄的OS交互层、一个通讯环境和一堆跑在它上面的应用。想法不断简化提纯，最后变成一个虚拟应用容器，这个平台负责模块的安装、配置、启动、卸载、升级、监控、通讯、位置查找、自动并行/分布等功能，当把它的描述写完时，我把目前的存储系统套用在上面，发现功能得到极大的简化，我预计只需要原来的1/3代码量，大概2万行代码！前提是有这个平台。MapReduce在这上面应该只是个非常简单的应用部署。所有的应用都是外部进程，这样可以保证平台稳定性，应用和平台进行IPC通讯，在单机来看效率会有所下降，但集群不是这样，并发应用更不用过分在意微小的时间延迟，Google Data Store和Amazon SimpleDB都有延迟，有时甚至达到上百毫秒，但如果你的WEB也是个大集群，这个延迟算不得什么，如果有能力还可以把WEB改造成Coroutine架构，承受并发上万个动态请求，这个时候的100毫秒和上千并发请求时的10毫秒是相同的。当然这个延迟是存储系统带来的，而不是分布式系统的问题。很多单机来看比较麻烦的问题，并行/分布式系统解决起来却比较方便。

当把它的部分细节都整理过一遍以后，我想到了Erlang OTP（开放电信平台），竟然有许多相似之处。有时不得不惊讶于先贤们的经验和智慧，他们二十年前就想通了这些并行/并发和分布式问题，于是专注地做了二十年。以前经常为Erlang的性能烦恼，用惯C这种高效语言的人不能接受这种性能损耗，但如果把它作为应用管理平台，应用本身也采用外部进程的模式，Erlang的性能瓶颈就可以忽略了，Erlang就是这么做的。不过从Erlang社区对Erlang的使用方式来看，大部分人都没有认识到Erlang要提供什么样的平台，所以这个社区一直没有太热。（注2）

这个平台太让人兴奋了，去年带队做分布式存储系统时虽然知道可以完成它，但没有这种兴奋感。 

注1：原来的设计能力是3万次/秒，10万次时si已经成为瓶颈。Intel工程师帮我们简单分析了一下认为，改用Intel的网卡，使用NAPI方式，性能还可以提升，期待进一步测试。
注2：只是对Erlang的OTP比较欣赏，它的性能还是很低的。

评论

2 楼 qiezi 2008-11-02  

cookoo 写道

"大部分人都没有认识到Erlang要提供什么样的平台" 因为大部分人接触不到Erlang设计针对的那种高并发应用场景, 光凭脑子里假想那种场景而设计产品缺乏实际测试和调试结果可想而知.

确实如此，即便是有这种场景的公司，也只有极少部门和小组有这样的场景。

1 楼 cookoo 2008-11-02  

"大部分人都没有认识到Erlang要提供什么样的平台" 因为大部分人接触不到Erlang设计针对的那种高并发应用场景, 光凭脑子里假想那种场景而设计产品缺乏实际测试和调试结果可想而知.