Booking.com的首席开发人员Ivan Kruglov在SlOmer DevOps上以主题为SRE进行了演讲，并在发言后同意在Booking.com上通过一杯咖啡讨论Kubernetes，Service Mesh，开源和“非标准”解决方案。
由于SRE的主题范围更广，因此，Ivan和Booking.com的首席开发人员同事Ben Tyler同意担任Slurm SRE的发言人，该会议将于2020年2月3-5日举行 。 它将讨论应用SLI / SLO /错误预算，事后分析，有效消除IT事件，构建可靠的系统（监视和警报，正常降级，故障注入，容量规划，防止级联故障）的理论和实践。 ）
现在对伊万说一句话。
最近对您而言，什么是有趣的职业挑战？
在过去的两年中，我一直在做两件事。 首先：做Booking.com的内部云。 它基于Kubernetes构建。 这次，我有一份关于Highload的漫长而全面的报告。
我们采用了漫长而有趣的方式来构建云。 这是我以前的项目，我留给了一位同事。
现在，我正在处理一个称为“服务网格”的主题。 实际上，这是一个热门话题，因为大数据和Kubernetes曾经是同一时代。
一方面，这个想法很简单，另一方面又很复杂-在微服务架构中，所有交互都通过网络进行，嗯，这是微服务不可或缺的一部分。 交互本身是一个复杂的操作，在那里可能会出错。 这整个事情需要加以控制。 特别地，施加了限制-如果我们拥有一个整体并且有两个功能起作用，并且这两个功能可以彼此信任，因为它们是同一过程的一部分，那么从理论上讲，现在微服务现在无法彼此信任。
您怎么知道请求来自哪里？ 这是一个微服务，一个HTTP请求来了。 他真的来自我认为的服务吗？ 同样，另一个服务需要该服务。 我需要确保我调用的服务是我需要的服务，而不是某种假冒的服务。 在小型组织中，情况可能并非如此。 在大型汽车中，当您拥有成千上万辆汽车时，您将不会跟踪每台机器。 对于大公司来说，这是一个相当严重的问题。 也就是说，一切都建立在零信任的基础上。 每当您进行某种形式的交流时，都必须进行验证。 事实证明，在网络交互级别，必须对操作进行身份验证和授权。 就实施而言，这些都是非常困难的过程。 事实证明，服务网格承担了这些任务，以确保安全的交互。 这只是Service Mesh的功能之一。 还有更多内容-可靠性，监视，跟踪等。
您认为这项技术是未来吗？
服务网格是一个不断增长的趋势。 这是我个人的看法。 这已经很普遍了。 例如，有Istio。 然后在同一亚马逊的云中出现了Service Mesh。 我认为所有主要供应商都将很快拥有或已经拥有完善的Service Mesh。
也就是说，与过去相同的突破性技术，现在有Kubernetes吗？
我也这么认为 尽管有趣的是，在我看来，Kubernetes和Service Mesh都不发明任何新东西。 Kubernetes采用了现有技术并将其自动化。 Service Mesh做大致相同的事情。 他在现有基础上提供了新工具。 Envoy已出现在Service Mesh中，我将在今天进行演示。 （请注意Ivan在Slurm DevOps密集的演讲中解决了这个问题 。）这个想法是Service Mesh是一种高级工具，可让您协调大型微服务群的通信。 我将解释...为了启动微服务体系结构，首先需要这个所谓的运行时-这是将启动应用程序的地方。 这就是Kubernetes所做的。 从某种意义上说，服务网格对它进行了补充，因为它提供了将在运行时运行的这些微服务之间的交互。
您会在不久的将来开发这项技术吗？
我可以为自己说话。 我参与了基础架构。 在基础架构方面，在未来几年中，这将是主要主题之一-Kubernetes和Service Mesh。
他们会平行发展吗？
当然，因为它们是相辅相成的。 Kubernetes执行运行时。 服务网格提供了互操作性。
更确切地说，Kubernetes的某些组件似乎涵盖了Service Mesh的各个方面。 但是在Kubernetes中，它们太基础了。 也就是说，就网络而言，Kubernetes仅提供低级网络。 我的意思是，IP数据包可以从A点到达B点。就是这样。 好的，有Ingress控制器，还有一些更高级别的路由，即不仅是网络交互。 但是，例如，在Kubernetes中，没有内置机制可确保查询执行的可靠性。 这样的例子很简单。 在Kubernetes中，如果“下”（Pod）掉下，Kubernetes会自行捡起它。 默认情况下。 这是重试机制。 但是在网络交互级别上，这不会发生。 也就是说，如果主页服务将请求发送到购物篮服务，并且由于某种原因该请求不起作用，那么将不会重试该请求。
服务网格在这方面增加了功能。 如果请求失败，它允许再次重复。 还有其他机制，例如离群值检测。 例如，如果我们有一组“ pods”用于“主页”服务，而一组“ pod”则是篮子服务。 如果它们在地理位置上是分开的，那么其中可能会出现“炉床”的一部分看到“炉床”的一部分，而“炉床”的另一部分看到“炉床”的另一部分的情况。 因此，在Service Mesh中，有一些机制可让您动态地建立任何人都可以访问的人的图片，并在他们之间进行切换-所有这些都是实时的。 而且，如果其中一个“炉灶”的延迟过长，则将其丢弃。 每个“下”的人都可以断定，有了这个“炉边”，我的谈话很慢-其他人都是正常的，这也很慢-因为我会将他赶出了我的讨论范围。 这就是检测异常的机制的工作方式。 当我们有十个“炉膛”时，九个“炉膛”正常工作，第十个炉膛不断发送错误。 或有9个“炉床”以15毫秒的延迟响应，有一个回答以400毫秒的延迟响应。 服务网格决定将其丢弃。
Service Mesh还擅长允许您在客户端收集统计信息。 也就是说，我们有一个客户端，我们有一个服务器。 通常，统计信息是在服务器端收集的。 好吧，因为这是最简单的。 我们希望使用指标来了解我们的用户与我们的服务交互的程度。 因此，从理论上讲，您需要在客户端而不是服务器端进行度量。 因为它们之间存在很大的差距，所以充满了网络交互。
整个品种的每个组件都可能失效。
Service Mesh的优势在于它可以来回放置代理-并从两端发送统计信息。 当服务端等待时间为20ms，而客户端等待时间为2秒时，可能会出现这种情况。 例如，在服务器端，我们从Web服务器收集统计信息，但是由于某种原因，我们丢失了5％的数据包。 结果，由于在TCP堆栈中进行了重新传输，事实证明我们的客户端看到了2秒的延迟。 并且在服务器端，我们仍然看到出色的延迟：当所有内容都发送到缓冲区时，就是这样！ 我很好，我有20毫秒的延迟。 和客户是什么样的？
您如何解决呢？
从根本上讲，这是通过客户端的工具来解决的。 以一种很好的方式，应尽可能接近客户收集统计信息。 但是客户工具并非总是可能且并非总是方便。
贵公司的可靠性和可用性指标是什么？
一切都从总体上来说是标准的。 今天我将谈论它。 （注意：Slurm DevOps第三天的Ivan演讲 ）有五个或六个关键指标。 所谓的服务水平指示器：延迟，耐用性，新鲜度，正确性...当我准备在Slurm上进行演示时，我试图在Booking.com上找到非标准案例，这些有趣的SLI示例不适合该模型。 因为从理论上讲，SRE的关键思想是基于这样一种高级声明-我们需要强调一个或多个能够反映用户体验的指标。 对于某些服务，延迟，持久性是合适的，而对于其他服务则不适合。 以及如何找到可以反映用户体验的平衡点-这是一项有趣的任务。
当您在Booking.com上工作时，看到了什么独特的解决方案？ 还是一切都是标准的？
不行 我们有很多“非标准”的东西。 让我们解释一下为什么它不是引号中的标准。 非标准来自哪里...非标准通常来自以下事实：公司比市场早发现了问题，因此没有“标准”解决方案。 在这方面，Booking.com是一家自1997年以来一直在市场上运营并已成长为如此规模的公司，一次面临着许多尚未解决的问题。
例如，谷歌。 根据我的观察，看起来像这样。 它们在内部进行重大开发，并在五到十年内公开展示。 例如，我与来自Google的修补Linux内核补丁的人进行了交谈。 然后我在TCP堆栈中遇到了某些问题。 我告诉他们：“这显然是核心问题。 您如何应对？” 他们说：“啊，所以我们有一个修补的内核。 在这里我们可以调整设置。 2013年，我们对其进行了修补。 而且我们只是在2018年以开源形式推出它。”
与Service Mesh大致相同。 它也建立在Google内部使用的技术形象中。 但是他们没有将其直接上传到开源。 Istio本质上是对其内部系统的开源重新实现。 以及Kubernetes。 我认为，这是因为当一家公司成为先锋时，它会为自己创建解决方案。 因为它更快，更便宜。 开源很昂贵。 不管谁说您需要传播它，您实际上都需要建立一个社区。 要建立社区，您需要投入大量的精力。 只有这样，回报才会归您所有。 在我看来，在任何严肃的“药房”之后，都有一个更为严肃的营销活动，自然而然地投资了金钱。
我为什么...正如我所说，在解决问题时，公司为自己做了很多事情。 然后将其开源是相当困难的。 您需要删节业务逻辑和许多小细节。 我们拥有自己的服务Service Mesh和我们自己的监控系统。 而要在开放源代码中传播它，则需要重做。 开源出版物具有其优势...
例如哪个？
技术品牌，忠诚度，更容易上手。 它们很重要。
您无法直接计算它们。
是的，没错。 不要直接数。 这是一项长期的战略投资。 我不赞成或反对开源。 您需要保持平衡，评估公司提供的特定技术发布的内容。 平衡长期和短期策略。
回到问题，Booking.com中的标准和非标准数量是多少。 我要说的不是大多数不是标准，而是很多。 因为我们正在解决市场上仍然未知的问题，或者其他公司才刚刚开始。 仅对于公司而言，解决自己的问题变得更加容易，快捷，便宜。
PS ：不可能在一个演示文稿中涵盖SRE的整个主题。 不仅有工具，而且还有方法的哲学。 因此，我们重点介绍了针对该主题的全面密集的Slurm SRE，该活动将于2020年2月3-5日举行 。 演讲者将是Booking.com首席开发人员Ivan Kruglov，Booking.com首席开发人员Ben Tyler，Tungsten Labs首席技术官Eduard Medvedev ，Google知名开发人员Eugene Varavva。