微服务架构的演变

文章目录

    • 1.1 系统架构的演变过程
      • 1.1.1 单体应用架构
      • 1.1.2 垂直应用架构
      • 1.1.3 分布式架构
      • 1.1.4 SOA架构
      • 1.1.5 微服务架构
    • 1.2 微服务架构设计原则
      • 1.2.1 AKF拆分原则
        • 1.2.1.1 X轴扩展(水平复制)
        • 1.2.1.2 Y轴扩展(模块拆分)
        • 1.2.1.3 Z轴扩展(数据分区)
      • 1.2.2 前后端分离原则
      • 1.2.3 无状态服务
        • 1.2.3.1 状态化请求
        • 1.2.3.2 无状态请求
        • 1.2.3.3 HTTP是无状态的
        • 1.2.3.4 无状态服务带来的好处
      • 1.2.4 Restful通信风格

1.1 系统架构的演变过程

随着互联网的不断发展,网站应用的规模不断扩大,系统架构也因此也不断的演进、升级、迭代。从互联网早期到现在,系统架构大体经历了下面几个过程:

  • 1)单体应用架构

  • 2)垂直应用架构

  • 3)分布式架构

  • 4)SOA架构

  • 5)微服务架构

1.1.1 单体应用架构

单体应用架构也叫集中式架构,在单体应用架构中,系统将所有的功能包括前端、后端等全部打包在一起部署,所有的代码都写在一起,通常也是交由一个小的技术团队开发;

微服务架构的演变_第1张图片

优点:

  • 项目架构简单,开发成本低
  • 项目部署在一个节点上, 维护方便

缺点:

  • 代码耦合度太高,开发维护困难
  • 无法针对不同模块进行针对性优化
  • 系统容错率低,如果该系统一个模块出现不可用会导致整个系统无法使用。

1.1.2 垂直应用架构

当访问量逐渐增大,单一应用无法满足需求,我们就需要增加节点来提供系统的访问能力,但是并不是所有的模块都需要进行性能的提高,这时候单体应用架构无法满足我们的需求;

我们需要将系统里面的模块进行拆分,这样对于后面的水平扩容是非常友好的;

微服务架构的演变_第2张图片

优点:

  • 系统拆分实现了流量分担,提高了系统并发量
  • 垂直架构中可以针对不同模块进行针对性优化
  • 方便水平扩展,负载均衡,系统容错率提高

缺点:

  • 系统间相互独立,会有很多重复开发工作,影响开发效率
  • 系统间相互独立,无法进行系统数据共享(互相调用)

1.1.3 分布式架构

当垂直应用越来越多,重复的业务代码就会越来越多,并且在垂直架构中应用之间的交互不可避免,此时,为了解决基础代码重复太多、应用之间的调用等问题;我们将重复的代码抽取出来作为独立的服务,对外提供服务;

微服务架构的演变_第3张图片

优点:

  • 将基础服务进行了抽取,系统间相互调用,提高了代码复用和开发效率

缺点:

  • 系统间耦合度变高,调用关系错综复杂,难以维护

1.1.4 SOA架构

在分布式架构下,当服务越来越多,容量的评估,小服务资源等浪费等问题逐渐显现,此时需增加一个调度中心对集群进行实时管理集群容量

微服务架构的演变_第4张图片

服务治理要做什么?(优点)

  • 服务注册中心,实现服务自动注册和发现,无需人为记录服务地址
  • 动态监控服务状态监控报告,人为控制服务状态
  • 服务负载均衡、服务熔断保护、服务健康检测、服务注册与发现、服务缓存等…

缺点:

  • 服务关系复杂,运维、测试部署困难

1.1.5 微服务架构

微服务架构模式是从SOA架构模式演变过来, 比SOA架构模式粒度更加精细,让专业的人去做专业的事情(专注),目的是提高效率,每个服务与服务之间互不影响,微服务架构中每个服务独立,互不影响;

微服务架构的演变_第5张图片

微服务的特点:

  • 单一职责:微服务中每一个服务都对应唯一的业务能力,做到单一职责
  • :微服务的服务拆分粒度很小,例如一个用户管理就可以作为一个服务。每个服务虽小,但“五脏俱全”。
  • 面向服务:面向服务是说每个服务都要对外暴露服务接口API。并不关心服务的技术实现,做到与平台和语言无关,也不限定用什么技术实现,只要提供Rest的接口即可。
  • 自治:自治是说服务间互相独立,互不干扰
    • 团队独立:每个服务都是一个独立的开发团队。
    • 技术独立:因为是面向服务,提供Rest接口,使用什么技术没有别人干涉
    • 前后端分离:采用前后端分离开发,提供统一Rest接口,后端不用再为PC、移动段开发不同接口
    • 数据库分离:每个服务都使用自己的数据源
    • 部署独立,服务间虽然有调用,但要做到服务重启不影响其它服务。有利于持续集成和持续交付。每个服务都是独立的组件,可复用,可替换,降低耦合,易维护

1.2 微服务架构设计原则

