使用docker scale时遇到的一点小问题

今天在使用docker-compose时，突然发现有一个command叫做scale，感觉有点像kubernetes的replica，于是试了一下

-> # docker-compose scale yyets-web=5
WARNING: The scale command is deprecated. Use the up command with the --scale flag instead.
Starting websiterunner_yyets-web_1 ... done
Creating websiterunner_yyets-web_2 ... done
Creating websiterunner_yyets-web_3 ... done
Creating websiterunner_yyets-web_4 ... done
Creating websiterunner_yyets-web_5 ... done

果真是这个样子的，那么从其他容器访问这个container，用的是什么负载均衡算法呢？猜测应该是最简单也是最常见的round robin吧？在nginx里ping和curl试了一下，果真是的，每次解析的IP地址都会变化：

然后看了一下log，发现请求全部落在了1上，而没有平均到其他4个container

但是我如果在nginx里curl，却可以看到请求是均匀分布在5个container里的。

什么鬼嘛，怎么会这样，从外部过来的请求不过是经过了nginx proxy_pass，这和我在nginx container里直接curl有什么差别嘛。

后来吃饭的时候想到，难道是因为，我是后scale的，而nginx是早就启动的，所以nginx启动时把配置文件中的域名解析到了一个固定的IP。而我在container中curl每次都是重新解析的，所以每次解析的结果都是round robin的

于是重启了一下nginx

docker-compose restart nginx

看起来破案了，请求均匀分布到了5个container中。

从我个人的角度来讲，意义似乎不太大。我觉得，如果单个容器（进程）存在性能瓶颈，比如说单进程/单线程，只能用一个CPU宿主机有恰巧是多核心，多个进程可以明显提升性能，那么scale一下还是可以的。举个例子，万一我傻了吧唧的这么写的代码：

class ResourceHandler(BaseHandler):
    executor = ThreadPoolExecutor(5)

    @run_on_executor()....

那么scale一下，还是有很大希望的。

不过我当然没这么傻，所以这里scale对我可能用处不太大。

当然了，还是用kubernetes最爽:-)可惜俺并不会也没那么多机器去搞:-(