从0到1，蘑菇街怎样打破应用运维自动化的技术藩篱

从0到1，蘑菇街怎样打破应用运维自动化的技术藩篱？

中国统计网 2017-07-10 17:30

做者介绍

白海强（花名：普智），目前在蘑菇街平台技术部从事应用运维体系和其它建设工做，与团队一块儿推动业务应用运维标准化及自动化系统的建设。在加入蘑菇街以前在淘宝任职，负责淘宝商品详情等业务的运维工做。

本文根据〖6月25日DBAplus电商行业运维实践沙龙〗白海强老师的现场演讲内容整理而成。点击文末【阅读原文】还能下载PPT哦~

演讲大纲：

1. 蘑菇街技术架构及运维演进

2. 应用运维体系建设思路

3. 应用运维自动化实践过程

蘑菇街技术架构及运维演进

导购期（2011-2012）

2011年蘑菇街上线时，它的主要业务是分享社区，就是买家买了商品之后，把这个商品分享出来给你们。2012年开始转型商品导购，早期业务比较简单，相对设备比较少，基本上是一套业务代码。运维都是由具体的开发同窗本身去管理的，根本不须要专业的运维人员。

转型期（2013-2014）

从2013年开始，咱们开始自建电商平台，从下单到支付整条链路开始自主建设。业务发生了变化，可是整个架构没有太大的变化，只是把中间层，数据层脱离出来了。设备增长了很多，从原来个位数增长到三位数了，还有网络设备了。业务这一块是开发本身维护，运维这边主要建设了一些初级版的服务器管理系统、发布系统、监控系统。

社交化电商（2015-至今）

2015年整个业务开始发生变化了，集团开始从原来的PHP开发，逐步转向了Java开发，从原来主站一套单一业务套代码拆分红各个子业务系统，整个架构发生改变。流量入口咱们分红两块，无线端和PC端二块接入。MWP为无线网关。其余PC端的流量经过代理层分发到各个不一样的子业务系统，部分系统实现先后端分离服务化，最底层为数据层。从原来业务再新加业务需求，逐渐演变成拥有目前1300多个应用系统。

业务快速发展对咱们运维带来的挑战：

第一：1300多个应用如何进行管理，这是一个大的问题。不一样业务如何区分？业务确定要部署在具体服务器上面，不一样业务部署不一样服务器，业务和服务器之间的对应关系如何管理？还有业务部署环境，不一样的业务运行的环境有可能存在差别的，因此咱们须要把业务与环境之间的对应关系也要管理起来。

第二：早期业务之间能够依赖简单应用代码之间内部的调用，拆分演变成应用与应用之间的依赖关系，如何管理业务之间的上下游依赖？如何快速定位排查问题？这对咱们排查工具带来了挑战和要求。

咱们带着这些问题看一下运维体系建设的思路。

应用运维体系建设思路

运维核心理念

运维工做围绕这四个主题展开的：

• 稳定性。保证业务稳定快速地发展；

• 成本。成本涉及到两块：人力成本和系统资源成本，咱们指望以最小的成本创造最大生产价值；

• 效率。运维工做自动化，提升工做效率，减小成本；

• 安全。

咱们平常运维工做都是围绕这四块展开的，系统建设的时候也是围绕这四个主题展现；这四块主题优先等级我我的认为是：安全第一，若是系统存在安全问题，那确定是第一时间处理；其次是稳定性、成本、效率。以上我的对运维的理解。

应用运维系统架构

基于运维需求，咱们逐步建设起目前的运维体系的架构。从最底层看，第一层基础的硬件环境，如IDC/服务器/网络设务。第二层为业务须要的底层基础服务，如DNS、NTP、YUM源、LVS等；第三层针对这些系统资源管理平台，虚拟化平台，DNS管理系统等。上面三层针对业务的，有咱们应用管理系统、服务器管理系统、DBMS等；还有经常使用的系统，像发布系统、部署系统之类的。最顶层是开放给业务开发使用的统一运维平台。这些系统并非说在咱们建设当中一下就能建设好的，而是根据咱们平常操做当中运维的须要逐步搭建而成。

应用标准化规范-思路

若是一个系统业务要接入进来，第一步要作的是标准化。按照咱们规范进行改造，符合咱们要求才能接入进来。否则1300多个应用没有一个统一接入标准，让咱们去作适配打造运维相关的系统，那是不可能的。咱们整体的思路，先标准、后接入，只有按标准改造了，业务开发才能方便地使用咱们的运维系统。

应用标准化规范-范围

