[关闭]
@JunQiu 2018-09-18T13:15:52.000000Z 字数 1493 阅读 460

微服务:服务发现与注册

summary_2018/08 arch


1、日常

1.1、facbookAd:PT-filter:mock test

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


2、技术

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

  1. ## 这篇文章主要去解决以下信息
  2. 1、注册的 IP 和端口怎么确定
  3. 2、实现服务治理还需要注册哪些信息
  4. 3、如何进行优雅的服务注册与服务下线
  5. 4、注册服务的健康检查是如何做的
  6. 5、当服务有节点退出或新的节点加入时,订阅者能不能及时收到通知 ?
  7. 7、我能方便地查看某个应用发布和订阅了哪些服务,以及所订阅的服务有哪些节点吗
  8. // IP获取
  9. 1、比如手动配置,但在生产基本无法使用,可能会服务间冲突,或者需要进行水平拓展
  10. 2、最好的方式通过动态分配
  11. // 端口确定
  12. 1、如果是 RPC 应用,启动的时候都有一个配置来指定服务监听的端口, 注册的时候直接使用配置项的端口值。
  13. 2、传统的 WEB 容器所提供的HTTP的应用,同样也存在一个配置文件来配置容器的监听端口,注册时候直接使用配置项的端口值
  14. // 服务的治理还需要哪些信息??
  15. 比较简单的服务,我们可能并不需要其余的信息,但是当业务发展到一定的时候,我们可能会有其它的需求:
  16. 1、比如HTTP服务是否开启了TLS
  17. 2、比如需要进行负载均衡
  18. 3、将服务分成预发环境和生产环境,方便进行AB TEST
  19. 。。。等等
  20. // 如何进行优雅发布和服务下线??
  21. // 优雅发布
  22. 虽然服务注册一般发生在服务的启动阶段,但是细分的话,服务注册应该在服务已经完全启动成功,并准备对外提供服务之后才能进行注册。
  23. // 优雅下线
  24. 绝大多数的服务注册中心都提供了健康检查功能,在应用停止后会自动摘除服务所对应的节点。但是我们也不能完全依赖此功能,应用应该在停止时主动调用服务注册中心的服务下线接口。
  25. 当然,服务也可能异常退出,这种我们应该做一些容错处理,而且一般情况下,我们并不能保证服务的正确性,因此我们应该假想服务可能会失败,从而保证服务的健壮性。
  26. // 服务的健康检查如何处理?
  27. 1、一种方法是基于客户端额,客户端每隔一段时间向服务中心发送“心跳”,但是这种情况并不能保证服务的正确性,只能保证两者间的链路正常。
  28. 2、另一种方式是通过服务中心,主动像客户端发起请求,根据返回结果来判断服务的正确性。
  1. // 怎么找到服务中心的地址??
  2. 在配置文件中指定、一个固定的服务中心地址
  3. // 当有节点退出或者加入的时候,订阅者如何及时收到通知??
  4. 订阅者和发布者模式,经典的pushpull问题。
  5. 1Push 的经典实现有两种,基于 socket 长连接的 notify,典型的实现如 zookeeper;另一种为 HTTP 连接所使用 Long Polling。但两者都存在消息丢失的情况也需要适当的和pull方式定时轮询来实现。
  6. 2pull方式的轮询对服务的中心有一定的压力,因此我们需要做一定的权衡。
  7. // 如何查看我发布和订阅了哪些服务??
  8. 提供丰富的API接口,便于管理和使用。
  9. // 容灾和高可用性
  10. 1、性能
  11. 当服务越来越多的时候,服务中心的压力会越来越大,这时候需要进行拓展来提升性能。一般而言进行水平拓展,对于采用强一致性的组件,水平拓展并不能提升其写性能,但是可以提高读性能。但对于采用最终一致性的组件而言,是可以提高的。
  12. 2、客户端
  13. 内存缓存->本地缓存->本地文件(主要针对故障长时间不能恢复,服务提供者又发生了比较大的变化时,可以直接从本地文件中读)
  14. 3、服务端
  15. 1、当某个节点宕机时,此服务注册中心节点的信息会自动地址服务器中摘除,客户端能及时感知到此节点已下线。
添加新批注
在作者公开此批注前,只有你和作者可见。
回复批注