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

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

首先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/


原文发布于微信公众号 - 马哥Linux运维(magedu-Linux)

原文发表时间:2017-08-01

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏一名叫大蕉的程序员

分布式架构的套路No.74

今天小蕉跟大伙一起聊聊分布式系统的架构的套路。在开始说套路之前,大家先思考一个问题,为什么要进行分布式架构? 大多数的开发者大多数的系统可能从来没接触过分布式...

22670
来自专栏技术翻译

理解分布式系统的8个谬误

你在分布式系统上工作吗?微服务,Web API,SOA,Web服务器,应用服务器,数据库服务器,缓存服务器,负载均衡器 - 如果这些描述了系统设计中的组件,那么...

16920
来自专栏企鹅号快讯

分布式架构的套路No.74

今天小蕉跟大伙一起聊聊分布式系统的架构的套路。在开始说套路之前,大家先思考一个问题,为什么要进行分布式架构? 大多数的开发者大多数的系统可能从来没接触过分布式系...

39290
来自专栏CSDN技术头条

微博热点事件背后数据库运维的“功守道”

【导语】 微博拥有超过3.76亿月活用户,是当前社会热点事件传播的主要平台。而热点事件往往具有不可预测性和突发性,较短时间内可能带来流量的翻倍增长,甚至更大。如...

292100
来自专栏沃趣科技

备份重于一切:远离“Gitlab删库事件”,QBackup是你的最佳选择!

作者简介:孙朝阳 沃趣科技高级产品经理。 案发现场: Gitlab删库事件回顾 Gitlab是大家很熟悉的开源Git代码托管工具,国内公司大多使用社区版自行搭...

38780
来自专栏云加头条

韩伟:解谜腾讯游戏海量服务架构

网络游戏和其他互联网服务一样,需要面对承载海量用户的压力,同时还需要满足游戏所要求的低延迟、业务逻辑高复杂度的特性。腾讯游戏研发部资深架构师韩伟为大家带来了“解...

57390
来自专栏Java成长之路

分布式系统入门

分布式系统是一个硬件或软件组件分布在不同的网络计算机上,彼此之间仅仅是通过消息传递进行通信和协调的系统。 首先分布式系统一定是由多个节点组成的系统,一般来说...

21030
来自专栏AI科技大本营的专栏

最新Python学习项目Top10!

【导读】过去一个月里,我们对近1000个Python 学习项目进行了排名,并挑选出热度前10的项目。这份清单涵盖了包括Web App, Geospatial D...

16120
来自专栏腾讯云TStack专栏

腾讯私有云MySQL解决方案—TDSQL

TDSQL是腾讯提供的一套完整的MySQL数据库集群化管理解决方案,作为私有云TStack平台重要的数据库产品能力,旨在解决高可用、高性能、分布式、配套设施等方...

81990
来自专栏EAWorld

建设DevOps统一运维监控平台,全面的系统监控你做好了吗?

前言 随着Devops、云计算、微服务、容器等理念的逐步落地和大力发展,机器越来越多,应用越来越多,服务越来越微,应用运行基础环境越来多样化,容器、虚拟机、物理...

94550

扫码关注云+社区

领取腾讯云代金券