油盐微服务——服务发现与请求方式

服务发现

传统的项目而言，服务器端的服务实例的网络地址是相对固定的。而基于云端、现代化的微服务服务实例的网络地址往往是动态更新的。由于服务器端的服务实例扩展、维护、升级，导致服务器端服务实例的IP地址、端口发生变化，从而使得客户端无法获取服务实例新的地址进行正常的调用。

服务发现为解决此类问题的一个解决方案，服务发现实时的获取服务器端服务实例的最新网络地址生成服务注册表，并提供给路由器或客户端服务实例的可用信息。服务注册表可以理解为一个包含所有服务信息的数据库。

服务发现的两种模式：客户端服务发现 、 服务器端服务发现。

客户端服务发现

客户端服务发现指的是客户端直接去服务注册表中查询服务实例信息，并对所有可用的服务实例进行负载均衡算法获得一个最终的服务实例地址，去进行请求。

服务实例在服务启动时向服务注册表注册服务信息，并定期发送心跳来更新服务信息。服务注册表会根据发送来的心跳判断服务是否正常运行，若多次收不到心跳则会剔除对应的服务实例。当然服务实例也可以像服务注册表注销服务信息。

客户端服务发现的优点：不需要额外配制路由器、负载均衡器，由客户端直接查询注册表并进行负载均衡。
缺点：需要客户端与服务注册绑定，客户端要根据服务端的编程语言和框架来实现服务发现逻辑。

Eureka、Zookeeper就是客户端服务发现的方式。

服务端服务发现

服务端服务发现不由客户端直接去查询服务注册表，客户端正常的请求负载均衡器，由负载均衡器进行与服务注册表的交互，最终通过负载均衡器的负载均衡算法找到可用服务实例并请求。而服务实例在服务注册表的注册与注销等机制 与 客户端服务发现一致。

服务器端服务发现的优点：客户端不需要关注服务发现的实现，只需要正常的向负载均衡器发送请求即可。
这减少了编程语言框架需要完成的发现逻辑
缺点：除非负载均衡器由部署环境提供，否则会成为一个需要配置和管理的高可用系统组件。

RPC服务和HTTP服务对比

• 当使用RPC框架实现服务间调用的时候，要求服务提供方和服务消费方 都必须使用统一的RPC框架，要么都dubbo，要么都cxf
  跨操作系统在同一编程语言内使用
  优势：调用快、处理快

-当使用http进行服务间调用的时候，无需关注服务提供方使用的编程语言，也无需关注服务消费方使用的编程语言，服务提供方只需要提供restful风格的接口，服务消费方，按照restful的原则，请求服务，即可
跨系统跨编程语言的远程调用框架
优势：通用性强

速度来看，RPC要比http更快，虽然底层都是TCP，但是http协议的信息往往比较臃肿
难度来看，RPC实现较为复杂，http相对比较简单
灵活性来看，http更胜一筹，因为它不关心实现细节，跨平台、跨语言。
因此，两者都有不同的使用场景：

如果对效率要求更高，并且开发过程使用统一的技术栈，那么用RPC还是不错的。
如果需要更加灵活，跨语言、跨平台，显然http更合适

RPC服务

一个完整的RPC架构里面包含了四个核心的组件，分别是Client ,Server,Client Stub以及Server Stub，这个Stub大家可以理解为存根。分别说说这几个组件：

• 客户端（Client），服务的调用方。
• 服务端（Server），真正的服务提供者。
• 客户端存根，存放服务端的地址消息，再将客户端的请求参数打包成网络消息，然后通过网络远程发送给服务方。
• 服务端存根，接收客户端发送过来的消息，将消息解包，并调用本地的方法。

RPC主要是用在大型企业里面，因为大型企业里面系统繁多，业务线复杂，而且效率优势非常重要的一块，这个时候RPC的优势就比较明显了。实际的开发当中是这么做的，项目一般使用maven来管理。比如我们有一个处理订单的系统服务，先声明它的所有的接口（这里就是具体指Java中的interface），然后将整个项目打包为一个jar包，服务端这边引入这个二方库，然后实现相应的功能，客户端这边也只需要引入这个二方库即可调用了。为什么这么做？主要是为了减少客户端这边的jar包大小，因为每一次打包发布的时候，jar包太多总是会影响效率。另外也是将客户端和服务端解耦，提高代码的可移植性。