基于AIOHTTP、Websocket和Vue3一步步实现web部署平台，无延迟控制台输出，接近原生SSH连接

背景：笔者是一名Javaer，但是最近因为某些原因迷上了Python和它的Asyncio，至于什么原因？请往下看。在着迷”犯浑“的过程中，也接触到了一些高并发高性能的组件，通过简单的学习和了解，aiohttp这个组件引起了我极大的兴趣。

协程、异步非阻塞、”吓人“的性能，这些关键词让我不得不注意到它。

老样子，我们先看成品，再讲讲我曲折的过程。

读取实时日志

 构建+部署

技术痛点揭露

相信大家一定遇到过笔者这次的场景：

        疫情隔离，居家办公，这次我们做的是一个小程序，前端的小伙伴们要联调接口，可是不能用公司的资源，因为公司都断电了😭 ，于是乎我自己买（bai）了（piao）云服务器，自己搭建了一套环境，用自己的域名给他们架上了。本以为事情解决了，前后端可以愉快地调试接口了，但是想都别想，现实还是无情地用它宽大的手掌啪啪打我的三寸小脸。

        你看，后端的小伙伴写完代码，改完bug，提交了之后，一次又一次的让你部署，导致吃饭都想着部署，每次都是噼里啪啦一堆命令，脑瓜子嗡嗡的。（First Blood！）

        你再看，后端猿小帅和前端媛小美正在对接接口，小美说接口怎么一直报错？小帅眉头一皱，手一抖，微信窗口多出个小表情，一脸无辜："我本地可以啊！"。对，就是这句话，“我本地可以啊，为啥线上不行”，成了接口对接中的口头禅。完了，肯定又是我的活，这不，咔咔一顿"艾特"，让我帮忙看日志，啊啊啊啊啊啊，一天到晚登上服务器看了不下N次日志，我的头发在抗议。（Double Kill！）

        你再再再看，我们对接用的yapi，在接口未完成之前，前端调用的是mock，完成之后，得切换到真实接口。为了保证项目开发进度，让前后端的联调顺滑如丝，那付出的肯定是我了。一天下来，在忙上面事情的同时，我还在不断地调整Nginx反向代理配置，为他们放开一个个接口的代理。我内心只能说：mmp。（Triple Kill！）

        你再再再再看看，正常开发过程中总有些粗心捣蛋的人，提交的代码像一个炸弹。这不，刚刚这哥们还在小区楼底下蹦迪，下一秒回家晕乎乎地写了几个bug，潇洒提交，又蹦迪去了。这不提交不要紧，一提交之后，紧接着我习惯性的部署上去，一系列的连锁反应导致几个接口不能用了，兄弟们叫苦不迭，要不是居家，我真想上去抽那仁兄几个嘴巴子。这屁股还是得我擦，回退到上个版本，先凑合调试着。这种操作隔三差五在上演，也是麻烦的很。。。（Quadra kill！）

        最后脑补一个五杀（Penta kill！）🧠

尝试曲线救国

        上面列举了那么多痛点，是个人都被折磨的够呛吧，拜托🙏🏻，疫情即使在家办公也是要高效，更何况家人都在身边，不能焦躁，不能焦躁，不能焦躁！

        这个时候就有大佬说了，你搞这么多费力不讨好的事情，为啥不直接用CI/CD（持续集成）呢？我花费了5根头发想了想，我这1GB内存，1核CPU还能再战吗？再摸了摸我那比纸都薄的钱包，最后点了三炷香“祭奠”了一下我死去的5根头发，心里默默说了声，算了，忍忍，你可以的。

方案一   脚本大法 + 代理

        我开始尝试写脚本。我们的项目是微服务，正常部署都应该用docker-compose，或者直接上到k8s集群里，但是非常时期我们没有办法，只能人工部署。所以我写了一个又一个的脚本，然后写好备注，然后写了一个Low到爆的 HTML，写了超级烂的几行Java代码来调用这些脚本。最后通过Nginx给他们代理出去，把URL分发出去让他们自己点。

        我花费了几个小时完成了上述工作，就在我以为万事大吉的时候，我发现我服务器进不去了。。。WTF？登上控制台，看到CPU使用率125%？我就一个核怎么还超过100捏？虚机超频？呸呸呸，言归正传，排查了半天，我发现是因为多个人短时间内执行构建脚本和部署脚本，直接启动多个进程把机器“干”死了，我摇了摇头，方案1？去你的吧。

