Docker Compose / Swarm 与微服务

微服务的概念大家应该都不会感到陌生,总结来说就是拆分与组合,拆分是为了提高硬件的利用率以及管理效率,最终将这些功能拼装成一个大型的体系架构。这样的系统更加灵活,硬件利用效率更高。

但是灵活也是有代价的,就是需要快速调整和广泛兼容的能力,如果拆分出的服务不能快速调整数量,那么还是会有比较严重的冗余问题,如果服务不具有广泛的兼容,那么没法移植就还是不能完全发挥硬件的性能。同时,他还不能消耗过多的资源,比如虚拟机就是一种不能接受的解决方案,它实在是太吃资源了。

这样对比就会发现 Docker 简直就是为微服务量身定做的,它足够轻量,启动足够快,兼容性足够好。

但是 Docker 本身做的还不够。

  • 单个 Docker 节点需要相对封闭,如何配置网络环境。
  • 如何解决节点之间的依赖关系和调起顺序
  • 组合成集群后如何批量管理

这时候就必须引入工具来管理这些松散的节点,为此 Docker 给出了两个套件 Docker Compose 和 Swarm。

先给出一份 Docker Compose 样例,配置先不细谈,我们主要看看这两个套件是如何解决上面所述问题的思路。

首先说网络环境的问题。Docker Compose 的思路很简单,它提供一个 bridge 节点来桥接,被 Docker Compose 所管理的所有容器都只能通过与 bridge 节点桥接来与外界通信。

内部通信则是由 bridge 进行转发。以上面的配置举例,例如 web 模块 links 了 mongo 和 mysql 两个模块,所以在 web 模块中直接 ping mongo 的话,这个请求就会发送到 bridge 节点,然后被路由到 mongo 容器中。

如果你有监听端口的需求,Docker Compose 可以使用端口绑定完成这个需求(虽然 Docker 中也有这个功能),如上例所示 web 模块的 8000 端口和宿主机器的 8001 端口进行了绑定,由 Docker Compose 负责监听,如果有请求发往宿主机器的 8001 端口,则会被 Docker Compose 转发到 web 容器的 8000 端口。

这样,整个 Compose 的网络安全有了保障(任何请求都得经由 bridge 过滤),同时也有了足够的开放性。

依赖关系也是比较棘手的一件事,如上例,我们的 web 模块需要等待 mongo 模块和 mysql 模块初始化完成再开始运行,如果是单独的 docker 那我们只能先启动一个,然后等待启动完成后再手动开启另一个,这实际上是个很低效的事情,而且人的介入意味着潜在的错误,我们希望机器帮我们做完所有的事情,我们最好只需要安静的喝咖啡就好。

Docker Compose 中的 depends_on 参数就是用来管理启动顺序的,所选的 service 只有等到依赖全部启动之后才会启动。

更多的 Docker Compose 参数可以在这里查看。有很多相当实用的配置,例如数据库备份等等。

Docker swarm 则是用来更详细的定制和管理集群的。

简单来说 Swarm 提供了一个控制台。我们可以通过

来使用指定的配置启动一个集群,在 swarm 中,我们可以对整个集群进行快速的调整,例如减少某个功能的节点数量,腾出资源等等。同时 swarm 也提供了配置管理和秘钥分发的功能。这可以免去一次次手动修改配置的苦恼,同时对于数据库来说,也无需再把密码耿直的写在配置文件中(虽然样例中确实就是这么耿直的写着的)具体如何操作这里暂时不展开,有兴趣可以在这里看更多的功能

发表评论

电子邮件地址不会被公开。

This site uses Akismet to reduce spam. Learn how your comment data is processed.