Uread 自动化运维平台七大阶段实践

Posted 2021-05-01 马哥Linux运维

首先技术并没有好坏之分，只能说一种技术在特定场景会优于另一种技术。

首先uread优读（ http://aiuread.com/ ）作为一个还处于起步阶段的团队，那么没办法造出像大企业他们那种自动化运维平台，真实情况是连用OpenStack来管理应用都是一种高难度活。

第一阶段，单体应用，纯人力部署

团队一开始，反正后端就一个系统，然后又是用git作为团队内部的协作工具，部署理所当然是直接每次发布新版本，直接执行git pull，然后执行一个封装好kill进程，重启进程的shell脚本，接着更新版本流程完成。

第二阶段，服务拆分，交互遇到问题

随着功能越来越多，后端前端的同学也越来越多，以前一个工程囊括整个项目的做法的弊端开始显露出来。首先，由于工程膨胀，要一位新来的同学看懂整个工程会变得非常困难，并且提交代码的时候冲突会非常严重。现在微服务不是很流行么，所以团队也考虑是不是拆开成微服务呢。

一开始，已经研发的部分也不可能推倒拆分。所以，决定新增的大功能拆成独立工程。当拆开独立项目的时候，第一个出现的问题并不是部署问题，因为多几个应用，部署工作量其实也不会是人力不能承受。

拆分应用之后，出现的主要问题是，这些独立的应用如何交互。也许你会说是不是设计不合理呀，微服务单向调用那会有什么问题。且慢，当你实践过，你就不会说就这么简单。

微服务交互，主要我们尝试过基于http协议的交互，对于耗时处理采用回调方式。由于业务原因，有大量耗时操作，所以一个功能就要写很多个微服务。

由于为了每位同学都只关注自己的模块，所以数据入库也是自己处理自己的部分，结果就是一个业务交互就需要4个微服务。

第三阶段，基于消息中间件的微服务交互

第四阶段，微服务基于sdk交互

这个时候，我们编写某个微服务的同学，就要提供调用该微服务的sdk，那么对于调用该服务的同学来说，只需要引入该sdk即可，无论微服务如何变，更新sdk即可（sdk的函数必须是兼容升级）。

第五阶段，服务发现系统

第六阶段，自动化部署

微服务的交互这个最主要问题解决之后，免去人工执行shell脚本部署应用提上了日程。

原始阶段，把创建环境拉取代码封装成一个shell脚本。打包环境采用docker镜像，为什么用docker呢，因为docker打包环境写一个Dockerfile就成了，并且最新版的docker可以用docker swarm把容器分布到多台机器。

每次更新，手动执行shell工作量还是有点大，好在有git钩子，每一次某个分支提交代码后触发脚本自动部署。

第七阶段，应用日志问题

由于阶段六，我们应用存在docker里面，日志也在容器里面，并且分散在多台服务器。日志收集是一个问题，主流的ELK这一套还是同样的问题，太重了，引入对团队是一个负担。所以一个折中的办法，由于我们用的框架都有一个同一个错误捕捉函数，当我们捕抓到错误的时候，我们就把信息post到通知机器人钩子，这些程序会把信息发到我们的协同工作软件，所以我们会第一时间知道哪个请求触发了什么错误。

接下来

当然是要做弹性扩容了，只是当前还没有需要大规模扩容的场景，那就先不造这轮子。

来源：

http://blog.yubangweb.com/uread-zi-dong-hua-yun-wei-ping-tai-shi-jian/

---

————广告时间————

《马哥Linux云计算及架构师》网络课程，由知名Linux布道师马哥创立，经历了8年的发展，联合阿里巴巴、唯品会、大众点评、腾讯、陆金所等大型互联网一线公司的马哥课程团队的工程师进行深度定制开发，课程采用 Centos7.2系统教学，加入了大量实战案例，授课案例均来自于一线的技术案例。

开课时间：随到随学

课程咨询请长按即可咨询