微服务架构

1 微服务

1.1 服务注册发现

        服务注册就是维护一个登记簿，它管理系统内所有的服务地址。当新的服务启动后，它会向登记簿交待自己的地址信息。服务的依赖方直接向登记簿要Service Provider地址就行了。当下用于服务注册的工具非常多 ZooKeeper，Consul，Etcd, 还有 Netflix 家的 eureka 等。服务注册有两种形式：客户端注册和第三方注册。

1.1.1 客户端注册（ （zookeeper ）

        客户端注册是服务自身要负责注册与注销的工作。当服务启动后向注册中心注册自身，当服务下线时注销自己。期间还需要和注册中心保持心跳。心跳不一定要客户端来做，也可以由注册中心负责（这个过程叫探活）。这种方式的缺点是注册工作与服务耦合在一起，不同语言都要实现一
套注册逻辑。

1.1.2 第三方注册 （ 独立的服务 Registrar ）

         第三方注册由一个独立的服务Registrar负责注册与注销。当服务启动后以某种方式通知Registrar，然后 Registrar 负责向注册中心发起注册工作。同时注册中心要维护与服务之间的心跳，当服务不可用时，向注册中心注销服务。这种方式的缺点是 Registrar 必须是一个高可用的系统，否则注册工作没法进展。

1.1.3 客户端发现

         客户端发现是指客户端负责查询可用服务地址，以及负载均衡的工作。这种方式最方便直接，而且也方便做负载均衡。再者一旦发现某个服务不可用立即换另外一个，非常直接。缺点也在于多语言时的重复工作，每个语言实现相同的逻辑。

1.1.4 服务端发现

        服务端发现需要额外的 Router 服务，请求先打到 Router，然后 Router 负责查询服务与负载均衡。这种方式虽然没有客户端发现的缺点，但是它的缺点是保证 Router 的高可用。

1.2 API 网关

        API Gateway 是一个服务器，也可以说是进入系统的唯一节点。这跟面向对象设计模式中的
Facade 模式很像。API Gateway 封装内部系统的架构，并且提供 API 给各个客户端。它还可能有
其他功能，如授权、监控、负载均衡、缓存、请求分片和管理、静态响应处理等。下图展示了一
个适应当前架构的 API Gateway。

         API Gateway 负责请求转发、合成和协议转换。所有来自客户端的请求都要先经过 API Gateway，然后路由这些请求到对应的微服务。API Gateway 将经常通过调用多个微服务来处理一个请求以及聚合多个服务的结果。它可以在 web 协议与内部使用的非 Web 友好型协议间进行转换，如HTTP 协议、WebSocket 协议。

1.2.1 请求转发 

服务转发主要是对客户端的请求安装微服务的负载转发到不同的服务上

1.2.2 响应合并

把业务上需要调用多个服务接口才能完成的工作合并成一次调用对外统一提供服务。

1.2.3  协议转换

重点是支持 SOAP，JMS，Rest 间的协议转换。

1.2.4 数据转换

重点是支持 XML 和 Json 之间的报文格式转换能力（可选）

1.2.5 安全认证

1. 基于 Token 的客户端访问控制和安全策略
2. 传输数据和报文加密，到服务端解密，需要在客户端有独立的 SDK 代理包
3. 基于 Https 的传输加密，客户端和服务端数字证书支持
4. 基于 OAuth2.0 的服务安全认证(授权码，客户端，密码模式等）

1.3 配置中心

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

1.3.1 zookeeper 配置中心

        实现的架构图如下所示，采取数据加载到内存方式解决高效获取的问题，借助 zookeeper 的节点监听机制来实现实时感知。

1.3.2 配置中心数据分类

1.4 事件调度 （kafka）

消息服务和事件的统一调度，常用用 kafka ，activemq 等。

1.5 服务跟踪 （ starter-sleuth ） 

        随着微服务数量不断增长，需要跟踪一个请求从一个微服务到下一个微服务的传播过程， Spring Cloud Sleuth 正是解决这个问题，它在日志中引入唯一 ID，以保证微服务调用之间的一致性，这样你就能跟踪某个请求是如何从一个微服务传递到下一个。

1. 为了实现请求跟踪，当请求发送到分布式系统的入口端点时，只需要服务跟踪框架为该请求
创建一个唯一的跟踪标识，同时在分布式系统内部流转的时候，框架始终保持传递该唯一标
识，直到返回给请求方为止，这个唯一标识就是前文中提到的 Trace ID。通过 Trace ID 的记
录，我们就能将所有请求过程日志关联起来。
2. 为了统计各处理单元的时间延迟，当请求达到各个服务组件时，或是处理逻辑到达某个状态
时，也通过一个唯一标识来标记它的开始、具体过程以及结束，该标识就是我们前文中提到
的 Span ID，对于每个 Span 来说，它必须有开始和结束两个节点，通过记录开始 Span 和结
束 Span 的时间戳，就能统计出该 Span 的时间延迟，除了时间戳记录之外，它还可以包含一
些其他元数据，比如：事件名称、请求信息等。
3. 在快速入门示例中，我们轻松实现了日志级别的跟踪信息接入，这完全归功于spring-cloud-
starter-sleuth 组件的实现。在 Spring Boot 应用中，通过在工程中引入 spring-cloud-
starter-sleuth 依赖之后， 它会自动的为当前应用构建起各通信通道的跟踪机制，比如：

• 通过诸如 RabbitMQ、Kafka（或者其他任何 Spring Cloud Stream 绑定器实现的消息中间件）传递的请求。
• 通过 Zuul 代理传递的请求。
• 通过 RestTemplate 发起的请求。

1.6 服务熔断 （Hystrix） 

        在微服务架构中通常会有多个服务层调用，基础服务的故障可能会导致级联故障，进而造成整个系统不可用的情况，这种现象被称为服务雪崩效应。服务雪崩效应是一种因“服务提供者”的不
可用导致“服务消费者”的不可用,并将不可用逐渐放大的过程。
        熔断器的原理很简单，如同电力过载保护器。它可以实现快速失败，如果它在一段时间内侦测到许多类似的错误，会强迫其以后的多个调用快速失败，不再访问远程服务器，从而防止应用程序不断地尝试执行可能会失败的操作，使得应用程序继续执行而不用等待修正错误，或者浪费 CPU时间去等到长时间的超时产生。熔断器也可以使应用程序能够诊断错误是否已经修正，如果已经修正，应用程序会再次尝试调用操作。

1.6.1 Hystrix 断路器机制

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

1.7 API 管理

SwaggerAPI 管理工具。