一些好的规则

向客户端的EC2可会见区域（EC2 Availability Zone）中的可用节点发送请求。若是这样的实例不存在，则在当前区域中找一个运行已凌驾一天的实例替换。

　　传统的负载平衡器并没有被设计成用来执行这种自界说逻辑。它们也无法获取太多关于客户端的信息（好比一个客户端所属的EC2可会见区域）。自界说负载平衡逻辑酿成了应用的一部门，使用相同的语言编写。这意味着编写代码的单元测试用例变得容易。而在传统上，这被以为是“基础设施的工具”。因此，这不仅让制订更庞大、更智能的决议成为可能；也使得人们对事情能准期完成更有信心。从某方面看，NIWS将DevOps带入了下一个条理：开发职员和运维工程师不仅坐在一起，在统一个团队中事情；而且他们使用相同的开发语言，向相同的代码库提交更新。

　　Prezi加入客户端负载平衡俱乐部

　　用一个内部的客户端负载平衡实现替换尺度的负载平衡器，这种让Netflix受益的手艺只适用于Netflix吗？纷歧定。在prezi.com，我们对内部流量也接纳了这种手艺。我们的一些应用服务器运行着若干个服务。当这些服务通讯时，我们希望它们优先选择当地的服务实例，而不是向网络中发送请求。然而，若是需要会见的服务没有运行在统一台服务器上，那么就可以会见任何一个该服务的实例。对于Prezi，获得的利益是，尽可能地制止了网络流量、淘汰了在AWS上的支出和响应时间。现在运行于prezi.com产物上的负载平衡逻辑由以下的这段Scala代码实现：

override def choose(key: scala.Any): Server = Option(getLoadBalancer).map(lb =>      lb.getServerList(true).filter{server =>          server.getHost == config.getHostname && serverIsAvailable(lb, server)      }).getOrElse(Seq()) match {      case Seq() => super.choose(key)      case matchedServers => matchedServers(0)} 

　　Netflix的工程师可以设计出NIWS，而不用担忧质疑当前手艺所带来的结果。由于公司的规则授权他们这么做。纵然任何人都可以获得NIWS的手艺，只有那些有着类似头脑的公司才气够使用这种手艺去搭建产物。详细来讲，期望工程师基于手艺价值做出决议的公司和完善主义的公司是无法使用这样的手艺的。

　　Netflix验证（Netflix test）

　　期望所有的工程师在做决议时不受办公室政治、盛行手艺和畏惧改变的制约，这是不行能的。然而，淘汰这些方面的影响，对确保开发不会误入邪路有很大的资助。一堆武断的限制划定会让工程师的设计缺乏创新和效用。相比之下，一些好的规则限制了问题空间、明确了约束、改善了产物的质量。

　　基于NIWS栈的源代码，Netflix在决议怎样实现一个组件时会思量两件事：

这个组件发生故障的可能性及结果是什么？当这个组件的设想场景发生改变时，是否容易修改这个组件的行为？

　　我将这些问题成为Netflix验证。这两个问题是精密关联的。甚至可以说，第二个问题包罗了第一个问题。这两个问题之以是意义重大，是在于他们如实地镜射出了Netflix的商业目的。这个目的就是提供可靠的、可扩展的服务。其他也有相同目的的公司也能从这个验证中受益。可是，这个验证的真正气力在于它没有提到的工具。它没有提到任何详细的手艺或者供应商。

　　不适用于完善主义者

　　真正让我惊讶的是，Netflix的代码只专注于足够好即可，而无过之。别误解，现在我所看到的代码容易阅读，而且有很高的单元测试笼罩率。即便云云，我也没有预推测Netflix能专注在足够好这个级别。好比，在代码的许多地方，当后台线程汇海之后，就再没有任何操作制止它们。这看起来有很大的问题，直到你意识到Netflix不在节点上举行软件升级。他们通过汇海一个新的EC2实例集群来部署新版本的应用。当通过监控验证新版本应用运行正常后，就将老集群关闭。若是有人使用了这些部署工具（也是开源的），那么就没有僵尸线程的问题。然而，若是有人在一个像Glassfish的应用服务器上使用Netflix的库，那么每次重新部署都将会触发内存走漏。

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