博客昵称：架构师Cool
最喜欢的座右铭：一以贯之的努力，不得懈怠的人生。
作者简介：一名Coder，软件设计师/鸿蒙高级工程师认证，在备战高级架构师/系统分析师，欢迎关注小弟！
博主小留言：哈喽！各位CSDN的uu们，我是你的小弟Cool，希望我的文章可以给您带来一定的帮助
百万笔记知识库， 所有基础的笔记都在这里面啦，点击左边蓝字即可获取！助力每一位未来架构师！
欢迎大家在评论区唠嗑指正，觉得好的话别忘了一键三连哦！😘

康威定律

康威法则设计系统的组织，其产生的设计和架构，等价组织的组织架构

单块应用时代

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1yP9bSqH-1677399580856)(康威定律-单块应用.jpg)]

几个团队共同去对一个单块应用去开发和维护时，如果一个团队对这个单块应用进行改造引入一些新的功能或技术的时候，往往需要其他的团队协作和配合，连同做集成测试才能交付这个应用，这个时候，不仅仅是沟通协调成本高，团队和团队之间往往容易产生摩擦。也就是说，多团队之间和单应用产生不匹配，违反康威法则。怎么解决，微服务是一个解决的手段：

我们把单块的应用拆分成诺干个独立的应用，每个团队负责自己的服务，相互之间不干扰，当团队A服务的服务进行修改不需要其他的团队来配合，或者说这种配合沟通成本比较少，一般只发生在双方边界交集的地方，那么这个时候发现多团队和微服务之间架构的关系可以映射起来，它符合了康威法则，整体研发效率更高效。

微服务利弊

• 利

  • 强模块化边界

    我们知道做软件架构，软件设计，模块化是非常重要的一点，一开始我们写程序做软件，我们采用类的方式来做模块化，后面开始采用组件或类库的方式做模块化，可以做到工程上的重用和分享给其他团队来使用。微服务在组件的层次上面又高了一层，以服务的方式来做模块化，每个团队独立开始和维护自己的服务，有明显的一个边界，开发完一个服务其他团队可以直接调用这个服务，不需要像组件通过jar或源码的方式去进行分享，所以微服务的边界是比较清晰的。

  • 可独立部署

    可独立部署是微服务最显著的一个特性，每个团队可以根据自己的业务需求，当产品经理或业务方把需求提过来，可以根据需要独立开发和部署服务，一般来说不需要太过依赖其他团队去协同，这个对比单块应用，单块引用在这个方面需求很多团队来协助和帮忙。

  • 技术多样性

    微服务是分散式治理，没有集中治理，每个团队可以根据团队自己的实际情况和业务的实际情况去选择适合自己的技术栈，有些团队可能擅长Java开发，有些团队可能更偏向前端，更适合用nodejs去开发服务，不过这个不是越多越好，技术栈的引入也是有成本

• 弊

  • 分布式复杂性

    在原来单块应用就是一个应用，一个对单块应用的架构比较熟悉的人可以对整个单块应用有一个很好的把控。但是到了分布式系统，微服务化了以后可能涉及到的服务有好几十个，一些大公司可能涉及到的服务上百个，服务与服务之间是通过相互沟通来实现业务，那么这个时候整个系统就变成非常复杂，一般的开发人员或一个团队都无法理解整个系统是如何工作的，这个就是分布式带来的复杂性。

  • 最终一致性

    微服务的数据是分散式治理的，每个团队都有自己的数据源和数据拷贝，比方说团队A有订单数据，B团队也有订单数据，团队A修改了订单数据是否应该同步给团队B的数据呢，这里就涉及到数据一致性问题，如果没有很好的解决一致性问题，就可能造成数据的不一致，这个在业务上是不可以接受的。

  • 运维复杂性

    以往的运维需要管理的是机器+单块的应用，分布式系统和单块应用不一样的是，分布式系统需要很多的服务，服务与服务之间相互协同，那么对分布式系统的资源，容量规划，对监控，对整个系统的可靠性稳定性都非常具备挑战的。

  • 测试复杂性

    对测试人员来说，在单块应用上，一个测试团队只需要测试一个单块应用就可以了，到了分布式系统，各个服务是分布在各个团队的，这个对测试团队来说要求就很好，做集成测试的时候需要很多的团队相互配合去联合做集成测试。