蘑菇街DeVops实践
Posted 百林哲
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了蘑菇街DeVops实践相关的知识，希望对你有一定的参考价值。
作者 ▕ 赵成
编辑 ▕ 七七
蘑菇街技术架构演进过程
早期2011年，产品形态是导购，业务量不大的情况下，技术架构选择了相对简单的LNMP架构。通过php快速开发，让业务快速运转起来。所以，当时主要以开发人员为主，没有专职的运维的团队。
2013年转型做电商，整个技术架构也没有发生太大地变化，还是以LNMP架构为主。不过在业务从小到大的快速发展过程中，最容易出现瓶颈和问题的是DB的连接、缓存的连接等这种连接数的资源，蘑菇街在这个阶段也遇到的同样的问题，所以架构上的调整，主要是DB中间层和缓存中间层的增加为主，但整体上还是LNMP。
随着业务发展，业务也开始变得丰富和复杂起来，带来的不仅仅是用户量、业务量这种体量上的增长，业务自身丰富度和复杂度也在发生着非常大地变化。对技术上带来的挑战和问题，如下图所示：
可以看到PHP的工程变得异常的臃肿，因为有太多的业务需求需要开发，有太多的开发人员在同时开发，结果短期内PHP的代码工程就造成了局面。
首先谈到PHP的优势，PHP上手非常快，入门门槛相对低一些，一个新手从学习到开发生产系统的代码的周期相对较短，同时，PHP部署发布的效率也相对简单，PHP文件发到线上即可运行，不用复杂的编译、打包和启停动作，在业务前期发展阶段，PHP效率上的优势就表现的很明显。但是，上图所示，随着业务的发展，业务类型越来越多，开发的人员也越来越多，大家都往一个工程里面去写代码，势必导致PHP的工程越来越大，越来越臃肿，给后续的代码维护带来了很高的复杂性。
举个例子，对于一个开发的人员来说，如果他要做的功能和需求涉及到其他人的开发的PHP文件，本来这个功能和需求在原有的程序上改就行了，但是因为工程太大了，他可能是没有办法评估清楚说改了这一个文件，对其他的文件、接口和方法会造成什么样的影响，即使能够评估清楚，也很难保证在测试的时候把这些所有的点都能够测试到，根本没这么大的精力。所以就导致很多开发人员会不断的Control C+V，就是宁可是把需要改的文件Copy一份出来，然后在Copy出来的文件上面做开发，原来的功能不动，这样就保证了新需求可以不影响老公能，但是这个状况就会导致进一步加大了PHP工程的臃肿，实际上是一个恶性循环。再就是，如果碰到非改不可的PHP底层的文件和代码，如果评估不到位，就是导致出现各种各样的线上故障。所以，到了这个阶段，PHP代码就很难维护了，反而影响到了需求和版本的迭代速度。
这种情况下应该怎样办呢？需要选择业界比较通用的方案-Java服务化，把大的工程拆分成一个个小的应用，通过服务化框架提供RPC的调用。这个阶段，从PHP转向JAVA，从单一工程转向了分布式服务架构。
经过拆分后，整个架构就变成了现在的这个样子。这样看下来整个架构分了很多层，也有很多的细节，乍看上去是比刚才的架构图要复杂一些。但是这样的架构根据条理性，也会让架构里面很多的技术细节都曝露出来，更加便于管理。相对那刚才非常庞大和臃肿的PHP工程，内部的逻辑、方法和接口的依赖等等，是很难梳理清楚的。
下面主要讲做了JAVA服务化的技术转型后，对运维带来的挑战是什么：
1、服务化应用的管理问题
2、服务化之后的服务治理问题
运维解决方案和思路
运维基本上要围绕着以下5个目标开展，效率、稳定、成本、体验和安全，重点从效率和稳定这两个方面去讲。
从0开始应该怎样做，一定要从标准化开始，并围绕标准化展开。关于标准化，不管是做运维平台也好，还是运维体系也好，或者运维系统也好，第一件事要做的一定是做标准化。
标准化主要做三方面的工作，第一是基础软件及基础设施的标准，主要是操作系统的版本必须统一，内核参数统一，基础设施上，用KVM虚拟化技术将我们的资源做成2C2G、8C16G这样的资源模板，确保资源配置的统一。第二是应用及配置标准化，这个后面细讲。第三是技术架构标准化，技术架构这块分接入层、中间件技术、缓存、DB等，关于技术架构标准化，它的重要性和它的意义在案例中体现出来。
举个例子：
在做整个运维平台之前，首先将整个系统梳理一下，然后看一下整个系统里面到底有哪些基础环节和软件，应用到底有哪些应用类型。把这些东西一条一条地记下来，然后归纳总结，慢慢的就形成了左边的集团标准化，包括应用管理的标准化。基础服务的标准化，安全的标准化，稳定性的标准化，全部都制定清楚形成文档。
把标准化的动作做完以后，如果只是纸面上的，那它的威力是没有显现出来的，如果仅仅是以写脚本的方式去管理它，实际上还是有点笨拙，所以再往后就做了这样一个应用配置系统，目的就是把做的标准化沉淀在技术平台上面，可管理，可提供服务。以上的样例就是我针对Java的标准，它的目录，起停的脚本等，通过一个应用模板固化下来，比如实际应用过程中，典型的Java应用，是nginx+Tomcat的运行方式，那在应用配置管理中，就会有应用模板、基础软件和应用配置文件管理几个模块来管理。
以上这部分，是针对标准化，最后通过应用名这个核心将上面所说的这些零散的标准项给串起来，也就是常说的以应用为核心的运维体系。
案例分享
做完了标准化及标准化管理以后，遇到的比较棘手的问题就是这么多的应用应该怎样高效发布，这就涉及到持续集成和发布的问题。原来的PHP工程，只要在一个PHP的文件里面把代码写好，把文件推送到服务器上，然后最新的PHP文件就可以直接运行起来了，不用做中间环节的管控，但是对于Java应用来说整个环节就没有这么简单了，Java文件涉及到编译、二方包、三方包依赖，然后编译打包后，将软件包发布到制定的机器上，然后还要重启Java进程，最新的文件才能得以执行，期间还会涉及服务的注册和下线问题等等。
从整个过程来说，JAVA整个发布过程是要比PHP复杂很多的。所以为什么要去做持续集成，对于这个持续我的理解是怎样能够把中间环节它的效率尽量提升，减少人为的干预，通过发布的自动化，提升开发和运维的效率。
接下来做的发布系统，提炼一下，发布做的事情就是，将提交后的应用代码，进行编译打包，然后发布到应用对应IP主机的指定目录下，并且做到应用服务的优雅上下线（或者叫做优雅启停）。
可以抽象出发布的最重要的三步，如下：
下面就分阶段详细描述三个主要环节：
1、代码提交环节（分支合并管理）
代码管理工具是Gitlab，代码提交过程中最重要的就是对于分支合并的管理（这里又涉及到标准规范的制定），策略示意大致如下：
描述如下：
1、master分支，跟线上应用代码保持同步，也就是说随时可以发布到线上进行部署运行。
2、开发分支，通常以feature/defect来表示，比如开发一个新的需求，就会以当前master为基线，拉一个feature分支出来进行开发，同一个应用可以同时存在多个feature分支并行开发。
3、发布分支，以release表示，在发布时会将所有提交集成的代码commit合并，形成release_环境_时间戳为分支名称，比如release_dev_01_29_20_52_10 就代表该分支是在1月29号20:52:10在dev环境发布时创建的临时发布分支。
4、从预发进入线上时，会以当前预发环境的发布分支release_pre_xxxx为基线创建一个release_online分支，作为线上的发布分支，线上发布结束后会把release_online分支合并到master中，这也就保证了发布到线上的代码最终一定会跟master的代码保持一致。
2、编译构建环节
以上介绍了代码提交环节，下一个环节就是要构建了，以Java为例，构建用到了两个工具，Docker和Maven。Docker主要用来提供一个干净独立的编译环境，Maven作为依赖管理和打包工具。整个构建过程如下：
以Java为例，简单描述如下：
1、首先准备好JDK的编译镜像，这个镜像环境与线上环境保持一致，当有新的构建任务进来时，就创建一个对应的Docker实例进行代码编译；
3、对于Java应用，在这个Docker实例环境中，就可以执行mvn package命令打包了，最终会生成一个可发布xxx.war的软件包；
4、同样的，对于C++，Go、NodeJs，也会准备好类似的编译镜像，不同的是打包时，对于C++是cmake&make，Go就是go install等等，最终也会生成一个可发布的软件包；
5、构建完成后，Docker实例销毁；
这里面Docker发挥了一个很大的作用，就是提供了干净的，互不干扰的编译环境，且对于并发打包的情况，Docker快速创建多个并行的实例出来提供编译环境，使用完销毁，这个效率上的优势也是非常大的。
6、关于配置管理，当时设计时考虑比较简单，做法是同时做三个配置文件出来，dev_pom.xml，pre_pom.xml，online_pom.xml，分别对应开发、预发和线上三个不同的环境，根据发布的环境不同，将不同的配置文件替换上去。这样做其实可扩展性不够，对于多机房、多分组的情况会有更多的配置文件创建出来，且对于有敏感信息的配置项保密也不够（不过这些配置都已经加密挪到中间件的配置中心了），更好的办法可以考虑采用阿里早已开源的auto-config方案。
3、部署环节
以上，代码提交和编译构建完成后，就该进入发布到线上的部署环节了，也就是将代码发布到应用对应IP主机的指定目录下，并且能够优雅的上下线应用服务，貌似很简单，但是，看下图：
这个过程的环节还是比较多的，这些环节内部又会有很多的细节，所以整个部署环节是很复杂的，下面将整体思路介绍一下：
0、从CMDB中，拿到应用-主机IP对应关系，然后再从1开始做，后面的过程可以是针对单台机器做，也可以是分批或分组多台机器同时做。（从第0步开始，原因就是上一篇文章里面说的CMDB和应用配置管理的基础要先打好，这个基础没有，下面的环节就无法顺畅地执行）；
1、检查每台机器上的服务是否正常运行的，如果是正常服务的，说明可以发布，但是服务本身异常，就要记录或跳过了；
2、下载war包到指定目录（应用的目录信息，应用配置管理又发挥作用了）；
3、将监控关闭，以免服务下线和停止产生误告警；
4、优雅下线，包含RPC服务从LB下线或Web服务从Nginx下线（如果不提供http服务就不涉及），下线动作均通过API接口调用方式实现；
5、下线后自动检测无新的流量进入，停止应用，发布代码，然后启动应用（这时应用配置管理里面，启停命令等等就又发挥作用了）；
6、优雅上线，进行健康监测，检查进程和应用状态是否正常，如果全部监测通过，开始上线服务，开启监控；
7、分批发布，这里简单提一下，假设我们一个应用有100台主机，这个时候做发布不可能全部一把停掉，这样服务会中断，但是也不能一台台的做，这样效率又太低，所以我们可以折中分批发，比如可以分5批，每批20台，也可以分10批，每批10台，这样既可以保证在线升级，也可以保证效率能够跟的上。当然复杂一点，还有分组分批，或者按步长分批，第一批5台，第二批10台，后面每批20台等等。示例如下：
整个过程下来我们可以看到：
1、基于场景入手，将业务流程梳理细致，做到细分环节，每步自动化，流程串联
2、上篇文章提到的CMDB和应用配置管理的内容，在这一部分无时无处不在发挥着基础的作用
效果：NoOps or DevOps？
发布系统上线后，整个过程已经可以做到开发全程自助发布，之前运维还在参与审批，后来审批环节也省略，在发布这个过程中，全流程NoOps。效果如下图所示：
从0到1做完以后，效率问题基本得到解决，但是系统的稳定性这个矛盾马上就凸显出来了。经常遇到的问题是系统慢了，系统宕了，或者是突发流量非常大，会碰到这样那样各种诡异的问题。所以这里分享稳定性建设这方面的内容，主要分为：
主要介绍全链路跟踪系统。首先，为什么要做这个事情？
这整个的全链路的架构图，在前端的应用上面会做埋点日志，然后通过Kafka放到实时日志集群里面，这样可以快速看到实时的数据，然后对于历史的数据，放到Hadoop里存储。
这里要介绍关键的技术点，其中最关键的就是TraceID，当一个请求到达接入层，会在接入层生成全局唯一的TraceID，由我们自研的Nginx的module实现。然后后续的后端接口或方法调用都会把这个ID带上，这样每一次调完会成都会输出一条日志，把本次请求花费多长时间，调用哪些接口记录下来，这样通过刚才实时的Storm集群就可以计算出整个的实时请求是怎样的。
这里呼应为什么要做技术架构的标准化，这个TraceID是通过Nginx的module生成的，在ID透传的过程中，每一个请求都会从框架层面把这个ID自动带上，业务层面是不用考虑对这个ID单独做处理的，对于http请求，就是自动带上这个参数，对于RPC调用，通过分布式服务框架来处理的。所以接入层架构、分布式架构的这样一个统一的技术栈标准化之后，落地这样的稳定性方案其实就非常顺利了。假设这个标准不统一，Nginx大家有用原生版本的，有用Openresty的，有用Tengine的，或者直接用了Apache，这个module是没法统一定制的，对于分布式的框架，如果有用dubbo，HSF、Thrift的等等，也会无法统一。
样例：
1、发现页面慢了到底怎样去做。经常遇到的一个情况就是页面慢了或者是某个页面慢了，根据问题反馈的时间点，可以进行筛选。这个时间段内，请求超过1秒的有哪些，筛选出来后，以TraceId为入口，那接下来整个请求的过程就展示出来了。从这个界面上我们可以很明显的看到，整个请求花了1.5秒，但是下面红色的地方有一个评价的服务，单这个服务接口的调用自己花了1.3秒，肯定是这个服务出了问题，这时候可以大大缩短问题范围的缩小，根据这个IP，直接到这台主机上检查发生了什么问题，后面就可以进入到详细的问题定位阶段。
2、调用合理性的问题。一次请求下来耗时非常长，但是看每一次的接口调用RT又是非常短，问题出在什么地方。比如下面这个这个请求花了1.8秒，但是每次请求都是了正常的，不像刚才一样，有一个请求自己占了1.3秒。这时候通过全链路可以看到，这个请求在频繁的重复的调用一个Cache接口，很显然在调用合理性上出现了问题。这时就可以把问题反馈给开发，检查下代码的逻辑，为什么这么调用，是不是应该优化下调用方式。
3、链路分析。一个应用提供出去以后，一个应用又包括了很多服务化的接口，而应用仅仅是成百上千应用当中的一个，这当中有哪些应用依赖了我，然后我又依赖哪些应用的哪些服务化接口，这些应有服务的质量到底怎样等等，这就是一个服务治理的问题了。所以做了这样的一个链路依赖的整个分析，从这里里面可以看到我提供服务的运行情况，有哪些应用是依赖我的，我又依赖了哪些应用。
链路分析还有一个非常关键的作用，稳定性中有一个限流降级系统。关键点就是通过链路分析提炼出核心应用（交易链路）和非核心应用，对于核心应用优先保障，配置的并发数和优先级就高一些，非核心应用就会小一些，如果出现流量特别大的情况，就会考虑把非核心应用降级或限流掉，优先保障核心应用的调用和运行。
举个简单例子，比如交易相关的购物车下单，如果下单应用依赖了我的服务，那它的优先级就会相对较高，毕竟下单后会马上产生收入，同时可能还有商品评价也依赖我的服务，但这个与交易无关的，那它的优先级就低一些。当我的服务和应用在峰值时（比如大促），策略就是要优先保证交易的应用，其他非核心的应用就降级降掉，或者是并发数限掉，宁可失败但是不可以影响到我整个交易的链路。所以它非常关键的价值就在这里，能够帮助我们梳理清楚核心和非核心的应用，不同的场景采取不同的稳定性保障策略。
赵成—百林哲咨询（北京）有限公司专家团队成员，美丽联合集团运维负责人
近10年研发和运维经验，期间非常有幸见证和参与了几个电信级和互联网产品从无到有的创造，从微量到海量的成长过程，个人也随着产品的发展壮大，积累了非常丰富的电信级和互联网业务研发和运维经验。之前在华为公司，现在负责美丽联合集团（原蘑菇街和美丽说）运维团队的管理以及运维体系建设工作，专注于运维创造价值，以及云计算时代运维的转型和突破。
集满
20个赞，戳小编，领奖品啦~~
更多精彩内容尽情点击阅读全文╭(╯3╰)╮
以上是关于蘑菇街DeVops实践的主要内容，如果未能解决你的问题，请参考以下文章