7.1.1. 服务注册发现
服务注册就是维护一个登记簿，它管理系统内所有的服务地址。当新的服务启动后，它会向登记
簿交待自己的地址信息。服务的依赖方直接向登记簿要 Service Provider 地址就行了。当下用于服
务注册的工具非常多 ZooKeeper，Consul，Etcd, 还有 Netflix 家的 eureka 等。服务注册有两种
形式：客户端注册和第三方注册。
7.1.1.1.
客户端注册（zookeeper）
客户端注册是服务自身要负责注册与注销的工作。当服务启动后向注册中心注册自身，当服务下
线时注销自己。期间还需要和注册中心保持心跳。心跳不一定要客户端来做，也可以由注册中心
负责（这个过程叫探活）。这种方式的缺点是注册工作与服务耦合在一起，不同语言都要实现一
套注册逻辑
7.1.1.2.
第三方注册（独立的服务 Registrar）
第三方注册由一个独立的服务Registrar负责注册与注销。当服务启动后以某种方式通知Registrar，
然后 Registrar 负责向注册中心发起注册工作。同时注册中心要维护与服务之间的心跳，当服务不
可用时，向注册中心注销服务。这种方式的缺点是 Registrar 必须是一个高可用的系统，否则注册
工作没法进展。
7.1.1.3.
客户端发现
客户端发现是指客户端负责查询可用服务地址，以及负载均衡的工作。这种方式最方便直接，而
且也方便做负载均衡。再者一旦发现某个服务不可用立即换另外一个，非常直接。缺点也在于多
语言时的重复工作，每个语言实现相同的逻辑。
7.1.1.4.
服务端发现
服务端发现需要额外的 Router 服务，请求先打到 Router，然后 Router 负责查询服务与负载均衡。
这种方式虽然没有客户端发现的缺点，但是它的缺点是保证 Router 的高可用。
7.1.1.5.
7.1.1.6.
7.1.1.7.
7.1.1.8.
Consul
Eureka
SmartStack
Etcd
7.1.2. API 网关
API Gateway 是一个服务器，也可以说是进入系统的唯一节点。这跟面向对象设计模式中的
Facade 模式很像。API Gateway 封装内部系统的架构，并且提供 API 给各个客户端。它还可能有
其他功能，如授权、监控、负载均衡、缓存、请求分片和管理、静态响应处理等。下图展示了一
个适应当前架构的 API Gateway。
API Gateway 负责请求转发、合成和协议转换。所有来自客户端的请求都要先经过 API Gateway，
然后路由这些请求到对应的微服务。API Gateway 将经常通过调用多个微服务来处理一个请求以
及聚合多个服务的结果。它可以在 web 协议与内部使用的非 Web 友好型协议间进行转换，如
HTTP 协议、WebSocket 协议。
7.1.2.1.
请求转发
服务转发主要是对客户端的请求安装微服务的负载转发到不同的服务上
7.1.2.2.
响应合并
把业务上需要调用多个服务接口才能完成的工作合并成一次调用对外统一提供服务。
7.1.2.3.
协议转换
重点是支持 SOAP，JMS，Rest 间的协议转换。
7.1.2.4.
数据转换
重点是支持 XML 和 Json 之间的报文格式转换能力（可选）
7.1.2.5.
安全认证
1. 基于 Token 的客户端访问控制和安全策略
2. 传输数据和报文加密，到服务端解密，需要在客户端有独立的 SDK 代理包
3. 基于 Https 的传输加密，客户端和服务端数字证书支持
4. 基于 OAuth2.0 的服务安全认证(授权码，客户端，密码模式等）
