| title | toc | layout | categories | tags | date |
|---|
|
康威定律与微服务的关系
|
true
|
blog
|
|
|
2018/07/18 10:19
|
{{title}}
康威定律与微服务的关系
康威第一定律
人类是复杂的社会动物
康威第二定律
罗马不是一天建成的，学会先解决首要问题
康威第三定律
创建独立的子系统，减少沟通成本
总结
前面提到，人类是复杂的社会动物，人与人之间的交流是非常复杂的，当涉及到一个系统时，人们经常选择增加人力去减少复杂性，对于企业来说，该如何处理这样的沟通问题？答案是：分而治之。
看看公司内，一名经理管理的员工一般少于15个，二三线经理管理的员工要更少，因此，大企业通常会将团队拆成一个个小团队或部门减少沟通成本及管理的问题，有一些需要考虑的场景：
- 创业的项目很好，拿到一大笔风投，再招募更多的程序员
- 人员太多，需要找几个经理进行管理
- 康威定律好告诉我们，可以从系统设计中看出组织通信的模式，每个经理要对大系统的某一小部分负责，通过这种方式，它们和更大的系统间沟通有了便捷，因此大的系统也会被拆分成一个个小系统。（微服务可以更好地服务于此)
康威定律与微服务
康威定律是如何在半个世纪前就奠定了微服务理论基础的
- 人与人之间的交流很复杂，每个人的精力都是有限的，因此当问题很复杂需要协调的去解决时，需要将组织划分进而提高沟通效率。
- 团队成员工作的系统设计依赖于成员之间的沟通，管理人员可以调整划分模式，实现团队之间的不同沟通方式，这也会影响系统的设计。
- 如果子系统有清晰的外部通信便捷，那么就可以有效的降低通信成本，相应的设计将更加适合和有效。
- 需要不断优化一个复杂的系统，并容错性和故障恢复率的帮助下进行优化，不要期望大而全面额设计或架构，因为它们的开发以迭代的方式发生。
具体的实践建议：
- 利用一切手段提高通信效率，如Slack、GitHub、Wiki，且至于相关人员进行沟通，每个人和每个系统必须有明确的职责，在遇到问题时，知道找谁去解决。
- 在
MVP模式下设计一套系统，以迭代的方式优化及验证，并确保系统的弹性。 - 采用与系统设计相一致的团队，以扁平化和以业务为基准的方式去简化团队，每个小团队之间必须有对应负责的模块，避免模糊的界限，可以在发生问题时定义责任承担者。
- 精简团队规模，求精而不将就。人员数量的增加在降低效率的同时也在增加投入成本，亚马逊CEO Jeff Bezos的经验法则：如果两个披萨对于一个团队来说不够，那么这个团队就太大了。互联网公司的产品团队普遍由7-8人组成(包括前端和后端测试、交互和用户体验师，一人可能身兼数职)。
在查看以下微服务标准时，更能体现微服务与康威定律间的关系：
- 由分布式服务组成的系统
- 企业部门的业务线
- 开发优秀的产品
- Smart endpoints and dumb pipes
- DevOps
- 容错
- 快速发展
内容来源：简化自翟永超文章 | 
转播
