一、 是什么

一种架构模式，将一个很大的代码库拆分成若干个小模块，一个模块即一个服务，符合单一职责，对外提供服务，服务之间通信基于网络，某一个服务内部的修改不会影响服务调用方的变动。

1.1 优势

  • 编程语言没有限定，不同模块可以使用单独的技术语言；
  • 各个模块独立，升级或者出现问题，不会影响其他模块，不会有扩散性；
  • 易于扩展，可以给某个单独模块提升扩展；

1.2 问题

微服务是基于分布式的系统，那就需要解决一致性的问题和自身对分布式的知识储备。

1.3 全景架构

img

1.4 核心组件

  • 服务注册与发现；
  • 服务通信；
  • 配置中心；
  • 服务治理；
  • 服务监控；
  • 链路追踪；
  • API 网关服务；

二、服务通信

2.1 理解

微服务架构服务与服务之间，如何通信是一个需要学习的地方。

这时候就需要学习 RPC 的相关知识了，它是绝大多数微服务架构下服务交互通信的方式。这里我主要就需要 JSON RPC 和 GRPC。一个是目前实习中需要使用到的，一个是主流目前使用的。

  • JSON RPC
  • GRPC

2.2 组成

服务按照调用方或者或者调用方角色来区分的话，分为服务提供者和服务消费者，A 服务对 B 服务提供服务，A 服务就是服务提供者，B 服务就是服务消费者，同时 A 服务也有可能使用到了别的服务，那它也有可能既是服务提供者也是服务消费者。

三、服务注册与发现

3.1 理解

服务拆分之后，B 服务调用 A 服务，我们需要让 B 服务知道 A 服务的相关地址信息（ IP 地址、端口号等），我们为可以一个服务一个服务的单独配置，当前服务每调用一个新的服务就增加一个配置，但是这样子的不就很繁琐以及不利于更新。所以就有一个服务中心的东西，每个服务将当前自己的相关信息注册到服务中心，然后服务调用者去服务中心找所需服务的配置信息（服务发现）然后进行调用。

并且如果服务提供者信息发生了变动，服务中心会立刻同时服务消费者。

img

3.2 组成

  • 服务提供者
  • 服务消费者
  • ·服务中心（负责服务注册和发现）

3.3 CAP

三者只能实现两者，分为CP和AP，分区容忍性是必须实现的。

  • 一致性：多个节点的数据返回始终一致的性质；
  • 可用性：每次请求都能获取到非错的响应的性质；
  • 分区容忍性即使分区现象发生，系统仍然可以工作的性质。

后面主要先需要 consul 和 etcd 这两个注册中心

四、配置中心

全局统一管理配置信息的地方，微服务下传统的配置文件管理方式不利于管理。

img

五、服务治理

5.1 节点管理

监控服务调用者或者消费者是否健康，如果出现异常就将其剔除。

5.2 负载均衡

多个服务，基于负载均衡算法，选择一个服务提供服务。

  • 随机算法；
  • 轮询算法；
  • 最少连接算法；
  • Hash 一致性算法；

5.3 服务路由

  • 灰度发布；
  • 多机房就近访问；

5.4 服务容错

  • FailOver 失败自动切换；
  • FailBack 失败通知，通知服务调用者，不再重试；
  • FailCache 失败缓存，果断时间再重试；
  • FailFast 快速失败，失败了直接结束。

5.5 服务熔断

5.6 服务限流

5.7 服务重试

六、服务监控

监控各个服务的健康状态

七、链路追踪

微服务架构下，一个请求会调用 n 个服务，追踪这些服务的服务情况已经处理延迟等信息是一个迫切的需求。

img

八、API 网关

服务和服务之间基本都是靠 RPC 来通信的，但是用户是通过 HTTP 来访问的，这时候就需要一个网关来聚合这些服务，处理请求。

img

九、参考链接