[译]英雄联盟的技术设计

2016-01-16 19:45:11 | 来源：玩转帮会 | 投稿：佚名 | 编辑：小柯

原标题：[译]英雄联盟的技术设计

[译]英雄联盟的技术设计

Cameron Dunn·2016-01-14 21:16

架构师（JiaGouX）我们都是架构师！

译者：杰微刊–缪晨

我是Cam Dunn,英雄联盟的技术总监。我始终觉得到底人类对于自己的历史有多少未知是一件很有趣的事情，因为没有时间没有录像。谁发明了锤子?带柄的锤子数万年前就存在了，但是没人确定谁造了第一个。有时历史就像我们集体宿醉酒醒时惊呼，“天哪, 我们昨晚到底做了什么?”

虽然Riot成立时语言已被发明，但是我们依然遭受了同样的问题——最初公司成型的几年里，什么事情都发生的太快，以致于我们有时忘记了把它们记下来或者拍下来。我记得我第一次参观一个Riot的数据中心，我看见在数个已经断电的机架中有一组还在运行的服务器。当我问起这事的时候，我得到的答案是, “哦，我们没法确定这几台机器上到底运行着什么，因此不敢关了。”

最后我们仔细确认了一下这几台机器，然后把它们关机了，但是这次经历使我反思：我们需要一个方式来对服务进行检索，即使我们不知道这是什么服务。我们需要对服务ID建立一个标准。但是这种标准要如何建立才更合适呢?

在Riot，我们高度重视团队自治权；事实上，我们将我们的团队形容为“高度一致，高度自主（highly aligned, highly autonomous）。”这种程度的自主性意味着对的技术设计书或标准的任何形式的正式审批—— 就是那种需要 “那个人(The Man)” (如下图) 在你的设计上盖章的行为 —— 在这里将不复存在。但是这并不意味着我们被给予了绝对的自由：我们有你期待的技术标准以及工程化的最佳实践。为了获得一致性我们引入了一套认证请求（RFC）流程。

“那个人”，他/她的各种形式

RFCs 不是我们发明的——因特网的标准都是RFCs，而且在各种社区中，像 Python 使用了一套类似的系统叫做 PEPs。我们继承了这个名字，但是根据我们自己的需要对流程进行了部分修改。

我们一般的RFCs的使用方式很简单：我们假设你需要新写一个系统，或者对现有系统做一些比较大的更新。你知道在Riot有很多优秀的工程师，甚至其中一些可能是你遇到问题的领域的专家。因此你写下你准备做什么，然后群发给整个工程师团队，来征询他们的意见。例如，为避免上文提到的 “神秘服务器问题”，我写了一篇RFC提议每个服务根据一个标准的机制生成一个ID，然后即使你不知道这个服务是什么，也能根据ID很方便的查到。

然后我给我的RFC一个唯一ID而且根据文章元数据加了一些标签来帮助其他可能有兴趣的工程师查找。标签可以包括团队或组织的名称，或者这篇RFC直接应用的领域。这些额外的细节可以帮助维护以及防止过载。由于所有人都有访问所有RFC的权限，这个系统可以帮你更容易的找到你所关心的内容。我的“神秘服务器”RFC最终被定为RFC100，然后我打上了“SOA”、“API”和“Standard”等标签，然后关心这些内容的人可以记录笔记和开始发表评论。

当你的提议得到反馈的时候，你可以决定怎么处理。这不是一个审批流程；这是为了得到有价值的意见。通常人们会选择忽略部分评论，但会在修改的时候参考其它的意见。有时人们无法得到任何可行的反馈，设计还是按照原来的样子。有时候，作者通过反馈意识到原先的问题，而把原来的主意彻底推翻。决定权始终在最初的工程师手中。

对RFC100，我得到了很多非常好的反馈。擅长设计API的工程师们指出我的我的提议太过模糊太过游戏化，也给了一些具体的改进意见。例如，我的背景是在游戏技术，所以我最初的建议所有的服务应该提交它的帧率，但帧率是个预告片游戏的概念，传统的web服务并没有这个概念。因此我们最后把它调整到一个更为适用、更为通用的指标。

