Architect_019:如何发现微服务?(摘录+整理)

标签: 软件设计模式与架构 | 发表时间:2016-06-09 11:25 | 作者:noreply@blogger.com (千红一窟)
分享到:
出处:http://maping930883.blogspot.com/
微服务的实例的网络位置都是动态分配的,而且因为扩展、失效和升级等需求,服务实例会经常动态改变,因此,需要一种更加复杂的服务发现机制。



目前有两大类服务发现模式:客户端发现和服务端发现。

1. 客户端发现模式
当使用客户端发现模式时,客户端负责决定相应服务实例的网络位置,并且对请求实现负载均衡。客户端从一个服务注册服务中查询,其中是所有可用服务实例的库。客户端使用负载均衡算法从多个服务实例中选择出一个,然后发出请求。
服务实例的网络位置在启动时注册到服务注册表中,并且在服务终止时从注册表中删除。
服务实例注册信息一般是使用心跳机制来定期刷新的。

客户端发现模式相对比较直接,除了服务注册表,没有做其它改变。除此之外,因为客户端知道可用服务注册表信息,因此客户端可以通过使用哈希一致性(hashing consistently)变得更加聪明,更加有效的负载均衡。
这种模式最大的缺点是需要针对不同的编程语言注册不同的服务,在客户端需要为每种语言开发不同的服务发现逻辑。
成功案例:Netflix OSS 使用了客户端发现模式。
Netflix Eureka 是一个服务注册表,为服务实例注册管理和查询可用实例提供了REST API接口。Netflix Ribbon 是一种IPC客户端,与Eureka 合作工作实现对请求的负载均衡。

2. 服务端发现模式
客户端通过负载均衡器向某个服务提出请求,负载均衡器向服务注册表发出请求,将每个请求转发给可用的服务实例。跟客户端发现一样,服务实例在服务注册表中注册或者注销。
服务端发现模式最大的优点是客户端无需关注发现的细节,客户端只需要简单的向负载均衡器发送请求,实际上减少了编程语言框架需要完成的发现逻辑。

3. 服务注册表
服务注册表是服务发现很重要的部分,它是包含服务实例网络地址的数据库。服务注册表需要高可用而且随时更新。客户端可以缓存从服务注册表获得的网络地址。然而,这些信息最终会变得过时,客户端也无法发现服务实例。因此,服务注册表由若干使用复制协议保持同步的服务器构成。
 

服务注册表例子:
  • etcd – 是一个高可用,分布式的,一致性的,键值表,用于共享配置和服务发现。两个著名案例包括Kubernetes和Cloud Foundry。
  • consul – 是一个用于发现和配置的服务。提供了一个API允许客户端注册和发现服务。Consul可以用于健康检查来判断服务可用性。
  • Apache ZooKeeper – 是一个广泛使用,为分布式应用提供高性能整合的服务。
4. 服务注册方式

4.1 自注册方式当使用自注册模式时,服务实例负责在服务注册表中注册和注销,并且,服务实例也要发送心跳来保证注册信息不会过时。下图描述了这种架构: 
自注册模式的优点是相对简单,不需要其他系统功能。
自注册模式的缺点是把服务实例跟服务注册表联系起来,必须在每种编程语言和框架内部实现注册代码。

4.2 第三方注册方式
当使用第三方注册模式时,服务实例并不负责向服务注册表注册,而是由另外一个系统模块,叫做服务管理器,负责注册。
服务管理器通过查询部署环境或订阅事件来跟踪运行服务的改变。
当管理器发现一个新可用服务,会向注册表注册此服务。
服务管理器也负责注销终止的服务实例。
下图是这种模式的架构图。

参考文献:
1. http://dockone.io/article/771

相关 [architect_019 发现 服务] 推荐:

Architect_019:如何发现微服务?(摘录+整理)

- - 热爱Java ,热爱生活
微服务的实例的网络位置都是动态分配的,而且因为扩展、失效和升级等需求,服务实例会经常动态改变,因此,需要一种更加复杂的服务发现机制. 目前有两大类服务发现模式:客户端发现和服务端发现. 当使用客户端发现模式时,客户端负责决定相应服务实例的网络位置,并且对请求实现负载均衡. 客户端从一个服务注册服务中查询,其中是所有可用服务实例的库.

