Uread 自动化运维平台实践

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

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

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

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

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

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

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

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

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

基于http交互

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

基于http协议交互,一个问题是,每一个微服务都有一个ip和端口。当我们的微服务数量越来越多的时候,配置里面的地址信息也越来越不好维护,特别涉及服务地址变动的时候。这个时候,基于消息中间件的微服务交互方式进入我们的研发之中。

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

当我们引入了rabbitmq这个消息中间件,代替了http请求通讯。我们再也不怕微服务地址变更这种问题,在微服务扩容的时候,我们也可以无缝处理。但是我们最后还是弃用了这种交互方式,为什么呢?因为我们忘记了我们只是一个小团队,引入越多的技术,对于我们经验不太丰富的同学来说,简直就是灾难。

那么,我们只能用回基于http的交互方式,但是微服务地址维护这个大问题就需要一个途径解决掉。

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

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

第五阶段,服务发现系统

虽然,我们基于sdk来调用微服务,但是一个问题来了。我们微服务每一次扩容,就要更新sdk里面的地址。这个对于我们弹性部署来说是一个严重问题。

这个时候,sdk动态获取一个微服务真实地址就十分重要了。所以我们简单的造了一套系统,一个服务名字随机获取一个微服务真实地址。架构图如下:

服务发现系统

第六阶段,自动化部署

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

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

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

第七阶段,应用日志问题

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

接下来

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