微服务的优缺点_单体架构和微服务系统架构的优缺点

烟囱式系统建设的弊端:

1.重复功能的建设和维护带来的重复投资

2.烟囱式系统交互集成和协作成本高

3.不利于业务的沉淀和持续发展

ab64c060e392e617648c581fbdc78563.png

1.重复功能的建设和维护带来的重复投资

这一条很好理解就是当我们公司内部拥有多套子系统的时候,势必会带来一些重复性的工作,比如说公司内部OA系统和报表系统、两个系统按照单独的设计都会存在用户管理功能,如果某一天公司需要在加一套管理系统的话,那么在管理系统中还需要添加一套用户管理的逻辑,该重复功能的建设工作和维护势必会带来时间、资源上的浪费。

2.烟囱式系统交互集成和协作成本高

随着公司内部系统业务不断的增加以及完善,多个系统之间的集成和交互也将变得困难,多系统之间的协作、沟通成本较高,例如公司有一套mes系统(生产制造系统)该系统当中有wip模块、alm模块当有一天我新建了一个报表系统去统计使用人数,那我需要从两个系统当中分别去获取用户,带来的时间成本和沟通成本是比较高昂的

3.不利于业务的沉淀和持续发展

不利于产品的快速跟新和迭代,当今互联网项目每周每月都在不停的变化、市场的反馈根业务上的需要都需要得到快速的响应,而传统系统的迭代周期长对业务响应不及时。

为什么要微服务化

1.协作成本高,业务响应慢 

传统单体架构如果功能模块100个以上一般的公司内部按照功能模块进行划分工作,每一次新版本上线总会出现各种问题,例如分支合并冲突、代码不一致、等各种问题也会带来很大的协作成本,沟通成本。

2.系统复杂度增加难以维护

单体架构随着业务量不断的增加和扩展以及随着组织人员的变化,业务代码也会变得越来越难以维护,一次小小的改动可能会带来灾难行的风险!

3.错误不能隔离

当所有的业务功能模块都聚集在一个程序集当中,如果其中的某一个小的功能模块出现问题,那么都有可能会造成整个系统的崩溃

4.数据库连接能力很难扩展

数据库集群的连接数量是有限的,当数据库的连接数量资源随着实例的增加将难以保证

5.应用扩展能力差

单体架构不能够按需扩展,例如某一天我们的网站当中部分业务模块访问量暴增,如果我们要对服务扩展只能把整个系统进行打包、发布而不能针对特定的模块进行扩容

综合上述烟囱式建设模式带来的一些弊端接下来讲到了soa方法,SOA的主要特点有如下几种:

  • 面向服务的分布式计算

  • 服务间松耦合

  • 支持服务的组装

  • 服务注册和自动发现

  • 以服务契约方式定义服务交互方式

SOA架构带来的真正核心意义价值:服务重用。

e7c8843743d49ba27d74971e1fc16a6f.png 

单体架构

所谓的单体架构就是把所有的业务模块编写在一个项目中,最终会打包成一个war包,然后进行部署

b251f6af62898161eb9581a3a7fa06c1.png

单体架构的优点:
  1. 部署简单:由于是完整的结构体,可以直接部署在一份服务器上即可
  2. 技术单一:项目不需要复杂的技术栈,往往一套熟悉的技术栈就可以完成开发
  3. 用人成本低:单个程序员可以完成业务接口道数据库的整个流程

单体架构的缺点:

  1. 系统启动慢:一个进程包含了所有的业务逻辑,涉及到的启动模块过多,导致系统的启动时间周期过长
  2. 系统错误隔离性差:可用性差,任何一个模块的错误均可能造成整个系统的宕机
  3. 可伸缩性差:系统的扩容只能对这个应用进行扩容,不能做到对莫讴歌功能点进行扩容
  4. 线上问题修复周期长:任何一个线上问题修复需要对整个应用系统全面升级

微服务系统架构:

微服务架构风格是一种将一个单一应用程序开发为一组小型服务的方法,每一个服务运行在自己的进程中,服务间通信采用的轻量级通信机制(通常用Http资源API),这些服务围绕业务能力构建并且可通过全自动部署机制独立部署,这些服务公用一个最小型的集中式的管理,服务可用不同的语言开发,使用不同的数据存储技术

9f962b91989a71d0ec8740966fdbf0c4.png

微服务架构的优点:
  1. 易于开发和维护:一个微服务只会关注一个特定的业务功能,所以他的业务清晰,代码量少,开发和维护单个微服务相当简单,而整个应用是若干个微服务构建而成的,所以整个应用也被维持在一个可控状态
  2. 单个微服务启动较快:单个微服务代码量较少,所以启动会比较快
  3. 局部修改容易部署
  4. 技术栈不受限
  5. 按需收缩:可根据需求,实现细粒度的扩展,例如:系统中的某个微服务遇到了瓶颈,可以结合这个微服务的业务特点,增加内存,升级CPU或者增加节点
  6. 可以承受高并发

微服务架构的缺点:

  1. 运维要求较高:更多的服务意味着更多的运维投入,在单体架构中,只需要保证一个应用的正常运行,而在微服务中,需要保证几十甚至几百个服务正常运行与协作,这给运维带来了很大的挑战

  2. 分布式固有的复杂性:使用微服务构建的是分布式系统,对于一个分布式系统,系统容错,网络延迟等都会带来巨大的挑战

  3. 接口调整成本高:微服务之间通过接口进行通信,如果修改某一微服务API,肯呢个所有使用该接口的微服务都需要调整

07a7571c8ce42d98894d8c3692d65010.png

推荐阅读

微服务架构和相关的组件

微服务与领域抽象:支付系统2.0架构演进

浅谈微服务体系中的分层设计和领域划分

关于微服务架构入门篇

面试题

Spring Cloud面试题万字解析(2020面试必备)

85道Java微服务面试题整理(助力2020面试)

2019年面试官最喜欢问的28道ZooKeeper面试题

2019年Dubbo你掌握的如何?快看看这30道高频面试题!

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值