[原]Curator服务发现

- - 升华思想 技术高深
一个服务发现系统提供下面几个机制:.  注册它们有用的服务.  定位一个单一特殊服务的实例.  当一个服务改变时发出通知. 3.3.1.1 服务实例. 一个服务实例使用类ServiceInstance作为服务实例类. ServiceInstance有一个名称、id、地址、端口或者ssl端口以及可选负载(用户定义).

服务发现:Zookeeper vs etcd vs Consul

- - 企业架构 - ITeye博客
服务发现:Zookeeper vs etcd vs Consul. 【编者的话】本文对比了Zookeeper、etcd和Consul三种服务发现工具,探讨了最佳的服务发现解决方案,仅供参考. 如果使用预定义的端口,服务越多,发生冲突的可能性越大,毕竟,不可能有两个服务监听同一个端口. 管理一个拥挤的比方说被几百个服务所使用的所有端口的列表,本身就是一个挑战,添加到该列表后,这些服务需要的数据库和数量会日益增多.

基于 Consul 的 Docker Swarm 服务发现

- - IT瘾-dev
基于 Consul 的 Docker Swarm 服务发现. 2017 年 1 月 10 日发布. Docker 是一种新型的虚拟化技术,它的目标在于实现轻量级操作系统的虚拟化. 相比传统的虚拟化方案,Docker. 虚拟化技术有一些很明显的优势:启动容器的速度明显快于传统虚拟化技术,同时创建一台虚拟机占用的资源也要远远小于传统的虚拟技术.

Apach警告Web Server发现拒绝服务漏洞

- coofucoo - Solidot
Apache发出警告,Apache HTTPD Web Server中发现拒绝服务漏洞,受影响的版本包括Apache 1.3分支和Apache 2分支的所有版本. Apache表示将在未来48小时内发布补丁. 名叫Apache Killer的攻击工具上周五发布在Full Disclosure邮件列表.

Marathon 服务发现及负载均衡 marathon-lb

- - 企业架构 - ITeye博客
       从官网摘抄了Mesos-DNS的缺陷,也是选择使用marathon-lb做服务发现和负载均衡的原因.        DNS does not identify service ports, unless you use an SRV query; most apps are not able to use SRV records “out of the box.”.

Kubernetes中的服务发现与负载均衡

- - Feisky's Blog
Kubernetes在设计之初就充分考虑了针对容器的服务发现与负载均衡机制,提供了Service资源,并通过kube-proxy配合cloud provider来适应不同的应用场景. 随着kubernetes用户的激增,用户场景的不断丰富,又产生了一些新的负载均衡机制. 目前,kubernetes中的负载均衡大致可以分为以下几种机制,每种机制都有其特定的应用场景:.

暗访北京三大电信运营商客户服务,发现十个小问题

- - 付亮的竞争情报应用
 近日,对北京三大运营商官方的实体营业厅、网厅、掌厅(手机客户端)、短信营业厅、客户电话做了一个初步的摸底(不涉及在电商开的网店及微信、微博客户服务). 这里列举发现的部分问题,就不一一列明了,欢迎对号入座. 1、运营商套餐太复杂了,政策变化太快,连营业员也搞不明白. 如果您看到一个合适的优惠套餐,您得拿着宣传页去找营业员,就这,可能有的地方还办不了,或者网厅和实体营业厅政策还不一致.

服务禁语

- tiancaicai - 白板报
前几天在一个公交汽车站拍到了一张规定,里面规定了服务禁语和礼貌用语,看了大乐. 3、乘车高峰车厢内拥挤时,禁语:“快往里走,站在前面又没有钞票检. ”文明语:“请尽量往里走,照顾没有上车的乘客”. 4、车子抛锚,禁语:“车子抛锚没有办法,人都要生毛病的,车子坏了也正常. ”文明语:“对不起,车子出现故障修一下,请大家理解.

服务熔断

- - CSDN博客推荐文章
服务熔断也称服务隔离,来自于Michael Nygard 的《Release It》中的CircuitBreaker应用模式,Martin Fowler在博文 CircuitBreaker中对此设计进行了比较详细说明. 本文认为服务熔断是服务降级的措施. 服务熔断对服务提供了proxy,防止服务不可能时,出现串联故障(cascading failure),导致雪崩效应.