首页 / 关于快网 / 媒体报道

2016GOPS干货实录:光载无限CDN“高度自动化的变迁,或将运维之路推向新的巅峰”

  近日,2016GOPS全球运维大会在帝都完美谢幕,一场IT技术人的盛宴就此告于段落。“光载无限CDN”作为主办方多次力邀的重要合作伙伴,在本次大会上带来了由海外研发负责人对运维发展趋势的重要分享。光说不练那是假把式,让我一起回顾下这个精彩分享的瞬间。

 

以下内容为现场分享实录: 

  大家好!我是欧曜玮,很多人不了解光载无限,今天我介绍的是光载无限用的分布式监控系统,我们做的CI/CD实践。

 

  四部分,首先,分布式监控系统。这个分布式监控系统的架构让我们遇到了什么难题,我们怎么样通过持续集成的实践来去解决、克服这些问题。我也会跟大家介绍微服务、DevOps、Docker。

 

  光载无限用的监控系统是基于Open-Falcon的解决方案,是一款企业级、高可用、可扩展的开源监控解决方案,最初是小米用的。为了让客户解决问题,希望把运维标准化,各个公司提出运维行业标准,提出自动化。Open-Falcon这套系统国内已经有上百家公司在使用,包括小米、滴滴、美团、金山、光载无限。有2万台设备,我们自己部署的将近5000台设备,选择Open-Falcon不仅是选择了监控系统,也是选择了一个生态。在各个业务上都有社区,贡献了他们的插件。二维码可以扫到一号仓库。

 

  Open-Falcon也在前几个月加入了开放社区联盟,目的就是为了社区的开发,制定行业标准,推动互联网的技术发展。

 

  接下来是Open-Falcon的架构图,我们要从这边切入,看我们在分布式接入系统中遇到什么样的运维难题。Open-Falcon不过多介绍,我直接切入点出它架构上的问题。


 
(Open-Falcon架构图示)

 

  架构图中,首先,部署,然后上传指标,同时转到judge,看了这个图可以发现,一是模块特别多,我们部署一套完整的Open-Falcon需要同时启动十几个模块。复杂度稍微高了一些,可能大家在这个过程中会遇到很多的困难,选择放弃。二是模块过多,自然而然部署、分发、配置都不容易。三是最初这套系统是由小米内部诞生的,小米内部的内网像刚才介绍的,外层做防火墙,里边是天堂,外面是地狱,内网没有做安全性考量,这套系统安全性是没有完全考虑到的。四是KPI没有加入任何权限设计,API就是同一个身份。五是每一个Garph实例均是单点、扩容有损。六是上下游组件无动态管理机制。七是报警没有入库,现场没有保存。

 

  我为什么讲这些,这也是微服务普遍面临的问题。提Open-Falcon,因为它是很典型的微服务架构系统。什么样是微服务,我们能按照功能边界划分出不同的组件,这个组件可以独立地编译、测试、开发、部署,它就属于有五服务。这个概念在近几年特别火,更早以前大家提的概念是SOA,就是每一个微服务之间都是通过API做相互通讯。

 

  微服务有什么样的优缺点,优点灵活,一是易于横向扩展,当所有的模块切成一个个小服务以后,改了A组件不需要管B组件是不是需要更新。还有是为了每一个组件各自有不同的版号,我们就可以针对不同的运维服务各自去管理。当错误产生的时候,故障隔离了。二是容错机制容易实现。三是技术选型灵活,采用微服务架构好处是每一个团队的合作,每一个组件的合作都与人无关,只与接口有关。四是独立部署,每一个微服务组件可以独立编译、测试和部署。五是复杂度可控。

 

  缺点,DevOps技术栈,把技术切成大大小小微服务以后,对运维的技术能力要求就特别高,必须熟悉现在比较先进的DevOps技术,还有接下来讲的Docker,还有海量运维等,DevOps新的一些工具来去管理微服务。二是提高运维成本,所有的配置都需要独立去管理,这些配置之间又有相应关系,它带来更高的运维成本。三是接口之间也会有相依,微服务都有独立的版号,我们的产品也有独立的版号,每一个产品包含底下组件的版号,你必须对微服务的每一个模块版本做一个比较细致的控管,不然整个系统无法运作。四是分布式系统本身有一定的复杂性,跨模块之间如何去沟通,API接口如何定义,怎么样避免接口频繁修改,都是带来的挑战。


 