标准化到底要作哪些事情呢？主要分红三块：

• 基础环境。基础环境里面规范有哪些呢？咱们能够分为两块：硬件、软件。硬件咱们规范了使用的服务器硬件配置规格，目前虚拟机规格分红三类：2核4G内存的，4核8G内存的，8核16G内存的；目前要求都使用的是虚拟机。软件方面咱们主要规范部署须要的软件的版本、管理方式和部署目录；

• 应用配置。这里规范了应用部署目录、应用包名和应用配置等。

• 技术架构。规范了业务对基础组件使用姿式，如流量接入层、ZK、Kafka等。

应用标准化规范-内容

集团应用体系规范

接下来看一下具体的标准化定义内容。整个运维标准化体系是咱们运维部牵头搞的。主要是刚才讲到的内容，定义了具体咱们使用的应用和基础服务的接入、目录的规范。旁边能够看一下应用的管理规范，详细定义应用名命名规范、应用包名规范、应用目录、部署目录等内容，造成文件，在整个集团各个部门里面传达执行。

应用标准化规范文档-实例

应用部署规范

咱们按照开发语言不一样，应用服务对服务器的部署环境要求也不一样；咱们前后制定Java版、PHP版、GO版和Node.js版等。每一个版本的规范里面都基本上定义了这些内容：

第一：目录：基础软件部署目录和版本要求；

第二：应用运行的用户帐号是什么、权限是什么。

应用标准化规范文档-实例说明

（1）应用启停脚本

接下来咱们还规范了启停脚本，还定义了这个脚本里面传的参数，能够支持哪些参数，启动或者重启。每条指令里面作什么事情都进行了说明和规范。

（2）规范应用上线标准

除此以外还定义了一个业务上线以前要遵循的标准，上线的标准和下线的标准。上线以前须要业务方提供标准的自检功能，要怎么知道你这个应用是成功仍是失败的，那确定须要有一个检测机制告诉我，脚本里面经过这个检测机制知道这个业务究竟是否正常，这是一个强制性的规范。下线也是同样，上流根据定时检测指定这个URL，根据访问结果判断是否把流量自动地切掉。

标准化文档里面主要就是规范上述一些内容。这些内容为后面的运维系统作了规范。咱们运维系统都是基于这个规范来作。

应用运维自动化实践过程

应用运维核心概念

1300多个应用如何管理？在介绍应用管理以前须要重点介绍一下这几个概念，这做为蘑菇街应用运维核心概念。

第一：应用名表明在蘑菇街应用系统中具体业务功能，不一样的应用名用于区分不一样的业务，咱们按照一套业务代码进行划分。

第二：应用名分组是管理服务器的，用来组织管理服务器的。

二者之间的关系是什么？一个应用下面能够对应多个应用分组；这个分组按照什么维度来划分的呢？能够根据环境，也能够根据稳定性的要求来拆分的。应用名做为应用运维的核心，运维系统都以应用名做为资源的组织方式。

应用管理系统

系统里面主要管哪些内容呢？其中一块用于管理业务、部门、人员三者之间的关系。

能够看一下这个图，像这个业务是属于哪个部门的，开发者是谁，代码review是谁，这个里面都会维护好。除此以外还会定义这个应用的部署特征，这个应用部署类型是什么，这个比较关键。后期的运维系统咱们会拿着部署特征信息后面作判断应用于具体操做。应用管理系统中定义里面每个字段在后面运维系统里面都会存在必定关联。

服务器管理

接下来服务器管理也有单独的系统，服务器管理系统前面说了，分组是做为管理服务器的，在这一层能够看一下咱们整个层次结构分红两层：部门下面是具体的应用，应用下面是分组。应用分组默认有三个组：DEV表明线下测试环境，PRE表明预发环境，ONLINE表明生产环境。咱们在分组上面创建了不一样环境的标识；发布系统或其余运维系统就能够根据需求按应用的纬度获取不一样环境的机器列表。

同一个应用目前咱们只分了三套环境：测试环境、预发环境和线上环境，通常默认对应3个应用分组；但有时基于稳定性考虑，会把线上环境的服务器拆分红多个应用分组。假如某个应用是为其余应用业务提供基础服务的；若是调用服务不隔离管理的话，很容易出现稳定性的问题，如非核心业务调用量过大，致使核心业务调用失败或超时，基于上述问题，咱们很容易想到解决方案就是把服务拆分红不一样服务集群，让核心业务调用1个服务集群，让非核心业务调用另一个集群。这个需求RPC服务管理控制台均可以实现IP与服务关系绑定；根据依赖业务重要程度区分出不一样的服务集群，再根据不一样集群调用量需求将服务器划到不一样的应用分组中进行管理，这个拆分分组是比较好的一个解决方案；

