一些好的规则

　　英文原文：A Few Good Rules

　　什么是明智的尺度化？

　　想象一下第一次和特殊的人约会。当你到达最喜欢的餐馆时，所有的灯都熄灭了，你身处漆黑之中。希奇的是，从厨房传来的声音又讲明这里像往常一样正在营业中。你听到一位女服务员走来，等候着指导你到没有灯光照射到的座位上。你的同伴不知所措，而且有一点畏惧。你是计划留下，照旧找个正常点的地方用饭？

　　Web应用就像餐馆一样，人们通过其所提供的体验对其举行评价。纵然是短暂的中止也会影响服务提供商的口碑或服务水平。政策和指导目标在防止价格高昂的服务中止中饰演着主要的角色。不幸的是，它们也能导致不理智决议的发生，从而造成更大的损害。好比公司内“DevOps团队”的建设。这将导致所有的运维知识都被隔离在一个单独的团队中。只管这样一个治理层指令可能预示着DevOps的到来，但它什么都不是。

　　工程师藐视无逻辑的、权要主义的规则。这些规则是前进的障碍物。然而，每家公司至少都市有一些这样的规则。在已往，可能有好的理由在一些问题上制订这样的规则。徐徐地，这些规则过时了。可是，规则制订者不能（或不敢）作废它们。当使用C++代码库时，由于历史缘故原由，被见告不能使用STL；到场的Java项目被坚定地拒绝从1.4迁徙到新版本。任何有过这样履历的人都明确有些措施可能会对生产力发生消极的影响。

　　我们应该遗忘这些规则吗？

　　面临这些像障碍物一样的规则，我们都很想将它们破除。不幸的是，“无为”的公司通常都没有乐成地破除它们。好的规则是一种主要的交流形式。这种形式关乎到恒久计谋、从已往吸收到凄惨教训、以及来自用户需求中的发现。理想情形下，一个组织制订的与时俱进的规则，可以资助小我私家增强做出准确决议的信心。在实践中， 这样的情形真的发生过吗？

　　一家公司是否拥有真正有用的指导目标，Netflix就是一个很好的例子。至少通过阅读他们的博客和开源的代码会给人留下这样的印象。好比，纵然没有和Netflix的任何员工聊过，我也能确定，“构建它，运行它”是一个他们怎样把开发和运维联合起来的不错的想法。另一个明确的原则是：写代码是为了构建一个可靠的、可扩展的服务，而不是为了其他目的。他们开源了所写的大部门后台软件。这个事实比任何事都更具有说服力。

　　Netflix已经构建了Netflix内部Web服务框架（NIWS）。这是一个自界说的软件栈，用于建立可靠地运行在云上的内部Web服务。NIWS接纳了一些不太盛行的手艺和不太常用的要领。使用这种与最佳实践南辕北辙的要领需要有相当强的自信。毫无疑问，部门可以归因于落实的政策。这些政策让工程师可以不受限制地思量问题。

　　Netflix的负载平衡

　　在Netflix怎样挑战通例的例子中，我最喜欢的是他们是怎样在NIWS中实现负载平衡的。面向客户的流量仍使用传统的负载平衡处置惩罚器（一个尺度的Amazon EC2 ELB），但对于Netflix服务器之间的流量，他们选择了一个完全差别的方案，称作客户端负载平衡（client-side loadbalancing）。基本头脑很简朴：作废专门用于负载平衡的节点。这些节点用于在Netflix服务器间转发流量。客户端自己维持着一张列表，记载了可用的后台节点。当客户端发送请求时，直接与所选的后台实例交互。而这样就没有须要使用专门的负载平衡器。

　　客户端负载平衡并不是Netflix发现的。可是， 它是著名的公司里第一个在基础架构中完全使用这种手艺的（公正地说，统一时期内，Twitter和Yahoo也在做基于相同观点的实验）。在多个后台服务器上做平衡的尺度要领是：通过一个负载平衡器，如Amazon EC2 ELB，或者在服务器上运行类似HAProxy的软件。对于这么要害的组件，使用守旧的要领和一种大多数工程师都熟悉的手艺是很有意义的。可是，险些没有公司在Netflix之前试验客户端负载平衡的要领。其真正缘故原由是，他们甚至都没有思量到这种要领。

　　对于从事大规模应用程序开发的软件工程师，天天都要和种种库和组件打交道。这有点像鱼和水的关系。在能使用一种特定要领乐成地构建系统这么多年后（也许几十年） ，对已经经由磨练的要领或者系统的构建模块提出疑问，这看起来是在铺张时间。在许多公司里，这些决议已经被写进政策中。这些政策基本上是不行变的。可是，Netflix接纳了客户端负载平衡的要领，并因此取得了显著的乐成。首先，他们从系统中移除了一个单点故障点（对于频仍地在没有忠告下就制止服务的EC2实例，这是一个重大的胜利）。其次，通过将负载平衡的逻辑集成进客户端，负载平衡的计谋可以参考客户端提供的信息。好比，思量以下的负载平衡规则：

 1/4    1 2 3 4 下一页 尾页