康威法则与微服务

字数统计: 796字   |   阅读时长≈ 2分

mark

什么是康威法则

最开始是一个叫康威的人，他原来是一个程序员，在1967年的时候提出来。康威法则我们认为它是微服务的理论基础。康威法则的原话是这样讲的，设计系统的组织，其产生的设计和架构等价于组织的组织架构。

康威法则和微服务

为什么这么说呢？今天主要就是介绍康威法则和微服务之间的一个关系。

一个互联公司在刚开始的时候业务量一般是不大的，刚开始的时候他是尝试业务模式能不运行能起来，所以他一开始的时候开发的系统一定是一个简单的单块系统，这个时候他的团队规模不大，一般就几十个人或者是有限的几个。随着业务规模越来越大，团队肯定也会扩大规模，需要两个、三个、甚至几十个团队来协同那么这个时候，如果你的系统架构仍然是单块，然后他就跟分散式的多团队之间产生了一种不匹配的情况。

就所谓的违反了我们的康威法则，该架构它没有反应组织的这个组织架构。这时候就会出现，矛盾协调成本很高，交付效率很低，假如有一个单块的一个大型的服务，但是那有好多个团队，可能有七八个甚至十几个团队围绕的这个单块这个架构进行开发，当其中一个团队对这个单块应用进行了一些升级，而引入一些新的功能往往，需要其他的团队来协作配合，做集成测试，才能够交付。以这个时候团队之间的协调成本很高，有的时候甚至还会产生摩擦。也就是说我们的单块应用和多团队之间产生了一种不匹配的情况，康威法则怎么来解决这个问题？

怎么解决呢？微服务是解决的一个手段，我们把这个单块的这个应用把它拆解出来。拆分成若干个微服务。每个团队负责维护自己的服务，相互之间不干扰。当S1在这个团队在开发它自己的服务的时候，不需要其他的团队都得一起来，或者说这种配合的沟通协商成本比较小，还可以去独立的迭代和交付自己的微服务。那么这个时候就会发现，多团队和多模块之间的这个结构关系又能够映射起来，它符合了康威法则，然后整体的研发的效率，对业务的支持就更高效。

所以介绍的这个即将康威法则法则是这样描述的，设计系统的组织，其产生的设计和架构等价于组织的组织架构，架构师不仅仅要做好技术价格，同时要了解组织的组织架构！

赏

谢谢你请我喝咖啡

支付宝
微信

扫一扫，分享到微信

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia-plus根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true