在反馈方面，RFC100 并不是一个特别的例子。我每次写RFC，Riot总会有人在我的提议中发现一些改进或指出一些潜在的缺点。他可能是个有20年经历、写过数次类似系统的老鸟，也可能是年轻的甚至完全没接触过我提议中所涵盖的范畴，但依然能从我的提议中挖出一些缺陷。如果我已经开始编码，估计结局会差得多。

反馈是无价的，但是怎样才能让事情形成一种标准呢？如果每个人都只按自己想得去做，那事情**怎么一起搞？RFC流程使得Riot的员工在技术标准上达成一致。我们通过一个叫“接受”的流程来实现，通过团队（或数个团队甚至整个项目）可以选择性的接收一份RFC。

接受一份RFC简单的讲就是我们期望在“接受域”中的所有人都遵从这篇RFC的指引，如果这篇RFC的内容对他有意。有时他们什么都不必做——可能这篇RFC这对Java开发生效，但是他们是写C++的。或者，可能这篇RFC是讨论从游戏服务器上收集运行数据，但是他们是从事内部工具研发的。这没什么。在这里关键的因素是好的判断力。但是一般来说的如果有什么在“riot.lol”接受域内，那么它对所有的英雄联盟的工程师生效。通常当我们考虑是否要在整个项目中接受什么的时候，每个团队都可以在内部形成独立的接受域。

可以预见，任何类似的流程都面临怀疑而且需要不断的改进。在过去的三年里，我们以初始的流程为基础不断迭代，以进行简化与改进。例如，最初我们开始的时候，每个RFC都有一组作者认为在该主题“说话有分量”的“保管人”。然而，当你作为作者需要选出“保管人”列表中的其他人的时候，尝试选出关心该列表的人，其实是个伪命题，这样可能使得这份名单不那么有价值。我们现在更倾向一种自服务模型，通过有潜力的保管人自荐的方式，比让作者在全Riot的员工中选择他认为对自己提议感兴趣的人要靠谱得多。RFC100相当广泛适用，因此一堆写服务的工程师纷纷加入。这只是一个我们不断改进流程进而更符合我们目标的例子。

RIOT RFC LIBRARY

我们现在(约2015年10月) 有超过425 个RFC在我们内部资料库中，涉及到我们技术栈的方方面面。其中大部分为“你怎么想？”类型的提议，主要是作者想对自己的方法寻求反馈的。其中一部分是“标准” 类型的RFCs，定义了一些类似通讯协议或编码规范之类的。一部分的评论屈指可数，其它的有数以百计的评论。有的已经被我们废弃，也有的已经被我们作为全公司的标准。

最后，我的RFC100变成了一个叫做“查询与控制的RPC模型的”全公司的标准。他定义了一些标准点比如服务ID。现在你可以根据服务id查询Riot的任意服务，再也不会有服务因为“不敢肯定什么在上面运行，可能非常重要”这种理由而在运行。以后数据中心的参观者再也不会对着谜样运行的服务器抓耳挠腮了。

感谢RFCs，Riot的工程师每天苦恼的事情少了很多，现在我们有一种书写东西的方式对我们有效。在Riot没有人想做“那个人”，但是所有人都意识到分享我们技术设计和标准的价值。RFC流程给我们提供了一种去中心化且自服务的方式实现。

来源：公众号杰微刊

原文：http://mp.weixin.qq.com/s?__biz=MzIxMjE0MjM4NA==&mid=401929629&idx=1&sn=70f7e500306672ebd502e80131c097b0&3rd=MzA3MDU4NTYzMw==&scene=6#rd

转载文章，向原作者致敬！如有侵权或不周之处，敬请劳烦联系若飞（微信：1321113940）马上删除，谢谢！

·END·

架构师

我们都是架构师！

架构师订阅号，关注获取更多技术分享

现已开通多个微信群，有兴趣交流学习的同学

可加若飞微信：1321113940进群

合作邮箱：admin@137x.com