1.背景
l 服务的客户端（包括API网关或者其他服务）如何获取服务端实例的位置
l 每个服务端实例都会在特定的位置（主机及端口）通过HTTP/REST或者Thrift等方式发布一个远程API
l 服务端实例的具体数量和位置会发生动态变化
l 虚拟机与容器通常会被分配动态IP地址
2.方案
2.1 客户端服务发现
向某一服务发送请求时，客户端会通过查询Servcie Registry，即服务注册表来回去该服务的具体位置/该注册表包含全部服务的位置。
2.2 客户端服务发现的优缺点
（1）优点
l 相比服务端发现，客户端服务发现的活动部件与网络中转数量更少。
（2）缺点
l 需要为应用程序中使用的每种语言建立客户端发现逻辑
2.3 服务端服务发现
向某一服务发送请求时，客户端会通知在已知位置的路由器（或者负载均衡器）发送请求。路由器会访问服务注册表，并向可用的服务实例转发该请求。服务注册表也可能被内建于路由器之中。
2.4 服务端发现的优缺点
（1）优点
l 相较客户端发现，其客户端代码无需实现服务发现功能，只需要向路由机制发送请求即可。
（2）缺点
l 除非成为云环境的一部分，否则该路由机制必须作为另一个系统组件进行安装与配置。为实现可用性和一定的接入能力，还需要为其配置一定数量的副本。
l 相较于客户端发现，服务端发现需要更多的网络跳转
3.服务注册表
3.1 背景
l 服务的客户端需要使用客户端发现机制或者服务端发现机制，获取需要发送请求的服务实例的位置
l 每个服务实例都会在特定位置（主机与端口）通过HTTP/REST或者Thrift等方式发布一个远程API。
l 服务实力的数量和位置会动态的发生变化。虚拟机与容器通常会被分配一个动态的IP地址。
3.2 方案
建立一套服务注册表。即一个包括服务、服务的实例和起位置的数据库。各服务示例需要在启动时注册至服务注册表，并在关闭的时候进行注销。该服务的客户端或者路由器通过查询此服务注册表获取可用的服务实例
3.3 服务注册表模式的优缺点
（1）优点
l 服务的客户端及路由器可以获取可用的服务实例的位置
（2）缺点
l 除非服务注册表被内置于基础设施，否则其必须做为另外的基础设施组件进行安装，配置及管理。
l 需要解决各服务示例如何注册至注册表，如何从注册表中注销
3.4 服务注册表的注册方式
3.4.1 需求
l 各服务实例必须在启动时注册到服务注册表，并在关闭时从服务注册表中注销
l 崩溃的服务实例必须从服务注册表中注销
l 在运行但无力处理请求的服务实例必须从服务注册表中注销
3.4.2 方案
3.4.2.1自注册
一项服务实例必须可以自动注册到服务注册表中。在启动时，该服务实例将自身（主机与IP地址）注册至服务注册表，使自身可被发现。客户端必须定期更新其注册信息，确保注册表获悉其仍处于运行状态。在关闭时，服务实例从服务注册表中自动注销。这一流程通常由微服务底盘框架实现。
3.4.2.2 自注册的优缺点
（1）优点
l 服务实例了解自身的状态，因而能够实现比启动/停止更为负责的状态模型。
（2）缺点
l 将服务与注册表耦合起来
l 需要为编写服务时使用的每种语言分别实现服务注册逻辑。
l 正在运行但无法处理请求的服务示例往往无法自动在服务注册表中进行自我注销
3.4.2.3第三方注册
由第三方负责将服务和服务实例在服务注册表中的注册，并在服务启动的时候将服务实例注册到服务注册表。而在服务实例关闭的时候在服务注册表中注销
3.4.2.4 第三方注册的优缺点
（1）优点
l 与自注册相比，服务端无需实现自动注册逻辑，复杂度较低
l 注册工具可以对服务进行健康检查，并根据健康检查注册或者注销该实例
（2）缺点
l 第三方注册只能了解服务实例的一些表层状态，例如其是否正在运行，并不能判断正在运行的服务是否能够处理请求
l 除非该注册工具属于基础设施的一部分，否则我们需要对其进行安装、配置及维护。由于其属于关键部件，需要保证其高可用。
1087
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
