由独立团队负责的服务架构

什么是“由独立团队负责的服务架构（STOSA）”？STOSA对于由多个开发团队来负责并管理一个或多个系统服务的大型组织来说，是一个重要的指导原则。拥有一个STOSA的系统和组织意味着什么？要达到STOSA，必须满足以下几个条件：

• 你必须有一个基于服务或者微服务架构建立的应用程序。

• 由多个开发团队负责构建和维护这个应用程序。

• 应用程序中的每个服务必须分配给某个开发团队，由它们所有。哪个团队所有哪个服务应该有良好的文档记录，并且组织中的每个人都可以很方便地知道。

• 不允许有某个服务被分配给多个开发团队。

• 一个开发团队可能会负责多个服务。

• 开发团队负责管理服务的所有方面，从服务架构到设计再到开发、测试、部署、监控和故障处理。

• 服务之间有清晰的边界，包括文档编写良好的API接口。

• 服务拥有自己的数据。数据是服务的一部分。如果一个服务需要访问存储在另一个服务中的数据，那么它必须使用一个文档编写良好的API来访问这些数据。

• 各服务负责维护服务之间的服务等级协议，开发团队负责对服务进行监控和报警。

一个基于STOSA的应用程序，就是一个所有服务都满足以上条件的应用程序。一个基于STOSA的组织，就是所有服务团队都满足以上条件，并且所有应用程序都是STOSA应用程序的组织。

在一个基于STOSA的组织中，每个团队的大小是确定的（通常在3～8人之间）。如果一个团队太小，它无法有效管理某个服务。如果团队太大，管理团队的工作会太繁重。

图6-1展示了一个基于STOSA的组织，以及它是如何来管理STOSA应用程序的。

图6-1：管理基于STOSA应用程序的STOSA组织

在图6-1中，标识从A到L的方块表示应用程序中每个独立的服务。椭圆表示完全负责这个服务的开发团队。

这个应用系统包含了由6个团队管理的12个服务。你会注意到，每个服务由一个团队来管理，但是一个团队可能会管理多个服务。每个服务都有一个所有人，并且一个服务只能有一个所有人。

应用程序的每个方面都有清晰的所有权，对于系统的任何一个部分，你都可以很容易地知道谁是负责人，以及有疑问、问题或者改动应该联系谁。

图6-2展示了一个非基于STOSA的应用程序和组织。

图6-2：非基于STOSA的组织

你会注意到几件事情。首先，服务I没有所有者，并且服务C和服务D归属于多个团队。

在图6-2中，服务之间没有清晰的所有权。如果你需要在服务C或者服务D中完成某些事情，不清楚谁应该为此负责。如果其中一个服务出现问题，应该由谁来响应？如果你需要让服务I来完成某些事情，你应当联系谁？缺少清晰的所有权和责任会让一个复杂系统变得更加难以管理。