容器服务Docker&Kubernetes + 关注
手机版

利用阿里云容器服务实现Docker微服务间的负载均衡和服务发现

  1. 云栖社区>
  2. 容器服务Docker&Kubernetes>
  3. 博客>
  4. 正文

利用阿里云容器服务实现Docker微服务间的负载均衡和服务发现

csome 2016-07-01 14:52:40 浏览7060 评论2

摘要: 容器服务的服务间的负载均衡和自动服务发现方案

基于容器服务实现Docker微服务间的负载均衡和自动服务发现的方法

在容器服务上可以通过acsrouting将基于域名的http的服务暴漏出去,而且能够配合健康检查自动的负载均衡和服务发现,当其中一个容器出现问题之后,routing会自动将健康检查失败的容器从后端摘除,所以能做到自动的服务发现。

然而这个是将服务暴漏到外网的,那么服务间如何通过这种方式做到自动的服务发现和的负载均衡呢?容器服务引入了负载均衡的功能,只需要使用.local结尾的域名,并在依赖的服务的external_links中增加这个域名, 依赖的服务便可以通过.local的域名访问到依赖的服务,并且能够配合健康检查做到自动的服务发现,例如:

restserver: # 模拟rest服务
  image: nginx
  labels:
    aliyun.routing.port_80: restserver.local # 使用local的域名,只有集群内的容器可以访问这个域名
    aliyun.scale: "2" # 扩展出2个实例,模拟负载均衡
    aliyun.probe.url: "http://container:80" # 定义容器的健康检查策略是http,端口是80
    aliyun.probe.initial_delay_seconds: "2" # 健康检查在容器起来之后2秒之后再检查
    aliyun.probe.timeout_seconds: "2" # 健康检查超时时间,如果两秒还没返回认为不健康
restclient: # 模拟rest服务消费者
  image: registry.aliyuncs.com/acs-sample/alpine:3.3
  command: "sh -c 'apk update; apk add curl; while true; do curl --head restserver.local; sleep 1; done'" #访问rest服务,测试负载均衡
  tty: true  
  external_links: 
    - "restserver.local" #指定link的服务的域名

然后通过如下的restclient服务的日志,我们可以看到restclient的curl的http的请求就被路由到不同的rest服务的容器上了,容器id分别是053cb232fdfbcb5405ff791650a0746ab77f26cce74fea2320075c2af55c975fb8c36abca525ac7fb02d2a9fcaba8d36641447a774ea956cd93068419f17ee3f:

internal-loadbalance_restclient_1 | 2016-07-01T06:43:49.066803626Z Server: nginx/1.11.1
internal-loadbalance_restclient_1 | 2016-07-01T06:43:49.066814507Z Date: Fri, 01 Jul 2016 06:43:49 GMT
internal-loadbalance_restclient_1 | 2016-07-01T06:43:49.066821392Z Content-Type: text/html
internal-loadbalance_restclient_1 | 2016-07-01T06:43:49.066829291Z Content-Length: 612
internal-loadbalance_restclient_1 | 2016-07-01T06:43:49.066835259Z Last-Modified: Tue, 31 May 2016 14:40:22 GMT
internal-loadbalance_restclient_1 | 2016-07-01T06:43:49.066841201Z ETag: "574da256-264"
internal-loadbalance_restclient_1 | 2016-07-01T06:43:49.066847245Z Accept-Ranges: bytes
internal-loadbalance_restclient_1 | 2016-07-01T06:43:49.066853137Z Set-Cookie: CONTAINERID=053cb232fdfbcb5405ff791650a0746ab77f26cce74fea2320075c2af55c975f; path=/

internal-loadbalance_restclient_1 | 2016-07-01T06:43:50.080502413Z HTTP/1.1 200 OK
internal-loadbalance_restclient_1 | 2016-07-01T06:43:50.082548154Z Server: nginx/1.11.1
internal-loadbalance_restclient_1 | 2016-07-01T06:43:50.082559109Z Date: Fri, 01 Jul 2016 06:43:50 GMT
internal-loadbalance_restclient_1 | 2016-07-01T06:43:50.082589299Z Content-Type: text/html
internal-loadbalance_restclient_1 | 2016-07-01T06:43:50.082596541Z Content-Length: 612
internal-loadbalance_restclient_1 | 2016-07-01T06:43:50.082602580Z Last-Modified: Tue, 31 May 2016 14:40:22 GMT
internal-loadbalance_restclient_1 | 2016-07-01T06:43:50.082608807Z ETag: "574da256-264"
internal-loadbalance_restclient_1 | 2016-07-01T06:43:50.082614780Z Accept-Ranges: bytes
internal-loadbalance_restclient_1 | 2016-07-01T06:43:50.082621152Z Set-Cookie: CONTAINERID=b8c36abca525ac7fb02d2a9fcaba8d36641447a774ea956cd93068419f17ee3f; path=/

实现的原理:

  1. 首先利用了docker 1.10之后支持在容器中做别名的方式,在依赖负载于restserver.local的服务的容器中restserver.local的域名解析到的是routing服务的地址,这样可以实现HTTP请求转发到routing的容器,并带上了HOSTrestserver.local的请求头。
  2. 然后routing会对配置了aliyun.routing_port_xxx: restserver.local的服务监听它的容器的健康状态并挂载到haproxy的后端,haproxy接收到带有restserver.local HOST头的HTTP请求就能转发到对应了容器了。
    screenshot

优势

  1. 相对于使用link或者hostname的基于DNS的方式来说,首先不同客户端对DNS缓存的处理不一致会导致服务发现的延迟性,其次DNS的方案也只有round robin,对于微服务的场景是不够用的;
  2. 而相对于其他的微服务服务发现的解决方案,提供了一个实现无关的服务发现和负载均衡机制,无需server端和client应用做任何修改即可使用;
  3. 并且服务生命周期解耦的,每个微服务可以采用一个docker-compose模板独立部署,更新。相互只是通过一个虚拟域名实现动态绑定即可。
【云栖快讯】一站式开发者服务,海量学习资源免费学  详情请点击

网友评论