开发者社区 > 云原生 > 微服务 > 正文

docker compose管理的多个微服务和传统单体应用管理的多个模块区别在哪?

现在所说的微服务架构,把以前大应用的各个模块拆分成独立的微服务,这些微服务号称独立部署的好处,但实际在产品级别又需要把一群微服务通过编排的方式组合出一个真正可用的业务应用,那么对开发者来说岂不是还要关心这个大应用的所有模块功能吗?(至少要了解每个微服务的依赖关系),他开发到发布的整个过程还是和以前单个应用没什么区别啊(当然组织形式变化了,发布载体工具变化了),可是这个和微服务一再强调的独立发展、部署相矛盾,请问能给解释下怎么看待这个问题?

展开
收起
backhantang-14902 2017-11-30 12:36:51 3557 0
3 条回答
写回答
取消 提交回答
  • compose 跟侧重于组织一些有关联的镜像生命周期,楼主迷惑的部分比如服务,资源是容器编排平台来解决的问题

    2019-07-17 21:46:13
    赞同 展开评论 打赏
  • 微服务的应用独立自治,意味着更高的灵活性。

    比如现在用户应用的压力较大,我可以灵活地给它更多的资源,让它去支撑服务。

    另外,开发和部署问题。比如我现在修改一个模块,之前没有独立出来,可能很多业务代码耦合在一起。相互调用,你修改一处地方,结果导致了另一个模块异常。但是独立的服务,只要保证自己提供的API标准输出就至少不会出现这个问题。

    而以上是其它的区别一小部分,也是平时大家最重视的一部分。

    2019-07-17 21:46:13
    赞同 展开评论 打赏
  • 同求

    2019-07-17 21:46:13
    赞同 展开评论 打赏

为微服务建设降本增效,为微服务落地保驾护航。

热门讨论

热门文章

相关电子书

更多
微服务治理技术白皮书 立即下载
微服务与Serverless 立即下载
EDAS4.0 助力企业一站实现微服务架构转型与 K8s 容器化升级 立即下载