专栏首页Forrest随想录从0到1:蘑菇街运维技术管理体系建设分享(上)

从0到1:蘑菇街运维技术管理体系建设分享(上)

大家下午好!我叫赵成,来自蘑菇街。今天给大家分享的题目是从0到1,蘑菇街运维技术管理体系建设分享。正式开始分享之前,首先作一个简单的自我介绍和公司介绍。我叫赵成,花名谦益。2008—2015在华为技术有限公司,高级软件工程师。2015年加入蘑菇街,很有幸,进入蘑菇街后,经历了公司业务高速发展的这样一个阶段,在技术上,我们技术团队也经历了自创建以来非常关键的一个演进过程。同时,也是运维团从小到大的发展起来,运维体系架构也从无到有建设起来的的一个过程。这样的经历对于我和我的团队都是非常宝贵的,今天也是想把这样一个过程在这里分享给大家。

下面是蘑菇街发展的过程,不详细描述,大家可以自己看一下:

今天的分享,主要分以下几个部分,第一部分是蘑菇街技术架构和运维体系演进历程,以及这当中我们遇到的困难和挑战。第二个是跨越篱笆,我们的运维解决方案。第三部分是运维技术管理分享。

下面进入到第一部分蘑菇街技术架构和运维体系演进。早期2011年,整个产品形态以导购方式上线,当时用户量和业务不大,也没有很大地并发量。当时我们整个的技术架构选择了业界最常见的LNMP结构,通过PHP快速开发,放到Linux服务器上快速让业务运行起来。当时也没有专职的运维的团队,整个开发的同学就专职去做运维工作。

2013年我们转型做电商,这是我们的技术架构,可以看到,整个技术架构也没有发生太大地变化,还是以LNMP架构为主。如果有同学经过业务从小到大的快速发展的过程的,可能会有相似的经历,在这个过程中,最容易出现瓶颈和问题的是DB的连接、缓存的连接等这种连接数的资源,蘑菇街在这个阶段也遇到的同样的问题,所以架构上的调整,主要是DB中间层和缓存中间层的增加为主,但整体上还是LNMP。

随着业务发展,业务也开始变得丰富和复杂起来,也就说随着业务的发展,带来的不仅仅是用户量、业务量这种体量上的增长,业务自身丰富的程度和复杂度也在发生着非常大地变化。对技术上带来的挑战和问题,我们直接看图:

可以看到PHP的工程变得异常的臃肿,因为有太多的业务需求需要开发,有太多的开发人员在同时开发。短期内PHP的代码工程就成了这个样子。

这里首先说下PHP的优势,我们一开始是选型用PHP作为主力开发语言,因为PHP上手非常快,入门门槛相对低一些,一个新手从学习到开发生产系统的代码的周期是很短的,同时,PHP部署发布的效率也相对简单,PHP文件发到线上即可运行,不用复杂的编译、打包和启停动作,在业务前期发展阶段,PHP效率上的优势就表现的很明显。

但是,刚才我们看到的图,随着业务的发展,业务类型越来越多,开发的同学也越来越多,大家都往一个工程里面去写代码,势必导致PHP的工程越来越大,越来越臃肿,给后续的代码维护带来了很高的复杂性。

举个例子,对于一个开发的同学来说,如果他要做的功能和需求涉及到其他人的开发的PHP文件,本来这个功能和需求在原有的程序上改就行了,但是因为工程太大了,这位同学可能是没有办法评估清楚说改了这一个文件,对其他的文件、接口和方法会造成什么样的影响,即使能够评估清楚,他也很难保证在测试的时候把这些所有的点都能够测试到,根本没这么大的精力。所以就导致很多开发同学会不断的Control C+V,就是宁可是把需要改的文件Copy一份出来,然后在Copy出来的文件上面做开发,原来的功能不动,这样就保证了新需求可以不影响老公能,但是这个状况就会导致进一步加大了PHP工程的臃肿,实际上是一个恶性循环。再就是,如果碰到非改不可的PHP底层的文件和代码,如果评估不到位,就是导致出现各种各样的线上故障。所以,到了这个阶段,PHP代码就很难维护了,反而影响到了需求和版本的迭代速度。

这种情况下我们应该怎样办呢?我们选择业界比较通用的方案-Java服务化,把大的工程拆分成一个个小的应用,通过服务化框架提供RPC的调用。这个阶段,我们从PHP转向JAVA,从单一工程转向了分布式服务架构。

经过拆分后,整个架构就变成了现在的这个样子。这样看下来整个架构分了很多层,也有很多的细节,乍看上去是比刚才的架构图要复杂一些。但是这样的架构根据条理性,也会让架构里面很多的技术细节都曝露出来,更加便于管理。相对那刚才非常庞大和臃肿的PHP工程,内部的逻辑、方法和接口的依赖等等,是很难梳理清楚的。

下面主要讲一下我们做了JAVA服务化的技术转型后,对运维带来的挑战是什么,我觉得总结下来两个:

下面就进入到第二部分,跨越篱笆,我们的运维解决方案。分两个阶段,一个是从0到1,运维做了哪些基础的工作,然后把基础工作做好以后,我们从1到100,可以做哪些更有价值的事情。

整个的运维从0到1,从0开始我到底应该怎样做,我觉得一定一定要从标准化开始,并围绕标准化展开。

关于标准化,可能大家在各种社区和社群的分享里听到或看到过,不管是做运维平台也好,还是运维体系也好,或者运维系统也好,第一件事要做的一定是做标准化。所以关于为什么要做标准化我不再讲,大家多看看社区里的分享就可以了。我直接说我这边做的具体动作,后面我会在案例里面把标准化的重要性把它提炼出来。

