组织:康威定律和系统设计
康威定律:任何组织在设计一套系统时,所交付的设计方案在结构上与该组织的沟通结构保持一致
1. 证据
1) 松耦合组织和紧耦合组织
紧耦合组织的一个例子时商业产品公司,员工在一起工作,并有着一致的愿景和目标
松耦合组织的典型代表时发布时开源社区。
研究发现(Exploring the Duality Between Product. And Organizational Architectures, 作者:Alan MacCormack、John Rusnak和Carliss Baldwin):组织的耦合性越低,其创建的系统的模块化越好,耦合也越低;组织的耦合度越高,其创建的系统的模块化也越差。
2. Amazon和Netflix
信奉组织和架构保持一致的两个典范是Amazon和Netflix
1) Amazon:
a. 团队对服务/所管理系统的整个生命周期负责
b. 两个比萨团队:小团队比大团队的工作更有效。
2) Netflix:
a. 确保其本身由多个小而独立的团队组成,以保证创建的服务能独立于彼此
3. 我们可以做的:
3.1 适应沟通途径,划分服务所有权
1) 适应沟通途径:
a. 参与创建系统的开发人员中间存在地理位置差异,是一个应该对服务进行分解的很明显的信号。
b. 一般来说,应该分配单个服务的所有权给可以保持低成本变化的团队
c. 积极思考系统的那部分可以移交给异地办公的新团队:按照接缝拆分
d. 一个团队对其管理的服务会倾向于更紧密地集成,而这种方式在分布式组织中是很难维护的
2) 服务所有权
a. 所有权延伸到服务的方方面面,从应用程序的需求、构建、部署到运维
b. 所有权程度的增加会提高自治和交付速度
c. 团队需要自己负责部署和维护应用程序,这会激励团队创建出易于部署的服务(所谓的自吃狗粮?)
3.2 分析共享服务的原因,找出令人信服的替代方式
共享服务的效果不佳
1)共享服务的原因:
a. 难以分割:拆分服务的成本太高,常见于大型的单块系统中
b. 特性团队:基于特性开发的团队。一个小团队负责开发一系列特性需要的所有功能,即使这些功能需要跨越组件(甚至服务)的边界。
例如:跨越用户界面、用户逻辑及数据库,提供完整的功能
大范围采用特性团队后,所有服务都是共享的。
如果负责某个微服务的团队与业务领域相匹配,它更容易保持对客户的关注,也更容易进行以特性为导向的开发。
c. 交付瓶颈:避免交付瓶颈是共享服务的另一个关键原因。
2) 替代方案:内部开源
a. 守护者:在内部需要分离出一组受信任的提交者(核心团队)和不受信任的提交者(团队外提交变更的人)
核心团队需要对更改由某种程度的审批,确保所有的更改服务该代码库的惯例,遵循和代码库其它代码一致的编码准则
b. 成熟
服务越不稳定或越不成熟,就越难让核心团队之外的人提交更改。
如果一个服务已经相当成熟,而且很少改变,才是开源并让其他人贡献代码的最好时机
(如何判定一个服务是成熟的?)
c. 工具
使用支持pull请求的分布式版本控制工具;
支持讨论和修改提交申请的工具
良好的构建和部署流水线,以及集中构件物仓库
4. 限界上下文和交付团队结构
保持交付团队和限界上下文一致的好处:
1) 团队会更容易掌握领域的概念,因为它们是相互关联的
2) 限界上下文的服务更可能发生交互,保持一致可以简化系统设计和发布的协调工作
3) 在交付团队和业务干系人进行交互方面,有利于团队与此领域内的一两个专家创建良好的合作关系
5. 孤儿服务
1) 什么是孤儿服务?
不再活跃或修改频率很低的服务
2) 如何处理孤儿服务?
如果团队结构和组织的限界上下文是一致的,即使是孤儿服务也会有实际的所有者。
6. 案例研究
1) 每条业务线交付团队,负责自己创建的服务的整个生命周期,包括构建、测试、发布和运维,甚至弃用
2) 一个核心交付服务团队,为业务线交付团队提供建议、指导和工具来帮助他们完成工作。
3) 浓厚的自动化文化
4) 与业务相一致的架构。
例如集成方式:
a. 一条业务线内,服务间可以不受任何限制地以任何方式来通信,只要团队确定的服务守护者认为合适
b. 业务线之间,所有的通信都必须是异步批处理。
7. 反向的康威定律:系统架构设计对组织的反向作用
无论系统有什么样的设计缺陷,我们都不得不通过改变组织结构来推动系统的更改。
8. 人
“不管一开始看起来什么样,它永远是人的问题“
-- 温伯格(没听说过),咨询第二定律
每个组织都有自己的节奏,了解员工能够承受的变化,不要逼他们改变太快。
需要跟员工清楚的阐述,在微服务的世界里每个人的责任,以及为何这些责任如此重要。