深圳石岩小学网站建设,knowhow wordpress,东莞个人网站制作,做自己的网站如何赚钱的博客昵称#xff1a;架构师Cool 最喜欢的座右铭#xff1a;一以贯之的努力#xff0c;不得懈怠的人生。 作者简介#xff1a;一名Coder#xff0c;软件设计师/鸿蒙高级工程师认证#xff0c;在备战高级架构师/系统分析师#xff0c;欢迎关注小弟#xff01; 博主小留言… 博客昵称架构师Cool 最喜欢的座右铭一以贯之的努力不得懈怠的人生。 作者简介一名Coder软件设计师/鸿蒙高级工程师认证在备战高级架构师/系统分析师欢迎关注小弟 博主小留言哈喽各位CSDN的uu们我是你的小弟Cool希望我的文章可以给您带来一定的帮助 百万笔记知识库 所有基础的笔记都在这里面啦点击左边蓝字即可获取助力每一位未来架构师 欢迎大家在评论区唠嗑指正觉得好的话别忘了一键三连哦 康威定律康威定律微服务利弊康威定律 康威法则设计系统的组织其产生的设计和架构等价组织的组织架构 单块应用时代
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1yP9bSqH-1677399580856)(康威定律-单块应用.jpg)]
几个团队共同去对一个单块应用去开发和维护时如果一个团队对这个单块应用进行改造引入一些新的功能或技术的时候往往需要其他的团队协作和配合连同做集成测试才能交付这个应用这个时候不仅仅是沟通协调成本高团队和团队之间往往容易产生摩擦。也就是说多团队之间和单应用产生不匹配违反康威法则。怎么解决微服务是一个解决的手段 我们把单块的应用拆分成诺干个独立的应用每个团队负责自己的服务相互之间不干扰当团队A服务的服务进行修改不需要其他的团队来配合或者说这种配合沟通成本比较少一般只发生在双方边界交集的地方那么这个时候发现多团队和微服务之间架构的关系可以映射起来它符合了康威法则整体研发效率更高效。
微服务利弊 利 强模块化边界 我们知道做软件架构软件设计模块化是非常重要的一点一开始我们写程序做软件我们采用类的方式来做模块化后面开始采用组件或类库的方式做模块化可以做到工程上的重用和分享给其他团队来使用。微服务在组件的层次上面又高了一层以服务的方式来做模块化每个团队独立开始和维护自己的服务有明显的一个边界开发完一个服务其他团队可以直接调用这个服务不需要像组件通过jar或源码的方式去进行分享所以微服务的边界是比较清晰的。 可独立部署 可独立部署是微服务最显著的一个特性每个团队可以根据自己的业务需求当产品经理或业务方把需求提过来可以根据需要独立开发和部署服务一般来说不需要太过依赖其他团队去协同这个对比单块应用单块引用在这个方面需求很多团队来协助和帮忙。 技术多样性 微服务是分散式治理没有集中治理每个团队可以根据团队自己的实际情况和业务的实际情况去选择适合自己的技术栈有些团队可能擅长Java开发有些团队可能更偏向前端更适合用nodejs去开发服务不过这个不是越多越好技术栈的引入也是有成本 弊 分布式复杂性 在原来单块应用就是一个应用一个对单块应用的架构比较熟悉的人可以对整个单块应用有一个很好的把控。但是到了分布式系统微服务化了以后可能涉及到的服务有好几十个一些大公司可能涉及到的服务上百个服务与服务之间是通过相互沟通来实现业务那么这个时候整个系统就变成非常复杂一般的开发人员或一个团队都无法理解整个系统是如何工作的这个就是分布式带来的复杂性。 最终一致性 微服务的数据是分散式治理的每个团队都有自己的数据源和数据拷贝比方说团队A有订单数据B团队也有订单数据团队A修改了订单数据是否应该同步给团队B的数据呢这里就涉及到数据一致性问题如果没有很好的解决一致性问题就可能造成数据的不一致这个在业务上是不可以接受的。 运维复杂性 以往的运维需要管理的是机器单块的应用分布式系统和单块应用不一样的是分布式系统需要很多的服务服务与服务之间相互协同那么对分布式系统的资源容量规划对监控对整个系统的可靠性稳定性都非常具备挑战的。 测试复杂性 对测试人员来说在单块应用上一个测试团队只需要测试一个单块应用就可以了到了分布式系统各个服务是分布在各个团队的这个对测试团队来说要求就很好做集成测试的时候需要很多的团队相互配合去联合做集成测试。
