从开发到上线 实战持续交付 -李道兵

在产品的开发过程当中，对数据量要求较高的网站进行架构设计时如何部署是个很复杂的问题，涉及到多个层面的不一样要求，七牛首席架构师李道兵在部署工具和测试以及持续集成方面给出了本身的思考。在七牛的开发者实践日中与你们分享《从开发到上线 实战持续交付》。

李道兵首先从不一样的层面来分析目前的网站的架构的设计，从数据库、缓冲层的方面引出部署的概念。而后开始介绍部署工具的进化史，从最初的安装文档、FTP/SFTP、War包、系统安装包到一键部署工具，一直到最近兴起的docker，逐个分析了每种部署工具的优缺点。针对capistrano+puppet，进行了重点的讲解和说明。最后结合七牛的实例分析了如何从代码到上线的整个部署、测试、持续集成过程和其中可能会遇到的问题。下面是完整的现场记录：

此次想和你们分享的是从开发到上线，特别是咱们七牛在这方面关于一些持续交付的事情。在演讲以前我推荐两本书，一本是《精益创业》，更多讲的是从想法变成实现的。其实从想法变成一个代码，再到运营的阶段，经过运营阶段反馈修整你的想法，造成这样一个循环，达到用户的快速增加或者快速试错调整你的产品。我今天讲的是从想法到代码，从代码再到运营阶段。第二本书是《持续交付》发布可靠软件的系统方法，讲的是你须要作哪些事情，包括持续集成和一键部署，你们有兴趣的能够看一下。

咱们回到总体，简单的想法无论是作什么，如今大部分的形式要否则是APP，要否则是网站。咱们从网站开始讲，从前日后最前面是提供静态文件或者是分发动态请求。再后来是业务逻辑层，咱们尽可能作到无状态设计，它的好处是一天的量从一百万上升到一千万，你从十台变成一百台就能够了，这种伸缩不用改代码，只须要后面有多少个后端而已。一个用户来访问，确定要有相关业务逻辑，通常是用什么作呢？数据库，里面要注意两个事情，一个是容灾，一个是容错。容灾更多的是高可靠的架构处理你的需求，容错是作一些近期备份的工做。剩下的就是一个需求了，如今咱们对媒体的应用很是多，用户有音频、视频等等的需求。用户上传的时候，用一些小的软件或者更直接一点上公有云存储都有很好的解决方案。剩下一些不是可选的，可是建议尽早上的就是缓冲层，目的是让数据无压力。就是你怎么保证你的数据库的数据一致性，缓存也有使用的问题。好比说机器宕了，怎么解决一会儿就把数据库压跨的事情。做为一个开发人员，已经把你的想法变成了产品，接下来的问题是在一个反馈循环以后须要改代码，至关于这些东西从新上线。考虑到这些事情的时候，咱们又应该作哪些事情呢？

这个过程咱们称之为部署，这么多年咱们一直是这么作的。第一个是安装文档，好比wordpress，按照安装文档作这个事情，最大的问题是若是你要对它里面的东西作一些改动怎么作呢？要否则在线上修改，若是是大的改动的话，就须要从新安装一遍。至关于对你整个时间的消耗会很大，成本会高不少。第二个常见的是FTP/SFTP，好比PHP这种，其实上传了以后你的整个服务就直接可用了。这里面比较麻烦一点是适用面很窄，本地要作版本管理。若是不作版本管理的话，极可能原文件都找不到了，很是尴尬。第三个常见的是Java里面的一些war文件，是你把服务端有一个Java的文件，须要手动拷贝，多机状况下仍然要搭配一些合适部署系统作这个事情。第四个是系统安装包，比较累一点，可是对大规模部署压力很小。好比说你有几百台、上千台的机器，之前yahoo是这样部署的，不知道如今是否是。最大的麻烦是系统安装这一部分比较费时间。

最后一个是能够作到一键部署，配置文件比较简单案件，好比说现场有一些小错误，你能够五分钟以内把这个错误修复掉，不用等到漫长的部署流程。puppet和salt能够用来解决配置问题。在这样的状况下，基本上就把这个东西解决了。如今有一些比较新兴的部署方面的技术方向是docker，如今有必定程度上能够取代一些虚拟机的东西，也可能成为一种新的软件分发方式。可是如今来说，在咱们看来有一些地方不太成熟，有一些严重的错误绕不过去，咱们正在作研究，可是尚未完成采用。

