用基于RPCserver的方式实现一个容器管理平台，思路记载

用基于RPCserver的方式实现一个容器管理平台，思路记载 0. 引言

做了一个管理平台用于管理一组容器的管理，需求很简单：

1. 根据前端的请求，后端向对应的容器发送对应的指令，容器执行完毕之后再把结果返回给后端，后端打包之后再返回给前端展示；
2. 后端会定期轮询各个容器的状态。

1. 后端与容器的通信模型：RPC

为什么使用RPC模式：

1. 因为单次请求之间没有相关性，所以容器不需要记录上一次请求，也不需要保持长连接；
2. 对于后端来说，每一次发送命令可以看成是向容器调用一次它的服务，而容器只需要在执行完服务返回一个response即可。

所以我们将每个容器都设置一个RPC进程，让后端通过向容器中的RPC进程发送请求来实现对容器的管理。

2. RPC进程的实现方式

RPC服务的实现我们使用的是rabbitMQ。

首先解释为什么使用消息队列来做RPC：

1. 因为后端和容器之间的交互很像生产者和消费者，后端是生产者，负责生产命令，容器是消费者，消费后端生产的命令并返回相对应的结果；
2. 后端与容器之间是1对多的关系，借助消息队列可以很方便的对单个容器或者所有容器发消息；
3. 消息队列对异步的支持。

使用rabbitMQ是因为rabbitMQ本身针对RPC的实现提供了一组非常方便且稳定的组件，而且相关学习资料多，学习成本较低，所以就使用了rabbitMQ。

Server解决三个问题：

1. 命令的实现与注册
2. 命令的执行
3. RPCServer的开启与维护
4. 多个容器之间的维护更新
5. 容器状态的更新

相对应的解决方法：

1. 通过抽象一个Command作为父类，新的命令只需要继承Command并实现相关接口即可，并且将命令放到指定的文件夹即可
2. 设置一个执行命令的单例，它负责两件事：
   1. 加载指定的文件夹下所有的文件，每个文件对应一个py文件；
   2. 当收到后端的请求时，根据收到的请求调用相关的函数；
3. RPCserver启动后就不会关闭，后端会定期轮询各个容器的状态，如果发现没有回应，会尝试再次发起状态更新请求；如果到达最大次数仍然没有连通，那么就会发出告警；
4. 通过git来维护更新，如有更新，只需要向各个容器发送git命令并执行重启命令即可；
5. 容器的状态通过设置定时任务的方式由后端向各个容器轮询，使用celery实现。

3. 后端的容器注册

1. 在容器侧上传执行一个写好的脚本，脚本的内容包括：
   1. 安装环境和相关的包；
   2. 克隆相关的仓库；
   3. 运行RPCserver；
2. 在后端侧填写容器的配置信息，完成。

4. 后续可能遇到的瓶颈

1. 如果服务器的数量持续上升，那么瓶颈大概率会出现在两个方面：
   1. 数据库的读写压力，解决方法：
      1. 主从模式；
      2. 分布式数据库；
      3. 引入redis缓存，减少写压力；
   2. 服务器的性能压力，解决方法：
      1. 对服务器进行功能拆分，比如轮询和写数据库 *** 作可以由另一个服务器负责；
      2. 由容器主动向后端推送个人信息；
      3. 加一个负载均衡器，引入多台服务器。
   3. 还有一个解决方法，调整轮询频率，但是是一个过渡的方法

总结

优点：

1. 这个架构基本保证了增减容器不需要太高的 *** 作成本；
2. 对于命令的扩展支持也很友好；
3. 屏蔽了 *** 作细节，对于用户来说也降低了使用成本。

缺点：

1. 安全性方面其实考虑得比较少；
2. 由后端发起轮询的方式比较笨；
3. 对于数据库 *** 作的优化还做得比较少；
4. RPC对于直连容器的 *** 作支持不够；

之后重构的时间点应该是：

1. 服务器数量翻一番；
2. 需要一个可以直连容器的黑窗口。