超级会员免费看
微服务团队构建与实践指南
1. 团队模型
在构建微服务团队时，可依据康威定律的逆定律，即通过塑造组织的结构和职责来实现理想的系统架构。不过，确定团队之间的合理边界并非易事，需遵循以下两条通用规则：
-
关注团队规模
：若团队人数接近或超过9人，可能意味着团队承担的任务过多，或者会面临沟通成本过高的问题。
-
考虑团队活动的连贯性
：团队所开展的活动是否具有内聚性和紧密的关联性？若不是，则团队内部可能存在不同的连贯工作小组，可进行自然拆分。
2. 基础设施、平台和产品
虽然端到端的所有权模式值得提倡，但并非总是可行。大型公司的底层基础设施或微服务平台通常较为复杂，需要统一的路线图和专门的投入，而非不同团队的DevOps专家之间松散的协作。
-
初期阶段
：在开展微服务工作的初期，构建应用程序的团队通常也负责构建平台。
graph LR
classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px
A(Microservice team):::process -->|Builds| B(Application):::process
A -->|Builds| C(Platform):::process
A -->|Supports| B
A -->|Supports| C
- 发展阶段 ：随着时间推移，平台需要服务多个团队，此时可成立平台团队。
graph LR
classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px
A(Product teams A):::process -->|Builds| B(Application):::process
C(Product teams B):::process -->|Builds| B
D(Product teams C):::process -->|Builds| B
E(Platform team):::process -->|Builds| F(Platform services):::process
E -->|Supports| F
F -->|Enables| B
- 进一步拆分 ：根据公司需求和技术选择，可进一步拆分平台团队，区分核心基础设施问题（如云管理和安全）和特定的微服务平台问题（如部署和集群操作）。这种情况在拥有自有基础设施而非使用云服务提供商的公司中尤为常见。
graph LR
classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px
A(Product tier: Application Services):::process -->|Builds| B(Application):::process
C(Platform tier: Observability, Deployment, Cluster, Security, Networking, Storage...):::process -->|Builds| D(Platform):::process
C -->|Supports| D
E(Infrastructure tier):::process -->|Builds| F(Infrastructure):::process
E -->|Supports| F
D -->|Enables| B
F -->|Enables| D
3. 谁负责值班？
DevOps理念对微服务方法产生了深远影响。“你构建，你运行”的思维模式对于做好微服务至关重要，团队对其服务的运营生命周期负责，将有助于构建更优质、稳定和可靠的应用程序，这包括为生产服务随时待命响应警报。
在三层模型中：
- 工程团队负责处理自家服务的警报。
- 平台和基础设施团队负责处理底层基础设施或共享服务（如部署）的问题。
- 两个团队之间应存在升级路径，以支持问题调查。
graph LR
classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px
A(Product):::process -->|Alerts| B(Errors, anomalous latency/throughput, events from application code):::process
C(Platform):::process -->|Alerts| D(Errors, saturation, anomalies from underlying cluster or tools, e.g., cluster, databases, deployment):::process
E(Infrastructure):::process -->|Alerts| F(Errors, saturation, anomalies from underlying infrastructure, e.g., network):::process
B -->|Teams| G(Application):::process
D -->|Teams| G
F -->|Teams| G
一个成功的值班轮换制度应具备以下特点：
-
包容性
：所有有能力的人都应参与，包括副总裁和总监。
-
公平性
：值班工作应在正常工作时间之外给予报酬。
-
可持续性
：参与轮换的工程师数量应足够，以避免疲劳和对工作生活平衡或日常工作的干扰。
-
反思性
：团队应不断审查警报，确保只有重要的警报才会唤醒值班人员。
4. 知识共享
虽然自治团队可以提高开发速度，但也存在一些缺点：
- 不同团队可能会以不同方式多次解决相同的问题。
- 团队成员与其他团队的专业同行交流较少。
- 团队成员可能在不考虑全局背景或更广泛组织需求的情况下做出局部决策。
可以通过以下方式缓解这些问题：
-
采用Spotify的章节和公会模式
：章节按功能专长分组人员，公会围绕跨领域主题分享实践经验。
graph LR
classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px
A(FE dev):::process -->|Belongs to| B(Frontend chapter):::process
C(Dev):::process -->|Belongs to| B
D(Designer):::process -->|Belongs to| B
E(Test):::process -->|Belongs to| B
F(FE dev):::process -->|Belongs to| B
G(FE dev):::process -->|Belongs to| B
H(Dev):::process -->|Belongs to| B
I(Test):::process -->|Belongs to| B
J(FE dev):::process -->|Belongs to| B
K(Dev):::process -->|Belongs to| B
L(Dev):::process -->|Belongs to| B
M(Payments):::process -->|Part of| N(Team):::process
O(Growth):::process -->|Part of| N
P(International):::process -->|Part of| N
Q(Belongs to):::process -->|Performance guild| R(Shared practice):::process
- 矩阵管理 ：一些组织使用矩阵管理为职能单元建立正式身份，但会增加管理结构的复杂性。
定期在团队之间轮换工程师有助于知识和技能的共享，是章节和公会模式的有益补充。
微服务团队构建与实践指南
5. 微服务团队的推荐实践
微服务应用的变革规模巨大，可能会让工程师难以跟上步伐。同时，将人员分组为独立团队可能不利于形成全局视角。这些因素会带来一些文化方面的影响：
- 工程师设计的解决方案可能仅在局部最优，对自身或团队有利，但不一定适合更广泛的工程组织或公司。
- 可能会绕过问题而不是解决问题，或者部署新服务而不是修复现有服务的问题。
- 团队的实践可能高度本地化，使工程师难以在团队之间流动。
- 架构师或工程负责人难以全面了解情况并做出有效的决策。
为避免这些问题，团队在构建和维护服务时应遵循以下实践：
6. 微服务变更的驱动因素
日常工作中，产品团队的待办事项主要是功能性的添加或变更，如推出新功能、响应客户新需求、进入新市场等。微服务旨在确保应用在面对变化时具有灵活性，但功能性需求并非服务变更的唯一驱动因素。每个微服务可能因以下原因发生变化：
| 驱动因素 | 说明 |
| — | — |
| 底层框架和依赖项升级 | 如Rails、Spring或Django等，可能出于性能、安全或新功能的考虑进行升级。 |
| 服务不适用 | 例如达到自然可扩展性限制，需要进行更改或替换。 |
| 发现缺陷 | 包括服务本身或其依赖项中的缺陷。 |
这些变更会增加复杂性，例如需要确保工具支持跨多个应用程序的静态分析和警报。一些微服务从业者主张采用不可变服务，即服务成熟后进行功能冻结，若需要变更则添加新服务。但这涉及到成本效益的权衡，需要根据业务背景和风险承受能力来决定。
7. 架构的作用
微服务应用会随着时间不断演进，团队会构建新服务、停用现有服务、重构现有功能等。这种快速变化和灵活的环境改变了架构师和技术负责人的角色。
架构师在指导应用的范围和整体形态方面起着重要作用，但不应成为瓶颈。在微服务应用中，过于规定性和集中化的重大技术决策方式并不总是有效，原因如下：
- 微服务方法和团队模型应赋予本地团队在无需多层审批的情况下快速做出符合上下文的决策的权力。
- 微服务环境的灵活性意味着任何总体技术计划或预期系统模型都会很快过时，因为需求会变化，服务会演进，业务也会成熟。
- 随着服务数量的增加，决策量也会增加，可能使架构师不堪重负，成为瓶颈。
不过，架构仍然是有用且必要的。架构师应具备全局视角，确保应用满足全局需求，引导其演进，使应用：
- 与组织的更广泛战略目标保持一致。
- 一个团队的技术选择不会与其他团队的选择冲突。
- 团队共享一套共同的技术价值观和期望。
- 跨领域问题（如可观测性、部署和服务间通信）满足多个团队的需求。
- 整个应用在面对变化时具有灵活性和可塑性。
架构的最佳起点是设定原则。原则是团队为实现更高层次目标应遵循的指导方针（有时是规则），它们会影响团队的实践。例如：
| 目标 | 原则 | 实践 |
| — | — | — |
| 进入新市场 | 1. 支持灵活的区域要求
2. 设计适应多个云区域
3. 支持国际化（i18n） | 1. 将区域规则编码化
2. 使用多主存储（如Cassandra）；服务采用12因素原则设计
3. 选择具有良好i18n支持的UI框架 |
原则应具有灵活性，可根据业务优先级和应用的技术演进进行调整。一些日常实践，如设计评审、内部开源模型和实时文档，有助于实现这种演进式架构。
8. 同质性与技术灵活性
在选择编写微服务的语言时，会面临一个棘手的决策。虽然微服务提供了技术自由，但使用多种语言和框架会增加风险：
- 由于共享知识有限，关键人员依赖和单点故障风险可能增加，使服务的维护和支持变得困难。
- 新语言编写的服务可能不符合生产就绪标准。
在实际应用中，有时确实需要选择不同的语言，例如满足特定功能或性能需求。在这种情况下，应让更多团队成员参与新语言/框架服务的开发，以降低关键人员依赖风险，具体操作如下：
1. 轮换团队成员，让更多人熟悉新语言和框架。
2. 采用结对编程的方式，促进知识共享。
3. 编写详细的文档，方便后续人员理解和维护。
4. 为新工程师提供指导和培训。
选择单一主要语言或少数几种语言，可以更好地优化实践和方法。创建服务模板、底盘和/或示例将自然地简化在偏好语言中的开发，吸引更多开发者使用该语言编写服务，形成良性循环。即使没有明确选择偏好语言，这种情况也可能自然发生，但所需时间更长。需要注意的是，微服务应具有可替换性，必要时应能够用更合适的编程语言重写任何服务。
9. 开源模型
将开源原则应用于微服务代码有助于缓解团队间的冲突和技术孤立问题，同时促进知识共享。在微服务组织中，每个团队通常拥有多个服务，但每个生产服务都必须有明确的所有者，负责其功能、维护和稳定性。
这并不意味着只有所有者团队的人员才能为服务做出贡献。其他团队可能需要调整功能以满足自身需求或修复缺陷。采用内部开源模型（即在组织内部实行开源）可以平衡所有权和可见性：
- 任何服务的源代码都应在内部可用（某些高度敏感的代码可能除外）。
- 任何工程师都可以向任何服务提交拉取请求，但需要服务所有者进行审核。
这种模型类似于大多数开源项目，核心提交者团队进行大部分提交和关键决策，其他人可以提交更改供审核。例如，团队A的工程师需要对团队B拥有的服务进行更改时，可以自己拉取代码、进行更改并提交拉取请求供团队B审核。这种方法有以下三个好处：
- 缓解团队间的冲突和优先级协商问题。
- 减少因服务工作局限于少数人而产生的技术孤立和占有感。
- 通过帮助工程师了解其他团队的服务和内部消费者的需求，促进组织内的知识共享。
graph LR
classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px
A(Team A):::process -->|Submits| B(Pull requests):::process
C(Team N):::process -->|Submits| B
D(Team B):::process -->|Reviews| B
B -->|Merged| E(Service codebase):::process
D -->|Owns| E
综上所述，构建高效的微服务团队需要综合考虑团队模型、基础设施、值班制度、知识共享以及各种实践方法，以应对微服务应用带来的挑战和变化。
扫一扫
61
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