既然RPC这边已经把服务逻辑分组，那服务器管理系统中是否是能够不用区分了，服务器放在同一个应用分组下进行管理，这样不是更简单吗？

不拆分出应用分组，对于业务访问是没有影响的，由于应用分组的做用只是管理服务器，不会影响线上正常访问；可是运维系统是不知道应用业务内部逻辑访问分组是什么样，那些机器属于同一个服务集群，操做时须要必须一块儿操做；若是同一个集群一块儿操做的话，那线上的服务就挂完了；因此必须把这个体现出来，管理起来；

应用分组这个管理方式是比较灵活的，能够根据不一样业务的特征创建不一样的分组。好比说机房纬度、地域纬度等。分组能够理解为是一个集群的概念，同一个应用分组下提供服务和服务对象都是相同的。这是服务器管理这一块。

应用部署类型模板管理

同一类开发语言开发出来的业务应用对于部署环境依赖大体都是相同的。基于这个特征，咱们基于应用部署类型制定应用部署模板，用于管理同类应用部署服务器环境的需求。咱们基于不一样部署类型创建对应的应用部署模板，如Java版、C++、GO等。在这个模板里面咱们定义了：部署的软件和常规配置文件等内容。举个例子，Java开发业应用，通常部署服务器环境所须要的包括一个JDK，容器咱们使用Tomcat，Nginx做为Web代理服务器；除此以外，咱们还有可能须要启停脚本和配置文件，用于保证环境正常运行。

应用基线管理

部署模板的用途用是什么呢？它主要为应用基线提供服务的。应用基线咱们创建的维度按照应用分组维度创建的。

应用基线创建的维度咱们是按照应用分组维度来创建的。通常状况下应用基线部署的内容配置都是从部署模板里面导过来的，基本上都能知足相应的应用部署环境的须要；当个别应用须要个性化的环境配置或软件时，咱们就能够针对相应的应用分组的应用基线进行修改补充，已知足业务方的需求；

应用基线产生时间点是在应用申请流程结束后，根据应用申请时选择的部署类型自动地把应用模板相应配置信息导入到该应用下的全部应用分组下面。

应用部署系统

经过前面几个系统，咱们基本上把环境、应用都管理起来了。但如何实现环境的自动化部署？咱们创建了应用的部署系统，应用部署系统里面定义什么呢？就是咱们定义了部署环境的执行步骤。

如第一步，部署安装软件；第二步配置文件；第三步初始化等等。根据咱们应用的部署类型创建不一样的部署须要执行的步骤，按照定义执行步聚能完整地构建起一个应用的运行环境。

运维工单管理

最后缺一个触发的场景，能把上面各个相关系统串联起来的系统。像申请服务器、扩容，新应用申请，由于这些都是业务开发提出了需求，如何组织在一块儿，跟咱们的环境部署系统组织在一块儿呢？经过运维工单的方式，须要业务开发提相应的工单，根据不一样的工单把咱们前面运维的步骤总的综合在一块儿。

目前咱们工单的范围比较多，覆盖了咱们运维当中常见的一些运维需求，像服务器申请、新应用申请之类的。这些步骤里面，每一个工单里面都包含两部分：第一部分是流程审批，由于有的人很反对流程，但流程是为了保证稳定性的手段而已。还有一部分是咱们的工单，具体作的事情。工单系统里面是这两部分组成。

应用运维自动化实现总结

接下来讲一下整个过程，当运维开发提交一个工单给咱们的时候，假设新应用申请，重新应用里面根据这个应用里面定义的内容获取应用的配置信息。应用的审核人员是谁，根据这个审核人员审批流程经过之后，会获取对应系统里面部署的机器列表，根据部署列表拿到之后，把数据传给应用部署系统里面部署环境。部署环境里面，部署哪些软件、同步哪些配置文件，这些数据从哪取？从应用基线里面取。应用基线里面若是是空的，就从应用模板里面获取。当环境部署完成之后或者出了异常之后把具体信息返回给工单系统，工单系统能够作一次重试任务或者结单。

（1）应用运维自动化实现-工单实例

这边是具体使用的工单实例场景——新应用申请。有流程审批，流程审批结束之后，运维系统里面作的第一步，应用的基本信息插入到应用管理系统里面，同时设备管理系统里面自动的建立分组，分配机器。机器分配完之后去部署环境，同时添加相应责任人的权限。这几个步骤基本上都是所有自动的。有问题的时候会停留在具体工单上面，运维人员会作这一块的重试或者查看工单详情，看哪一块出了问题。

