(转)为什么要采用微服务?

上一篇 / 下一篇  2019-06-12 13:54:26

  未拆分微服务的单体应用
  复杂性高 :以百万行级别的单体应用为例,整个项目包含的模块非常多,模块的边界模糊,依赖关系不清晰,代码质量参差不齐,混乱地堆砌在一起……整个项目非常复杂。
  技术债务:随着时间推移、需求变更和人员更迭,会逐渐形成应用程序的技术债务,并且越积越多。
  部署频率低:而在单体应用中,每次功能的变更或缺陷的修复都会导致我们要重新部署整个应用。全量部署的方式耗时长、影响范围大、风险高,这使得单体应用项目上线部署的频率较低。
  可靠性差:某个应用BUG,例如死循环、OOM等,可能会导致整个应用的崩溃。
  扩展能力受限:单体应用只能作为一个整体进行扩展,无法根据业务模块的需要进行伸缩。
  阻碍技术创新:如一个使用Struts 2构建的、有100万行代码的单体应用,如果想要换用Spring MVC,毫无疑问切换的成本是非常高的。
  微服务的应用
  复杂性低 :单个微服务业务逻辑单一,模块的边界清晰,依赖关系转化为接口调用关系,整个项目是微服务的有机整体。
  技术债务低:即使时间推移、需求变更和人员更迭,熟悉微服务的业务和掌握技术的代价降低。
  部署频率高:微服务的每次功能的变更或缺陷的修复,接口不变的情况下,不会影响整个应用的使用。部署的方式多样化,耗时短、影响范围小、风险低,使得微服务应用项目上线部署的频率更高。
  可靠性高:某个微服务应用的BUG,例如死循环、OOM等,在做熔断的情况下,不会导致整个应用的崩溃,增加了应用的可靠性。
  扩展能力强:根据业务模块的需要,对热点微服务进行线性扩展,有效利用资源。
  有助技术创新:微服务可以使用不同的语言,采用不同的架构,部署不同的环境等等,采用适合微服务业务场景的技术,来构建合理的微服务模块。

TAG: 微服务

 

评分:0

我来说两句

显示全部

:loveliness: :handshake :victory: :funk: :time: :kiss: :call: :hug: :lol :'( :Q :L ;P :$ :P :o :@ :D :( :)

日历

« 2019-06-20  
      1
2345678
9101112131415
16171819202122
23242526272829
30      

数据统计

  • 访问量: 7696
  • 日志数: 25
  • 建立时间: 2019-02-12
  • 更新时间: 2019-06-12

RSS订阅

Open Toolbar