网站地图添加,新乡做网站公司电话,wordpress 幻灯制作,做海报的话网站摘要#xff1a; 可能出乎很多人意料之外的一个事实是#xff0c;微服务很多核心理念其实在半个世纪前的一篇文章中就被阐述过了#xff0c;而且这篇文章中的很多论点在软件开发飞速发展的这半个世纪中竟然一再被验证#xff0c;这就是康威定律。前段时间看了Mike Amundsen… 摘要 可能出乎很多人意料之外的一个事实是微服务很多核心理念其实在半个世纪前的一篇文章中就被阐述过了而且这篇文章中的很多论点在软件开发飞速发展的这半个世纪中竟然一再被验证这就是康威定律。前段时间看了Mike Amundsen 《远距离条件下的康威定律——分布式世界中实现团队构建》在InfoQ上的一个分 概述 关于微服务的介绍可以参考微服务那点事。 微服务是最近非常火热的新概念大家都在追也都觉得很对但是似乎没有很充足的理论基础说明这是正确的给人的感觉是 不明觉厉 。前段时间看了Mike Amundsen 《远距离条件下的康威定律——分布式世界中实现团队构建》是Design RESTful API的作者在InfoQ上的一个分享觉得很有帮助结合自己的一些思考整理了该演讲的内容。 可能出乎很多人意料之外的一个事实是微服务很多核心理念其实在半个世纪前的一篇文章中就被阐述过了而且这篇文章中的很多论点在软件开发飞速发展的这半个世纪中竟然一再被验证这就是康威定律Conways Law。 在康威的这篇文章中最有名的一句话就是 Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. - Melvin Conway(1967) 中文直译大概的意思就是设计系统的组织其产生的设计等同于组织之内、组织之间的沟通结构。看看下面的图片来源于互联网侵删再想想Apple的产品、微软的产品设计就能形象生动的理解这句话。 用通俗的说法就是组织形式等同系统设计。 这里的系统按原作者的意思并不局限于软件系统。据说这篇文章最初投的哈佛商业评论结果程序员屌丝的文章不入商业人士的法眼无情被拒康威就投到了一个编程相关的杂志所以被误解为是针对软件开发的。最初这篇文章显然不敢自称定律law只是描述了作者自己的发现和总结。后来在Brooks Law著名的人月神话中引用这个论点并将其“吹捧”成了现在我们熟知“康威定律”。 康威定律详细介绍 Mike从他的角度归纳这篇论文中的其他一些核心观点如下 第一定律 Communication dictates design 组织沟通方式会通过系统设计表达出来 第二定律 There is never enough time to do something right, but there is always enough time to do it over 时间再多一件事情也不可能做的完美但总有时间做完一件事情 第三定律 There is a homomorphism from the linear graph of a system to the linear graph of its design organization 线型系统和线型组织架构间有潜在的异质同态特性 第四定律 The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems 大的系统组织总是比小系统更倾向于分解 人是复杂社会动物 第一定律 Communication dictates design 组织沟通方式决定系统设计 组织的沟通和系统设计之间的紧密联系在很多别的领域有类似的阐述。对于复杂的系统聊设计就离不开聊人与人的沟通解决好人与人的沟通问题才能有一个好的系统设计。相信几乎每个程序员都读过的《人月神话》1975年感觉都是老古董了经典的就是经得起时间考验里面许多观点都和这句话有异曲同工之妙。 比如《人月神话》中最著名的一句话就是 Adding manpower to a late software project makes it later --Fred Brooks, (1975) Boss们都听到了吗为了赶进度加程序员就像用水去灭油锅里的火一样无奈大家还是前赴后继。 为什么人月神话也给出了很简洁的答案沟通成本 n(n-1)/2沟通成本随着项目或者组织的人员增加呈指数级增长。是的项目管理这个算法的复杂度是O(n^2)。举个例子 5个人的项目组需要沟通的渠道是 5*(5–1)/2 10 15个人的项目组需要沟通的渠道是15*(15–1)/2 105 50个人的项目组需要沟通的渠道是50*(50–1)/2 1,225 150个人的项目组需要沟通的渠道是150*(150–1)/2 11,175 所以知道为什么互联网创业公司都这么小了吧必须小啊不然等CEO和所有人讲一遍创业的想法后风投的钱都烧完了。 Mike还举了一个非常有意思的理论叫“Dunbar Number”这是一个叫Dunbar废话生物学家在1992年最早提出来的。最初他发现灵长类的大脑容量和其对应的族群大小有一定关联进而推断出人类的大脑能维系的关系的一些有趣估计。举例来说 亲密intimate朋友: 5 信任trusted朋友: 15 酒肉close朋友: 35 照面casual朋友: 150 是不是和上面的沟通成本的数字很貌似有关联是的我们的大脑智力只能支持我们维系这么多的关系。大家都知道这不是程序猿擅长的领域在开发团队里这个值应该更小估计和猿差不多 -_-凸 沟通的问题会带来系统设计的问题进而影响整个系统的开发效率和最终产品结果。 一口气吃不成胖子先搞定能搞定的 第二定律: There is never enough time to do something right, but there is always enough time to do it over 时间再多一件事情也不可能做的完美但总有时间做完一件事情 Eric Hollnagel是敏捷开发社区的泰斗之一在他《Efficiency-Effectiveness Trade Offs》 一书中解释了类似的论点。 Problem too complicated? Ignore details. Not enough resources?Give up features. --Eric Hollnagel (2009) 系统越做越复杂功能越来越多外部市场的竞争越来越剧烈投资人的期待越来越高。但人的智力是有上限的即使再牛逼的人融到钱再多也不一定招到足够多合适的人。对于一个巨复杂的系统我们永远无法考虑周全。Eric认为这个时候最好的解决办法竟然是——“破罐子破摔”。 其实我们在日常开发中也经常碰到。产品经理的需求太复杂了适当忽略一些细节先抓主线。产品经理的需求太多了放弃一些功能。 据说Eric被一家航空公司请去做安全咨询顾问复杂保证飞机飞行系统的稳定性和安全性。Eric认为做到安全有两种方式 常规的安全指的是尽可能多的发现并消除错误的部分达到绝对安全这是理想。 另一种则是弹性安全即使发生错误只要及时恢复也能正常工作这是现实。 对于飞机这样的复杂系统再牛逼的人也无法考虑到漏洞的方方面面所以Eric建议放弃打造完美系统的想法而是通过不断的试飞发现问题确保问题发生时系统能自动复原即可而不追求飞行系统的绝对正确和安全。 下面的图很好的解释了这个过程 听着很耳熟不是吗这不就是 持续集成 和敏捷开发吗的确就是。 另一方面这和互联网公司维护的分布式系统的弹性设计也是一个道理。对于一个分布式系统我们几乎永远不可能找到并修复所有的bug单元测试覆盖1000%也没有用错误流淌在分布式系统的血液里。解决方法不是消灭这些问题而是容忍这些问题在问题发生时能自动回复微服务组成的系统每一个微服务都可能挂掉这是常态我们只有有足够的冗余和备份即可。即所谓的 弹性设计Resilience 或者叫高可用设计High Availability。 种瓜得瓜做独立自治的字系统减少沟通成本 第三定律 There is a homomorphism from the linear graph of a system to the linear graph of its design organization 线型系统和线型组织架构间有潜在的异质同态特性 这是康威第一定律组织和设计间内在关系的一个具体应用。更直白的说你想要什么样的系统就搭建什么样的团队。如果你的团队分成前端团队Java后台开发团队DBA团队运维团队你的系统就会长成下面的样子 相反如果你的系统是按照业务边界划分的大家按照一个业务目标去把自己的模块做出小系统小产品的话你的大系统就会长成下面的样子即微服务的架构 微服务的理念团队间应该是 inter-operate, not integrate 。inter-operate是定义好系统的边界和接口在一个团队内全栈让团队自治原因就是因为如果团队按照这样的方式组建将沟通的成本维持在系统内部每个子系统就会更加内聚彼此的依赖耦合能变弱跨系统的沟通成本也就能降低。 合久必分分而治之 第四定律 The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems 大的系统组织总是比小系统更倾向于分解 前面说了人是复杂的社会动物人与人的通过非常复杂。但是当我们面对复杂系统时又往往只能通过增加人力来解决。这时我们的组织一般是如何解决这个沟通问题的呢Divide and conquer,分而治之。大家看看自己的公司的组织是不是一个一线经理一般都是管理15个人以下的二线经理再管理更少的一线三线再管理更少的以此类推。这里完全没有暗示开发经理比程序猿更难管理 所以一个大的组织因为沟通成本/管理问题总为被拆分成一个个小团队。 创业的想法太好了反正风投钱多多招点程序猿 人多管不过来啊找几个经理帮我管我管经理 最后 康威定律 告诉我们组织沟通的方式会在系统设计上有所表达每个经理都被赋予一定的职责去做大系统的某一小部分他们和大系统便有了沟通的边界所以大的系统也会因此被拆分成一个个小团队负责的小系统微服务是一种好的模式 康威定律如何解释微服务的合理性 了解了康威定律是什么再来看看他如何在半个世纪前就奠定了微服务架构的理论基础。 人与人的沟通是非常复杂的一个人的沟通精力是有限的所以当问题太复杂需要很多人解决的时候我们需要做拆分组织来达成对沟通效率的管理 组织内人与人的沟通方式决定了他们参与的系统设计管理者可以通过不同的拆分方式带来不同的团队间沟通方式从而影响系统设计 如果子系统是内聚的和外部的沟通边界是明确的能降低沟通成本对应的设计也会更合理高效 复杂的系统需要通过容错弹性的方式持续优化不要指望一个大而全的设计或架构好的架构和设计都是慢慢迭代出来的 带来的具体的实践建议是 我们要用一切手段提升沟通效率比如slackgithubwiki。能2个人讲清楚的事情就不要拉更多人每个人每个系统都有明确的分工出了问题知道马上找谁避免踢皮球的问题。 通过MVP的方式来设计系统通过不断的迭代来验证优化系统应该是弹性设计的。 你想要什么样的系统设计就架构什么样的团队能扁平化就扁平化。最好按业务来划分团队这样能让团队自然的自治内聚明确的业务边界会减少和外部的沟通成本每个小团队都对自己的模块的整个生命周期负责没有边界不清没有无效的扯皮inter-operate, not integrate。 做小而美的团队人多会带来沟通的成本让效率下降。亚马逊的Bezos有个逗趣的比喻如果2个披萨不够一个团队吃的那么这个团队就太大了。事实上一般一个互联网公司小产品的团队差不多就是78人左右包含前后端测试交互用研等可能身兼数职。 再对应下衡量微服务的标准我们很容易会发现他们之间的密切关系 分布式服务组成的系统 按照业务而不是技术来划分组织 做有生命的产品而不是项目 Smart endpoints and dumb pipes我的理解是强服务个体和弱通信 自动化运维DevOps 容错 快速演化 参考资料 远距离条件下的康威定律——分布式世界中实现团队构建本文图片来源该ppt截图 Conway‘s Law in wiki Conways Law Homepage 原文https://yq.aliyun.com/articles/8611 .NET社区新闻深度好文欢迎访问公众号文章汇总 http://www.csharpkit.com
