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

标签: 软件设计模式与架构 | 发表时间:2016-06-09 19:25 | 作者:[email protected] (千红一窟)
出处: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 发现 微服务] 推荐:

The Right Way to Architect iOS App with Swift

- - limboy's HQ
关于 iOS 架构的文章感觉已经泛滥了,前一阵正好 Android 官方推了一套. App Architecture ,于是就在想,对于 iOS 来说,怎样的架构才是最适合的. 这是第一个也是最重要的问题,为什么会出现各种 Architecture Pattern. 我们来想一下,无论是做一个 App 还是搭一套后台系统,如果是一次性的,今天用完明天就可以扔掉,那么怎么快怎么来,代码重复、代码逻辑、代码格式统统不重要.

后端架构师技术图谱 architect-awesome/README.md at master · xingshaocheng/architect-awesome · GitHub

- -
最后更新于20180502. CopyOnWrite容器. 运维 & 统计 & 技术支持. 零拷贝(Zero-copy). 分布式 Leader 节点选举. TCC(Try/Confirm/Cancel) 柔性事务. DDD(Domain-driven Design - 领域驱动设计). 《java队列——queue详细分析》.

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

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

Sencha Architect 2:用于构建桌面与移动HTML5应用的所见即所得IDE

- - InfoQ cn
近日,Sencha 发布了Sencha Architect 2——这是对Ext Designer的重大升级. Sencha Architect 2是个可视化的应用构建器,它使用 Sencha Touch 2来构建移动应用,使用 Ext JS 4来构建桌面应用. Sencha Architect 2构建在该公司的HTML5布局工具Ext Designer之上,并扩展了其功能以为桌面与移动Web应用的构建提供更为广泛的应用设计环境.

初识微服务

- - ITeye博客
微服务架构越来越火,有必要学习一下. 软件开发过程中碰到什么问题. 一个简单的应用会随着时间推移逐渐变大. 在每次的sprint中,开发团队都会面对新“故事”,然后开发许多新代码. 几年后,这个小而简单的应用会变成了一个巨大的怪物. 一旦你的应用变成一个又大又复杂的怪物,那开发团队肯定很痛苦. 敏捷开发和部署举步维艰,其中最主要问题就是这个应用太复杂,以至于任何单个开发者都不可能搞懂它.

谈微服务架构

- - 人月神话的BLOG
其实在前面很多文章谈到SOA,特别是系统内的SOA和组件化的时候已经很多内容和微服务架构思想是相同的,对于微服务架构,既然出现了这个新名称,那就再谈下微服务架构本身的一些特点和特性. 从这个图可以看到微服务架构的第一个重点,即业务系统本身的组件化和服务化,原来开发一个业务系统本身虽然分了组件和模块,但是本质还是紧耦合的,这关键的一个判断标准就是如果要将原有的业务系统按照模块分开部署到不同的进程里面并完成一个完整业务系统是不可能实现的.

微服务性能模式

- - 互联网 - ITeye博客
前言:基于微服务系统越来越普遍. 下面我们就来看看五种常见的特定微服务性能的挑战,以及如何应解他们. 背景:在IT界微服务架构为基础的系统越来越多, 每一个应用系统都集成了不同的组件和服务,几乎所有的特定业务应用程序都需要集成一个或更多的应用服务. 但是一个综合性系统集成不同的服务这无疑是一个巨大的挑战.

微服务与架构师

- - 乱象,印迹
因为工作的关系,最近面试了很多软件架构师,遗憾的是真正能录用的很少. 很多候选人有多年的工作经验,常见的框架也玩得很溜. 然而最擅长的是“用既定的技术方案去解决特定的问题”,如果遇到的问题没有严格对应的现成框架,就比较吃力. 这样的技能水平或许适合某些行业,但很遗憾不符合我们的要求. 软件架构师到底应该做什么,又为什么这么难做好,这都是近来的热门问题,我也一直在和朋友们讨论.

从Excel到微服务

- - 乱象,印迹
Excel很老,Excel很土,Excel一点也不sexy;微服务新,微服务很潮门,微服务很高大上. 那么,Excel和微服务有什么关系. 上个月看了篇文章,The Unbunlding of Excel. 作者认为,对于初创公司(尤其是非“纯IT”初创公司)来说,Excel几乎包办各种工作. 想做轻量级的CRM,可用Excel.

微服务拆分之道

- - DockOne.io
微服务在最近几年大行其道,很多公司的研发人员都在考虑微服务架构,同时,随着 Docker 容器技术和自动化运维等相关技术发展,微服务变得更容易管理,这给了微服务架构良好的发展机会. 在做微服务的路上,拆分服务是个很热的话题. 我们应该按照什么原则将现有的业务进行拆分. 接下来一起谈谈服务拆分的策略和坚持的原则.