这个月为了与分布式架构主题符合，我们了解到一些读者关于学习一些好的设计和实现技巧只是在嘴上说说而已。在服务器端，我们旨在让人满意，所以我们制作了一个简短的提纲，关于我们从该主题采访专家那里收集的一些最聪明的技巧和实际的观点。

　　#1 加入NoSQL一族 不要迟到

　　你是否认为NoSQL很酷，但却不适合你？重新思考。《Making Sense of NoSQL》的联合作者Dan McCreary 和Ann Kelly说，这个数据库技术不仅仅只是给有巨大数据集的公司准备的。忘记Twitter和LinkedIn作为“典型”的案例。这些新系统甚至给那些不是很巨大的大数据带来了好处。当你给NoSQL一次机会后，你会很明显到得到大量意想不到的甜头。有一些引人注目的、更简单的接口（不是Java和对象关系映射需要的）。你可能能够轻易地把XML文件拖拽到一个存储系统中，立刻开始执行查询，然后开始创建服务的工作。你的开发人员可以释放出他们的时间来建立企业应用，来保持你的业务灵活性在快速变化的时代。这有很多益处，不仅仅只是解决非结构化数据的问题。据Dan说，“你停留在NoSQL上的许多原因将会非常的不同说你认为你选择它的理由。”

　　#2 我们希望你擅长数学

　　《Hadoop in Action》的作者Chuck Lam正是我们建议寻访解决我们关于Hadoop的问题的家伙（真想不到！）对于这个框架他看到的光明的未来，但他还说不是所有的用户都真正了解它的局限性。简单地说，它不会为你做所有的工作。“你需要很好的了解你要解决的问题，要更深一层。例如，人们认为Hadoop将会自动扩展。他们认为他们可以在这个MapReduce框架中编写他们的算法，并扔给它更多的机械指令，然后它将会扩展它。大部分时间它是有效的，但一旦他无效了，你就会陷入麻烦之中。你还将遇到基本算法复杂性问题。” 像O(N2)这样的算法，给它更多的机械指令都不会有用，即使是Hadoop也一样。你需要以不同的方式来解决此问题。

　　#3 你的RESTful web API安全吗？

　　夜晚，辗转反侧，电教你的REST服务是否安全，而无法成眠吗？你希望做的第一件事是确保你的Web API信任HTTPS。这确保了客户和服务器之间的安全通信。我也有一些好消息。对于弹性授权，自定制工作已经是过去的事了。据《Restlet Framewor》的作者Jerome Louvel说，“这一年，适当的授权访问你的Web API的标准方式是，给谁技术增加OAuth2.0。以前，该标准是不稳定的，因为它有多个版本。确保你你的RESTful web API与OAuth2.0的最终版本相兼容。”

　　#4 不要懒于解决问题——要认真考虑

　　分布式架构不容易，但是把你的问题归咎于有着晦涩的缩略语的理论上，也不让这些问题消失的。耶鲁大学计算机科学副教授Daniel Abadi在讨论此话题时是出了名的不留情，“对于CAP原理我最大的问题是，人们使用它作为建立分布式系统的一个理由，但却不能确保一致性。更不用说，不需要一致性的数据库的网络分区了。这是说，在只有一个分区时，你要么放弃一致性，要么放弃可用性。但是，如果一切进行顺利的话，那么你就哪个都不用放弃。”当然，一致性对延迟那就另当别论了，当然这之中有权衡协商，但这都不CAP原理无关。在许多情况下，为全球消费大众确保低延迟而放弃少许的一致性也是有一定意义的。

　　#5 分布式系统没有控制狂的容身之地

　　关于Web服务有一个我们中间的技巧。它来自于Arnon Rotem-Gal-Oz，他是Nice Systems企业部分的架构主管。他承认参与在SOA或RESTful中的分布式事务有时意味着对完全控制的释放。例如，你不一定能确保事务可以完全回滚，当它走向了通往Web的康庄大道时。“当你做一些本质上灵活的事情时，你的事务的另一端最终可能是其它人的，而不是你的公司。你不可能承担保存所有的日志，为了那些超出你的服务范围的人。”他建议用Sega交互模式来弥补不可避免发生的故障。你可以免费阅读Arnon关于SOA和Saga的一些建议。