咱们多介绍一点capistrano，右边是整个部署的目录图，下面分三个子目录，一个是软件机，再一个是目录的部署结构。再下来是一个共享的东西，好比说配置是共享的，每次部署的时候用的是同一份配置。好比说你的一些文件都是共享的，在它部署的过程当中，一键部署具体怎么作呢？第一个步骤很简单，下载新的代码到releases目录，里面就有五个了，在当前的时间造成新的目录名，再把对应的一些代码拷贝过去。第二步是把全部的配置文件、日志目录所有连接过去。第三步是连接到最新的目录里，第四步是重启程序，至关于程序里面的定义目录都以这个为主的，你整个的程序就一会儿到了新版本。你这边实际上是一键作了四件事情，很是简单。第一个切换capistrano连接到上一个版本，测试之后立刻能够回滚了，很是有用。

这种方法有一个小问题，你的机器在线上的代码修改能很好的解决，若是你的系统盘毁掉了就有一个问题，你须要重装系统。重装系统须要多少时间呢？有可能记得以前你安装完系统的时候，你打了哪些补丁、调了那些配置？配置了哪些目录和日志滚动？可是你有没有作文档化，若是作了的话，顺着文档重装一遍须要多久？若是说这段时间内作的很差，服务就下线了，作的好也许就是在一个阶段里面。你须要多久可以恢复服务，这是面临很麻烦的问题。第二个问题是业务的大量增加，你须要把你得有些服务器扩容，好比说一台扩展到十台，十台扩展到一百台。扩展带来两个问题，第一个问题是怎么把这个事情作的很是快，不用浪费不少人力。第二件事情是怎么把事情作的很对，其实扩容的机器当中有很微妙的差别，好比说原来的机器上面已经调过了，可是这个没有。怎么经过一些方法把事故消除掉？若是有这些方法你们会很高兴。新来的机器是否是监控配齐了？原来的机器一步一步积攒过了监控，可是新机器有没有呢？是咱们关心的问题。

puppet/salt这两套系统是来帮助你解决这个问题的，首先第一个全部的配置入库，你的全部机器上无论是要预装哪些软件或者怎么样，均可以在版本库里看到信息。第二个是胸模板简化配置，十台或者一百台不须要把全部文件拷贝，只须要指定一下就能够了，对应的哪些功能有哪些天然就知道了。并且也不用一台一台的应用这个配置，并且会按期作一些安全更新，或者其余的一些配置调整的东西，哪些须要重启，它能够引入一些依赖或者消息，经过这些指令使你不用想配置哪些配置了，相似的也会有一些其余的需求，这些需求均可以经过它来知足。

对于咱们来说cap+puppet的问题是咱们要考虑的，咱们回滚的时候只能回滚程序，若是程序和配置偶合的很紧的时候，新版本程序须要一个新配置，你能够用编程来解决，这样程序员就有很大负担了。第三个有中心架构，可是优化的不够好。当数量达到一千台往上的水平，它有一点支撑不住了，这是咱们另外从新开发的理由。咱们作云存储对数据安全很是关心，咱们去线上裁判数据。开发人有很强的需求了解你的日志，你线上的一些状况。好比说网络流量，一些链接数等等都是咱们开发人员想去了解的。这样的状况下，你就须要不少的脚本帮助你的开发人员了解这些状况，这些也是以前不够用的，须要咱们另外开发一套新的部署系统的理由。这个新的系统咱们如今已经逐步在采用了，也许未来有机会能够对外发布一下。

前面讲了从代码到上线的整个流程，尽管回滚很方便，可是你确定不但愿把错误的版本放上去。更况且有时候回滚并不能解决问题，由于有的错误已经发生了。好比说转帐转错了，钱损失了，也挽回不了。你要保证代码的质量就是要测试，咱们推崇的是自动测试和持续集成。首先来说你的开发人员要写你的单元测试和一些集成测试。第二个是你每次作一些合并请求的时候，全部单元测试和集成测试都会跑一遍，保证你全部的提交不会干扰你原有的业务逻辑。负责这个代码的人员会特别注意，针对你写的新功能或者错误修复是否补充了测试？若是没有补充，直接就被拒绝了。最后发布的时候咱们会有一个更加好的测试，咱们这个软件能够决定跑一个大规模的测试，来决定咱们这个是否是最好的版本。可是一些代码质量的可视化工做是它作不了的，好比说单元测试的总数量是否随着时间缓慢上升，你的测试覆盖率是否稳定在可接受的水平，这些都是很方便量化的。量化的可视化可以帮助主管或者其余人也好，很方便的知道这个团队或者说代码质量是否有裂化的问题，也方便你们介入。

