Notice: Constant WP_DEBUG already defined in /var/www/html/wordpress/wp-content/plugins/changyan/sohuchangyan.php on line 12

Notice: Constant WP_DEBUG_LOG already defined in /var/www/html/wordpress/wp-content/plugins/changyan/sohuchangyan.php on line 13

Notice: Constant WP_DEBUG_DISPLAY already defined in /var/www/html/wordpress/wp-content/plugins/changyan/sohuchangyan.php on line 14
Docker的进程困境【zoues.com】 – zoues

LOADING

Follow me

Docker的进程困境【zoues.com】
六月 10, 2017|DockerPaaS

Docker的进程困境【zoues.com】

Docker的进程困境【zoues.com】

进程困境

最近看《Docker容器与容器云》时,在介绍Kubernetes的Pod概念时,书中提到Docker自身的一个问题, Docker是围绕单个足够简单、足够独立的应用的,而无疑“单进程”是最适合的模型,甚至在“知乎”上,很多人建议微服务改造的应用最好控制在100行-1000行。 所以容器的种种概念、架构、底层设计,都希望容器是一个单进程的应用。但开发的大千世界,原比这个复杂。有两种情况:

   1、中间件本身是多进程的,比如apache,有两个基础进程,管理进程和业务进程。每个业务进程支持25个线程。如果并发多,就会出现多个子进程。

   2、应用是多进程的,紧耦合的,例如我们写的金融行业的应用,一般都会编写通信进程、交易进程、监控进程等,设置有对账、日终的专门进程。这也是我们在微服务改造时的一个棘手问题。


多容器模式

针对以上问题,有2种方式。第一种是用多个容器实现,将原来的3个进程一一改造成3个容器,这样的改造代价最小,但问题也最大。

第一,容器间通信成本就很高,从原来的IPC通讯,变成了Restful 接口。

第二,由于容器的相关性,需要人为控制一起启动,一起停止。

虽然了3个容器,但还是紧耦合,1:1:1的配比,不能实现微服务期望的“可以单独扩容某个服务的数量” 

进程树模型

第二种处理方式是使用“进程树”

1、将3个进程放到一个容器中,对程序进行改造,将独立的3个进程,变成了有父子关系的进程。例如原来3个进程的启动脚本,是run.sh  包括3行

  runA.sh;

  runB.sh;

runC.sh;

 改造成:

   runA.sh;

  runB.sh;

exec runC.sh;

这样最后一个进程变成了主进程。runA和runB都成了runC的子进程。

 

2、  另外的一种方式,是借助Supervisor进程改造:

(1)    通过pyhon启动Supervisord

(2)在/etc/Supervisord下,每个应用会有1个配置文件。

这样Supervisord就是这多个应用的子进程。

 

下图是孙宏亮画的容器中的进程模型


Docker的进程困境

Kubernetes的做法

  Kubernetes的一个核心概念,就是推出了Pod,就是要处理现实世界中复杂的进程模型的。Pod的含义,是豆荚,它将多个容器放到一个Pod中,可以共享主机名、IPC、网络资源。但也带来了2个成本:

  1、大材小用: 对于仅有一个进程的应用,一个Pod中实际有2个容器,即默认有一个pod容器,增加了故障点、系统消耗、维护成本。

  2、技术绑定:对于swarm和mesco,都只做调度层面的工作。但Kubernetes向下走了一步,推出了类似compose的pod,且是必选项。这样,对于多进程应用,我们就要完全依赖Kubernetes内部的管理模型,形成了技术绑定。

总结

    容器是一种伟大的技术,但实现容器的道路,永远是曲折的,尤其当你使用新的技术栈,改造原有系统,改变原有开发模型时。

    此心光明,奋勇前行。

 Docker的进程困境

舟行万里,方知海阔天空;鲲鹏展翅,九万里云中计算

Docker的进程困境

做终身学习者;金融IT建设,云计算,容器,IT支持业务创新的分享

长按二维码关注

  作者微信号:         gobackto2000

no comments
Share