<p>在这篇文章里，我将和大家分享一下我用Scala、Akka、Play、Kafka和ElasticSearch等构建大型分布式、容错、可扩展的分析引擎的经验。</p>    <p>我的分析引擎主要是用于文本分析的。输入有结构化的、非结构化的和半结构化的数据，我们会用 <strong>分析引擎</strong> 对数据进行大量处理。如下图所示为第一代架构，分析引擎可以用REST客户端或Web客户端（引擎内置）访问。</p>    <p><img src="http://static.open-open.com/lib/uploadImg/20160815/20160815082844_157.png"></p>    <p>简单描述一下用到的技术：</p>    <ul>     <li><a href="/misc/goto?guid=4958877308856215352" rel="nofollow,noindex">Play框架</a> 做REST服务器和WEB应用。Play是个基于轻量级、无状态和WEB友好的MVC框架。</li>     <li><a href="/misc/goto?guid=4959676804702607322" rel="nofollow,noindex">Akka集群</a> 作处理引擎。Akka是个工具集，用于在JVM上简化编写高并发、分布式、和有弹性的消息驱动应用。</li>     <li><a href="/misc/goto?guid=4959676804798702036" rel="nofollow,noindex">ClusterClient</a> 用于与Akka集群通信。它运行在REST服务器上，将任务发给Akka集群。使用ClusterClient是一个非常错误的决定，因为它并不会维持与Akka集群的长连接，因而会经常报连接错误，而且重新建立连接时还要把那个Client所在的JVM也一起重启。</li>     <li><a href="/misc/goto?guid=4959676804877905512" rel="nofollow,noindex">ElasticSearch</a> 用作查询引擎和数据存储，包括原始数据和分析结果。</li>     <li><a href="/misc/goto?guid=4958966186692897106" rel="nofollow,noindex">Kibana</a> 用作可视化平台。Kibana是有弹性的分析和可视化平台。</li>     <li><a href="/misc/goto?guid=4959676804987605797" rel="nofollow,noindex">Akka Actor</a> 用作ElasticSearch的数据导入导出服务。它的表现非常好，服务从来没出过故障。</li>     <li><a href="https://aws.amazon.com/s3/?sc_channel=PS&sc_campaign=acquisition_IN&sc_publisher=google&sc_medium=s3_b&sc_content=s3_e&sc_detail=amazon%20s3&sc_category=s3&sc_segment=78960224341&sc_matchtype=e&sc_country=IN&s_kwcid=AL!4422!3!78960224341!e!!g!!amazon%20s3&ef_id=Vrw7-gAABcqLC4le:20160707183244%3as" rel="nofollow,noindex">S3</a> 用作集中化文件存储。</li>     <li><a href="/misc/goto?guid=4958968527950870689" rel="nofollow,noindex">Elastic Load Balance</a> 用作节点之间的负载均衡。</li>     <li><a href="/misc/goto?guid=4958971672494246221" rel="nofollow,noindex">MySQL</a> 用于元数据存储。</li>    </ul>    <p>我们从Akka 2.2.x版开始用起，也碰到了一些严重问题，主要表现为：</p>    <ul>     <li><strong>ClusterClient与Akka集群之间连接断开</strong> ：在负载大CPU使用率高时，ClusterClient常常莫名其妙的与Akka集群断开连接。因为它是个第三方库，所以我们只好把JVM重启来让它继续工作，有的时候还要半夜爬起来处理问题。</li>     <li><strong>资源利用率</strong> ：我们发现REST服务器上CPU使用率只有2-5%，这样太浪费资源了，Amazon EC2服务器可不便宜。</li>     <li><strong>延迟问题</strong> ：REST服务器运行在不同的服务器上。这样就造成了延迟问题，因为对于每一条Client发过来的请求，它都要把请求反序列化，再序列化然后才能发到Akka集群。从Akka集群发来的响应消息也是一样，要先反序列化再序列化，然后才能发给请求方。这样的序列化和反序列化过程常常导致超时问题。而且，我们只是把Play用作REST后台而不是完整的WEB框架，我承认这是我们的设计问题。</li>    </ul>    <p>为了解决这些问题我们设计了 <strong>第二代架构</strong> ，主要变化有：</p>    <ul>     <li>去掉Akka ClusterClient。</li>     <li>用 <a href="/misc/goto?guid=4959616066904254512" rel="nofollow,noindex">Spray</a> 替换掉Play架构，因为把Play用作REST服务不是个正确的决定。Spray是个轻量级HTTP服务器。</li>     <li>为了减少端到端的延迟，我们把REST服务运行在Akka集群节点所在的JVM上，而不是单独的节点上。</li>    </ul>    <p>新架构是这样的：</p>    <p><img src="http://static.open-open.com/lib/uploadImg/20160815/20160815082844_316.png"></p>    <p>太棒了，这样的系统工作得非常好。生活又变得非常美好，团队也得到了很多表扬。</p>    <p>三个月后，来了个要增加Datasift做为数据源的新需求，提供流数据和历史数据。这个需求好满足，只要增加一个新服务，从 <a href="/misc/goto?guid=4959544280410658735" rel="nofollow,noindex">Datasift</a> 中拉取数据并发送到分析集群上即可。</p>    <p> </p>    <p><img src="http://static.open-open.com/lib/uploadImg/20160815/20160815082844_569.png"></p>    <p>增加新服务很简单，但却导致了新问题：</p>    <ul>     <li>上述架构本质上来说是个推送模型，每当有大量的流或历史数据被推送过来时，集群就会处理不过来。</li>     <li>我们决定把集群由4个节点扩展为8个节点。这样峰值情况下还可以，但正常情况下大多数节点都处于非常空闲的状态。我们用的是Amazon EC2 4x.Large节点，非常贵，所以就引发出了 <strong>基础设施的费用问题</strong> 。</li>     <li>我们决定使用Amazon的自动扩容服务。在集群上负载增加时它的确是自动扩容了，可是负载降下来时它却没有缩容。Amazon自动扩容服务对我们的业务情况处理得不够好。</li>     <li>另一个问题是Akka集群的内部节点通信在CPU使用率超过90%时常常出问题，原因可能是因为我们经验不够不会配Akka集群，也有可能是Akka集群那时候不象现在这么成熟。</li>     <li>如果有节点崩溃的话，那整个处理过程就会停止。</li>    </ul>    <p>当我们在努力为这个问题找解决方案时，又收到需求要再增加一种数据源！</p>    <p>在经过很多次头脑风暴之后，我们明白了现有架构的问题，于是做出了一个简单、可扩展和容错的 <strong>第三代架构</strong> ：</p>    <p><img src="http://static.open-open.com/lib/uploadImg/20160815/20160815082845_83.png"></p>    <p>在这个新架构里，我们去掉了Akka集群，重写了分析引擎。它完全是基于Akka Actor的，REST服务也是运行在相同的JVM上。REST服务只是简单的从客户端接收请求，做认证和鉴权，然后创建一条待处理消息发送到Kafka队列中去。分析引擎的每个节点都会从Kafka队列中拉取数据，处理完毕再拉取下一批。这样它就永远不会忙不过来。</p>    <p>受益于Kafka的内部机制，不管哪个节点死掉了，Kafka都会自动的把要处理的消息发送到另一个正常节点上，所以不会有任何消息丢失。</p>    <p>在这个架构下我们就不必继续租用以前的Amazon EC2 4X large服务器了，只要用Amazon EC2 2X large就可以支持任何负载，节省了很多钱。（此处应有掌声。:) ）</p>    <p>这完全是个基于 <strong>拉取模式</strong> 的架构。所有的请求和浪涌 都通过Kafka集群处理。它永远不会忙不过来，因为所有操作都是基于拉取模式的。整个系统部署在 <strong>26台EC2节点</strong> 上，已经快两年了，生产系统一次故障都没出过。</p>    <p>我们也用Kafka保存了各种服务日志来分析性能、安全和用户行为。Kafka生产者会把日志发送到Kafka服务器中。因为我们已经有了ElasticSearch的导入导出服务，我们可以仍然用它们来推送ElasticSearch的日志。我们也可以轻松地用Kibana将用户行为可视化。</p>    <h2>结论</h2>    <ul>     <li>Akka Actors非常适合于打造高并发、分布式、有弹性的应用程序。</li>     <li>Spray非常适合作轻量级HTTP服务器。现在它已改名为 <a href="/misc/goto?guid=4959676805265067329" rel="nofollow,noindex">Akka-HTTP</a> 。</li>     <li><a href="/misc/goto?guid=4958877308856215352" rel="nofollow,noindex">Play框架</a> 非常适合于构建高并发、可扩展的WEB应用，它底层是Akka。</li>     <li><a href="/misc/goto?guid=4959676804877905512" rel="nofollow,noindex">ElasticSearch</a> 是个非常好的搜索引擎，它底层是Lucene，可以提供全文检索功能。尽管我们也把它当成数据存储来用，但数据持久化并不是它的强项（比如与Cassandra相比）。</li>     <li>Kafka非常适合于流处理和日志汇聚。它的架构设计就已经支持可扩展、分布式、容错等功能。</li>    </ul>    <p>请耐心等待我改进第四版架构之后再更新这篇文章吧……快乐编程，不断创新！</p>    <p> </p>    <p>来自：http://www.infoq.com/cn/articles/use-akka-kafka--build-analysis-engine</p>    <p> </p>