<p>谈到设计推ter, 我们首先要问一个本质问题： <strong>设计推ter的基本方法论是什么？</strong></p>    <p>其实是我们计算机设计最基本的方法： <strong>分治法（Divide and Conquer）。</strong></p>    <p>什么是分治法呢？就是把问题不断的拆解，拆解到你可以解决为止，它的艺术在于，从哪个维度来拆解非常考验我们能力。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/c70fe81a4ad5f55cec78375056bb3689.jpg"></p>    <p><img src="https://simg.open-open.com/show/e9282a2600e055e7b28359353d965a1b.png"></p>    <p>如果要求一周开发出推ter，你会怎么做？</p>    <p>你的架构是什么样的呢？</p>    <p>相信你一定不会给出复杂的架构。前端是各种各样的业务逻辑，后端是MySQL数据库，这样就够了。因为这已经解决了当时的问题，满足了一周开发出来的要求。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/6d2f1ed18ed030d33370dcc19338e051.png"></p>    <p><img src="https://simg.open-open.com/show/b23870a6bd5891bd16e7dedafc63cd45.png" alt="推ter 架构如何支持上亿用户" width="550" height="62"></p>    <p>但随着推ter的成长，我们会遇到各种各样新的挑战：</p>    <ul>     <li> <p>MySQL难扩展。</p> <p>为什么难扩展？因为它把同样的一个数据分成各种关系存在里面，每次取的时候，都要通过Join来进行复杂的操作，这个Join当数据被切分的时候存在更多的服务器上，会变得越来越复杂，所以很难扩展。</p> </li>     <li> <p>小变化也要全部部署。</p> <p>任何变化都需要部署到所有机器上，因为服务不断升级，就变成了每天不断部署，变成了daily deployment。所以每次部署的时候耽误时间很长。</p> </li>     <li> <p>性能差。</p> <p>因为所有服务都要部署在一起，造成了它的内存占用率大，而且部分核心模块还因为最初当时的单线程设计成为了各种瓶颈。</p> </li>     <li> <p>架构混乱。</p> <p>因为所有模块在一起很混乱。</p> </li>    </ul>    <p><img src="https://simg.open-open.com/show/b23870a6bd5891bd16e7dedafc63cd45.png" alt="推ter 架构如何支持上亿用户" width="550" height="62"></p>    <p>那要怎么破解这些问题？</p>    <p>答案是将问题拆解开来。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/e59250f2ba8de79ad76dfc8c8059309f.png"></p>    <p>第一刀将存储切开。</p>    <p>我们看后台，可以拆成存Tweets，存User，存Timeline，存Social Graph不同内容，Timeline可以拿Redis这样的数据库来保存，而对于其它的数据比如Gizzard其实是一个分布式的MySQL数据库。并不是所有数据都不适合用MySQL分布，我们可以把这些适合的用MySQL来shutting一下，而不适合的用别的数据库来存，就是一个存储切开的方法。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/4f52a1de72dda19bcfccedf139bef6ef.jpg"></p>    <p>第二刀是将路由、展示、逻辑切开。</p>    <p>我们可以看到又多出了一层，逻辑层。Tweets，User，Timeline它们分别对应后边的各种数据存储。前端会有外部访问的接口，API访问接口，并且它还保存了以前数据的整个架构，用来进行一些小规模的使用。最前面需要有一个Routing，来将不同的请求分布到不同的API上。所以之后推ter就变成了上百上千个小小的数据模块，包括它的服务模块，他们通过之间的相互调用来完成具体的请求。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/31596c45da7095d9705804984386a7d4.jpg"></p>    <p><img src="https://simg.open-open.com/show/b23870a6bd5891bd16e7dedafc63cd45.png" alt="推ter 架构如何支持上亿用户" width="550" height="62"></p>    <p>如果Lady Gaga发了个推文，会发生什么呢？</p>    <p>首先她发出一个推文，会到达最上面一层的外部模块，负责把推文写出来；接着到了API模块，负责接收这个推文；再往后是Fanout，Fanout将推文的ID推荐给所有订阅这个用户的信息收件箱里，收件箱就是Timeline，比如有400万人订阅了Lady Gaga，就会有400万的收件箱收到这个消息；紧接着由于我们Timeline要发到收件箱里，收件箱必然是一个最复杂的操作，为了优化它的性能，就把它们用分布式的方式存储在Redis里面，Redis是偏向内存的数据库，所以能够很快的存储这些信息；但Redis里存的只是ID，所以当一个用户具体要她推文的时候，实际上要通过Timeline服务去找到这个用户对应的是哪个Redis服务器上存了推文的 Timeline list，接着找到所有ID，然后这个Timeline service把ID的具体内容通过另外的数据库装载进来，最终得到结果反馈给用户。这些保证了我们推整个数据的时候速度最快，能够达到每秒30万次的性能。</p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/2d30311611f1cd2187af7062d1c7f01e.jpg"></p>    <p><img src="https://simg.open-open.com/show/b23870a6bd5891bd16e7dedafc63cd45.png" alt="推ter 架构如何支持上亿用户" width="550" height="62"></p>    <p>虽然有了这样的过程，如何支持搜索呢？</p>    <p>很简单的想法是当我们写入API，它Fanout到每个用户的Timeline list的时候，我们可以拿另外的Ingester把这个推文放到里面，Ingesert最后把它放到Earlybird，就是所谓的倒排索引中。比如有个推文发过来“我喜欢太阳”，就把我，喜欢，太阳，拆成三个词，把这些单词，进行倒排索引，存到Search index里面。这时候实际会用到很多很多Earlybird，这样就能建立很多倒排索引，能够并行的去做。当用户一个请求过来之后，比如搜索“早上吃饭”，就会把morning和eat作为两个关键词发到我的Earlybird集群里，得到结果后Blender会把它组合到一块，并反馈结果。当然很多用户可以并行的向Blender发送请求，从而得到最终结果，这就是我们的搜索服务。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/6828e29ef412b920c189d3702b46d4af.jpg"></p>    <p><img src="https://simg.open-open.com/show/b23870a6bd5891bd16e7dedafc63cd45.png" alt="推ter 架构如何支持上亿用户" width="550" height="62"></p>    <p>如何通知用户新消息到达呢？</p>    <p>第一个方法是另外再开一个Write API，在有新东西发生以后，我把它放到一个Push的服务里，那所有用户只要都连到这个后台里，HTTP PUSH，就会通知他有新消息产生了。同理对Mobile ，会有Mobile Push，当然大家对不同的信息有不同的对接方法，大家可以去仔细考虑下怎么能做到这个样子。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/4cba521d6e72f1ff8728a126b74de8bd.jpg"></p>    <p><img src="https://simg.open-open.com/show/b23870a6bd5891bd16e7dedafc63cd45.png" alt="推ter 架构如何支持上亿用户" width="550" height="62"></p>    <p>如何搭建这样的服务呢？</p>    <p>最基本的是开源项目推ter-Server。</p>    <ul>     <li> <p>配置服务，IP之类；</p> </li>     <li> <p>管理服务，哪些down了、控制、启动等；</p> </li>     <li> <p>日志服务，运行怎么样，以后出问题找谁等；</p> </li>     <li> <p>生命周期服务，什么时候启，什么时候关，什么时候控制；</p> </li>     <li> <p>监控服务，到底有没有出错，出错以后怎么办，互相报警等</p> </li>    </ul>    <p>这些东西合到一起，就构成了这样服务的基本架构。</p>    <p><img src="https://simg.open-open.com/show/b23870a6bd5891bd16e7dedafc63cd45.png" alt="推ter 架构如何支持上亿用户" width="550" height="62"></p>    <p>各个服务之间如何交流？</p>    <p>这就是传统的RPC（远程的进程调用），大家能够通讯的不仅是数据，而且可以通讯命令或请求之类的。这时需要开源项目Finagle。</p>    <ul>     <li> <p>能够提供服务发现，因为有很多服务，所以要找谁发送这个请求呢；</p> </li>     <li> <p>负载均衡，可能有十个人提供服务，先放到谁那儿？</p> </li>     <li> <p>重试，如果失败了怎么办，是否需要重试？</p> </li>     <li> <p>基本的线程池和链接池，大家可以复用，不用每次去创建，浪费资源了；</p> </li>     <li> <p>统计信息的收集；</p> </li>     <li> <p>分布式调试。</p> </li>    </ul>    <p><img src="https://simg.open-open.com/show/b23870a6bd5891bd16e7dedafc63cd45.png" alt="推ter 架构如何支持上亿用户" width="550" height="62"></p>    <p>如何调用一个服务？</p>    <p>因为从A调用B，大家之间各种远程，写代码上要怎么做呢？可以使用函数来调用（Service as a Function），背后实际上是Function programming的思想。</p>    <p>可以看下这个基本例子：trait Service[Req,Rep]extends(Req=>Future[Rep])</p>    <p>简单理解为：我有一个请求想得到一个Response，就是Request到Response。这里面实际上可以先面向未来实现，之后当它执行的时候，就会得到相对应的结果。</p>    <p><img src="https://simg.open-open.com/show/b23870a6bd5891bd16e7dedafc63cd45.png" alt="推ter 架构如何支持上亿用户" width="550" height="62"></p>    <p>多个服务的调用如何整合在一起？</p>    <p>我们看一看它要如何运行？比如我们有一个请求是得到一个用户的所有Timeline数据。它其实有很多步，第一步是得到User ID；第二步得到User timeline list里的那些消息ID；下一步是针对每一个消息，得到它的每一个具体内容，比如“我早上吃饭”这些内容，这些内容里面可能还有图片，还需要得到图片的数据。这是一个很复杂的过程，但这个箭头表达了它们最基本的执行顺序。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/b0cab807c1a03d77143e4f6be3fc26b2.jpg"></p>    <p><img src="https://simg.open-open.com/show/b23870a6bd5891bd16e7dedafc63cd45.png" alt="推ter 架构如何支持上亿用户" width="550" height="62"></p>    <p>最佳的执行路径是什么？</p>    <p>首先是得到ID，再得到Timeline以后可以并行地读取每个tweet，可能会有的快有的慢，然后又得到一些它的具体信息，比如说图片之类，所以这就是最优策略。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/50f343e098318adb8a4c1b92e53fdcda.jpg"></p>    <p>下面我们来看一看代码：</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/6920d6719e3de6f70d05122560f96fbc.jpg"></p>    <p>第一行是得到用户ID，用一个面向未来的方程得到一个用户ID。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/438d064a526ca03eec711809cd3d9c82.jpg"></p>    <p>第二行根据ID拿FlatMap，FlatMap其实是后面针对每一个ID执行的函数，这个函数来得到这个ID用户的Timeline list。所以这也是我们Function programming，或者如果用Spark也会经常碰见的函数。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/0c2fb1caa0245dc76a5be2d9ae1abe4f.jpg"></p>    <p>得到每一个ID以后，实际上要针对每个ID执行，所以需要Map。Map每一个ID是做什么的，得到这个Tweet的具体信息。代码第二行就是根据ID得到他的具体内容。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/0c01a8f490c86f589626692f1aa4df35.jpg"></p>    <p>当然如果这个东西有图片，那需要得到图片。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/b3229f7fb3afc72bc5fea3426d4d9a51.jpg"></p>    <p>中间一步还需要把这些东西并行起来，大家都去单独得到Tweet，并且把它集合放到一块儿去。整个过程我们就得到了最终的代码。</p>    <p><img src="https://simg.open-open.com/show/ebedda8842b4be4038894d1fefd37d03.jpg"></p>    <p>这其实就是 <strong>第三刀：切开“做什么”和“怎么做”。</strong> 在这个代码过程中，所谓面向函数的编程，只是写了想做什么事儿，但具体怎么做，比如从哪个机器找、连接服务器、从谁那儿抓取，怎么并行等都没有写，实际上这些东西都被封装到了一个底层的库里面。所以现在推ter就可以有两个团队，一个团队负责写代码，“做什么”；另一个团队负责写底层是怎么实现的。这样就能实现并行开发，这也是Function programming的一个好处。</p>    <p><img src="https://simg.open-open.com/show/b23870a6bd5891bd16e7dedafc63cd45.png" alt="推ter 架构如何支持上亿用户" width="550" height="62"></p>    <p>一个服务器的架构长什么样呢？</p>    <p>上方是你的服务，下方就是你的服务器，包括一些集群的管理、内存、Java的虚拟机、操作系统和硬件。</p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/1548c0735ff920c6f9e663bee991b6b7.jpg"></p>    <p><img src="https://simg.open-open.com/show/b23870a6bd5891bd16e7dedafc63cd45.png" alt="推ter 架构如何支持上亿用户" width="550" height="62"></p>    <p>有很多服务如何整合？</p>    <p>结果整合到一起就是很多层，底层都是一样的，但上层跑了不同的服务：HTTP、聚集器、时间timeline服务等。我们所有东西加在一起，系统就会跑上千个不同的小服务器，而且之间会有各种各样的备份。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/95405c0251696b35be666aa28389e3c8.jpg"></p>    <p><img src="https://simg.open-open.com/show/b23870a6bd5891bd16e7dedafc63cd45.png" alt="推ter 架构如何支持上亿用户" width="550" height="62"></p>    <p>那如何来统计出现的服务器情况呢？</p>    <p>比如会统计平均延迟，或统计一些信息来验证服务器是不是出问题了，实际上，在这种大规模里面，一个比较好的方法就是不要拿平均值统计，因为特殊情况会拉低所有情况。举个例子，假设北京有一个人，他年收入是100万，另外99个人每个人年收入都是1元。那平均下来每个人收入都是1万块钱，但实际上大多数人是很穷困的。所以不能拿平均数来算，尤其是在服务器的情况下。所以大家一般都会取中位数（median），百分之90的点，百分之99的点和百分之999的点。我们可以看到，下图是一个服务发生故障的前后。在服务故障发生前，百分之99点的平均延迟是100毫秒，但故障发生后变成400毫秒，发现这个问题以后就会去抓。但如果用平均值，很可能就发现不了这个问题。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/eca282cc74f342e796804265b710a325.jpg"></p>    <p>这样还有一个好处，当我们做到上面整合的架构以后，每一个负责写代码的团队，只负责处理跟它相关的上下层就行，而不用做那么多交互，所以每个人的东西都非常简单，这也是所谓微服务的一个好处。</p>    <p><img src="https://simg.open-open.com/show/b23870a6bd5891bd16e7dedafc63cd45.png" alt="推ter 架构如何支持上亿用户" width="550" height="62"></p>    <p>如何监控一个服务呢？</p>    <p>实际上针对这个服务在整个栈里面用的时间，会有一个图表达出来。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/bbd929c00f21968f834d2977816d929a.jpg"></p>    <p><img src="https://simg.open-open.com/show/b23870a6bd5891bd16e7dedafc63cd45.png" alt="推ter 架构如何支持上亿用户" width="550" height="62"></p>    <p>如何监控一个请求呢？</p>    <p>实际上，基于一个请求，会有一个整个运行的最佳策略，这就需要运行的整个过程的图。这就是我们之前讲的，得到一个用户所有Timeline内容信息的锯齿图，Zipkin，这也是一个开源项目。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/8b4b978ba18e1cfe07e971b87f6bd319.jpg"></p>    <p><img src="https://simg.open-open.com/show/b23870a6bd5891bd16e7dedafc63cd45.png" alt="推ter 架构如何支持上亿用户" width="550" height="62"></p>    <p>如何监控系统的运行情况呢？</p>    <p>因为这个时候失败已经成为常事了。举个例子，假设每秒有30万的请求，有99.99%的成功率，那每秒一定会有30个失败的，所以不能说每次失败怎么样，统计失败率会比单独的失败更重要，而且写代码的时候要为这个失败来进行自动重试。大家不用纠结每次的失败，只要大部分过去就行了。</p>    <p><img src="https://simg.open-open.com/show/b23870a6bd5891bd16e7dedafc63cd45.png" alt="推ter 架构如何支持上亿用户" width="550" height="62"></p>    <p>最后做下总结</p>    <ul>     <li> <p>学好分治法，走遍天下都不怕。</p> </li>     <li> <p>函数式设计切分做什么和怎么做。做什么是由函数式设计来写，而怎么做由底层的语言和编译器来优化。</p> </li>     <li> <p>面向错误让我们使用了统计域监控。99.9%的点出什么问题了，这样就叫做基于统计域的监控方式。</p> </li>    </ul>    <p>参考资料：《Real-Time Systems at 推ter》</p>    <p> </p>    <p> </p>    <p> </p>    <p>来自：http://mp.weixin.qq.com/s/c9mFDmHRLbuKbqS6aGUdiQ</p>    <p> </p>