剑客
关注科技互联网

当你的团队是一个分布式系统时……

关于团队结构,有很多学问和秘密。小数在上一篇文章中与大家探讨了当 DevOps 运用到开发与运维团队中的几种情况。今天我们上升一步,把整个团队组织看做是一个分布式系统时,它是否适用于CAP理论,又会有哪些新的发现?

对于团队来说,CAP理论意味着什么?在分布式数据库系统中,CAP理论是这样的:只能在一致性、可用性和隔离性中选择两个——而隔离性是必选的。

开发一个软件系统,除非软件全部由一个人搭建,否则必须要选择隔离性。因为众人的想法不能融合,交流十分缓慢。

在数据库,我们选择一致性(数据相同)和可用性(可以获取数据)。随着团队成长扩大,我们会选择一致性(以同样的方式和理由做事)和执行力(把事情真正地完成)。

换句话说,撇开CAP理论,我们平衡了抱团和前进的节奏。

抱团,齐步走

一组一人的形式不值得提倡:决策虽然具有一致性,所有的工作都不停歇,但是输出却很有限,一旦某个人生病,所有的事情都会停下来。

2到7人组成的团队很理想:沟通伴随着想法相互碰撞,对话后全新的产出弥补了交谈花费的时间成本。它仍然具有可行性,因为团队里的每个人了解团队其他人的心智模式(mental model),清楚每个人各自需要什么。当利益相关者彼此成为朋友,一致性也很容易达成。

一个2到7人的团队紧密地工作在一起,这个空心向上的箭头代表了他们的潜在产出是很高的。 当你的团队是一个分布式系统时…… 这支团队构建了系统,运营一家便利店,他们全力前进,实心代表了真正的产出。

当你的团队是一个分布式系统时…… 接下来我们添加更多的网站,同时开发销售点收款的工具。团队分裂为两个。我们仍然使用同一个项目数据库,打造着同样的品牌,所以依然紧密合作着。我们利用彼此的工具。更多的人意味着更多的协调成本,但是大家是一个整体,互相喜欢,所以并没有太多负担。

当你的团队是一个分布式系统时…… 一个绿色箭头,一个红色箭头,彼此通过连线来沟通,工作上都是半满的。

现在商店运营得很好,网站吸引了更多的零售业务,邻近的便利店想在我们的网站上宣传他们的东西,一切都很顺利,我们也招聘了更多人进来。一个负责合作伙伴的团队,意味着我们需要对外做报告,需要一个数据管道(data pipeline)。 当你的团队是一个分布式系统时…… 紫色和蓝色的箭头加入,线交错纠缠在一起,这些箭头都只填满了一点点,因为合作成本增加。紫色箭头连接的比较少,并且比较满,但是它向左偏移了30度。

我们不再使用相同级别的一致性和协调性。协调成本沉重,新人进来后不了解其他人的情况。合作伙伴关系团队接触数据库,可能会破坏销售点或者网站。每个人都要检查每件事,所以最慢发布的那个团队定下了整体的节奏。紫色团队在协调上花费了更少时间,数据管道正在建设,但是和绿色团队并没有任何关系,也不会和销售点有任何合作。

方向正朝着混乱发展,我们如何才能在规模扩大的同时稳步前进呢?

独立,大步走

另一个极端是去耦合,划清边界。在数据管道、销售点和网站之间有非常明确的API。将数据库分开,必要时复制数据。这是一种不同的开销:更多的技术,更少的人。打破了数据库的后端耦合;打破了前端API耦合及其向后兼容性;团队彼此运作自己的日程安排,发布不再需要协调。这由更广阔的箭头来表示,因为向后兼容和graceful degradation的代价都是昂贵的。 当你的团队是一个分布式系统时…… 四个箭头,每个都是短而宽的。彼此有很少的连线。但是工作横向扩展(厚重)比纵向(项目方向)更多。

这些团队和上文协调负担沉重的团队相比,跑得一样远。差别在于:它可以横向扩展。我们可以在沟通成为限制项之前增加更多的团队。

亚马逊是这种模式的极端例子:向后兼容所有事情。每个团队全副武装后前进。一切完全独立,没有团队可以预测其他团队的情况。它使得AWS的产品成为可能。然而,它带来了大量的技术开销,以及不那么亲和的工作文化。

谷歌走向另一个极端。他们的monorepo允许更多团队之间的耦合,库是共享的。他们通过极度的工具化来弥补——测试,重构工具,自定义版本控制和构建系统,甚至整个编程语言。成千上万的工程师在为谷歌的基础设施工作,所以他们通过技术开销来实现并头前进。

平凡如我们,平衡一下吧

对于谷歌亚马逊之外的我们来说,公司里有7-1000个工程师,不能过于极端化。我们不禁要问:哪里的一致性比较重要?哪里的一致性会阻碍我们前进?

目标和方向上的一致性是非常重要的。我们建立了相同的业务,所追求的业务结果最好也是相同的。

一致性在后端可能会造成严重后果。当需要协调发布时,当不能在无法预测是否影响其他团队的前提下升级库时,当数据库变化可能打破一个系统关键性生产时——这些都可能会导致系统瘫痪。所以不要让团队彼此共享数据库或者库。

利用共享的工具和专业知识呢?如果每个团队运行自己的数据库,这些箭头会迅速变宽,除非他们克扣了检测和冗余——然而这样会导致系统非常脆弱。我们并不想在系统挂掉后重构一切。

答案是宽箭头和高箭头兼而有之。当它们在内部服务时,共享的工具非常棒。让数据管道服务合作伙伴以及向团队汇报。让数据库团队为其他团队提供支持良好的数据库实例。(它们仍然是单独的数据库,但是现在我们有共享的工具来与之合作,数据管道让彼此同步。) 当你的团队是一个分布式系统时…… 绿色、红色和蓝色箭头窄而高,几乎全部填满工作,一些线将它们彼此连接。紫色和一个新的黑色箭头宽且短,工作充分。宽箭头(内部服务)巧妙地与高箭头(产品团队)进行沟通。

敲黑板,总结

  • 避免共享代码库,除非你像谷歌那样有完美的测试覆盖率,或者像亚马逊那样有一整个团队负责支持向后兼容的库。
  • 避免共享数据库实例,但是要建立内部团队支持常见的数据库工具。
  • 鼓励分享想法,在一个组织内人们随机的交流拥有巨大的潜力。弄明白其他团队在做什么,可以完善自己的方向以及提升开发速度。
  • 在目标结果、为什么做以及如何做上达成一致。在同一个方向上,独立地前进。

每一个组织都是一个分布式的系统,哪怕我们彼此就坐在旁边。协调使得共同工作成为可能,却不是全无代价。在你的组织成长过程中注意权衡,因为一致性越来越无用,也越来越花费巨大。新人的加入需要更多的协调成本。让团队按照他们各自的方式前进,只要在一个大方向上是一致的就可以。

分布式系统很难,然而我们可以做到。

作者:Jessitron 文章来自: http://blog.jessitron.com

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址