ECI@创新科技 |微服务的回顾——从Netflix身上我们到底学到/没学到了什么（下）
ECI @HiTech开栏语
【ECI @科技创新】是由ECI@HiTech科技创新专委会每周从全球精选热门科技创新主题，帮助科技创新者和初创团队取得成功！让我们共同携手，寻找改变现有游戏规则的科技创新，激发人类的智慧和挑战，实现科技的创新和梦想。这就是科技创新的终极魅力！也是ECI”将创新带入生活Bring Innovation to Life” 的使命所在！
通常来说，科技的发展都会交替经历平台期和爆发期。平台期的科技创新更多聚焦于识别并解决客户现在的痛点，而爆发期的科技创新更多聚焦于引领并创造客户未来的需求，划时代的伟大科技创新往往诞生于此。
缺了什么？（超时和重试）
我们大部分时候使用TCP/IP。TCP是面向连接的。当你第一次尝试给某人打电话时，它会建立连接，然后发送请求。如果是安全连接，它会首先进行额外的握手。大多数情况下，在更高级别的系统中，我们只是想调用另一个服务，所以这在一定程度上在翻译过程中遗漏了。考虑连接超时时一定要非常小心，因为这一过程只是一次跳转，相对较短，而请求超时则是通过多个跃点进行端到端的传输。这些通常设置不正确，它们通常是全局默认值。很多时候系统会因为重试风暴而崩溃，仅仅是因为超时没有设置正确。大多数人设置的超时时间过长，重试次数过多。我更喜欢减少这种情况的发生。最终结果是服务正在执行无法使用的操作，并引发重试风暴。
我们将尝试用一些简单但有效的图表来阐明这一点。以下是一个正在运行的系统的示例。它发出一个请求，并得到了响应。如果中间的服务出现任何问题，由于有2次重试和2秒的超时设置，边缘服务在6秒内将无法响应。而中间的服务需要处理9个外出请求，这就意味着有9个线程在同时运行，而不是仅有一个。这种情况会导致内存耗尽，线程数量不足。原本运行良好的中间服务，由于下游服务的故障，可能会突然失效，导致边缘服务也出现问题。最终，你会遇到一个连锁问题：系统中一个失败的服务会导致整个系统的效率大幅下降，甚至完全崩溃。要实现这一点，你只需在所有位置设置相同的超时并增加重试次数。即使你只部分成功，首次失败后再次响应，仍会导致中间服务进行额外的无效操作，因为它是通过重试来完成的，但边缘服务已经放弃并再次调用。
要解决这个问题，您需要采用一个级联的超时预算。这意味着在系统中设置一个较长的超时时间，并使用级联超时。所有适合该超时时间的组件都应该被使用，就像望远镜的各个部分一样，一直深入到系统的最深处。
如果您拥有一个相对简单的体系结构，并且知道各个组件的执行顺序，那么您可以静态地设置超时时间。然而，在大多数情况下，您可能需要一个动态的预算或截止期限，以便在请求中传递。例如，您可以设定一个从边缘服务开始的10秒超时时间，这意味着在未来10秒内必须完成操作。如果超过这个时间，系统就会放弃任务并清理资源。另一方面，为了避免在同一个连接中向实例询问相同的问题，您可以在不同的连接中重试。
例如，如果边缘服务的超时时间为3秒，而中间服务的超时时间为1秒，并且有一个重试机制，那么即使中间服务在第一次尝试时失败，它也会在2秒内响应并重试，从而避免了超过边缘服务的超时时间。通过这种方式，您可以拥有一个快速失败的系统，并且能够更好地处理超时和重试问题。
为什么要尝试同样的服务呢？只是因为该服务可能正在执行垃圾回收或其他的操作，导致它在10秒或1分钟内停止与所有人通信，或者类似的情况发生。此外，还有其他许多原因。我们想要做的就是调用一个不同的连接，连接到不同的服务，第一次请求可能会失败，但我的第二次请求往往会成功。我们在Netflix实现了这一点。同样，我不知道为什么每个人都没有这样做。这听起来很明显，而且这种弹性非常重要。我认为这是另一个没有在某个地方被重视的教训。我们仍然看到许多框架和环境都存在重试风暴的问题，但是我们在十年前在Netflix解决了这个问题。
微服务多种策略
我们尝试了微服务，但并不奏效。有许多人抱怨说，也许我们应该停止使用微服务，因为它对我们不起作用。为什么它对你不起作用呢？微服务是相互加强的许多战术之一，这些战术形成了一个快速、有弹性、可扩展的系统。如果它不仅仅是微服务，那么它就是许多战术，你可能在使用更多话、效率低下的协议，或者你的系统边界不合适。如果所有事情都必须在毫秒内发生，你就构建一个大型服务来完成这个任务。这就是广告服务器的工作方式，它们必须快速响应。一个整体，因为你要在毫秒内响应，你必须这样做。或者，你正在进行高频交易，当然，整体构建，并非常小心如何构建它。如果你正在为世界另一端的人构建一个网页，你不需要把所有内容都放在一个实例中。你更感兴趣的是快速开发实践和更快创新的能力。
如果您缺乏弹性，那么可能还需要解决重试风暴的问题。例如，当某个服务出现故障时，重试可能会导致更多的故障，因此需要采取更复杂的策略来处理这种情况。此外，如果开发人员编写的代码不可靠，那么在面对突发情况时可能会更加困难。
混沌工程是一种用于提高系统弹性的技术，可以帮助开发人员更好地理解系统的行为并提高系统的稳定性。正确利用AZ可以提供更多的冗余和备份，从而提高系统的可用性和弹性。
可扩展性是另一个重要的因素，如果系统没有去规范化数据模型，那么在处理大量数据时可能会变得非常缓慢。后端的一些SQL查询可能会失败，因此需要采取一些措施来确保这些查询的成功执行。
垂直扩展可以将代码调整为更高效地运行在实例上，从而提高整体效率并减少成本。深度自动缩放可以将所有实例的平均利用率提高到40%到50%之间，从而更好地利用资源并减少成本。
购买预订和储蓄计划等措施可以帮助减少成本，但让利用率翻倍才是最有效的减少成本的方法。使用无服务器功能可以更好地利用资源，并减少对硬件的依赖。综上所述，提高系统的弹性、稳定性和可扩展性是减少成本和提高效率的关键。
Netflix及其他公司的系统思考
Netflix没有招聘毕业生，也没有实习生，仿佛正在组建一支奥林匹克团队。它不会让高中运动员加入这支团队，除非他们绝对能达到奥林匹克水平。如果你想在顶级联赛和顶级球队中效力，你必须经过联盟的考验并变得更好，这就是Netflix的态度。
他们确实在明确地撇取顶尖人才，为每个人提供这些超级明星工程师和奥林匹克运动员。你在Google或Facebook或其他地方工作了5到10年，然后加入Netflix。这里，我们欢迎那些经验丰富的工程师，他们在这里得到的益处远超过以前的工作环境。
本·克里斯滕森，这位建造了Hystrix系统的工程师，他说过一句话：“我们只是推了他一把，他便振翅高飞。”这正是Netflix的精神所在。我们鼓励创新，提供广阔的空间让工程师们自由发挥，从而释放出他们的全部潜力。来到Netflix，你也会感受到这样的鼓励和支持，而不是被阻碍或牵制。
这涉及到一些深度的思考和复杂性。有目的的系统代表了系统对发展的看法。我们假设在所有三个维度上都有多元性：功能、结构和流程。他在这里真正想表达的是，有很多方法可以达到我们的目标。有很多种方式可以审视功能、多种结构以及多种流程。如果我们把所有的事物都限制在一个功能、一个结构、一个流程上，那么我们就没有真正地代表一个适用于目的的有用的系统。
还有另一种看待这个问题的方法，那就是W.罗斯·阿什比的必要多样性法则。这个法则表明，如果你正在尝试管理某件事情，那么管理它的系统或方法必须具有至少与被管理的对象相同的复杂性。
然而，这里的问题是，人们往往倾向于简化，他们追求效率，忽视了事物的复杂性。当你得到一个新的首席信息官，他们可能会试图简化所有的事情，这样可能会扼杀一些重要的元素，导致系统无法再有效地运行。这是因为业务的复杂性需要由复杂的系统和流程来管理。
同时，演变的能力也意味着事物是模糊和不稳定，充满了复杂性和变化。如果你能管理和驾驭这种复杂性，那么你的业务就能够实现快速的发展。
另一段引人深思的引述出现在Netflix的文化资料中：“如果你想建造一艘船，不要召集人们收集木头，分配工作和发布命令。相反，要教授他们向往无边无际的大海。”这里的重点是我们想要为全世界建造电视。我们正在打造第一个全球电视台。为此感到振奋，去探索如何实现这一目标，而不是按部就班地详细规划。
总结
我们忽略了首要指令，因为我们没有在组织尚未准备好的情况下保护它们免受引入先进技术、知识和价值观的风险。在Netflix，我们也曾提出一些想法并与人们分享，有些人将其带回家并在其组织尚未准备好的情况下试图实施。我们也曾遇到过类似情况，而一些非常成功的公司实际上采纳了这些想法并将其推向新的高度，我们也在相互学习中不断进步。
注：本文内容转载于InfoQ文章：
Microservices Retrospective – What We Learned (and Didn’t Learn) from Netflix
（https://www.infoq.com/presentations/microservices-netflix-industry）
ECI Media官方媒体矩阵
联系我们
转载请在文章开头和结尾显眼处标注：作者、出处和链接。不按规范转载侵权必究。
未经授权严禁转载，授权事宜请联系作者本人，侵权必究。
本文禁止转载，侵权必究。
授权事宜请至数英微信公众号(ID: digitaling) 后台授权，侵权必究。
评论
评论
推荐评论
暂无评论哦，快来评论一下吧！
全部评论（0条）