发帖    主题    评论    推荐    标签    作者    订阅    查搜    注册   登陆   关注
 
面向对象 设计模式 领域驱动设计 企业架构 框架 开发教程 微服务 CQRS 扩展性 并发编程 事件溯源 分布式 SOA

Docker Swarm集群中的服务发现

         
2016-09-20 10:02
赞助商链接

在旧版本Swarm中需要一个服务注册器,这样所有管理者能有一个统一的集群状态视图,因此,在初始化老版本Swarm节点时,我们需要指定服务注册器的地址,而在新版本Swarm中,也就是Docker 1.12引入的Swarm Mode,除了Docker引擎以外什么都不需要,无需额外的服务注册器或key-value存储库。

是不是Swarm不需要服务发现吗?正好相反,服务发现很重要,因此被放入Docker引擎中,Docker引擎现在扮演Swarm 管理器,Swarm工作器和服务注册器三个角色。Docker Swam Mode一个巨大进步。引擎内部服务注册器只能提供给内部用户使用。

只要所有服务在同样网络中彼此通讯,我们所需要做的是对目标服务进行命名,比如所有go-demo服务需要知道如何发现相关的数据库,那么这个目标数据库的DNS是go-demo-db。

在Swarm集群情况下(Docker Swarm),好像扩展一个服务非常方便,只要执行:
docker service scale SERVICE_NAME=NUMBER_OF_INSTANCES
这样,这个服务就会运行在多个自身复制。也即是在集群多个节点上运行。其实这种方便扩展只能说扩展无态服务很容易,因为服务没有状态,在哪个节点上运行都没有问题。

但是世界并不是无态的,状态在工程产品业界是无法避免的,状态被创建就要存储,存储状态的地方就变成有态了,状态还会经常变化,扩展有态服务需要考虑:
1.我们如何传播一个服务实例状态的变化给其他的同样的有态服务?
2.我们如何创建有状态的服务一个副本(一个新服务实例),确保状态复制准确?

我们通常混合无态和有态服务到一个逻辑实体,后端服务能够是无态的,依赖数据库服务作为外部状态存储,在这种情况下,这些服务在不同生命周期上有一个清晰的分离关注。

以前我们都认为使得有态服务扩展和容错是没有银弹的,我们看看Docker Flow:Proxy是如何处理有态服务的,其核心HAProxy就是一个有态服务,从配置文件加载配置到内存,在动态集群中包含有态服务是一个挑战,因为我们不知道有多少个有态服务实例在运行,以及运行在哪个节点上。这时我们首先需要存储有态服务实例的状态,Docker Flow将有态服务状态复制存储在Consul,Consul这是一个分布式数据库。这样解决了状态改变的广播问题和有态服务实例的状态复制问题。

Service Discovery Inside A Docker Swarm Cluster |
[该贴被banq于2016-09-20 10:04修改过]

微服务      docker     

赞助商链接

赞助商链接

返回顶部

移动版 关于本站 使用帮助 联系反馈 最佳分辨率1366x768
OpenSource JIVEJDON Powered by JdonFramework Code © 2002-20 jdon.com