系统架构之引言(墨菲定律、康威定律) - 小白进阶 - CSDN博客

标签: | 发表时间:2019-08-25 13:31 | 作者:
出处:https://blog.csdn.net

系统设计的墨菲定律

  • 任何事都没有表面看起来那么简单
  • 所有的事都会比你预计的时间长;
  • 会出错的事总会出错;
  • 如果你担心某种情况发生,那么它就更有可能发生。

“墨菲定律”的根本内容是“凡是可能出错的事有很大几率会出错”,指的是任何一个事件,只要具有大于零的机率,就不能够假设它不会发生。

系统划分的康威定律

第一定律:组织沟通方式会通过系统设计表达出来

组织的沟通和系统设计之间的紧密联系,解决好人与人的沟通问题,才能有一个好的系统设计。在项目管理《人月神话》一书中有一句“Adding manpower to a late software project makes it later”( 向进度落后的项目中增加人手,只会使进度更加落后),并给出了说明,沟通渠道(成本) = n(n-1)/2,沟通渠道(成本)随着项目或者组织的人员增加呈指数级增长。

  • 5个人的项目组,需要沟通的渠道是 5*(5–1)/2 = 10
  • 15个人的项目组,需要沟通的渠道是15*(15–1)/2 = 105
  • 50个人的项目组,需要沟通的渠道是50*(50–1)/2 = 1,225

沟通的问题,会带来系统设计的问题,进而影响整个系统的开发效率和最终产品结果。

第二定律:时间再多一件事情也不可能做的完美,但总有时间做完一件事情

系统越做越复杂,功能越来越多,但人的智力是有上限的,即使再牛逼的人,融到钱再多也不一定招到足够多合适的人。对于一个巨复杂的系统,我们永远无法考虑周全。Eric Hollnagel 在2009年《Efficiency-Effectiveness Trade Offs》一书中提出“Problem too complicated? Ignore details. Not enough resources?Give up features.”( 问题太复杂了?忽略详细信息。资源不足?放弃特色。)。

对于一个分布式系统,我们几乎永远不可能找到并修复所有的bug,解决方法不是消灭这些问题,而是容忍这些问题,在问题发生时,能自动恢复,即所谓的高可用设计(High Availability),也叫弹性设计(Resilience)。

第三定律:线型系统和线型组织架构间有潜在的异质同态特性

想要什么样的系统,就搭建什么样的团队,可以按职能或者业务进行划分。微服务的理念团队间应该是内聚的,定义好系统的边界和接口,在一个团队内全栈,让团队自治,原因就是因为如果团队按照这样的方式组建,将沟通的成本维持在系统内部,每个子系统就会更加内聚,彼此的依赖耦合能变弱,跨系统的沟通成本也就能降低。

第四定律:大的系统组织总是比小系统更倾向于分解

人与人的沟通非常复杂,当我们面对复杂系统时,又只能通过增加人力来解决,可以通过分而治之来解决 一个大的组织因为沟通成本或管理问题,总为被拆分成一个个小团队。

总结:

  • 人与人的沟通是非常复杂的,一个人的沟通精力是有限的,所以当问题太复杂需要很多人解决的时候,我们需要做拆分组织来达成对沟通效率的管理。
  • 组织内人与人的沟通方式决定了他们参与的系统设计,管理者可以通过不同的拆分方式带来不同的团队间沟通方式,从而影响系统设计
  • 如果子系统是内聚的,和外部的沟通边界是明确的,能降低沟通成本,对应的设计也会更合理高效
  • 复杂的系统需要通过容错弹性的方式持续优化,不要指望一个大而全的设计或架构,好的架构和设计都是慢慢迭代出来的。

拆分原则

  • 应该按照业务闭环进行系统拆分或组织架构划分,实现闭环、高内聚、低耦合,减少沟通成本。
  • 如果沟通出现问题,那么应该考虑进行系统和组织架构的调整。
  • 在合适时机进行系统拆分,不要一开始就把系统或服务拆的非常细,虽然闭环,但是每个人维护的系统多,维护成本高。

相关 [系统架构 引言 墨菲定律] 推荐:

系统架构之引言(墨菲定律、康威定律) - 小白进阶 - CSDN博客

- -
任何事都没有表面看起来那么简单. 所有的事都会比你预计的时间长;. 如果你担心某种情况发生,那么它就更有可能发生. “墨菲定律”的根本内容是“凡是可能出错的事有很大几率会出错”,指的是任何一个事件,只要具有大于零的机率,就不能够假设它不会发生. 第一定律:组织沟通方式会通过系统设计表达出来. 组织的沟通和系统设计之间的紧密联系,解决好人与人的沟通问题,才能有一个好的系统设计.

HBase 系统架构

- - 博客园_首页
HBase是Apache Hadoop的数据库,能够对大型数据提供随机、实时的读写访问. HBase的目标是存储并处理大型的数据. HBase是一个开源的,分布式的,多版本的,面向列的存储模型. 5 可在廉价PC Server搭建大规模结构化存储集群. HBase是Google BigTable的开源实现,其相互对应如下:.

Facebook 的系统架构

- Ivan - 博客园新闻频道
  来源:http://www.quora.com/What-is-Facebooks-architecture (由Micha?l Figuière回答).   根据我现有的阅读和谈话,我所理解的今天Facebook的架构如下:. Web 前端是由 PHP 写的. Facebook 的 HipHop [1] 会把PHP转成 C++并用 g++编译,这样就可以为模板和Web逻贺业务层提供高的性能.

Digg.com 的系统架构

- - 标点符
在过去的几年间,我们一直致力于重构Digg的架构,现在我们称之为“Digg V4”.本文我们将全面介绍Digg的使用的系统和技术. 首先,我们来看下Digg给大众用户提供的服务吧:. 人们通过浏览器或者其他应用来访问这些Digg服务. 一些有Digg账户的用户,可以得到“我的新闻”. 每位用户可以得到的我们称之为“热门新闻”.

系统架构师JD

- - CSDN博客架构设计推荐文章
国内大型的物流企业,专业从事国内公路运输和航空运输代理. Foss项目的架构设计,包括需求分析,模块设计,系统结构设计,关键功能的开发,技术难题的解决,对团队质量输出的把控等等. 1、熟悉WebLogic/Websphere/JBoss等一个以上大型应用服务器,熟悉Linux及应用服务器集群. 2、 具有丰富J2EE架构设计经验,具有大型基于J2EE体系结构的项目规划、系统架构设计、开发经验.

Android 系统架构分析

- - CSDN博客移动开发推荐文章
Android:开源的 Linux + Google 的封闭软件 + 私有的基带 + 运营商锁定 = 开放的 Android 手机. iPhone:开源的 BSD + 苹果的闭源软件 + 私有的基带 + 运营商锁定 = 封闭的苹果 iPhone. 一个平庸的应用商店,开发者依靠广告赚钱,商店并非独此一家,用户找不到好软件.

twitter系统架构分析

- - 企业架构 - ITeye博客
twitter系统架构分析. (一)twitter的核心业务. twitter的核心业务,在于following和be followed:. (1)following-关注. 进入个人主页,会看到你follow的人发表的留言(不超过140个字),这是following的过程;. (2)followed-被关注.

支付宝系统架构

- - 编程语言 - ITeye博客
支付宝的开源分布式消息中间件–Metamorphosis(MetaQ). Metamorphosis (MetaQ) 是一个高性能、高可用、可扩展的分布式消息中间件,类似于LinkedIn的Kafka,具有消息存储顺序写、吞吐量大和支持本地和XA事务等特性,适用 于大吞吐量、顺序消息、广播和日志数据传输等场景,在淘宝和支付宝有着广泛的应用,现已开源.

大型网站系统架构粗探

- - 网站架构_搜搜博客搜索
  软件架构有很多种定义,下面是卡内基梅隆大学软件研究所关于软件架构的定义:.   软件架构是一系列相关的抽象模式,用于指导大型软件系统各个方面的设计. 软件架构描述的对象是直接构成系统的抽象组件. 各个组件之间的连接则明确和相对细致地描述组件之间的通讯. 在实现阶段,这些抽象组件被细化为实际的组件,比如具体某个类或者对象.