(分层后系统架构图示)

 

  这是我自己画的架构图,我们知道遇到什么问题,接下来是怎么解决它。一是简化,整个系统有这样的模块,我们可以把它细分为这几个,不管部署多少种类的Agnet,包含报警通知,最上层是所有的UI展现,其他的就是辅助模块。

 

  简化了系统以后,回到主题上,怎么样透过持续集成的实践,基于微服务的容器架构设计提高产品质量,加速开发迭代。我们第一个用的是Docker,Docker的优势,第一,我们把所有的依赖,所有的环境都封装到镜像中,也就是容器中。另外,它非常简单,容易学习,基本上你只要会了Docker就会了。第二,社区也很活跃,你必须跟版本跟得很紧,不然可能会被拖累,因为它很多新功能只能在新版本下用。第三,大家很少提到的,Infrastructure as Code,可以大服务降低沟通成本。如果一切写成代码所有东西都赖不掉,你必须在这个镜像中测试通过。第四,容器之间相互隔离,发生故障的时候就不会感染到同一台机器的其他容器,让故障的范围被限制住。在微服务架构下,组件之间的依赖关系特别复杂,有了容器以后把你所有的封装在里面,可以部署相应的决策来解决问题。大家说Docker这个东西以前做不到吗?当然是做得到的,但是Docker有一个更好的性能,它的虚拟化是低于一般用的虚拟机。一台物理机上跑上千、上百个容器都是有可能的。第五,比传统虚拟化速度,有更好的性能。通过Docker做热备份。第六,让你的镜像只有那一行的改动,才会重新编译一层,最终的镜像是分为很多层的。

 

  Docker的优势如下图,像集群管理、监控、日志、存储、网络、编排,全部的东西都是在容器上的。


 

 

  Docker的局限,一是它的隔离没有到系统/内核的隔离,/proc, /dev 等目录都没有被隔离。另外是集群管理机制还不够成熟,工具和方案框架都不够成熟。我把这个划掉是因为,在整个容器的生态里面这块进展得特别快。三是业务无感知的升级,Docker daemon live upgrade。Docker一两个月就发新版,每一个版本都有重大的改变,每一个版本对内核的依赖越来越高。如果你想用新的功能,你就必须跟着Docker走。另外是带来运维成本的提高。

 

  回到整个来看怎么做,最重要的是闭环,最基本的是编译、测试,并且通知到开发你这次的提交是成功还是失败,所有的东西在后台都有记录,有报表。

 

  我开发完代码会自动测试、单元测试,并且会自动地部署到测试环境,还会做安全性检查,最后确认都没有问题就上升到一个环境。

 

  这个闭环通常不叫CI,叫CD,CD有两种,Continuous Delivery 以及 Continuous Deployment,差别在部署到生产环境是手动还是自动,时间有限,关于 CD 的细节今天就不特别展开了。

 

  我们怎么做的,不管用什么语言开发微服务,你必须在测试环境,这边代码确认都没有问题以后会编出Docker镜像,存到镜像库里,然后在测试和运维那一端就拉取镜像,确认镜像可用的几秒就可以发布完成。

 

  最后用简单示意图说明一下我们的架构,负载均衡采用典型的方法 nginx + haproxy 所有的业务模块都容器化,编译测试的结果,包含日志都输出到 ELK 之上,Ansible 作为集群中的批量管理工具。


 

 

  1. 接着我来说明一下:
    1 . 配置的部分我们利用了 Docker 的 Volume Container 实现动态配置变更,只要发现 Git 上面的配置有变更就会立刻下发到集群中的所有模块里;
    2. Jenkins 上面负责所有的镜像创建;
    3. 所有的建置与发布的日志分析都是统一发送到 ELK 之上;
    4. 利用 nginx 与 HAProxy 查看集群状态。

 

  1. 介绍完我们在 CI/CD 上的实践之后,我们来回顾一下跟微服务共同的问题:
    1. 我们将后端代码库统一,同时保留分布式模块的特性。时间有限没有办法讲太多细节,有兴趣的话可以到我们的 Github 仓库看 ;
    2. 集群的分发因为已经有了封装过的容器,接着我们只需要善用 Docker-Swarm 以及 Docker-Compose 即可大幅降低部署难度 ;
    3. 动态管理机制我们透过了 Volume 容器统一管理配置实现。

 

 


  当这个系统如此简化之后,就如同上面这张图,前后端分离,并且透过 Docker 协助编排与管理。

 

  我们的分布式监控系统正在逐步完善,未来我们将计划把一部分贡献回社区,接下来要发布的 0.2.0 版本有兴趣的话欢迎一同交流,谢谢!