构建分布式系统 - 技术考量
前不久在拉斯维加斯举办的 RICON分布式系统大会 取得了圆满的成功，这佐证了当今大型应用的重要性。各场演讲都爆满，观众的参与度也空前高涨。此次大会由 Basho Technologies （知名的分布式NoSQL数据库 Riak 的创立者）举办，不过RICON并非关于Basho的大会，它是个分布式计算机会议，由来自工业界与学术界的演讲构成。我们有幸采访到了Basho的技术市场总监Tyler Hannan与技术产品市场高级总监Dorothy Pults，就如何构建分布式系统以及从本次大会学到的技术内容展开了讨论。
Tyler： 我认为无论何时，只要谈到分布式系统这个主题，你都要考虑清楚其定义。我最喜欢的一个定义来自于Leslie Lamport的，他认为“所谓分布式系统指的是系统中某台你都不知道的计算机的故障会导致你自己的计算机不可用”。
大家要知道，RICON是个面向开发者的分布式系统大会而绝非Basho的秀场。
浏览大会主题及与会者，你会发现主要分为两类。一类主题是工业界与学术界的密切协作，这就衍生出了各种主题。
另一类是关于运维的简化。工业界不断认识到分布式系统部署背后的力量，那么它也要确保系统能够做到易于管理、易于维护，本质上是要简化运维的工作。
因此，主题就是这两类：简化运维以及工业界与学术界的协作。
RICON关注于系统与技术。Basho从学术研究中获益匪浅，我们反过来也要资助这个大会并继续对几个研究项目贡献力量，比如说无需同步来处理大规模计算的 SyncFree CRDT项目。这样，将这两个领域的与会者都吸引过来，整个社区就会获益颇丰。
Dorothy： 像Google和非死book这样的不少大公司都有很多研究团队在尝试解决新的和不断涌现出来的分布式系统难题。参加RICON的一个好处就在于没有这些内部研究团队的公司可以与学术界一起学习和探讨最新的问题与研究成果。就像其他新事物一样，学术界不断会出现新的突破，但如何将这些突破实现出来，并且能够解决实际的问题则是非常重要的一环。虽然RICON本身就是一场大会，但工业界与学术界之间的协作并不会因为大会的闭幕而终止。
InfoQ：方才你提到了CRDTs，能否介绍一下呢？
Tyler： CRDTs用于表示最终一致环境下的弹性数据类型。“C”的定义有好几种，比如说“无冲突”、“可交换”及“收敛的”，RDT则表示“多副本数据类型”。
在分布式环境下，对冲突解决建模要比传统的关系型数据库复杂得多。Riak CRDT实现以Riak数据类型（在2.0中）的形式公开出来。这样，我可以直接从Riak APIs对应用中的数据进行建模而无需在客户端构建冲突解决。对于开发者来说，开发与部署要比以往更加轻松；对于Basho来说，重要的是学术研究被证明是正确的，它驱动着我们的底层实现。
从某种程度上来说，分布式系统与其他系统一样，同样强调监控、度量（二者不是一回事）与实现。
工具虽然很重要，但不同的组织会选择不同的工具。因此，组织在分布式系统底层的投资就很容易激发人们的兴趣了。
InfoQ：下面来谈谈流程。我想要构建一个应用广泛的分布式应用，首先该做什么呢？先从编写业务逻辑开始，还是从集群着手？
Tyler： 这个问题问得好。
这两种方式都有公司采用，并且都是可行的。不过能以最快的时间成功实现的方式都是那些工具集中考虑到了容错、可用性以及运维简便性，然后再开始实现的做法。一旦分布式环境运行起来并存储关键数据后，那么再将其迁移到新系统就需要高额投资了。因此，在设计阶段考虑这些选择时，如果能将容错、可伸缩以及运维简便性放进来，那么部署时就会平滑很多。
InfoQ：在标准开发中，我会使用诸如构建工具、源代码控制、持续集成等工具，那么在构建分布式系统时也会用到这些工具么？
Tyler： 没错，我认为这也是分布式系统有趣的一点，虽然二者在工程行为以及需要理解的事情上存在差别，但大多数工具集还是一致的。他们所连接的东西（比如说 Riak数据库）被设计为在分布式环境下依然能够使用。有一些东西需要我们考虑，不过无需放弃我所喜欢的与Riak交互的开发语言，我依然可以使用现有的工具与Riak交互，这个例子也很好地说明了分布式系统的特点。
InfoQ：下面来聊聊测试吧。对于小型应用来说，我会使用JUnit和Mock对象，通过工具来模拟邮件服务器。不过在分布式系统下，出现非确定性行为的概率会大很多。在大规模分布式系统中，负载很高并且出错概率很大的情况下该如何测试呢？
Tyler： 有很多方法和工具可以帮助我们做到这一点，比如说 QuickCheck ，它可以根据测试规范而非“测试用例”对代码做确定的测试。
我认为有趣的是你可以开始将应用层测试与持久层测试分隔开来。我依然可以像传统的单元测试/持续集成环境那样测试应用的UI/UX。接下来通过各种方式测试系统的容错性。 Chaos Monkey 就是业界知名的一款工具，不过有一些客户只是通过在容器测试环境下关闭网络路由来进行测试，这可以确保所选择的产品能够满足他们对于失败条件的期望。
除此之外，测试很难提供标准的准则，这是因为它要依赖于组织所采用的工具集。使用Akka、Scala与Java JVM的组织的测试方法与使用Python的不同，与Erlang更是有巨大的差别。这正是RICON的有趣之处，人们会谈论规模化的测试系统，同时来自于Fastly的Ines Sombra还做了题为“Testing in a Distributed World”的演讲。她并没有谈论工具集，而是探讨了方法的重要性。从根本上来说，方法与思维模式是重要的，而工具集的实现则根据组织的偏好存在着很大的差别。
InfoQ：那监控工具呢？
Tyler： 现在有很多监控工具，可以满足人们的各种需求，从 Boundary 到 Splunk 再到内部实现都非常棒。就像来自于 OpenX 的Matt Davis在演讲中所介绍的那样，分布式环境下的关键之处在于要监控的东西变多了，特别是随着数据集的不断增长更是如此。比如说，OpenX在遍布全球的产品集群中使用了几百个Riak结点。你不仅要监控某台机器的健康情况，还要监控出现的并发等级，从客户端到数据库集群以及创建的对象大小等都需要监控。因此，要监控的东西变得更多了，不过大多数工具链还是与以前一样。
InfoQ：不过在集群环境下，对于我来说更为重要的是要知道查询路径。是否有工具可以监控到请求/响应的完整拓扑？
Tyler： 通常情况下，业界对于这种情况的做法是监控应用、监控应用与集群之间的通信、监控集群与自身的通信，以及监控集群中机器的健康情况。根据这些监控数据，你可以推断出整个环境的健康情况。不过，规模化监控变得更加困难了，因此一开始对于容错性与可用性特性的决策就变得非常重要。这是因为我必须要确保所构建的系统能够运行起来。
InfoQ：在传统应用中，我们常常会围绕着某个易出现问题的点进行规划。不过在大规模分布式系统中，很有可能出现若干处都会发生问题的情况，对于这种情况该如何规划呢？
Tyler： 在Riak中，底层的Erlang实现实际上可以做到代码的热交换，这样如果需要为某个环境打补丁，你可以直接将补丁打到运行的集群中而无需停止。另外，集群的设计方式要考虑到机器的故障情况，并且做到对应用透明，这也是非常重要的，接下来当机器可用时又可以将其加到集群中。因此，集群中机器出现故障就不是什么问题了。
InfoQ：在传统的企业应用中，我们会有一个由关系型数据库所维护的分布式缓存。现在它被NoSQL数据库取代了么，将持久化与缓存合并到一个工具中？
Tyler： 这要看具体情况。还会有一些场景，根据所选择的NoSQL工具以及读写配置，在NoSQL解决方案前加上一个缓存层是有意义的。我会选择 Redis ，因为我有一些很棒的机器，内存很大，我想将整个键的集合存放到内存中。接下来，当缓存中没有所需的记录时才从NoSQL数据库中查询。在很多情况下，我们发现用户只是通过Riak替换掉标准的n层缓存持久化机制，并将其作为单独的层次。
InfoQ：正如你指出的那样，监控与度量是不同的。
Tyler： 度量与监控之间的主要差别在于监控有动作的含义，而度量指的是随着时间流逝的一种趋势。这在RICON大会中来自于OpenX的Matt Davis的演讲中得到了体现，他谈到了查看从集群中分布式系统到应用的健康度随着时间的流逝而变化的重要性，如果是我来监控，那么我需要在某个时间点对特定情况发出警告。不过度量工具一般来说与监控所做的事情是一样的。
对于Basho来说，我们总是在寻求改进方式，并提供比现在更好的集群监控方式。这对于我所在的公司来说非常重要，我们也很骄傲地实现了运维简单化并会继续在这上面进行投入。
InfoQ：对于实现来说，有哪些指导原则呢？
Tyler： 考虑企业中既有的开发环境与工具，Basho提供了.Net与Java客户端库。我们认识到提供与分布式数据库类似的交互方式的重要性。与之类似，我们还提供了Ruby、Python等其他库。丰富的选择是非常重要的。
分布式系统市场的不断成熟为公司提供了很好的机会来寻求成功模式。比如说，在RICON上，来自于Braintree（一家PayPal公司）的David Pick做了一场关于 Apache Kafka （大容量的消息代理）的演讲，以及如何搭配Clojure实现大容量的失败容错。Cloudsoft的CTO Alex Heneveld谈到了如何通过 Apache Brooklyn 来管理云端部署。我个人很喜欢的演讲是来自于Riot Games的Michal Ptaszek所做的关于Riak是如何实现英雄联盟每天2700万玩家聊天的深度讲解。
毫无疑问，分布式系统在技术选择上需要更多的思考以及更多的考量。诸如RICON之类的大会为我们提供了从彼此的经验中学习如何构建和部署这些系统的机会。
查看英文原文： Building Distributed Systems - Technology Considerations