方案二  方案一的“进化”

        鉴于方案一存在的致命短板，我不得不针对这个问题进行优化，优化的手段嘛，不出大家所料，还是脚本，用low到爆的一个办法：每次运行构建，都通过 ps | grep | xargs kill -9 杀死之前的进程，再进行构建。运行结果也增加了反馈，用户执行结果会根据Sheel执行返回值进行判断，给出成功与否的响应。至于触发方法嘛，当然是老样子， 继续HTML点击，Java调用脚本。

        再次试验效果，我组织了一场视频会议，会议上我让小美和阿伟还有阿强分别点击部署，哇，效果嘎（chao）嘎（la）的（ji），小美先点击的居然部署成功了，阿伟和阿强后来的居然被杀了？awsl（阿伟死了）。后来排查了半天，发现小美家的wifi只有一格信号，请求发到后台慢了。总体来说方案二的可用度提高了，但是依然没什么卵用，小美提交的代码运行一会后报错了，原因是阿伟提交的一段代码引用了jdk中sun包内的东西，服务器openjdk没有相关类，服务压根没起来。还是很鸡肋。

方案三 另辟蹊径

        方案一和方案二都是短时间内拍脑门儿想出来的活，到现在为止我已经发现问题不能这么草率的解决了， 否则永远都是不断地返工。我深刻地分析了一下，作为一个完备的协同部署功能，至少需要满足以下几个条件：

1. 能够协同工作和实时交互。看了比较大的运维平台，基本上都具备实时的反馈，接近SSH会话级别的体验，能够确认当前的部署状态和部署进度，用户可以及时发现并避免和其他人的交叉使用。此外，如果可能的话，应该实现当前部署状态未完成，其他用户不可操作服务器。

2. 能够查看实时日志。系统运行的状况如何，应该具备日志查看的入口，这些入口开放给开发人员，才能够做到每个人都能及时处理自己的问题。此外，日志滚动频率过快，应该提供“暂停日志”和“恢复日志”的能力。

3. 实现用户身份标识。该功能也是必须的，因为通过HTML按钮点击部署出了问题，往往无法追溯是谁干的😭。后面，我设计为每个用户提供身份标识确认，通过线下发放key的方式提供服务的使用权限，每个key可以绑定到具体的用户，绑定key后，才可以正常使用运维能力。

4. 具有版本控制和一键回滚。一个合格的部署平台，必须具有防范风险的能力，体现在健壮性上来说，就是版本控制。利用shell脚本实现版本控制并不难，实现一键回滚也不难，难的是库表结构修改后产生的种种恩怨情仇。

        经过系统的分析之后，我们说干就干。

= 开始干活 =

        工欲善其事，必先利其器。干活前老样子，先做技术选型。为了一步到位，我直接选择了Vue3去写前端，后端压根没想着用Java去写，因为我写过很多pipleline的代码，java处理起来冗长又效率低下，果断选择了Python大法。事实证明，我的选择太明智了。

搭建Vue项目

技术栈

• Vue 3

• Ant Design Vue 3.1.1

• Socket.io-client

• CodeMirror Editor

• Axios

我们使用最新的vue-cli搭建项目。

1. 环境准备

# 安装 Vue CLI
npm install -g @vue/cli

# 创建项目
vue create web

# 安装依赖
cd web
yarn add ant-design-vue @ant-design/icons-vue axios socket.io-client codemirror-editor-vue3

2. 项目配置

babel.config.js - 按需加载配置

module.exports = {
  presets: [
    '@vue/cli-plugin-babel/preset'
  ],
  plugins: [
    ["import", { "libraryName": "ant-design-vue", "libraryDirectory": "es", "style": "css" }]
  ]
}

vue.config.js - 开发服务器配置

module.ex