构建一个简单的CaaS系统
157 浏览量
2021-01-10
19:38:46
上传
评论
收藏 98KB PDF 举报
构建一个简单的构建一个简单的CaaS系统系统
在CaaS系统出现前企业应用架构基本被IaaS/SaaS/PaaS等模式垄断，直到Docker的出现为我们打开了另一个扇大门，废话
不说了，我们直奔主题。
我们先了解下一个简单的CaaS系统是如何为用户提供服务的：
企业用户上传它的应用代码或其他代码托管方式，我们生成用户应用的镜像，或者用户直接上传镜像,或者用户直接使用我们
提供的基础服务镜像
用户部署他的镜像应用，启动它的镜像容器
用户访问他的应用服务
OK，需求确定了，该搬砖了。
用户镜像制作用户镜像制作
既然是一个简单的CaaS系统，我们就不让用户上传代码或者使用第三方代码托管了，直接让他们制作镜像后提交给我们，为
此我们需要搭建一个Docker私服来让用户上传镜像，假设用户上传的镜像遵循这种格式 :docker 私服地址 /{appId}:{version}
，这对用户有一定要求，毕竟一些用户可能连Docker是啥都不知道就更别奢望让他们编写Dockerfile制作镜像交付给我们了。
当然如果我们提供一些基础服务镜像（比如MySQL服务，Redis服务等）给用户那最好了。
启动用户镜像启动用户镜像
有了用户制作的镜像，该是启动它的时候了。
docker pull docker私服地址/{appId}:{version}
docker run -d docker私服地址/{appId}:{version}
启动方式很简单，但这并不是我们想要的，毕竟我们是要让用户能够访问到他部署的服务的，假如用户的服务是一个Web服
务，那你得暴露出用户的Web服务端口，这需要我们确定容器的通信方案：
跟宿主机共用一个网络空间
发布一个容器端口，让Docker随机选择一个未使用的高位端口
发布一个容器端口，并映射到宿主机上指定端口为外部路由服务
采用Docker的’links’来允许容器间通信。 如果一个新容器链接到一个已有容器，新容器将会通过环境变量获得已有容器的链接
信息，一个关联的容器将会获得它的对应连接信息，在它处理了那些变量后允许它自动连接。这样就使得同一个宿主机上的容
器不需要知道对应服务的端口和地址，就可以直接进行通信
我们简单的CaaS系统暂时还用不到容器间通信，如果跟宿主机共用一个网络空间即 –net="host" 模式启动的话，那么如果有
多个用户上传了镜像，他们的WEB服务端口都是8080，显然宿主机上只能启动一个8080端口，只能有一个用户的容器启动成
功，其他的因为端口已经被占用导致启动失败，在这里我们选择第三种模式，选择指定的端口映射来发布容器，这也方便我们
后面管理宿主机上的端口资源。OK，启动方式改成下面：
docker run -d -p 25701:8080 docker私服地址/{appId}:{version}
为了不让某个用户的应用占用过多资源导致影响到整个宿主机上其他的应用，我们稍微对用户的资源进行下限制，比如限制用
户应用容器的使用内存和CPU权重：
docker run -d -p 25701:8080 -m 512M -c 1024 docker私服地址/{appId}:{version}
为了能做到水平扩展，容器服务最好是无状态的的，这样能更好的实现负载均衡和水平扩容。
应用启动成功，我们可以通过在宿主机上访问25701即可访问容器的8080端口服务。
在写代码的时候我们通过 Docker Remote API client libraries 来启动卸载容器，具体代码实现就不多说了。
服务发现服务发现
容器启动成功后，用户该如何访问到他的容器服务呢，总不能提供宿主机IP给用户直接访问吧，这就需要我们构建一个服务发
现组件了。
服务发现的工作方式
当每一个服务启动上线之后，他们通过发现工具来注册自身信息
服务的消费者能够在预设的终端查询该服务的相关信息，然后它就可以基于查到的信息与其需要的组件进行交互
为了简便，我们使用ZooKeeper来作为我们的服务发现工具。
首先在容器启动成功后我们将服务注册到zookeeper中，存储的path路径如下:/caas/service/address/{appId}/{version}，存储
评论0
最新资源