一些好的规则

　　代码中包罗大量单例模式的类，也是我未预推测的。当我们以一种Netflix未预见的方式使用一个NIWS库时，我们很快会发现自己在不停挣扎地使用错综庞大的手艺来处置惩罚问题。包罗使用多个类加载器。

　　最后，只管wiki页面上关于代码的文档有很大的资助，可是这样的文档太少了，许多细节都没有形貌。通常，代码就是文档。有频频，我在github issue tracker上找到了一些解决NIWS相关问题的最佳建议。

　　我的许多同事，在第一次接触Netflix生态圈时都有点不知所措。他们的第一反映是训斥那些写代码的工程师未经训练或者太懒惰。“应该有一些规则关闭这些没用的线程”，我听他们这样说着。然而，对于Netflix，我们所列出的NIWS的弱点，都不算是一个真正的问题。用于处置惩罚线程关闭的时间被用在了其他更需要的地方。若是有人想要以不支持的方式重用代码，那么单例模式的类只是其中一个会遇到的问题。最后，只管写文档是一件好事。可是，可读性高的代码和大量内部专业知识让文档成为了一个可选项。Netflix建设了关于线程治理、恼人的设计模式和最小化文档量的规则。通过建设这些规则，让工程师可以专注于其他主要问题。

　　事实上，我已经意识到Netflix的软件栈之以是乐成，是由于它有着兴旺的精神。这不仅让Netflix“砍掉了软件栈的一些边角”的事实可以被接受，而且现实上也催生了一个更好的产物。编写了大量形貌代码的文档还得保证文档不会逾期，由于代码总是在不停的演进。编写不会用到的特征会使开发者失去动力、且难已为团队证实自己，对社区也没有什么利益，由于这部门代码不会在产物中被验证到。在Prezi，我们有一些一直想开源的项目。但由于缺乏时间加入一些我们希望的革新，现在还不能将它们开源。Netflix乐成地开源了大量的代码却没有停业。由于它们一直专注于代码的可读性和单元测试，而不是加入过多的亮点，以及保证其不会过时。Netflix实行的这些合理规则，使得它的设计开发可以应对不停快速增加的用户；甚至是不停开源所写的代码。

　　因此所有的特定规则都欠好吗？

　　若是用Netflix验证再形成一些指导目标，那么这些目标是相当通用的。例如，通过起劲获得乐成的名言，像“花10%的时间用于归还手艺债”，或者手艺信息，如“0.6.1版的NodeJS使我们的Web应用变得不稳固，别使用它”。若是把从已往失败中总结获取的教训忘了，这岂非不是一种铺张吗？

　　这样的建议，和最佳实践、着名的组件一样，是很是有价值的。在加速开发和简化系统的运维方面，通过多年的验证，这些建议已经获得了工程师的信托。好比在Prezi，大多数后台系统都是用Python写的，并使用了gunicorn web服务器、Django web框架和MySQL数据库。在公司的初期，这个软件栈使得开发者能够专注于新产物的特征上。多年来，“使用Django和MySQL开发服务”就犹如“不要在周五下战书3点后部署”一样明确。这些都不是Prezi成文的规则，但却早已在实验中。

　　随着注册用户数从0攀升到4000万，许多当初接纳这个平台的现实情形都已时过境迁。好比，当所有的网站流量都由一个应用处置惩罚时，将所有用户数据存入一个MySQL数据库中是有意义的。现在，Prezi拥有许多自力的服务。这些服务对响应延时、可靠性和一致性上都有着差别的需求。许多服务运行在EC2上，将数据库当做键－值存储的容器，通过主键会见数据。第一年制订的手艺指导目标，只管在那时有用，但没有一条能资助我们应对现在工程上的挑战。

　　只要尺度的手艺和特定的规则没有过时，就能够引发工程师的产出。问题在于，当这些特定的规则不再适用时，仍然被强制实行。

　　牢固的接口集

　　对于已经由时的规范而言，一个问题（而且很常见）是软件接口的过时。我最喜欢的例子是Java Servlet API。纵然它并没有真的过时！现实上，它是一个优异的接口：直观、稳固、有完整的文档、许多差别应用服务器都是使用它实现的。

　　当Prezi决议探索JVM，将其作为我们可靠的Django栈的一个可选平台时，我们选择了一个轻量级的署理应用作为我们的试用项目。我强烈地讲明应该使用Jetty和Servlet API，而不是团队思量的另一个可选方案。这个方案使用一个不着名的Scala Web服务器。6个月之后，我们关闭了原有的署理程序，而用一个基于Spray（这个手艺我是投阻挡票的）写沈阳软件设计的程序取而代之。部门缘故原由是：对于我们的用例，使用它可以获得更高的效率。由于在我们的用例中，响应时间主要受发出的HTTP请求的响应延时的影响。我最先从代码层面思索：我们想要什么样的目的，想使用什么样的接口。我们怎样写单元测试。开发者社区有多大。这正是Servlet API在抽象层面解决的问题。我本应该思量（或谈论）关于它是怎样使用硬件资源的。详细来说，瓶颈在于：处置惩罚请求时是否需要大量的CPU或者IO资源。由于在我们的用例中，大部门时间都破费在等候发出的HTTP请求的响应上，以是没有这样的资源要求。这就是署理程序的本质。鉴于我们的用例，使用Servlet的要领对每一个请求都建立一个专门的线程，不仅毫无须要地限制了处置惩罚请求的并行数，而且也无法高效地使用内存。

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