服务注册发现
服务注册就是维护一个登记簿,它管理系统内全部的服务地址。当新的服务启动后,它会向登记簿交待本身的地址信息。服务的依赖方直接向登记簿要 Service Provider 地址就好了。当下用于服务注册的工具很是多 ZooKeeper,Consul,Etcd, 还有 Netflix 家的 eureka 等。服务注册有两种web
形式:客户端注册和第三方注册。spring
客户端注册(zookeeper)后端
客户端注册是服务自身要负责注册与注销的工做。当服务启动后向注册中心注册自身,当服务下线时注销本身。期间还须要和注册中心保持心跳。心跳不必定要客户端来作,也能够由注册中心负责(这个过程叫探活)。这种方式的缺点是注册工做与服务耦合在一块儿,不一样语言都要实现一套注册逻辑。设计模式
第三方注册(独立的服务 Registrar)缓存
第三方注册由一个独立的服务Registrar负责注册与注销。当服务启动后以某种方式通知Registrar,而后 Registrar 负责向注册中心发起注册工做。同时注册中心要维护与服务之间的心跳,当服务不可用时,向注册中心注销服务。这种方式的缺点是 Registrar 必须是一个高可用的系统,不然注册工做无法进展。安全
客户端发现服务器
客户端发现是指客户端负责查询可用服务地址,以及负载均衡的工做。这种方式最方便直接,并且也方便作负载均衡。再者一旦发现某个服务不可用当即换另一个,很是直接。缺点也在于多语言时的重复工做,每一个语言实现相同的逻辑。架构
服务端发现负载均衡
服务端发现须要额外的 Router 服务,请求先打到 Router,而后 Router 负责查询服务与负载均衡。框架
这种方式虽然没有客户端发现的缺点,可是它的缺点是保证 Router 的高可用。
API 网关
API Gateway 是一个服务器,也能够说是进入系统的惟一节点。这跟面向对象设计模式中的Facade 模式很像。API Gateway 封装内部系统的架构,而且提供 API 给各个客户端。它还可能有其余功能,如受权、监控、负载均衡、缓存、请求分片和管理、静态响应处理等。下图展现了一个适应当前架构的 API Gateway。
API Gateway 负责请求转发、合成和协议转换。全部来自客户端的请求都要先通过 API Gateway,而后路由这些请求到对应的微服务。API Gateway 将常常经过调用多个微服务来处理一个请求以及聚合多个服务的结果。它能够在 web 协议与内部使用的非 Web 友好型协议间进行转换,如HTTP 协议、WebSocket 协议。
请求转发
服务转发主要是对客户端的请求安装微服务的负载转发到不一样的服务上响应合并
把业务上须要调用多个服务接口才能完成的工做合并成一次调用对外统一提供服务。
协议转换
重点是支持 SOAP,JMS,Rest 间的协议转换。
数据转换
重点是支持 XML 和 Json 之间的报文格式转换能力(可选)
安全认证
基于 Token 的客户端访问控制和安全策略
传输数据和报文加密,到服务端解密,须要在客户端有独立的 SDK 代理包
基于 Https 的传输加密,客户端和服务端数字证书支持
配置中心
配置中心通常用做系统的参数配置,它须要知足以下几个要求:高效获取、实时感知、分布式访问。
zookeeper 配置中心
实现的架构图以下所示,采起数据加载到内存方式解决高效获取的问题,借助 zookeeper 的节点监听机制来实现实时感知。
配置中心数据分类
事件调度(kafka)
消息服务和事件的统一调度,经常使用用 kafka ,activemq 等。
服务跟踪(starter-sleuth)
随着微服务数量不断增加,须要跟踪一个请求从一个微服务到下一个微服务的传播过程, Spring Cloud Sleuth 正是解决这个问题,它在日志中引入惟一 ID,以保证微服务调用之间的一致性,这样你就能跟踪某个请求是如何从一个微服务传递到下一个。
为了实现请求跟踪,当请求发送到分布式系统的入口端点时,只须要服务跟踪框架为该请求建立一个惟一的跟踪标识,同时在分布式系统内部流转的时候,框架始终保持传递该惟一标识,直到返回给请求方为止,这个惟一标识就是前文中提到的 Trace ID。经过 Trace ID 的记录,咱们就能将全部请求过程日志关联起来。
为了统计各处理单元的时间延迟,当请求达到各个服务组件时,或是处理逻辑到达某个状态时,也经过一个惟一标识来标记它的开始、具体过程以及结束,该标识就是咱们前文中提到的 Span ID,对于每一个 Span 来讲,它必须有开始和结束两个节点,经过记录开始 Span 和结束 Span 的时间戳,就能统计出该 Span 的时间延迟,除了时间戳记录以外,它还能够包含一些其余元数据,好比:事件名称、请求信息等。
经过诸如 RabbitMQ、Kafka(或者其余任何 Spring Cloud Stream 绑定器实现的消息中间件)传递的请求。
经过 Zuul 代理传递的请求。
经过 RestTemplate 发起的请求。
服务熔断(Hystrix)
在微服务架构中一般会有多个服务层调用,基础服务的故障可能会致使级联故障,进而形成整个系统不可用的状况,这种现象被称为服务雪崩效应。服务雪崩效应是一种因“服务提供者”的不可用致使“服务消费者”的不可用,并将不可用逐渐放大的过程。
熔断器的原理很简单,如同电力过载保护器。它能够实现快速失败,若是它在一段时间内侦测到许多相似的错误,会强迫其之后的多个调用快速失败,再也不访问远程服务器,从而防止应用程序不断地尝试执行可能会失败的操做,使得应用程序继续执行而不用等待修正错误,或者浪费 CPU时间去等到长时间的超时产生。熔断器也可使应用程序可以诊断错误是否已经修正,若是已经修正,应用程序会再次尝试调用操做。
Hystrix 断路器机制
断路器很好理解, 当 Hystrix Command 请求后端服务失败数量超过必定比例(默认 50%), 断路器会切换到开路状态(Open). 这时全部请求会直接失败而不会发送到后端服务. 断路器保持在开路状态一段时间后(默认 5 秒), 自动切换到半开路状态(HALF-OPEN). 这时会判断下一次请求的返回状况,若是请求成功, 断路器切回闭路状态(CLOSED), 不然从新切换到开路状态(OPEN). Hystrix 的断路器,就像咱们家庭电路中的保险丝, 一旦后端服务不可用, 断路器会直接切断请求链, 避免发送大量无效请求影响系统吞吐量, 而且断路器有自我检测并恢复的能力。
API 管理SwaggerAPI 管理工具。