首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >Uread 自动化运维平台七大阶段实践

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

作者头像
小小科
发布2018-05-02 17:16:25
8960
发布2018-05-02 17:16:25
举报
文章被收录于专栏:北京马哥教育北京马哥教育

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

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

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

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

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

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

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

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

微服务交互,主要我们尝试过基于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到通知机器人钩子,这些程序会把信息发到我们的协同工作软件,所以我们会第一时间知道哪个请求触发了什么错误。

接下来

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

作者:yubang 来源: http://blog.yubangweb.com/uread-zi-dong-hua-yun-wei-ping-tai-shi-jian/


本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2017-08-01,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 马哥Linux运维 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
容器服务
腾讯云容器服务(Tencent Kubernetes Engine, TKE)基于原生 kubernetes 提供以容器为核心的、高度可扩展的高性能容器管理服务,覆盖 Serverless、边缘计算、分布式云等多种业务部署场景,业内首创单个集群兼容多种计算节点的容器资源管理模式。同时产品作为云原生 Finops 领先布道者,主导开源项目Crane,全面助力客户实现资源优化、成本控制。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档