如何利用php开源系统建立php网站,网站建设成功案例怎么写,东莞网站制作与网站建设,dw建设网站步骤本文来自#xff1a;http://www.dockone.io/article/2691 1、概述
微服务架构是一种非常流行的新概念#xff0c;即便可供以借鉴的经验比较少#xff0c;当然不能阻挡它成为热门话题与研究对象。
令人惊讶地是#xff0c;其实微服务的概念早在五十多年前就已经被提出http://www.dockone.io/article/2691 1、概述
微服务架构是一种非常流行的新概念即便可供以借鉴的经验比较少当然不能阻挡它成为热门话题与研究对象。
令人惊讶地是其实微服务的概念早在五十多年前就已经被提出多年来很久研究表明了这些观点的准确性。这就是本文所介绍的——康威定律。现在已经有很多企业正在尝试使用它创建高效的微服务架构。 在这篇文章中最有名的一句话莫过于
设计系统的企业受限于生产设计这些设计是企业沟通结构的副本——Melvin Conway(1967)。
这意味着设计系统的企业它们生产的设计等同于企业内的沟通结构。下图说明了此概念 该图展现了企业现有沟通结构简单地说企业结构等于系统设计。
作者这里提到的系统并不局限于应用系统据说这篇文章最初投稿于哈佛商业评论但被拒绝因此康威将其提交到了一个编程杂志所以被误解为只针对应用开发起初作者并没有把这种理论作为定律只是描述了发现和结论不过著名的《The Mythical Man-Month》一书介绍了Brooks的理论并引用了康威的一些观点于是康威的理论被推崇成为我们现在所熟知的康威定律。
康威定律详细介绍
在文章中Mike Amundesn总结了一些核心观点
第一定律企业沟通方式会通过系统设计表达出来第二定律再多的时间也没办法让任务完美至极但总有时间能将它完成第三定律线型系统和线型组织架构间有潜在的异质同态特性第四定律大系统比小系统更适用于任务分解
2、康威第一定律
“人类是复杂的社会动物。”
其他领域也提供了一些关于沟通和系统设计之间紧密关系的例证对于一个复杂的系统设计主题总会涉及到人们之间的交流一个好的系统设计能解决这种沟通问题很多老程序员都读过《The Mythical Man-Month》里面的一些观点都是这句话的佐证。 《The Mythical Man-Month》 这本书里有一句令人难忘的话在应用项目后期加大人员的投资会更加拖慢它的速度。——Fred Brooks1975
增加开发者的数量以跟上紧凑的进度是许多企业常见的问题虽然增加劳动以达到增加产出的目的是有意义的但在沟通成本上也会大大增加——随着项目或企业中的人员数量增加沟通成本成指数级增长它可以通过公式nn-1/2来计算而项目管理算法的复杂度是ON 2下面的例子说明了沟通成本的概念
5人团队需要沟通的渠道是 5*(5–1)/2 1015人团队需要沟通的渠道是15*(15–1)/2 10550人团队需要沟通的渠道是50*(50–1)/2 1,225150人团队需要沟通的渠道是150*(150–1)/2 11,175
这也就是互联网创业公司一般都比较小的原因如果创业公司有太多的员工Boos向每个人介绍自己的想法那么风投估计也快花完了。
生物学家Dunbar在1992年提出了一个名为Dunbar Number的理论灵长类动物的大脑容量与它的族群大小有关然后推论出一些人类大脑能够维持的关系数量例如一个典型的人会有
5个死党15个信任的朋友35个一般的朋友150个只打过照面的朋友 所以它们与上面提到的沟通成本有关大脑只能维持这么多的关系在开发团队中这个数字可能更小。
沟通的问题会影响系统设计进而影响整个系统的开发效率以及最终结果。
3、康威第二定律
罗马不是一天建成的学会先解决首要问题。
敏捷开发巨头之一Erik Hollnagel 在他的书中阐述了类似的观点 问题太复杂那么不妨忽略不必要的细节。 没有足够的资源放弃无用的功能。 ——Erik Hollnagel2009 系统的复杂性、功能数量、市场竞争以及投资人的期望值都在增加而人的智力是有上限的没有企业能说一定能找到合适的人对于一个极其复杂的系统总会有考虑不周全的地方Erik认为这个问题最好的解决办法就是不去管它。
在日常开发任务汇总会遇到一些问题如产品经理提出的要求是否过于复杂如果是首先关注那些主要的需求忽略次要的需求产品经理的需求太多了那就放弃一些功能。
据称Erik曾收到一家航空公司的顾问邀请保证飞行系统的稳定性和安全性他相信通过两种方式可以确保安全性
常规安全必须检测和消除尽可能多的错误非常规安全若出现错误要及时处理最快恢复服务
对于像飞行系统这样复杂的系统不管测试人员的业务多么纯熟也会忽略一些漏洞因此Erik建议公司放弃建立一个完美系统的想法尽量去保证安全和正确性通过不断地飞行测试去识别安全问题确保系统能够在出现故障时自动回复下图显示了安全的不同解释。 听起来是不是很熟悉没错这就是我们常说的持续集成和敏捷开发的概念。
而这个原则与互联网公司维护的分布式系统弹性设计也相同即使单元测试覆盖整个系统也不不可能识别和修复分布式系统中所有的缺陷分布式系统很容易出现错误最佳解决方案不是消除所有问题而是允许它们存在在发生故障时实现自动恢复。
在由微服务组成的系统中每个微服务都可能停止响应这是完全正常的只需要确保足够的冗余和备份这就是弹性或高可用性设计。
4、 康威第三定律
创建独立的子系统减少沟通成本。 上图代表了第一定律的团队和系统设计之间的内部关系具体应用简单地说需要建立一个适合自身系统的团队如果有一个前端团队、Java后端开发团队、DBA团队和OM团队那么系统将会如下图 相反如果系统是以业务边界划分的按照业务目标去构建小的系统或产品整体系统将会如下图所示即微服务架构 团队中微服务的理念应是Inter-Operate而不是Integrate Inter-Operate是指定义系统边界和接口并为整个团队提供完整的堆栈实现完全的自制。如此就能降低系统间的依赖性减少通信成本。
5、 康威第四定律
前面提到人类是复杂的社会动物人与人之间的交流是非常复杂的当涉及到一个系统时人们经常选择增加人力去减少复杂性对于企业来说该如何处理这样的沟通问题答案是分而治之。
看看公司内一名经理管理的员工一般少于15个二三线经理管理的员工要更少因此大企业通常会将团队拆成一个个小团队或部门减少沟通成本及管理的问题有一些需要考虑的场景
创业的项目很好拿到一大笔风投再招募更多的程序员人员太多需要找几个经理进行管理
康威定律好告诉我们可以从系统设计中看出组织通信的模式每个经理要对大系统的某一小部分负责通过这种方式它们和更大的系统间沟通有了便捷因此大的系统也会被拆分成一个个小系统。微服务可以更好地服务于此。
〓 康威定律与微服务 再来看一下康威定律是如何在半个世纪前就奠定了微服务理论基础的。
人与人之间的交流很复杂每个人的精力是有限的因此当问题很复杂需要协调地去解决时需要将组织划分进而提高沟通效率。团队成员工作的系统设计依赖于成员之间的沟通管理人员可以调整划分模式实现团队之间的不同沟通方式这也会影响系统的设计。如果子系统有清晰的外部通信便捷那么就可以有效地降低通信成本响应地设计将更加适合和有效。需要不断优化一个复杂的系统并容错性和故障恢复率的帮助下进行优化不要期望大而全面的设计或架构因为它们的开发以迭代的方式发生。
以下是一些具体的实践建议
利用一切手段提高通信效率如Slack、Github和Wiki且只与相关人员进行沟通每个人和每个系统必须有明确的职责在遇到问题时知道该找谁去解决。在MVP模式下设计一套系统以迭代的方式优化及验证并确保系统的弹性。采用与系统设计相一致的团队以扁平化和以业务为基准的方式去简化团队每个小团队之间必须有对应负责的模块避免模糊的界限以免在发生问题时互相推卸责任。要做小而美的团队人员数量的增加会降低效率以及加大成本亚马逊CEO Jeff Bezos有个一个经验法则如果两个披萨对于一个团队来说不够那么这个团队就太大了。一般来说一家互联网公司的产品团队由7到8个人组成包括前端和后端测试、交互和用户体验师一些人可能身兼数职。
在查看以下微服务标准时我们可以很容易地看到微服务与康威定律之间的密切关系
由分布式服务组成的系统企业部门的业务线开发优秀的产品Smart endpoints and dumb pipesDevOps容错快速发展
