在宏观层面上，最好将团队视为达到目标和沟通的基本单位，完成相应工作的是团队，人们通过团队在组织内相互联系。为了充分发挥微服务的优势并管理它们的复杂性，团队需要采用新的工作原则和实践，而不是使用与构建单体应用相同的方法。
高效团队的原则包括所有权、自治和端到端职责。
1．所有权
拥有强烈主人翁意识的团队具有较高的内在动力，并对其所负责的领域承担很大的责任。由于微服务应用通常都有很长的生命周期，因此长期负责某个领域的团队在对该领域的知识和了解越来越深的同时还需要为代码演进提供支持。
在单体应用中，所有权通常是n : 1。多个团队拥有同一个服务，即单体应用。这种所有权通常划分成不同的层（如前端和后端）或功能区域（如订单和支付）。在微服务应用中，所有权通常是1: n，这意味着一个团队可能拥有和负责许多服务。
在1: n的所有权模型中，多个团队负责同一个服务，这通常是一种不好的实践方式。这会导致团队之间因为技术选型和功能优先级问题而产生冲突。
清晰的所有权能够为团队职责设置自然、合理的界限，同时确保所有权是团队的责任，而不是单个开发者的责任，从而帮助大家避免上述风险。
2．自治
能够自主工作的团队——对其他团队的依赖有限——可以减少工作中的摩擦。这种类型的团队内部高度一致，但与其他团队的耦合度较低。
自治对于扩大规模非常重要。对于一个开发经理来说，管理多个团队是一项很耗费心力的（更不要说团队没有自治权的情况下）；相反，开发者可以授权团队进行自我管理。
3．端到端职责
开发团队应该对产品拥有完整的“设想-构建-运行”循环。通过对所构建内容的控制，团队可以做出理性的、局部的优先级决策；展开实验；并在很短的时间周期内用真正的代码和用户验证所提出的想法。
大多数软件的运维时间要比构建阶段花费的时间长得多。但是，许多软件工程师将精力集中在构建阶段，最后将代码抛给一个独立的团队来运行。
软件如何运行，如何在现实世界中观察它的行为，这些都应该反馈给软件以进行改进。
端到端职责与自治和所有权紧密相关。在一个团队的生产路径中，跨团队的依赖越少，就越有可能控制和优化交付的进度；更广泛的所有权范围能够让团队合理、有效地承担更多的整体交付职责。
摘取自 摩根·布鲁斯和保罗·A.佩雷拉的《微服务实战》
网友评论