
课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
随着互联网的不断发展,越来越多的人都在学习计算机编程开发技术,而今天我们就通过案例分析来了解一下,微服务与领域驱动设计之间的关系。
微服务的缺陷
微服务架构在分和治两个方面都给出了很好的理论指导和佳实践,那微服务是不是解决复杂问题的银弹呢?其实不然,很多团队在应用了微服务架构来构建他们的系统以后,发现并没有完全解决这种复杂性问题,甚至还带来了一些其他的问题。比如:
服务并没有解决复杂系统如何应对需求变化这个问题,甚至还加剧了这个问题。
当一个需求变化了,需要花大量的精力去识别这个变化影响到了哪些微服务,这些服务的多个团队之间,需要通过无休止的扯皮去决定哪个服务多一些,哪些服务少改一些。
然后测试团队还需要做昂贵的这种联调测试
即便如此呢,开发团队依然不放心,还要通过一系列的开关控制,小心翼翼的去做切流,去做灰度发布。
从业务层面来看,微服务架构没有避免这种散弹式的修改。甚至反而加重了他,这是为什么呢?一个重要的原因是微服务架构在分的这个纬度考虑的并不全面。
边界清晰的好处
我们更多的是两种架构模式的一个混合,比如A和B一起是一个部署单元,C是另外一个独立的部署单元,这种情况往往是因为C非常重要,他并发的访问量非常大,或者它的需求变更比较频繁。将C拆分出来的有以下几个好处:
资源倾斜
使用弹力设计模式:比如重试,熔断,降级
使用特殊技术:比如Go语言
具备独立代码库:有独立团队和运维人员,和A和B的运行期做到隔离不互相影响
这四点正是服务架构所关注的,它是基于非功能纬度的视角来看待拆分这件事情的,他关注的不是系统架构的逻辑边界,更多的关注的是应用程序行为的分隔。
【免责声明】:本内容转载于网络,转载目的在于传递信息。文章内容为作者个人意见,本平台对文中陈述、观点保持中立,不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。