阿里技术人的第一节课,都上些什么?


  • 来源:阿里技术
  • 时间:2018-09-27
  • 分类:工具技术

    从源码到上线  事情可不简单

    什么叫程序?或者说,什么叫软件?这里面好像有歧义。有时候指的是源代码,有时候指的是安装包或者安装光盘,比如“我下载了一个软件” 。有时指的是已经安装好随时可以运行的程序,比如“手机上新装了一个应用” 。还有的时候指的是正在运行中的,正在提供服务的程序,比如一个网站。

    这些不同的含义反映了一件事:单纯的源代码,还不能提供服务,不能为用户带来价值。只有源代码被构建打包,并且被部署运行起来,才能为用户带来价值。

    那么,如何才能部署运行起来,为用户提供服务呢?这很麻烦吗?——是的,这很麻烦。

    想象一下,如果你是一个初创企业的CTO。天上忽然掉馅儿饼,掉下来五个Git库,源代码已经写好,而且一点儿毛病都没有。每个Git库能编译成一个war包。你需要把每个war包部署到100台服务器上,总共需要500台服务器。另外,随着用户的使用,会不断追加新功能,产生新版本,需要更新服务器上的软件版本。

    假定你不是在阿里巴巴,假定也没有阿里云,假定你只是有很多钱可以雇到合适的人,你想想一共有多少事情要做?

    先要买或者租机房,再买服务器,风火水电都要搞稳妥。更要接好网络,每台机器要装好操作系统的合适版本。不止是操作系统,还有相关基础软件、路由、数据库、监控系统、日志收集系统以及中间件等都是必须的。哦,域名还忘了申请了……

    这些搞定之后,才能安装那些war包。这么多台,肯定不能一台一台操作,累死了,得有个批量操作的方法。可这方法怎么弄呢?另外,考虑到将来要更新软件版本,所以这还不是一次能搞定的事情,那更是得批量操作了。更新版本的时候,还有个麻烦事,不能一下子都停机啊,那不就要出事故了。所以得分批来。比如,先更新20%的机器,再更新20%,如此一共五批弄完。

    往细节看,其中更新某一台机器,其实都是个挺复杂的过程。首先下载新的war包到这台机器,然后开始替换过程。先得把流量切走,切流量前,还得先把监控报警关上。流量切走了,就可以停止当前war包的运行。然后用新的war包代替旧的war包,启动试试看。如果通过了一些基本的自动检测,说明新war包大体上能运行,于是就开始切流量回来,最后把监控报警恢复。

    忒麻烦!!

    还好有工具帮忙

    怎么办?——用趁手的工具啊!正是为了提高大家的工作效率,让大家能够集中精力在具体业务本身的研发上,阿里巴巴集团多年以来建设了一整套基础设施。

    在交付层和运维层,都有大量的基础设施。但这些,大家可能感受不深。对于一个应用来讲,它最关心的事情,基本都是通过Aone暴露出来的。Aone也就是最上层研发层的主要工具。

    注:本文提及的阿里内部产品叫Aone,Aone于2017年正式对外开放,更名为云效。

    回到前面讨论的场景,把完美的源代码发布上线这个过程,那么大体步骤应该是:

    第一步,把运行环境初始化好。这一步目前同学们基本可以在Aone上一站式完成了,就是在Aone上注册一个新应用,然后根据向导指引,把上线任务一项一项配下来。当然还有些内容比如数据库还需要访问其他系统申请配置,将来我们努力做成一站式配置好。

    第二步,根据源码构建出压缩包(基本就是把war包压缩一下),然后把压缩包部署到各目标服务器上。这一步,可以在Aone上一键完成。将来更新版本也一样。点一下按钮,所有事情都做完。这就是用Aone的好处。

    阿里巴巴相关术语

    为了使用Aone,我们得了解一些Aone的关键概念。其实是在阿里巴巴开发时,大家一开始约定俗成的概念,后来固化在Aone上。我们一个一个来看:

    应用:Git库里装的是源代码,这是程序的一种形态。那么运行中的程序叫什么呢?在阿里巴巴,我们管它叫“应用”。一般来说,一个Git库,构建生成一个包,产生一个应用,在若干台服务器/虚拟机/容器中运行,在测试、线上环境中运行。一般应用跟Git库是一比一的关系,不过也有各种特殊情况,比如一个Git库里有多个应用。所以,我们确实需要应用这个概念。另外,应用不仅包括了应用主包(通常是war包打成tgz包),也包括了运行所需环境的配置,比如tomcat版本等。

    二方包:三方包,指的是来自阿里巴巴外部的,开源或商业的包,比如jar包、rpm包等。而二方包,则是指来自阿里巴巴内部的,通常是其他团队的包。也就是说,一个团队研发出这个二方包,公布出来,供各团队使用。当然,也可能就是供团队自己使用。反正,只要是来自阿里内部的,上传到Nexus或Yum这样的包的仓库的,就都算二方包。

    产品/产品线/产品树:应用是从部署运维的角度看运行中的程序。产品是从使用者的角度看运行中的程序。通常产品由一到多个应用组成。产品进而构成产品线,这样一级一级地上去,形成了一棵树,叫产品树。产品树的根节点,就是阿里巴巴。产品树的第一级展开,是各个BU。

    变更:在外面的世界,现在变更通常是指线上运行环境的变化,比如更新了软件版本,比如扩容、缩容等运维操作。在阿里巴巴,变更也有这个含义。但是在阿里巴巴,变更还有一个含义,软件研发过程中的含义。通常我们把一条feature分支就对应到一个变更。于是也常管这条feature分支叫变更分支。从这个角度看集成,就是把若干变更攒到一起,通过各种质量检测后,部署上线。

    发布:发布,release,这个词常常是指软件版本公布出来供使用。但在阿里巴巴,这个词不仅对应于部署到线上环境,即使是部署到测试环境,也叫发布。换句话说,发布基本上就是部署的代名词。比如每个变更觉得自己OK了,就点一下变更详情页面上的“提交待发布”这个钮,标记一下。然后,在集成测试环境(也就是日常环境)对应的流程阶段的详情页面,就能看见这个变更。再选中它,然后点击“提交发布”这个钮,就与其他变更分支一起合并到发布分支,并部署到测试环境啦。

    技术发展趋势

    发布部署方面,在阿里巴巴,时下最重要的变革当然是Docker化。

    那么这一波浪潮之后,下一波浪潮会是什么呢?有可能是Serverless架构。这方面的文章也很多,大家可以翻翻看。

    提高质量的多种方法

    刚才我们给的是一个天上掉馅儿饼的例子,忽然间得到了完美的源代码,然后考虑构建并部署上线。现实世界中哪儿有这样的好事儿啊。代码里面肯定有bug。那么,怎么能够有效率地把问题找出来,继而修复好?具体有哪些方法?

    按四个象限梳理

    为方便梳理,我们划一个横轴,一个纵轴,然后按照得到的四个象限,梳理各种质量保证方法。这里所说的横轴,在最左边,是源代码。在最右边,是运行中的程序。这里所说的纵轴,在最上边,是自动化,在最下边,是人工。

    先看左半部分。左下角,人工的对源代码的检测。这主要对应的是代码评审。我们在代码服务这门课上介绍的。此外,安全评审有时也有人工介入。

    左上角,自动对源代码的检测。代码规约的自动检查工具,就落在这里。事实上,还有不少工具也落在这里,论品牌,有Sonar、PMD等。论方法,有圈复杂度等。所有这些自动检测,被称之为Staticprogram analysis 或 Static code analysis,静态程序分析/静态代码分析。

    这方面,在阿里巴巴有工具支持,对应的是Aone的实验室这个功能。可以通过实验室,接入各种静态程序分析工具和方法。实验室的前身是CISE。现在CISE也仍然是实验室背后的引擎。所以有时候听别人说CISE的时候,你就知道其实指的就是实验室啦。

    再来看右半部分。右上角,是自动的对运行中的程序的检测。这也就是常说的自动测试啦。在阿里巴巴,也是主要由Aone的实验室来向大家提供相应服务。这包括单元测试/集成测试;接口测试/Web UI测试;功能测试/性能测试,等等。

    右下角,是人工测试。虽说是人工测试,工具也同样可以提供支持,主要是管理测试用例。相应的工具是Aone中的测试用例管理。

    测试环境隔离技术

    不论是自动测试还是人工测试,只要是需要先把应用部署到测试环境,那就跟测试环境的管理有关系了。测试环境的管理,我们专门讲一讲测试环境隔离技术。

    想象一下,你开发了一个feature,也就是一个变更。为了让它比较靠谱再送去集成,你需要对它进行测试。单元测试当然好,但这是不够的。需要尽可能模拟真实环境进行测试。那么问题来了,如何尽可能模拟真实环境?比如,为每个淘系的工程师另搭一个淘宝测试用?这费用咱真花不起……

    怎么解决这个问题?阿里巴巴用了一个聪明的方法,测试环境隔离。让大家共享一个测试环境,但又仿佛每个人都是独占它的,互相不干扰。

    具体说来,假定搭起一套测试环境,需要1000台机器,分别运行应用ABCDE……。这个环境我们称作日常测试环境。每个应用的版本,我们姑且称之为A0、B0、C0、D0、E0……

    现在假定甲这名同学在开发A这个应用的一个变更,在开发过程中,现在产生的应用版本是A1。于是把A1部署到单独一台机器上,并用一些神奇的技术(通过中间件等)与刚才说的日常测试环境连通。于是,在甲这名同学看来,他所面对的系统是A1、B0、C0、D0、E0…… 而且仿佛他独占了这个系统。

    类似地,如果乙这名同学为了一个feature,在开发A和B分别拉出变更分支,产生A2、B2。那么A2、B2将分别被部署到单独的机器上,然后它们一起与日常测试环境连通。于是,在乙这名同学看来,他所面对的系统是A2、B2、C0、D0、E0…… 从乙的角度看,他仿佛独占了整个测试系统。甲和乙在测试时,不会互相干扰。

    有了这样的解决方案,就同时达到了两个目标:尽量模拟真实的环境;用不高的代价。

    关于测试环境隔离技术,这里只是简单介绍下原理。

    阿里巴巴相关术语

    项目环境:就是前面说的,测试一个feature所需的测试环境。可能对应一个应用上的一个变更,也有可能对应多个应用。项目环境使用了上面讲的测试环境隔离技术,背后接的一整套测试环境,是日常环境。

    日常环境:就是集成测试环境。把各个变更攒在一起,然后部署到这里,看是不是能work。

    预发环境:这个环境比日常环境更接近真实环境。事实上,从网络隔离的角度,它不是在测试网,而是在生产网。它所连接的数据库,也通常就是线上运行使用的数据库。一般来说,是先在日常环境测试,通过了再到预发环境测一下。

    正式环境:正式环境就是生产运行的真实环境,向广大用户提供服务。

    流水线

    所谓流水线,通俗地讲就是把不同的工作按一定顺序串起来。为什么要串起来呢?

    首先,有些工作天生就是有先后顺序的。如果想部署,总得先构建吧。所以构建-部署,就是天然的工作顺序。如果每次都是先点个按钮做构建,等构建结束后再点个按钮做部署,好像有点儿笨,不如点一个按钮,把这两件事按顺序都做了。

    其次,为保证质量,我们想往流程里面加规则和卡点。比如,必须通过代码评审和安全评审,才允许合并代码。这些质量保证性的工作,还有可能有不同的顺序和频率。典型的单元测试和静态程序分析应该早做,频繁地做。而整个链路的测试,比较费劲,频率可以相对低些。因此,这些工作也是流水线中的环节,并且可能以不同频率执行。不同频率这个事儿,就是持续交付这个流行词儿中所说的不同stage(阶段)不同频率。

    Aone提供了把不同的工作串接的能力,也就是流水线的能力。在分支模式下,每个环境,比如日常、预发、正式,分别对应一条流水线。在Git Flow和自由模式下,你甚至可以把所有工作内容,从代码提交到最后正式发布,做到一个流水线里。看着代码过一道道“关口”,然后发布上线,还是很爽的。

    结语

    以上,概要地介绍了从源代码到上线的基本的构建部署过程,讲解了各种质量保证方法及其工具支持,讲解了流水线把流程作业连接起来自动运转。这些能力合在一起,就实现了对持续交付的一整套工具支持方案。当然,如果你问DevOps的工具支持方案,我也会说,以上几部分,构成了DevOps的工具支持方案…… 名字是次要的,关键是帮上广大研发同学的忙,高效且稳妥的开发和发布。

    这节课只是概要介绍。有需要的童鞋可以使用Aone的对外版本云效,体验一位阿里技术人工作的一天。


[上一篇] Facebook低调开发AI技术工具:自动扫描代码找漏洞

[下一篇] 你的客户去哪了?——大数据,如何改变信贷行业?