微服务介绍-系统架构演变过程

1、微服务介绍

1.1、系统架构演变

随着互联网发展,网站应用的规模也在不断扩大,进而导致系统的架构也在不断的进行变化。从物联网早期发展到现在,系统架构大体经历了以下几个过程:单体应用内架构–》垂直应用架构–》分布式应用架构–》SOA架构–》微服务架构。当然还有悄然兴起的Service Mesh服务网格化。下面详细了解下每个过程的系统加过是什么样子的,各有什么优缺点。
微服务介绍-系统架构演变过程_第1张图片

1.1.1、单体应用架构

互联网早期,一般的网站应用流量比较少,只需要一个应用,将所有功能代码都部署在一起就可以了,这样可以减少开发,部署和维护的成本。
比如说一个电商系统,包含用户管理、商品管理、订单管理和物流管理等等很多模块,我们会把它们都做成一个web项目,代码写到一个服务项目里面,然后部署到一台tamcat服务器上。
优点:

  • 项目架构简单、开发成本低
  • 项目都部署在一个节点服务器上,维护方便
    缺点:
  • 全部功能模块都在一个项目工程中欧,对应不断增长的项目规模来讲不易开发和维护
  • 项目模块之间紧密耦合,单点容错率低
  • 无法针对不同模块进行针对性优化和水平扩展
1.1.2、垂直应用架构

随着访问量的逐渐增大,单一应用只能依靠增加节点来应对,但是这时候会发现并不是所有的模块都会有比较大的访问量,还是以电商为例,用户访问量的增加可能影响的只是用户和订单模块,但是对消息模块的影响就比较小,那么此时我们希望只多增加几个订单模块,而不增加消息模块,此时单体应用就做不到了,垂直应用就应运而上。
所谓的垂直应用架构,就是将原来的一个应用拆分成几个互不相干的几个应用,以提升效率,比如我们可以将上面电商的单体应用拆分成:

  • 电商系统(用户管理、商品管理、订单管理)
  • 后台系统(用户管理、订单管理、客户管理)
  • CMS系统(广告管理、营销管理)
    这样拆分之后,一旦用户访问量变大,只需要增加电商系统节点就可以应对,无序增加后台和CMS节点。
    优点:
  • 系统拆分实现了流量的分担,解决了访问量大,并发问题,而且可以针对不同模块进行优化和水平扩展
  • 一个系统的问题不会影响到其他系统,提高容错率
    缺点
  • 系统之间相互独立,无法进行相互调用
  • 系统之间相互独立,会有重复的开发工作
1.1.3、分布式应用架构

当垂直应用越来越多,重复的业务代码就会越来越多,这时候,我们就要考虑可不可以将重复的代码抽取出来,做成统一的业务层作为独立的服务,然后有前段控制层调用不同的业务层服务呢?
这就产生了新的分布式应用架构,它将把工程拆分成表现出和服务层两部分,服务层中包含业务逻辑,表现层只需要处理和页面的交互,业务逻辑都是调用服务层的服务来实现。
优点:

  • 抽取公共的功能作为服务层,提高代码的复用性
    缺点:
  • 系统前后端耦合度高,调用关系复杂,难以维护
1.1.4、SOA应用架构

在分布式架构下,当服务越来越多,容量的评估,小服务资源的浪费等问题逐渐凸显,此时需增加一个调度中心对集群进行实时管理,用于资源调度和治理的中心(SOA:Service Oriented Archectre)是关键。
优点

  • 使用治理中心(ESB/dubbo)解决了服务间调用关系的自动调节
    缺点
  • 服务间会有依赖关系,一旦某个环节出错会影响很大(服务雪崩)
  • 服务关系复杂,运维。、测试部署困难
1.1.5、微服务应用架构

微服务结构在某种程度上是面向服务的架构SOA继续发展的下一步,它更加强调服务的“彻底拆分”。
优点:

  • 服务原子化拆分,独立打包,部署和升级,保证每个微服务清晰的任务划分,利于扩展。
  • 微服务之间采用Restful等轻量级http协议相互调用
    缺点
  • 分布式系统开发的技术成本高(容错、分布式事务等)
  • 复杂性更高,各个微服务进行分布式独立部署,当进行模块调用的时候,分布式会变得更加麻烦

你可能感兴趣的:(Spring,Cloud,Alibaba,系统架构师,微服务)