混合云下的 DevOps 在 vivo 互联网的探索落地
目录
1. vivo 互联网架构演进和 DevOps 建设历程
2. 混合云架构下的 DevOps 实践之旅
3. vivo未来DevOps之路的探索
本文发布于vivo互联网技术微信公众号： https://mp.weixin.qq.com/s/vpj7DhVRzRJdP4EXtEVY5w
作者介绍：石建松，负责 vivo 互联网的交付系统架构设计和落地，之前在百度做移动运维平台和评价运维平台。本文为 石建松 在 DOIS 2018 · 深圳站的分享。
本次的分享主要分三个部分，第一部分主要介绍 vivo 互联网架构整体演进和 DevOps 建设历程，第二部分介绍混合云架构下 DevOps 整体实现方式，最后一个部分就是未来的探索。
1. vivo 互联网架构演进和 DevOps 建设历程
首先看第一个部分，首先介绍一下 vivo 互联网的整体业务，分为两部分，第一是系统业务，包括硬件，另外就是手机APP，包括用户看不到但是能感知到的搜索、广告等的服务，整体 DevOps 主要针对后面两个场景做介绍。
再看一下互联网这块的业务近三年来的发展非常迅速，可以看到单品日活浏览7千万，月活就近2000亿，CDN三年增长10倍，目前来看，我们整体服务数量已经超过2000个，项目数量超过350个。
整体互联网架构，我们的业务架构都是前端不管是静态下载还是动态加速都是通过CDN接受请求，CDN再回源到我们接入层7层和4层负载均衡，我们90%的在线服务都是Java技术，现在整体业务复杂度的增加，我们也在持续进行基础技术架构的改进，这块对于我们的基础能力建设提出了比较高的要求，因为异构这种能力建设对包容性要求非常强。
第一阶段在2011年左右，物理机的模式，当时的规模小于200-300台物理机，之后进入了虚拟机时代，在线业务都部署在基于 Openstack 管理的私有云上，最近2年则进入混合云时代，公有云和私有云共同承载互联网业务。
之前介绍互联网的这些架构的话，带来了不少挑战，分5方面，基础设施网络连通性，网络稳定性，业务规模增长迅速，要求我们迭代路度快，基础建设也需要比较强的能力业务架构也从单一技术栈向多元技术栈过度。
交付效率周期长，交付不标准，互联网人员规模增长了很多，增长速度非常快，这样对于我们上层平台提出了比较高的要求，建设平台不完善的话，标准化设施的建设都会有问题，这边的解决思路就是抽象资源层，评比底层资源异构的特性。在CI方面提升CI效率。
DevOps 的建设从0起步，代码开发上线都是纯手工操作，正常操作就是在IDE编译代码，通过手工的方式上传，测试通过之后告诉运维进行上线发布。
紧接着我们建立了第一条流水线，这不是完整的流水线，我们在流水线各个环节里面都有对应的开源工具串联起来，在这个阶段的话，线下和线上两个环节没有打通，包括线上完全是 ChatOps，就是通过V消息、邮件方式告诉运维怎么上线，要改什么配置，是这么原始的阶段。
初期通过这个配置对于新人和新的服务上线来说，整个配置复杂度比较高，不是特别友好的方式。CI和CD没有打通的话，整合服务交付时间段比较长，发布上线成为了瓶颈。整体上线是手工上线的，去年我们大部分的上线变更出现故障都是由于手动发布导致的。
2. 混合云架构下的 DevOps 实践之旅
DevOps 所有的平台大部分都是今年半年之内构建起来的，我们是基于 Spinnaker 自研CD持续交付平台，还将CI到CD环节进行了打通。我们可以看到增加的这几个部分，打包环节我们通过CI，发布环节通过CD。上线后的服务持续运营加入了包括调用链、基础监控、日志中心等服务。
这几张图是RightScale公司的调研结果，我们知道这个公司是全世界范围内做混合云市场份额比较领先的公司，我们可以看到在目前来说这些企业里面只有70%多的企业用了混合云的架构，1000 人以上的混合云比重高达 80 %，整个混合云使用的比例也是越来越大，每一家企业在使用混合云的话，平均都超过了4家以上，所以说混合云是我们整体互联网IT发展主流的趋势。
我们再看一下整个混合云架构的优势以及挑战，优势有三方面：
首先是灵活性，混合云能够按需进行分配，扩展性强，TCO更低。
第二是可靠性，多云形成了互补，今年、去年腾讯云宕机都有发生，如果有了多云的支持，就可以在多云之间形成容灾。
第三是丰富性，各家云都有各自的特点，百度云在AI计算有特殊的地方，腾讯云在用户关系链这块，多云的特性形成了互补。同时也带来了挑战，对于我们来说比较大的一个挑战就是安全性的问题和网络互通的问题。
整体 DevOps 平台，不管研发和运维都要达到这四个目标：标准化、自动化、自助化、多样性。
1.标准化要求环境需求、业务部署都要标准化。
2.自动化是要运维欢迎是快速、自动化、可重复的运行环境。
3.自助化是通过自助构成。
4.多样性不管是你的开发语言还是开发框架包括资源需求都要达到多样的需求。
下面这张图就是整体今年构建整体 DevOps 的功能全景图，在基础设施层，我们是多云的，我们可以看到我们引入了docker，往上是多云管控平台，再往上是中间件，然后是云服务、CI平台、CD平台、自动化运维平台。左侧就是串联整个场景的CMDB，包括服务资产、权限、流程。右侧通道包含了几个通道，配置管理、自研vivo底层控制系统vcs，Bees作为日志采集的，Ansible 我们用的不多，包括监控平台和日志服务。
DevOps 全链路，我们从开发到需求管理用的是 code 和 gerrit，代码提交后我们将代码进行编译，构建打包到线下制品库，然后做测试和部署，如果测试验证后再进行将制品推送到线上制品库，通知运维进行预发和生产环境部署。右侧会引入监控系统、日志中心以及一些我们需要自动化运维，通过作业平台进行。
刚刚赵班长也有详细介绍了他们的 CMDB 是怎么做的，CMDB 是 DevOps 的元数据管理的基础，现在我简单介绍一下我们 CMDB 是怎么做的，我们主要分为四大块，资产、服务、重建和流程，我们今年做的主机设备，网络设备有做一部分，剩下的还没有开始做，只是把整个图列在这里了，我们不单服务树形结构的管理，在权限统一了整体运维体系包括研发体系的权限管控。流程，我们替代了内部有一个BPM的系统，但那个系统包括自定义的流程，包括回掉的流程都做的不好，我们是完全基于我们的用户场景研发了流程管理的平台。
整体 CMDB 围绕服务树树型结构打造的，在横向我们做了平台串联，包括监控平台、CICD、配置中心、日志中心。在右侧，整个树型结构组织就是我们公司组织架构，我们会从公司、部门组、项目、备机池（临时机器存放），项目下面是服务，服务往下就是服务单元，服务单元是最小不可拆分的部分，有统一的生命周期，包括统一的配置管理，就是我们的监控策略，我们的发布策略，在这个服务单元里面都是相同的。
DevOps 之 CMP 统一资源访问和管理，包括物理机、私有云、公有云，通过这些统一在底层屏蔽了 API 的鉴权、异构特性，同时我们对私有云做了集群的编排，对其他云来说，都有统一的管理，各种的一些管理，还和整体的 CMDB 做打通，比如我们做机器申请，对应的关系都会统一录入到 CMDB 里面。
这是线下云服务，我们知道大家在开发测试阶段，我们要构建依赖，整体耗费的时间比较长，你都需要去知道是怎么搭建，这个事情对运维很简单，但对开发没有那么清晰，所以我们基于 Contiv 这个构建了 docker 容器云。
下面来说一下我们整体的CI和CD我们是怎么做的，我们整体编排流程引擎我们是通过 Spinnaker 做的，这是整体的 Spinnaker 的架构，一个是Deck是民向用户UI界面组建。Orca 是核心流程编排引擎组建，我们通过并行创行都是通过这个实现的。Igor 是CI系统组建，后端有CI都是通过这个组建的。Cloud driver 是适配不同云平台的组建。
基于 Spinnaker+Jenkins 的CI流水线建设，整个模板各方面是固定的，大家要做新任务构建的话，点几个鼠标写一下证书基本上构建任务就串联完成。我们通过 Spinnaker 把构建组合起来，然后完成流水线的流转。
构建编排方式，我们从几个维度构建，同时执行顺序、依赖关系都是通过 Jenkins 表述的。
发布编排方式，我们部署策略也是通过 Spinnaker 编排方式实现的，目前支持了机房间串并行，以及自定义。
Spinnaker 流水线建设优化，我们原来使用这套流水线的时候我们发现很多问题，我们的构建问题会发现这是官方的使用方式，下面是我们的使用方式，官方使用方式是用K8S做部署，部署完成之后这个是做的一堆机器的反馈结果；
我们是可以拆分成一个机器，这两种方式差别非常大，一开始我们没做优化的时候，直接上线我们发现原来支持100家的 Stage，我们整体的内存占用超过80%，CPU 间歇性的打满，我们看了原码之后，整个 Spinnaker 加载流水下的时候，会把上下游的东西全部加载进去，一个机器一个stage可能有20个，这样算下来整体内存占用非常大，我们根据我们的场景，我们重写了这部分的数据的加载，我们只需要知道上下游的关系，同时取消完整的扫描和序列化，对结构体进行优化，把整个结构体缩小。这几个部分取消掉之后我们整体并行和畅行能力达到了大大提升，目前来说2000+创并行没有问题。
我们整体全球发布方面，主要是通过每个机房有一个管理员，管理各个机房的 AGENT，通过上层连续管理员进行推送和发布，我们海外发布经过了代理中转，然后到 CACHE。
下面是自动化运维平台的基础，是作业平台，基本上通过我们的快速作业、作业流、工具箱、定植作业可以覆盖日常运维90%以上的场景，其中说一下作业流，底层通过Spinnaker实现的，这些影射到运维上的话就是前后脚本的依赖判断。
作业平台—统一Agent，通道统一，CMDB、监控、发布。统一Agent管控，变更和升级、进程守护、安全控制、审计。
域名变更管理，在完成这个系统之前，整个vivo不管内网域名还是外网外名的实现方式，内网DNS全网管控，平台化变更，对接 Dnspod、万网实现外网DNS变更。在这个基础上我们实现了流量预案，针对机房、VIP、域名三个维度，发生问题的时候，运维会有限在这个维度上制定预案，当发生监控告警，直接实行这个预案，就实现了切换。
下面再看一下 Nginx 变更管理，初期没有这个平台之前我们通过人工手动维护配置管理，但我们发现这个集群规模、集群数量增加之后，人工成本非常高，所以我们在线上设置了这个平台做 Nginx 配置管理，包括配置校验、管理、编排、发布编排等等。当测试集群测试通过之后才会往线上集群做下发。
再看一个就是我们知道之前看到我们的业务架构里面我们所有的服务都是通过 Nginx 转化，怎么样要无损发布呢？实现基础肯定要实现基础层的加载，目前微博开源的方案，通过 Consul，做分布式配置同步的系统，通过 upsync 做动态陆游的更新。
配置中心这块就是我们目前做代码和环境的分离，在用的一块系统，整体和市面的配置中心实现方式是一样，SDK嵌入我们的代码里面。
最后一部分讲监控是怎么构建的，自下而上分为基础监控、组建监控到业务监控，首先开源我们通过 zabbix 实现，在网上走的话，我们自研了 javaagent，再往上实现监控。
基于Zabbix搭建主机监控集群，通过Zabbix插件实现组建的部分监控，LVS、Mysql、redis、MongoDB，目前这套基础监控我们正在维护，我们每年会通过自研方式对这块做整体替换和我们的 CMDB 做打通。
拨测探测机通过云主机、体专店等手机上部署探针，整体架构其中难点主要体现在任务调度系统和实时流汇聚和计算系统，难点主要存在我在某个区保证稳定量的分布，对拨测来说体专店手机的稳定性比起我们的机房肯定有问题，所以我们要进行实时调度。整个数据回传、计算要在一分钟以内完成这个数据，在数据存储量和计算都有一些难度，我们这边采用OpenTSDB+Redis实现指示存储。
再说一下调用链，整体实现方式其实跟谷歌、腾讯、阿里的一样，整体调用链的作用可以帮助我们做一些服务的分析，故障定位、整体容量的规划。
这张图我们可以看到通过调用链梳理服务上下游、通过这个都可以实现。包括服务的QBS、响应时间，通过这些趋势图可以看到，当发生问题，比如说我定了同域名监控，都可以通过告警中心，通知到对应的开发和运维。
最后再讲一下我们整体的日志监控，数据采集分三块实现，一个是 flume，现在自研了 agent。会随着 CMDB 机器增加把采集应用到新增的机器上。上层的数据汇聚通过JAVA进行数据清晰。再往上走短期日志存在ES里面。
最后看一下我们未来vivo在 DevOps 的发展方向，我们现在也在做K8S资源调度层面的探索，未来我们会基于容器云向上提供服务，当在很长时间内我们继续提供服务。最上层我们是统一的计算表示层和分布式应用层，对服务方和应用方提供统一介入和服务。
3. vivo未来DevOps之路的探索
这块是基于容器云的CI/CD，我们目前用这个架构和方案做实施，当然我们可能优先会在开发册上跑这套方案，Jenkins在编译方面。
最后我们肯定也是从 DevOps 到 AIOps 发展方向，首先在几个方面可以做几个事情，包括 Spinnaker 组建做自动灰度分析和上线，基于机器分析做容量管理、智能监控相关的事情。
更多内容敬请关注vivo互联网技术微信公众号。