微服务是一种架构风格。一个大型的复杂软件应用,由一个或多个微服务组成。系统中的各个微服务可被独立部署,各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好的完成该任务。那么关于微服务的设计原则有哪些呢?

  • AKF拆分原则
  • 前后端分离原则
  • 无状态服务
  • RestFul 的通信风格

1.2.1 AKF拆分原则

随着互联网的高速发展,性能越来越成为我们瞩目的焦点,那么如何去提升我们服务器的性能呢?相信最简单和最直接的方法就是:加机器!如果一台不行就两台,两台不行就三台…

如何加机器?加在什么地方最有效?怎样的软件架构加机器才最有效成为我们考虑的重点;

对此,《可扩展的艺术》一书提出了一个更加系统的可扩展模型—— AKF 可扩展立方(Scalability Cube)。这个立方体中沿着三个坐标轴设置分别为:X、Y、Z。

微服务架构的演变_第6张图片

AKF公司的技术专家们从X/Y/Z三个维度来对应用进行扩展。理论上可以将一个单一系统进行无线的延伸扩展;

1.2.1.1 X轴扩展(水平复制)

X轴扩展就是我们平时说的水平扩容,一台机器不行就两台,两台不行就三台…简单来说就是搭建集群,使用Nginx等工具做到负载均衡,让多台机器一起工作来提升项目的整体性能;

微服务架构的演变_第7张图片

1.2.1.2 Y轴扩展(模块拆分)

Y轴扩展就是基于微服务架构的模块拆分,将一个庞大的项目拆分成若干个小模块,这些小模块分别独立部署在不同的机器,组成了一个完整的项目;

微服务架构的演变_第8张图片

1.2.1.3 Z轴扩展(数据分区)

Z轴扩展是基于数据的分区,比如我们之前学的MySQL数据拆分,ES的shard分片等都是基于数据的拆分,这些不同的数据分区独立部署不同的机器中,以提升这部分数据访问的能力;一般数据划分的方式有:

  • 1)根据数据类型进行分区(根据不同的业务拆分不同的数据库)
  • 2)根据数据的活跃程度进行分区(冷热分离)
  • 3)根据时间段进行分区(日志时间段)
  • 4)根据读写进行分区(读写分离)

微服务架构的演变_第9张图片

1.2.2 前后端分离原则

前后端分离原则简单的来说就是:前端负责前端的事情,后端负责后端的业务模块,前后端不再耦合在一起,分工明确;

前后端分离带来的优点有:

  • 1)可以由各自的专家来对各自的领域进行优化
  • 2)前后端交互界面更清晰,就剩下了接口模型,后端的接口简洁明了,更容易维护。
  • 3)前后端采用统一的数据和模型,可以支持多个前端:例如:微信 h5 前端、PC 前端、安卓前端、IOS 前端。
  • 4)职责更加清晰明确,前后端不再耦合,开发效率高;

1.2.3 无状态服务

无状态服务与有状态服务主要是根据:两个来自相同发起者的请求在服务器端是否具备上下文关系

1.2.3.1 状态化请求

服务器端一般都要保存请求的相关信息,才能分辨请求是否是同一个;

例如Cookie认证操作,客户端请求来到后端时查询Session,如果保存了用户的信息那么就认证通过,如果没有保存用户的信息,那么就认证不通过,这就是一个典型的有状态服务

1.2.3.2 无状态请求

服务器端所能够处理的过程必须全部来自于请求所携带的信息,以及其他服务器端自身所保存的、并且可以被所有请求所使用的公共信息;

例如Token认证,客户端发送请求携带Token来到后端服务,后端服务通过前端携带的Token来进行认证,如果换了台服务器依旧可以进行认证操作,此时就是有状态服务

1.2.3.3 HTTP是无状态的

由于HTTP协议本身就是无状态的,所以为了实现有状态服务(例如上面的Cookie认证),就需要通过一些额外的方案。比如最常见的session,将用户登录的信息保存到session中,当进行认证的时候,再从session中取出用户信息,进行认证;

1.2.3.4 无状态服务带来的好处

服务无状态,主要是提升服务的==可扩展性==;

如果服务是无状态的,我们就可以将请求发送到任意一台服务器,然后通过负载均衡,将请求平均分布在不同的服务器中,非常方便的实现水平扩展

如果服务是无状态的,就无法那么轻易的实现了,客户端需要始终将请求发送到同一台服务器才行,或者通过一些其他的手段达到目的,如分布式session共享、Redis单点登录等;

1.2.4 Restful通信风格

Restful架构,就是目前最流行的一种互联网软件架构,它结构清晰、符合标准、易于理解、扩展方便,所以正得到越来越多网站的采用。设计一个微服务架构的项目时,应该尽量遵守Restful风格进行通信;Restful好处如下:

1)基于JSON进行数据交互,简单轻量,人机阅读方便;

2)对请求进行更好的规范,如GET/POST/PUT/DELETE等都说明其用途,能更好的前后端对接;

3)Restful与编程语言无关,只要各个服务遵守Restful编写API,任何语言之间都可以进行通信(数据交互);

你可能感兴趣的:(Java,微服务,架构,分布式,Java,SpringCloud)