架构设计篇之微服务实战笔记（九）

第十三章、微服务团队建设

13.1、建设高效团队

• 确保沟通渠道可控

• 清楚描述团队的责任和义务、提高独立性和灵活性

• 团队文化统一价值观

• 拉清边界，避免协调竞争关系

13.1.1、康威定律

设计系统的组织受到限制所以设计出来的架构方案等价于组织的沟通结构

13.1.2、高效团队原则

• 所有权（系统 Owner）

• 自治（服务责任到人）

• 端到端职责（设想-构建-运行）

13.2、团队模型

• 职能团队（准时交付和需求导向）

• 跨职能团队（KPI 和结果导向）

13.2.1、按职能分组

• 所有权不清晰

• 缺乏自治

• 没有长期责任感

13.2.2、跨职能分组

解决了职能分组的弊端

13.2.3、设置团队边界

利用产品模式形成的模型

• 观察团队规模（人数接近或者超过 9 人团队的工作可能有点多会遇到沟通耗时的问题）

• 考虑一致性（团队的活动是否紧密联系，否则存在割裂）

13.2.4、基础设施、平台和产品

在前期，团队同时负责构建微服务应用和支撑平台

建立平台团队

基础设施层沉淀一层

13.2.5、谁负责，谁值班

轮班制度

• 包容性（不区分职位高低）

• 公平性（正常工作之外的值班需要报酬）

• 可持续性（足够多的工程师轮值）

• 反射性（告警和监控页面，以及重要告警的级别控制）

13.2.6、知识共享

13.3、微服务团队的实践建议

• 工程师局部最优的解决方案

• 围绕问题来开展，不要蔓延

• 提高可观测整体服务并作出有效的决策难度很大

13.3.1、微服务变更的驱动力

• 新需求

• 缺陷

• 框架迭代

• 安全问题

• 可扩展性问题

• 依赖项变更

13.3.2、架构的角色

• 基于上下文做出决策

• 随着需求变化，服务的演进和业务本身的不成熟，目前的模型和计划都会容易变化

• 决策的数量会随着服务数量的增加而增加

建议

• 应用应与组织更广泛的战略目标保持一致

• 一个团队的技术选型不会与其他团队冲突

• 团队遵循共同的技术价值观和期望

• 跨领域的问题-如可观测性、部署和服务间通信

• 整个应用在面对变化时候是灵活的

13.3.3、同质性与技术灵活性

微服务应该是可替换的

13.3.4、开源模型

将开源模型应用于服务开发

• 减少团队之间的争论

• 降级技术孤立感和占有欲

• 帮助工程师理解其他团队的服务和更好的理解内部消费者的需求，实现组织的内部共享

13.3.5、设计评审

新的需求导致的信息语言不一致或者单个应用更优于微服务设计

• 不一致

• 次优设计决策

标准评审可以解决下这个事情

部分目的问题与背景功能要解决的技术问题或者业务问题是什么、以及为什么这么做解决方案打算如何解决这个问题依赖项与集成如何与现有的或者计划开发的服务、功能以及组件进行交互接口服务会暴露哪些操作扩展性和性能如何进行功能扩展、运维成本是多少可靠性希望可靠性达到什么程度冗余性备份、恢复、部署和回滚监控和仪表如何了解服务的行为故障场景如何消除潜在的故障影响安全性威胁模型、数据保护等上线如何上线该功能风险和开放问题识别哪些风险、哪些开发者不知道的内容

13.3.6、动态文档

通过注册中心可以管控

• 概述（服务的功能，SLA 等）

• 契约（HTTP、API 等说明）

• 使用说明（常见操作和故障场景）

• 元数据（编程语言、主框架版本号、支撑工具的链接、部署 URL 实际情况）

13.3.7、回答应用的问题

架构师应该清晰的事情

• 服务的语言栈

• 服务存在安全漏洞或者是否过时的版本依赖

• 服务 A 的上游和下游协作方是谁

• 服务存在波峰波谷问题，服务是否区分关键路径和非关键路径

信息补充

• 语言和框架选择信息需要代码分析或者存储库标签

• 依赖关系管理工具（Dependabot）扫描过时的库

• 持续集成作业运行任意的静态分析任务

• 网络度量指标和代码检测揭示服务之间的关系。