微服务基础总结

1.服务注册和发现

服务注册维护一个登记簿，管理系统内所有服务地址，服务启动后会向登记簿交待自己的地址信息。

服务注册形式：客户端注册和第三方注册

• 客户端注册（zookeeper）
  • 服务自身要负责注册和注销工作，服务启动后向注册中心注册自身，当服务下线时注销自己，期间需要和注册中心保持心跳，心跳也可以由注册中心负责（探活）。
  • 缺点：注册工作与服务耦合在一起
• 第三方注册（独立的服务registrar）
  • 由独立的服务registrar负责注册与注销，服务启动后以某种方式通知registrar，然后负责向注册中心发起注册工作，注册中心要维护与服务之间的心跳，服务不可用时，向注册中心注销服务
  • 缺点：registrar必须是个高可用的系统，否则注册工作没法进展
• 客户端发现
  • 客户端负责查询服务地址，以及负载均衡工作
  • 缺点：多语言时的重复工作，每个语言实现相同逻辑
• 服务端发现
  • 额外的router服务，请求达到router，然后router负责查询服务于负载均衡
  • 缺点：保证router高可用
• Consul
• Eureka
• SmartStack
• Etcd

2.API网关

是进入系统的唯一节点，封装内部系统的架构并提供api给各个客户端，可能有其他功能：授权，监控，负载均衡，缓存，请求分片和管理，静态响应处理等。

所有来自客户端的请求都要先经过网关，然后路由这些请求到对应的微服务

将经常通过调用多个微服务来处理一个请求以及聚合多个服务的结果，可以在web协议与内部使用的非web友好型协议间进行转换，eg：http协议，webSocket协议

• 请求转发：对客户端的请求安装微服务的负载转发到不同的服务上
• 响应合并：把业务上需要调用多个服务接口才能完成的工作合并成一次调用对外统一提供服务
• 协议转换：支持 SOAP， JMS， Rest 间的协议转换。
• 数据转换：支持 XML 和 Json 之间的报文格式转换能力（可选 ）
• 安全认证：
  • 基于 Token 的客户端访问控制和安全策略
  • 传输数据和报文加密，到服务端解密，需要在客户端有独立的 SDK 代理包
  • 基于 Https 的传输加密，客户端和服务端数字证书支持
  • 基于 OAuth2.0 的服务安全认证(授权码，客户端，密码模式等）

3.配置中心

一般用作系统的参数配置，它需要满足如下几个要求：高效获取、实时感知、分布式访问

• zookeeper配置中心：采取数据加载到内存方式解决高效获取的问题，借助 zookeeper 的节点监听机制来实现实时感知。
• 配置中心数据分类：
  • 服务配置：数据库服务，队列服务，缓存服务
  • 各类开关：功能开关，业务开关，服务开关
  • 业务配置：模块A，B, C

4.事件调度（kafka）：消息服务和事件的统一调度，常用 kafka ， activemq 等

5.服务跟踪

• 随着微服务数量不断增长，需要跟踪一个请求从一个微服务到下一个微服务的传播过程， Spring Cloud Sleuth 在日志中引入唯一 ID，以保证微服务调用之间的一致性。
  • 为了实现请求跟踪，当请求发送到分布式系统的入口端点时，只需要服务跟踪框架为该请求创建一个唯一的跟踪标识（Trace ID），同时在分布式系统内部流转的时候，框架始终保持传递该唯一标识，直到返回给请求方为止 。通过 Trace ID 的记录，就能将所有请求过程日志关联起来。
  • 为了统计各处理单元的时间延迟，当请求达到各个服务组件时，或是处理逻辑到达某个状态时，也通过一个唯一标识(Span ID)来标记它的开始、具体过程以及结束， 对于每个 Span 来说，它必须有开始和结束两个节点，通过记录开始 Span 和结束 Span 的时间戳，就能统计出该 Span 的时间延迟，除了时间戳记录之外，它还可以包含一些其他元数据，比如：事件名称、请求信息等。
  • 在 Spring Boot 应用中，通过在工程中引入 spring-cloudstarter-sleuth 依赖之后， 它会自动的为当前应用构建起各通信通道的跟踪机制，比如：
    • 通过诸如 RabbitMQ、 Kafka（或者其他任何 Spring Cloud Stream 绑定器实现的消息中间件）传递的请求。
    • 通过 Zuul 代理传递的请求。
    • 通过 RestTemplate 发起的请求

6.服务熔断

在微服务架构中通常会有多个服务层调用，基础服务的故障可能会导致级联故障，进而造成整个系统不可用的情况，这种现象被称为服务雪崩效应。

服务雪崩效应是一种因“服务提供者”的不可用导致“服务消费者”的不可用,并将不可用逐渐放大的过程。

熔断器的原理很简单，如果在一段时间内侦测到许多类似的错误， 会强迫其以后的多个调用快速失败，不再访问远程服务器，从而防止应用程序不断地尝试执行可能会失败的操作，使得应用程序继续执行而不用等待修正错误，或者浪费 CPU
时间去等到长时间的超时产生。熔断器也可以使应用程序能够诊断错误是否已经修正，如果已经修正，应用程序会再次尝试调用操作

• Hystrix 断路器机制

  断路器：当 Hystrix Command 请求后端服务失败数量超过一定比例(默认 50%), 断路器会切换到开路状态(Open). 这时所有请求会直接失败而不会发送到后端服务. 断路器保持在开路状态一段时间后(默认 5 秒), 自动切换到半开路状态(HALF-OPEN). 这时会判断下一次请求的返回情况,如果请求成功, 断路器切回闭路状态(CLOSED), 否则重新切换到开路状态(OPEN). Hystrix 的断路器， 一旦后端服务不可用, 断路器会直接切断请求链, 避免发送大量无效
  请求影响系统吞吐量, 并且断路器有自我检测并恢复的能力

7.API管理：SwaggerAPI 管理工具