1.3 什么是服务

在本书中，“服务”这个词用得很多，这可能并不令人惊讶，因为它就是书名中的“S”。但是当我们谈论服务时，我们指的是什么？正如我们将用户定义为依赖服务的任何事物或任何人（无论是付费客户、内部用户还是其他服务），服务是任何拥有用户的系统！既然我们已经概述了关于如何度量服务可靠性的基本思想，那么让我们讨论一些服务是什么的常见示例。

本书有时用“系统”这个词来代替服务，这是因为计算机服务几乎总是复杂的系统。

服务示例

下面简要介绍一些常见的服务类型。这个列表并不是详尽无遗的，因为复杂系统通常在某种程度上是独一无二的。这只是思考服务的组成部分的一个起点，希望你能在下面的其中一个示例中看到与你的服务类似的内容。在本书中，特别是在第12章中，将为各种不同的服务类型提供示例SLI和SLO。

Web服务

什么是服务，最容易理解的应该是人们直接交互的基于Web的服务，例如，网站、视频服务、电子邮件服务等。这些类型的系统将作为一个很好的例子来进行讨论，原因如下：第一，它们通常要复杂得多，功能很多，这意味着它们对于考虑单个服务的多个SLI和SLO非常有用；第二，几乎每个人都与这样的服务进行过交互，而且每天可能都要进行多次交互，这意味着任何人都可以很容易地跟进，而不必对他们可能不熟悉的服务类型进行批判性思考。基于这些原因，我们将在本书中经常使用这类服务作为示例。然而，这并不意味着在任何情况下它们都是唯一的服务类型，或者是唯一可以通过基于SLO方法提高可靠性的服务类型。

请求和响应API

除了基于Web的服务之外，我们在讨论SLO时，最常见的服务是请求和响应API。这包括任何提供API的服务，该API接受请求然后发送响应。在某种程度上，放宽点说几乎所有的服务都在某种意义上符合这个定义。本质上，每个服务都接受请求并以某种方式对其做出响应。然而，术语“请求和响应API”最常用于描述分布式环境中的服务，这些服务接受一种形式的远程过程调用（RPC）和一组数据，然后执行处理，并返回一组不同的数据。

在讨论SLO时，通常讨论这种服务有两个主要原因。首先，它们非常普遍，尤其是在微服务的世界里。其次，与我们将要讨论的一些服务类型相比，它们通常非常容易度量。为请求和响应API建立有意义的SLI通常比为数据处理管道、数据库、存储平台等建立有意义的SLI要简单得多。

如果你不负责Web服务或请求和响应API，请不要担心，我们将在第12章讨论各种服务。我们还将在第11章深入讨论数据可靠性。

数据处理管道

数据处理管道与请求和响应API类似，即发送带有数据的请求并对该数据进行处理。最大的区别在于，管道处理之后的“响应”通常不会直接发送回原始客户端，而是完全输出到不同的系统。

数据处理管道很难开发SLI和SLO。管道的SLI很复杂，因为通常需要测量多个东西才能设定单个SLO。例如，对于日志处理管道，你必须度量日志摄取率和日志索引速率，以便更好地了解管道的端到端延迟。更可取的方法是在将特定记录插入管道后测量在另一端能检索到该准确记录所花费的时间，此外，在考虑管道的SLI时，你应该考虑测量到达另一端的数据的正确性。对于长管道或每秒看不到大量请求的管道，测量数据正确性和新鲜度可能比测量端到端延迟更有趣和有用。只要知道管道末端的数据在被频繁更新，并且是你所需要的正确数据即可。

SLO通常在数据处理管道中更为复杂，因为有太多的因素在起作用。一条管道必然需要不止一个组件，而且这些组件可能并不总是以类似的可靠性运行。数据处理管道的更多内容详见第11章。

批处理作业

比数据处理管道更复杂的是批处理作业。批处理作业是一系列仅在满足某些条件时才启动的进程。这些条件可能包括到达某个日期或时间、队列已满或资源在以前不可用时可用。度量批处理作业的一些好办法包括作业正确启动的时间百分比、成功完成的频率以及生成的结果数据是否新鲜和正确。你可以对许多批处理作业应用我们在数据处理管道中讨论的很多相同策略。

数据库和存储系统

在某种程度上，数据库和存储系统只是请求和响应API：你向它们发送某种形式的数据，它们对这些数据进行某种处理，然后它们向你发送响应。就数据库而言，传入的数据可能非常结构化，处理可能很紧迫，响应数据可能很大。另外，对于存储系统写入，数据的结构化程度可能较低，处理过程可能主要涉及在底层硬件层上的二进制操作，而响应可能只是对操作是否成功完成的判断。关键是，对于这两种服务类型，测量延迟和错误率（就像你对请求和响应API所做的那样）可能非常重要。

然而，数据库和存储系统还需要做其他更独特的事情。例如，与处理管道和批处理作业一样，它们还需要提供正确和新鲜的数据。但是，将这些服务类型区分开来的一点是，你还需要度量数据的可用性和持久性。为这些类型的系统开发SLI可能很困难，选择更有意义的SLO则更为困难。第11章将帮助你以最好的方式解决这些问题。

计算平台

所有的软件都必须运行在某个平台上，不管这个平台是什么，它也是一种服务。计算平台可以有多种形式：

• 在裸机硬件上运行的操作系统

• 虚拟机（V M）基础设施

• 容器编排平台

• 无服务器计算

• 基础设施即服务

计算平台并不是很难度量，但是当组织采用基于SLO的方法来提高可靠性时，它们常常被忽视。事实很简单，如果这些平台本身没有SLO目标，运行在这些平台之上的服务将很难选择自己的SLO目标。像这样的服务的SLI应该度量一个新的VM的实现速度，或者容器终止的频率。对于这些服务类型来说，可用性是最重要的，但是我们也不应该忽视度量持久性磁盘性能、虚拟网络吞吐量或控制平面响应延迟。

硬件和网络

在每一个栈的底部，你会发现还有物理硬件和允许各种硬件组件相互通信的网络。随着云计算的出现，并不是每个人都需要关心这个级别的事情，但是对于那些需要关心的人，你也可以在这里使用基于SLO的可靠性方法。

计算适当的SLI和设置适当的SLO通常需要大量的数据，因此如果你只负责某个数据中心中的几个机架，那么花费大量精力来设置合理的目标可能没有多大意义。但是，如果你有一个大型平台，你应该能够收集足够的数据来度量诸如硬盘驱动器或内存故障率、一般网络性能，甚至电源可用性和数据中心温度目标。

物理硬件、网络组件、电源电路和HVAC系统也都是服务。虽然这些类型的服务可能最需要追求非常高的可靠性，但它们也不可能是完美的，所以你可以尝试为它们的可靠性和操作选择更合理的目标。