微服务:服务发现与注册

summary_2018/08 arch

1、日常

1.1、facbookAd:PT-filter:mock test

1.2、微服务：服务的发现与注册

2、技术

2.2、微服务：服务的发现与注册

• 服务注册(ip、端口的获取、扩展信息、优雅的上线和下线)

## 这篇文章主要去解决以下信息
1、注册的 IP 和端口怎么确定 ？
2、实现服务治理还需要注册哪些信息 ？
3、如何进行优雅的服务注册与服务下线 ？
4、注册服务的健康检查是如何做的 ？
5、当服务有节点退出或新的节点加入时，订阅者能不能及时收到通知 ?
7、我能方便地查看某个应用发布和订阅了哪些服务，以及所订阅的服务有哪些节点吗 ？
// IP获取
1、比如手动配置，但在生产基本无法使用，可能会服务间冲突，或者需要进行水平拓展
2、最好的方式通过动态分配
// 端口确定
1、如果是 RPC 应用，启动的时候都有一个配置来指定服务监听的端口， 注册的时候直接使用配置项的端口值。
2、传统的 WEB 容器所提供的HTTP的应用，同样也存在一个配置文件来配置容器的监听端口，注册时候直接使用配置项的端口值
// 服务的治理还需要哪些信息？？
比较简单的服务，我们可能并不需要其余的信息，但是当业务发展到一定的时候，我们可能会有其它的需求：
1、比如HTTP服务是否开启了TLS
2、比如需要进行负载均衡
3、将服务分成预发环境和生产环境，方便进行AB TEST
。。。等等
// 如何进行优雅发布和服务下线？？
// 优雅发布
虽然服务注册一般发生在服务的启动阶段，但是细分的话，服务注册应该在服务已经完全启动成功，并准备对外提供服务之后才能进行注册。
// 优雅下线
绝大多数的服务注册中心都提供了健康检查功能，在应用停止后会自动摘除服务所对应的节点。但是我们也不能完全依赖此功能，应用应该在停止时主动调用服务注册中心的服务下线接口。
当然，服务也可能异常退出，这种我们应该做一些容错处理，而且一般情况下，我们并不能保证服务的正确性，因此我们应该假想服务可能会失败，从而保证服务的健壮性。
// 服务的健康检查如何处理？
1、一种方法是基于客户端额，客户端每隔一段时间向服务中心发送“心跳”，但是这种情况并不能保证服务的正确性，只能保证两者间的链路正常。
2、另一种方式是通过服务中心，主动像客户端发起请求，根据返回结果来判断服务的正确性。

• 服务发现

// 怎么找到服务中心的地址？？
在配置文件中指定、一个固定的服务中心地址
// 当有节点退出或者加入的时候，订阅者如何及时收到通知？？
订阅者和发布者模式，经典的push和pull问题。
1、Push 的经典实现有两种，基于 socket 长连接的 notify，典型的实现如 zookeeper；另一种为 HTTP 连接所使用 Long Polling。但两者都存在消息丢失的情况也需要适当的和pull方式定时轮询来实现。
2、pull方式的轮询对服务的中心有一定的压力，因此我们需要做一定的权衡。
// 如何查看我发布和订阅了哪些服务？？
提供丰富的API接口，便于管理和使用。
// 容灾和高可用性
1、性能
当服务越来越多的时候，服务中心的压力会越来越大，这时候需要进行拓展来提升性能。一般而言进行水平拓展，对于采用强一致性的组件，水平拓展并不能提升其写性能，但是可以提高读性能。但对于采用最终一致性的组件而言，是可以提高的。
2、客户端
内存缓存->本地缓存->本地文件（主要针对故障长时间不能恢复，服务提供者又发生了比较大的变化时，可以直接从本地文件中读）
3、服务端
1、当某个节点宕机时，此服务注册中心节点的信息会自动地址服务器中摘除，客户端能及时感知到此节点已下线。

• 参考文献
  
  • 聊聊微服务的服务注册与发现