（2）集成发布系统

对于运维开发还有一块须要关注的是集成发布系统。集成发布系统的功能就是把代码部署到线上服务器。当咱们把一个应用包编译打包完成之后，须要将这个应用包发布到具体的服务器到应用部署发布完成通过如下几个步骤：

首先检查一下环境完整不完整，发布系统检测一下目前机器上面的部署环境是否完整。确认部署环境没有问题后，发布系统把应用包同步到对应的服务器上面；接下来经过监控系统接口关闭相应服务器上监控项；接下来执行应用目录下的应用启停脚本，通知RPC调用方或Web代理该服务器即将下线；暂停必定时间后，再执行应用启停脚本中中止指令，停掉Nginx和Web容器；确认应用服务中止后，将应用包同步到运行目录里面解压、启动应用。

启动应用时如何知道应用是否启动成功了呢？经过咱们前面定义的，每一个应用里面上线必需要遵循的规则自检的程序来判断（发请求/status检测）。若是请求返回SUCCESS时，则说明应用启动成功了，不然认为失败；确认成功后，通知RPC调用方和WE代理该服务器能够正常服务了。

（3）监控系统

还有一块是监控系统，当咱们应用上线完了应用都启动成功了，把应用服务器状态调整成Online，这样能够把监控系统自动触发针对该应用进行监控。咱们会根据部署类型，部署不一样类型定义不一样的监控模板，固然业务方也能够自定义监控项。

（4）全链路跟踪分析

当从原来一个单一的应用演变成多个应用，之间的业务依赖关系如何进行管理，针对这块需求，咱们跟稳定性团队共同开发了一套“全链路跟踪分析系统”。在咱们流量的入口把全链路的功能模块嵌入进去，要求全部标准化的应用都引用了全链路的二方包，流量入口到底端构成了整个链路，经过这个链路分析对应的应用依赖关系。

在全链路跟踪分析系统中，能够看到应用自身提供的服务和依赖的服务，以及各个服务后端依赖的链路；当咱们出现问题的时候，在这个系统里面直观地能够定位到哪个业务出了问题和哪一个服务出了问题。

除了应用总体的依赖关系之外，还能够根据具体的链路分析出来整条链路上下游依赖关系，这条链路的这个请求进来之后依次通过哪些系统，并且系统与系统的调用关系是多少，在全链路分析系统里面咱们均可以看获得。全链路分析系统是咱们运维这边比较重要的一个定位排查的系统。

（5）运维一站式管理平台

咱们前期作了不少运维系统，如应用管理的、域名管理的、服务器管理等，涉及到各个运维资源管理。但这种分系统部署管理给业务开发会带来问题，须要一个信息之后，须要在不一样的系统之间进行切换去察看相应的信息，这对开发来讲是比较痛苦的。所以咱们目前正在作一站式的运维管理平台，但愿以业务的维度把全部的运维资源都展现在一块儿，并结合相应的运维工。

这一套系统里面分红两块：第一块是部门维度的。咱们基于部门能够看这个部门下面全部的业务有哪些业务以及相应的人员，除此以外还能够看到这个部门消耗的资源有哪些。旁边这一块有服务器利用率统计里面能够看到整个资源的消耗，这个部门下面有多少个业务，每一个业务消耗的服务器资源有哪些、利用率是多少。

第二块应用的详细信息，应用里面会把全部应用相关的资源都定义好，在这里面展现出来。咱们能够在这个平台里面综合的看到这个业务总体的状况。目标是想打造一套NOOPS运维平台，固然这是基于稳定性和安全的状况下，把运维操做让业务同窗自主的去完成的，不须要运维同窗过多参与，提升开发的工做效率。

咱们目标是NOOPS，目前正在路上，谢谢你们！

Q&A

Q1：内部Ops平台已经成型了。我想问一下PE蘑菇街这边的历程，如今是怎样的？

A1：蘑菇街前期PE主要是负责业务稳定性这一块，资源分配、环境管理这一块。慢慢的iPaas这个平台上线，平常运维工做逐步减小后，之后咱们PE会更多关去心使用服务器资源使用率和成本。

End.

来源：公众号“DBAplus社群”

运行人员：中国统计网小编（微信号：itongjilove）

微博ID：中国统计网

中国统计网，是国内最先的大数据学习网站，公众号：中国统计网

http://www.itongji.cn