基于容器服务实现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分别是053cb232fdfbcb5405ff791650a0746ab77f26cce74fea2320075c2af55c975f和b8c36abca525ac7fb02d2a9fcaba8d36641447a774ea956cd93068419f17ee3f:

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的容器，并带上了HOST为restserver.local的请求头。
2. 然后routing会对配置了aliyun.routing_port_xxx: restserver.local的服务监听它的容器的健康状态并挂载到haproxy的后端，haproxy接收到带有restserver.local HOST头的HTTP请求就能转发到对应了容器了。
   

优势

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