微服务(一)

服务注册发现

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

客户端注册(zookeeper)

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

第三方注册(独立的服务Registrar)

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

客户端发现

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

服务端发现

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


API 网关

  API Gateway是一个服务器,也可以说是进入系统的唯一节点。这跟面向对象设计模式中的Facade模式很像。API Gateway封装内部系统的架构,并且提供API给各个客户端。它还可能有其他功能,如授权、监控、负载均衡、缓存、请求分片和管理、静态响应处理等。下图展示了一个适应当前架构的API Gateway。
avatar
  API Gateway负责请求转发、合成和协议转换。所有来自客户端的请求都要先经过API Gateway,然后路由这些请求到对应的微服务。API Gateway将经常通过调用多个微服务来处理一个请求以及聚合多个服务的结果。它可以在web协议与内部使用的非Web友好型协议间进行转换,如HTTP协议、WebSocket协议。

请求转发

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

响应合并

  把业务上需要调用多个服务接口才能完成的工作合并成一次调用对外统一提供服务。
  ps:https://blog.csdn.net/u012702547/article/details/78213270

协议转换

  重点是支持SOAP,JMS,Rest间的协议转换。
  ps:JSM https://www.cnblogs.com/chenpi/p/5559349.html

数据转换

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

安全认证

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