标准化我们主要做了三方面的工作,一个是基础软件及基础设施的标准,主要是操作系统的版本必须统一,内核参数统一,基础设施上,我们用KVM虚拟化技术将我们的资源做成2C2G、8C16G这样的资源模板,确保资源配置的统一。二是应用及配置标准化,这个后面细讲。第三部分是技术架构标准化,技术架构这块分接入层、中间件技术、缓存、DB等,关于技术架构标准化这块,可能是在其他的分享里面可能见得不是很多,这块我后面还是通过案例把基础架构为什么做标准化,它的重要性和它的意义在案例中体现一下。

举个例子:

我们在做整个运维平台之前,或者是做整个运维体系之前,我们首先将整个系统梳理一下,然后看一下整个系统里面到底有哪些基础环节和软件,应用的话到底有哪些应用类型。我们把这些东西一条一条地记下来,然后归纳总结,慢慢的就形成了左边的集团标准化,包括应用管理的标准化。基础服务的标准化,安全的标准化,稳定性的标准化,我们全部都制定清楚形成文档。

然后右边是应用部署标准,这是整个大纲里面的分册,我们把应用这边的部署目录,它应用到的版本,它的参数以及它起停的脚本、命令,这个东西我们统统定义下来。比如下面这个例子,这是针对JAVA应用的版本,容器的目录哪些,应用的目录、脚本的目录、代码的目录、应用日志的目录等统统固化下来。

我们把标准化的动作做完以后,如果只是纸面上的,那它的威力是没有显现出来的,如果仅仅是以写脚本的方式去管理它,实际上还是有点笨拙,所以我们再往后就做了这样一个应用配置系统,目的就是把我们做的标准化沉淀在我们的技术平台上面,可管理,可提供服务。刚才大家看到的样例就是我针对Java的标准,它的目录,起停的脚本等,我们通过一个应用模板固化下来,比如实际应用过程中,典型的Java应用,是Nginx+Tomcat的运行方式,那在应用配置管理中,就会有应用模板、基础软件和应用配置文件管理几个模块来管理,具体样例如下:

刚才讲的这部分,是针对标准化,最后把它沉淀为标准的应用模板。那下面如果要去创建应用,应该怎么去匹配这个模板。首先讲一下关于应用,我们把一个Java这样一个庞大的应用拆分成几十、上百个应用以后,要将应用管理起来,首先要有应用名的定义,定义有相对准确地表达软件包或者是应用的含义就好了。

创建了这样一个应用后,选择下面模板类型,然后基于这个应用模板的起停的先命令、标准的目录就在这个应用生成了。

关于应用还有一个很核心的关联关系,就是应用-资源的关联关系,从资源管理的角度就是应用名-IP的关联关系,这个就是通过CMDB来管理了,所以我们的CMDB做的就相对轻量一些。

最后,这两个关键的基础设施建设完成之后,就有了如下的架构图:

本文分享自微信公众号 - Forrest随想录(forrest_thinking),作者:赵成

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2016-11-04

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

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 谈谈架构标准化的问题(跟运维有关系?)

    接上篇《运维架构是全站技术架构中不可分割的一部分》,文中提到一个问题,运维架构和技术架构的脱节这个问题到底出在哪了?到底谁应该承担这个责任?

    赵成
  • 未来到底还需不需要运维?

    早上第一个观点碰撞,是因为晓征总看到我专栏图书上写的:“软件架构的目的是将构建和维护的成本降到最低,以及软件架构的大部分工作都是为后续运维服务”的观点,感觉形成...

    赵成
  • 标准化,对象建模的过程

    今天我专门来讲讲标准化这个工作。可以说这项工作是运维过程中最基础、最重要的,但也是最容易被忽视的一个环节。

    赵成
  • 那些年我们刷的运维日常

    那些年我们刷的运维日常 运维不易,且行且珍惜! 那些年,我们不仅维护了服务器。还锻炼了一副好身体(码代码的肯定打不过抗服务器的啦哈哈哈) ? ? ? ? ? ?...

    小小科
  • 从图灵机、图灵测试到人工智能:什么决定了AI能否取代人类?

    导读:美国电视剧《西部世界》第二季的第一集一经播出就引起热议。一时间,人和人工智能这个话题又重新被辩论。由于程序功能越来越强大,人们开始担心:“人工智能程序会不...

    华章科技
  • 快速学习-Kylin入门

    在Hive中创建数据,分别创建部门和员工外部表,并向表中导入数据。 (1)原始数据

    cwl_java
  • 面向数据架构的云演变

    现代数据架构的概念在过去的10多年里发生了巨大的变化,具体可以参见公众号“补天遗石”的《从数据仓库到数据湖——浅谈数据架构演进》一文。

    半吊子全栈工匠
  • GeoHash原理和可视化显示

    最近在做附近定位功能的产品,geohash是一个非常不错的实现方式。查询资料,发现阿里的这篇文章讲解的很好。但文中并没有给出geohash显示的工具。无奈,也没...

    Ryan-Miao
  • python3下常用编解码与加解密

    Python3相对于Python2的一大改变就是,对默认字符类型进行了修改。Python2中定义字符串默认为二进制字符串,强制加前缀u的才是unicode字符串...

    上帝De助手
  • 深入机器学习系列之:4-KMeans

    本文会介绍一般的k-means算法、k-means++算法以及基于k-means++算法的k-means||算法。在spark ml,已经实现了k-means算...

    数据猿

扫码关注云+社区

领取腾讯云代金券