从头串一下工具链，咱们怎么作一个小事情的呢？第一个是提交issue，全部的工做跟它关联起来。第二个是修改代码提交你的PR(Pull Request)，若是持续集成经过了，这个PR就合并掉了。持续集成经过，经过以后进行部署，部署上线以后再次检验issue，而后就能够关闭了。咱们把这个流程作的个很短，十几二十分钟就会完成，使得咱们的试错周期更短一些。这里面有一些咱们的经验教训，第一个是所谓的正规化。

正规化是几个点，第一个是全部的原码须要入库，特别是第三方软件，你早晚有一天对它修改。你尽早把它入库，针对入库的代码作一份发布系统的话，即便是第三方软件也归入到部署流程里面来，这对你之后是一个好事。第二个是你线上的配置永远不要入代码库，由于涉及一些隐私，特别是安全问题。若是说开发人员拿到线上数据库密码的话，咱们认为是一个风险。第三个是你线上的配置要入库，不是入代码，是入一个部署库。最关键的密码和私钥的部分不要作到库里面，好比说你把模板配置作到里面，让咱们的整个过程很安全。整个程序也不须要上级领导盖章和批准，所有能够自动化，又比较安全

刚才提到从测试到上线流程，有一个咱们提的是测试环境。集成测试能够避免一些问题，可是仍然不放心。或者说咱们真的是对它不放心，咱们就搭一个测试环境。好比说你能够有测试环境和线上环境乃至更多的环境，首先部署到测试环境，经过手动检验完成以后再决定是否在线上部署。测试环境作到，两点一个是跟你的线上系统不要有任何关联，无论是数据库仍是怎么样的。大家之间不要共享一些共同的密钥之类的东西，这样会致使权限问题，若是别人拿到你测试系统的帐号，有可能在线上系统能够用的话，这种状况下是一个安全流动，这个就是须要注意的事情。

咱们另外作的是小入口，测试环境和线上环境不同。因而特别小型的东西，如今小作一个部署，而后才大规模的放量作一些部署，挺好的。第二个是你在小入口上面，个人整个请求量和访问量很是小。很是小的时候，不少线上测试工具就能够用了。若是你有一个小入口，无论是经过什么操做作的请求，均可以达到相似的效果。在这两个状况下，都是很好的，不只是测试手段，也是一个部署的手段。看上去也很简单，像一个一个的日志。

咱们有一个遗留问题，第一个是Go语言的问题，是一个编译性语言，咱们不但愿它到服务器去作，由于对咱们服务器扰动很大，咱们经过可执行程序作分发。第二个问题是可执行程序分发的时候，内网达到必定程度的话，会使你的服务器扛不住。咱们本身是作存储、分发的，最简单的方法是文件加一步推送到内网的分发节点，这样就能够支撑你内网上千台服务器。第三个是不少依赖外网的东西，咱们不少机器是彻底跟外网不能链接的。不只外网访问不了它，它也访问不了外网。好比说像安全中心，或者说安装部署的配置脚本，就须要它去外网作一些东西，咱们能够作一些图片包安装的，剩下的问题咱们能够经过它绕过来。
谢谢！

该分享来自七牛首席架构师李道兵在这次的沙龙活动中带来了题为《从开发到上线 实战持续交付》的分享。

顺便通知一下你们：开发者最佳实践日·第7期－互联网产品从设计到上线 上海站将于12月13日在上海创业者公共实训基地5号楼1层，EFG一楼举行，欢迎Segmentfault社区的各路猿们来相聚！
报名地址：
http://qiniu-7.eventdove.com

「开发者最佳实践日」是由七牛云存储发起并联合各方小伙伴为开发者举办的系列技术沙龙，关注开发者在实际应用中可能遇到的技术问题。致力于为敢于创新的开发者们提供行业内最前沿最热门的技术干货，以技术驱动应用创新，让更多的开发者享受技术带来的生活乐趣。