当公司考虑如何重组他们的组织时，他们往往关注必须填补的新角色和员工需要学习的技能。然而，重组你的组织以支持基于微服务的应用，不仅仅是一些角色和职称。公司为微服务进行重组需要整个文化的转变和新的工作方式。
层次分明的组织
为了利用面向服务架构的大部分价值，你必须将传统的等级制组织结构转变为更加横向的组织结构。
在传统的等级组织中，如图1所示，你的工程公司是围绕着角色和工作职能组织的。在这里，多个开发团队被创建，每个团队负责构建应用程序的一部分。一旦他们完成了指定的工作职能，责任就会移交给下一个小组，通常是QA小组，由他们进行测试和其余的工作职能。最后，责任被移交给一个IT运营团队，负责托管和运营应用程序。此外，其他小组也有自己的角色和工作职能，如安全小组，负责保持产品和公司的安全和保障。
每个人都有自己确定的工作职能。每个人都有自己分配的角色。问题是，没有人对整个产品负责。没有人拥有这个应用程序。在组织上，你必须一直到工程管理的最高层--如工程副总裁或CTO/CPO--才能找到拥有和管理整个产品的人。这种类型的结构导致了指责和 "不是我的问题 "的心态。
每个人都有自己的角色，但没有人有责任。
当你使用微服务构建你的应用程序时，其中一个优势是能够将应用程序的小块作为一个整体来定义和管理。当你保持传统的组织结构时，这个优势就不那么有用了。你只是从一个没有所有者的大型应用，转变成数百个没有所有者的小型应用。
为了充分利用微服务应用架构的结构优势，你必须修改你的组织结构，以配合这种模式。最重要的是，你必须从角色和工作职能分配模式转向所有权和责任分配模式。
豆荚模式
在Pod模型中，你的组织不是按工作职能划分的；相反，它被分割成小型的、跨职能的团队，称为Pod。每个团队都有能力、资源和所需的支持，完全负责整个应用程序的一小部分--微服务架构模型中的一两个服务。
一个在应用中拥有微服务的pod通常由6-10人组成，具有以下类型的工作技能：
- 团队管理
- 软件开发
- 软件验证
- 服务运营
- 服务扩展和维护可用性
- 安全性
- 运营支持和维护
- 基础设施运营维护（服务器等）
我使用工作技能这个词，因为团队拥有必要的技能来完成这些工作是很重要的。但是，在一个豆荚模型中，豆荚作为一个整体有责任，没有一个人被分配具体的工作职能。换句话说，豆荚里没有 "安全人员"、"DevOps人员"、"QA人员"。相反，豆荚中的每个人都分享整个豆荚的职责。
图2显示了使用pod模型的同一个组织。每个pod都是独立的，相互之间是对等的，每个pod都提供跨职能的责任：
图2.基于豆荚的组织结构
所有权是关键
成功运作pod模式的关键是创建pod，其职责不是具体的工作职能。相反，他们的职责是所有权。一个pod拥有一个服务或一组服务。所有权意味着他们对服务的架构、设计、创建、测试、操作、维护和安全有完全的责任。没有其他人拥有所有权，只有指定的pod。如果该服务发生任何问题，都是该pod的管理和修复责任。这完全消除了在服务失败时指责其他团队的能力。拥有服务的pod才是负责任的。这在图3中得到了说明，相互连接的服务用蓝色表示，而拥有这些服务的pod用红色表示：
图3.每个服务都有一个所有者。
每个服务都有一个所有者，如果一个服务出现故障，哪个pod负责解决这个问题是完全清楚的。
跨服务指责
但是，如果问题跨越了服务的边界，会发生什么？例如，如果图3中的服务E给服务C带来问题，会发生什么？在这种情况下，可能会出现两个服务都有问题的情况，而且可能不清楚问题的根本原因在哪里。因为这两个服务是由不同的pod所拥有的，哪个pod拥有这个问题？答案可能很难确定，也很复杂。在Pod 2和Pod 4之间指手画脚绝对是一种可能。
如果你已经成功地建立了一个pod模型，并将强烈的所有权思想根植于pod的成员中，在这种情况下，指责的可能性应该很低。在一个高质量的团队组织中，应该发生的是Pod 2和Pod 4共同解决这个问题。
虽然这是事情应该发生的方式，但这是不够的。该模型必须帮助快速而果断地解决这些所有权问题，以保持你的应用程序工作，在规模上，并保持高可用性。这就是你的微服务架构的两个特点的关键所在：精心设计和记录的API以及坚实的、可维护的SLA。并非每个提倡转向微服务架构的人都会推动这两个特征；但在我看来，它们是坚实的微服务架构的两个最重要的特征，而且它们对所有权组织模式至关重要。让我们来看看这两个微服务特征：
- 精心设计和记录的API：你的应用程序中的每一个服务都必须有一个精心设计的API，描述该服务应该如何使用以及如何与之对话，而且这个API必须在整个组织中得到良好的记录。当我们在谈论暴露给客户的API时，我们习惯于设计良好的和有文件记录的API。但在内部服务中设计高质量的API也同样重要。 任何服务都不应该在没有使用明确定义和记录的API的情况下与任何其他服务对话**.**这可以确保对每个服务做什么和不做什么的期望是明确的，而这些期望会推动更高质量的互动，从而减少应用问题。
- 坚实的、可维护的SLA：除了有API，还必须围绕这些API建立一套性能预期。如果服务C正在调用服务E的API，那么服务C必须了解它可以从服务E那里得到的性能期望。如果调用率增加，延迟会怎样？对一个服务的调用频率是否有限制？当达到这些限制时会发生什么？
API是关于理解，而SLA是关于期望。API帮助我们了解其他服务做什么以及它们负责什么。SLA帮助我们知道从性能角度看，我们可以从服务中期待什么。
如果图 3 中的服务 E 有一个定义明确的、记录在案的 API，并有关于如何使用它的定义明确的 SLA，而且它遵守这些 SLA，那么只要服务 C 按照记录在案的 API 使用该服务并保持在定义的 SLA 内，服务 C 就应该能够期望从服务 E 获得合理的性能。
现在，在上面的假设例子中，服务E给服务C造成了问题。在这种情况下，与记录的SLA相比，测量的性能应该很明显，服务E有问题，而不是服务C。通过使用监控和API/SLA管理，诊断问题变得容易得多。
Pods需要支持
在pod模型中，pod有很大的责任和很大的权力。组成一个pod的小团队（6-10人）不可能在没有支持的情况下处理服务所有权所有方面的广度和深度的责任。
为了给他们提供支持，创建了横向服务团队，为服务所有权的pod提供工具和支持。这些团队可以处理独立于pod的常见问题，如创建CI/CD管道，了解全球安全问题，创建管理基础设施的工具，以及维护供应商关系。然后，pods可以利用这些团队来增强pod，给pod以支持。这在图4中得到了说明。
需要注意的是，这些支持团队是在支持pod，而不是--也不能从pod那里夺走所有权责任。如果服务中存在安全问题，问题的责任在于拥有该服务的pod，而不是安全支持团队。荚有最终的控制和决策责任，因此对他们所拥有的服务的所有方面的操作都有最终的责任。
总结
在你的应用架构中转向服务/微服务架构是构建和管理大型复杂应用的宝贵工具。然而，仅仅改变架构是不够的。你必须更新你的组织结构以支持新的架构模型，否则你将无法有效地利用服务架构提供的优势。如果不同时围绕这些变化来组织你的团队，你就有可能回到旧的习惯和流程中去，这将导致缺乏所有权和责任感，以及你在转移到服务架构之前的同样的一般问题。
