图片来源网络
在前面一章，我们已经在本地支配好LNMP开拓环境，并且也完成了我们第一个小网站的开拓。这一章，我们将会进行激动民气的操作——向天下发布我们的代码。我们先来看下为了完成正常发布须要做哪些事情，然落后修完全的生产环境有哪些把稳事变，末了我将分享哪些糟糕的实践会阻碍我们追求完美的项目。
3.1 从零到一搭建发布系统
互联网大型公司是如何做到每天发布成千上万次却依然保持井井有条的？创业团队又该如何实现敏捷发布进行稳定持续的交付？小团队项目时又该如何发布？更主要的是，针对不同规模的团队和项目，分别如何搭建相应的发布流程；又应若何实现平滑切换，不断演进发布系统？对付这些问题，我们将会在这一节探索它的解空间。
在开始连续往下阅读之前，读者不妨想一下，当前所在的公司是如何发布的？并且思考一下，它的全体发布流程是如何实现的，存在哪些问题，它的上风与特点是什么，是否与当前的发展吻合？
3.1.1 不推举的发布办法
俗话说：幸福的人都是一样的，不幸的人各有各的不幸。同样地，精良的发布都是一样的，糟糕的发布各有各的不同。
但对付一些糟糕的发布，有些人却持有不同的见地，由于他们正在利用它而不以为有什么问题，并且他们已经通过这样发布办法事情了好多年。“存在即合理”，他们这样想，哪怕是糟糕的发布办法，既然它已经存在了那么多年，就自然有它存在的道理。我为什么还要做出改变呢？
这样想是无可厚非的，由于他们已经形成了一种发布文化，在他们的公司内形成了一种局部社会认同感。公司其他团队，团队内其他成员都是这样做的，那么他们也会这样做，甚至不会显得突兀、不合群。持有精良发布实践的人很难明得为什么还有那么多人乐意忍受这些糟糕的发布办法，另一方面，“沉醉”于糟糕发布办法的人也难以明白如何切换到精良发布，乃至为什么要做出改变。
我们先来看下常见糟糕的发布办法有哪些。这些糟糕的做法虽然有一定的代价，但综合考虑权衡的话，是弊大于利的。特殊从长期角度考虑，从顺应不愿定未来和知足多变市场的角度来看，更是如此。
随时发布
对付年轻的软件开拓领域，很多方面都还没形成公认的行业标准和规范，个中发布流程更是如此。每个公司都有自己的发布办法，每个技能职员又有自己不同的做法。而公司的发布流程在很大程度上决定于最初卖力发布职员的实现办法，不同技能职员由于背景不同，经历的项目履历不同，其做法各有千秋。但最糟糕的莫过于，这位卖力最初发布的同学，恰好又是之前从未打仗过正式商业项目发布的，这时他很可能就会方向于一种随意的发布意识。也便是我们接下来要谈到的——随时发布。
随时发布，可以说是一种不负任务的发布办法。它完备不考虑版本的观点，也没有所谓的迭代周期，对付线上生产系统的稳定性、健壮性以及项目的质量都置于九宵云外而不顾。
不管什么时候，开拓职员代码一完成后，就同步更新莅临盆环境。这非常随意马虎造成有问题就改，有故障就查的局势，从而使得技能开拓职员疲于奔命，四处“救火”。把稳，这里所说的完成，只是技能开拓职员的“一厢宁愿”，从他们自己的技能开拓角度认为是完成了业务功能需求的开拓，而没有经由测试团队的功能测试和回归测试，更别说通过测试了。而且这里须要特殊阐明的是，对付这时的完成，大部分开拓职员（尤其是绝大部分的低级开拓职员）更多的定义是他们只完成了快乐路径的功能开拓和自测，而对付失落败路径、非常路径、边缘路径、全体业务流程则没有考虑进内，也没对应的代码实现。
举个例子，我们现在有一个共享平台系统，在上面人们可以通过共享的办法向平台通过极低的用度租到价格高昂的商品，例如只须要100元就能租用代价5000元的单反数码相机并利用一周，但须要额外支付一定的押金。统统都运行良好，我们的网站受到了广大消费者的喜好，知足了人们短期内对高端消费品的诉求。随着项目的发展壮大，现在须要接入一家新的第三方支付系统，并且对方许可给消费者一定的支付折扣。卖力这块的技能开拓职员很快就完成了功能的开拓并发布上线，统统看起来很顺利。但过一段韶光后，我们创造出问题了。这是由于用户的押金须要退还，而当第三方支付系统识别到用户有退费时，不仅会原路还回，还会把之前的折扣也回收！
终极导致了消费者在享受支付折扣后，拿到归还的押金却少了！
由于技能开拓职员只考虑到支付这条快乐路径，而没考虑到押金退还这一点，使得公司在面临浩瀚用户投诉的同时，也增加了应对这一故障的处理本钱。
随时发布这种办法好吗？
大概好，由于需求方可以“很快”就看到他们的需求上线了，技能开拓职员可以“很快”就看到他们的代码在生产环境运行了。但是！
以此随时发布、快速上线换来的代价是，发布莅临盆环境的代码都是薄弱的，未经全面测试，兼容性极差的代码。如果说随时发布在竞争激烈、节奏飞快确当下，相称于在高速公路上换轮胎，那么很随意马虎让我们无法慢下来思考如何做到更好、更出色。说到底，我们随时发布的不是优质的代码，取而代之的是不断往臃肿的系统再塞进一些熵，再堆积一些代码异味。逐步地，越今后，项目越臃肿，越失落控，越糟糕。
在软件开拓过程中，我们应该时刻意识到，对付同一件事情，不同的干事办法，所产生的直接影响、间接影响都是不同的。在只有一位技能开拓职员时，他可以完备根据自己的喜好和便利性来操作，但一旦形成了团队、涉及多方沟通以及项目发展到一定规模时，则须要一些约定，以担保可以创造一个随意马虎催生高效团队协作和沟通的环境。
对付随时发布，我个人以为是过于随意，短缺严谨性，以是我是不推举的。由随时发布而产生的间接负面影响，要远大于它的直接正面收成。看似非常快速的发布办法，实际上却让我们一直在原地打转。以是，我不推举初学者一开始就钟情并习气于这种发布办法，更不推抬高等资深开拓同学恪守这种发布办法。如果你当前已经是随时发布，请不要妥协。
通过FTP上传发布代码
比随时发布轻微好一点的是，在韶光上，在版本上有一定的方案，或者说有一定的发布频率、发布节奏或发布窗口。按照不成文的约定，常日在每周五是不会进行发布的。由于接下来便是周六、周日，如果一旦因新功能发布上线而涌现问题，须要找到技能职员、产品职员、测试职员等项目干系人及时相应和处理是非常困难的。除此之外，沟通本钱也会变得非常大，平时在事情韶光一起紧密沟通的团队，到了周末就分散在各个城区乃至各个城市，通过远程办法进行不太顺畅的沟通。
那其他事情日期间，该当以什么节奏来发布呢？是每天N次，还是每周M次？这个韶光节点可根据项目的情形详细而定。下面我们来看下另一个糟糕的发布办法。
时到今日，我们很遗憾地看到，仍旧有不少公司未利用版本掌握系统对项目源代码进行版本掌握。由此带来的间接影响是他们很多时候都是通过FTP办法上传待发布的项目代码，然后发布上线。不仅如此，那些纵然是利用了类似Git，SVN的团队，出于历史遗留缘故原由也在利用FTP办法更新线上环境的代码。
这种发布办法，最明显的问题，它是严重依赖人工来操作的。它须要人为地来选择须要更新哪些代码目录、哪些代码文件，重复性的人工操作，都蕴藏着一个妖怪——低效且随意马虎出错。此外，还有一个很大的问题是，短缺发布回滚机制。
我只在最初做项目时，而且还只是在大学期间从事校内网站项目开拓时才用过FTP办法上传发布代码。毕业事情后就再也没打仗过这种发布办法。以是现在当我听到还有公司利用FTP来发布代码，在惊异的同时觉得到了我们在软件开拓领域的薄弱。这种发布办法太业余了，在倡导快速交付确当下还会大大拖慢我们的发布节奏。
生产环境即开拓环境
随时发布缺少对发布韶光的统一掌握，通过FTP发布是缺少对发布办法实现自动化，但更为糟糕的是，还有一种发布办法是既忽略了发布韶光也忽略了发布办法，那便是开拓环境与生产环境共用，技能开拓职员直接在生产环境修正代码。生产环境即开拓环境，开拓环境即生产环境。
这种办法的危害是相称大的，由于它每每也没有对代码进行版本掌握。假设一欠妥心删除了某个源代码文件，就只能自求多福了。而且，代码一修正完，立时生效，这导致了开拓调试期间，线上环境的系统功能基本是完备不可用的。由于或多或少会涌现一些语法缺点、运行时非常导致系统非常中断和退出。而更深远的影响莫过于通过缺点的处理办法对数据进行了持久化，对系统产生了脏数据。
不得不承认，这种办法是有好处的。它节省了支配本钱，也降落了技能职员的哀求。由于不须要区分开发环境和生产环境，只须要支配一套环境就可以了，也不须要再去折腾Git或SVN这类的版本掌握系统。技能职员也可以不用学习那么多工具、系统和软件，直接在生产环境修正代码，直到调试完毕就可以了。但是，软件开拓是一门专业的工程学科，它须要全面、专业的技艺。如果什么都只图方便，不考量架构合理性，不研究干系技能和事理，那只是小白的表现。
软件开拓从来都不是一件随意马虎的事，如果你以为随意马虎，要么你是还没入门的小白，要么你已经是资深专家级人物。生产环境即开拓环境这种做法，虽然节省了发布这一环节，看似高效，实际风险巨大。除了前面说的短缺版本掌握，短缺系统稳定性外，它会催生一种野草式的开拓模式。迫于压力，为了让系统能快速规复、正常事情，技能职员都因此当前能想到的办法，以最快的速率进行开拓和修复，而不管这种做法是临时的、糟糕的、还是本身便是有问题的。这导致，很多功能性的开拓，很多技能决策都是临时性的、突发性的、未加全面考虑的。软件开拓有点类似建筑行业，须要提前方案蓝图，有操持地进行履行，而不是像路边的野草放而任之，随心而行。
我曾经也有过利用这种办法的项目开拓履历。当时有一个项目也是开拓环境与生产环境共用一套环境，技能职员平时在上面直接修正代码，改完后立马生效。当时我在生产环境上修正这个项目系统的代码时，也是如履薄冰，恐怕删错源代码文件。但越担心什么，就越会发生什么。有一次，我还真的删错文件了，Linux的rm命令及其背后的文化让我无从规复刚才删错的文件 。幸好，其余一个团队成员在本地刚好有备份，才得以规复，虚惊一场。其余比较有趣的是，一旦公司的老板须要对外演示此系统，或者有主要商业互助展览时，我们技能职员就要停滞对代码的修正，这时时时光接阻碍了技能开拓的进度。
3.1.2 大略的发布
接下来，我们将开始从零到一搭建发布系统，这是一种更为正式、更为正统的发布办法。可能在详细履行过程中，不同团队会有不同的详细做法，但在实现办法、关键流程和核心观点上是类似的。
对付大略的项目，以及低级的项目，我们可以进行大略的发布。这里，只须要三个关键的要素就可以了。它们分别是：
开拓环境 即本地开拓环境，可以参考前一章，搭建本地LNMP开拓环境，让技能开拓职员可以在本地安全地进行开拓、调试和自测。托管仓库 不管项目有多小，都应只管即便纳入源代码版本掌握系统，将项目的源代码托管到远程做事器仓库。即须要在远程做事器存有项目代码的最新代码，便于团队内部共享，也保障了个人电脑硬盘破坏后代码仍能幸存于世。生产环境 系统终极的运行环境，并开放给终极用户人群访问和利用。不丢脸出，大略的发布流程是，先在本地开拓环境进行代码的编写，然后更新提交到远程代码托管仓库，末了发布莅临盆环境。
图3-1 大略的发布流程
当技能职员在开拓环境完成需求开拓，进行充分测试后，便可将代码提交到远程代码托管仓库。这时，开拓环境常日都是位于个人开拓电脑上，并且在公司局域网内。托管仓库，可以是公司的内部做事器，也可以利用第三方云做事器。当全部待发布的功能点都经由功能测试和回归测试后，就可以实行发布操作，将最新版本的代码发布更新到外网生产环境。这里，在外网生产环境也是类似平时在开拓环境上更新代码一样，例如Git下的git pull命令，SVN下的更新操作。如果须要回滚，可以通过源代码掌握系统进行特定版本的回滚。
这种做法，在项目初期，对付大略的项目，对付单台做事器是适用的。若线上的做事器是多台，或者是一个集群，又若何才能担保代码在同一韶光进行更新，我们又该如何快速、便捷、统一掌握呢？下面我们来看下更为专业的发布办法。
3.1.3 实现一键发布
鉴于我们支配的系统环境是LNMP，故而可以利用一些基本的shell命令快速搭建一键发布，实现发布流程化、自动化。这些shell命令紧张有打包解压命令tar、远程文件传输命令scp、远程登录和操作命令ssh。
不过在实现一键发布前，我们须要进行一些约定，以便能更好地进行整体的把控。紧张有以下几个方面：统一LNMP环境的版本和配置、统一项目路径、统一系统账号。
统一LNMP环境的版本和配置
对付Linux、Nginx、MySQL和PHP，不管选择哪个版本，为生产环境的做事器集群安装同样版本的操作系统和软件是大有裨益的。由于我们可以实现无差异批量化的操作，方便统一管理。
假设选择的是PHP 7.2.3，那么就全部做事器都安装PHP 7.2.3，只管即便保持版本上的同等性。不要做事器A安装了PHP 7.2.3，而做事器B则安装PHP 7.1.15；也不要部分做事器运行的是PHP 7，而其余一部分做事器则运行PHP 5。由于不同版本下的软件，都会或多或少存在一些差异。这些差异表示在配置、语法、和安装办法、利用办法上。
除了安装相同版本的环境外，还要进行相同的配置。假设在PHP的配置文件/etc/php.ini内修正variables_order的配置项为EGPCS，如：
variables_order = "EGPCS"
那么就该当同步此配置到其他做事器，担保在其他做事器上通过PHP也能正常读取到环境变量$_ENV。此时，你可以选择类似puppet这样的自动化运维工具。
统一项目路径
上面是对LNMP环境的哀求，对付项目运行时的支配也应只管即便做到同等。详细包括项目源代码的支配路径、日志路径和操持任务等。
例如，我们前面的网站项目www.examples.com，假设源代码的支配路径为：/home/apps/projects/www.examples.com，那么其他做事器也应安装在这一目录下。如果项目的日志存放路径为：/var/logs/apps/projects/www.examples.com，那么其他做事器也要保持同等。
统一系统账号
细心的读者已经留神到，前面在Linux系统上我们紧张利用了apps这位用户来支配系统项目。由此不难推断，我们同样建议全部做事器都应利用apps账号来统一操作。此外，引申到启动Nginx和MySQL等，也该当为其分配相同的账号。由于不同的账号在Linux系统上有不同的权限。保持操作系统账号的同等性，可以担保权限的同等性，而不会发生在这台机可以读取实行，到其余一台机却弗成。
关于Linux的权限，已经有大量干系书本。这里不再重复详细展开，但我们可以通过一个例子轻微回顾一下，温故而知新。例如对付前面的projects目录，它的权限如下：
drwxrwxr-x. 8 apps apps 4096 Mar 16 23:42 projects
则最前面的d表明projects是一个目录，中间的两个apps，分别表示属于apps用户和表示属于apps这个用户组。对付前面的权限，r表示可读，w表示可写，x表示可实行，分别对应二进制的4、2、1。也便是说，如果权限是rwx，则对应是7，如果权限是r-x，则对应是5。权限有三组，依次是用户自己的、相同用户组和其他用户组。例如常见的755则表示用户本人有全部权限，相同用户组和其他用户组只能读取和实行，不能修正。
当LNMP环境、项目路径和系统账号都统一约定好后，我们就可以进行下一步了。
为实现一键发布，构建完全的发布流程，我们须要引入一些新的要素和设定不同的角色。先来看下新的发布流程。
图3-2 一键发布
比较前面的大略发布，这里额外引入了两个要素：
测试环境 测试环境是用于进行功能测试和回归测试的环境，紧张利用工具是QA测试团队。和开拓环境一样，常日支配在公司内网，可以安全地进行各种集成测试，乃至可以把全体数据库清空再重修，以知足不同场景下的测试哀求。预发布环境 预发布环境类似仿真环境，和生产环境一样支配在外网，利用的也是和生产环境同样的数据库。轻微不同的是，预发布环境是只开放给公司内部职员利用的，并且利用独立的缓存机制。也便是说，项目代码在正式发布上线前，会先灰度发布到预发布进行更贴近真实环境的测试。大略做个小总结，我们的项目代码会先在开拓环境进行编写和调试，自测通过后提交到远程代码仓库。测试团队会将开拓完成的代码支配到测试环境，进行冒烟测试、功能测试、集成测试和系统测试等。全部验收通过后，在正式发布前，会灰度发布到预发布环境进行回归测试。末了，统统准备就绪后，更新发布莅临盆环境。从开拓环境，到测试环境，再到预发布环境，末了莅临盆环境，就构成了完全的一个发布流程。
在这个过程中，针对不同的阶段，针对不同专业领域的哀求，我们还须要设定不同的角色，以进行良好的团队协作。通过集体聪慧，完成这一系列的发布操作。前面有说到开拓职员、测试职员，此外为了进行发布，可再设立发布职员，专门卖力进行发布操作。
下面，我们将重点详细讲解如何构建一键发布。一键发布紧张用于将项目代码从开拓环境发布到预发布环境，当回归测试通过后，再将项目代码从开拓环境发布莅临盆环境。发布到预发布和生产环境是类似的，只是发布的目的地不同。关键的核心操作环节有：
1、准备待发布的版本代码2、传输待发布的代码到各做事器3、解压待发布的代码并完成发布的扫尾事情上面的三个核心环节，分别涉及了发布前、发布中和发布后。在发布前，我们须要把待发布的代码进行打包，如果须要进行前真个构建，或者须要把静态的资源文件同步到CDN的话，也可在这一环节完成。尤其对付代码有版本号，或者须要进行一些前置性的事情，都可在这时固化下来。可以说，这一环节非常关键，任何一处缺失落都有可能会导致上线后故障的发生。
在我曾经任职过的一个游戏公司里，每次发布前，都须要将根据数据字典自动天生PHP代码，根据XML配置刷新内存中的项目配置，须要提前将对应的Flash资源上传到外网CDN，须要进行必要的数据库变更以及准备新增的Redis实例。当这些都准备妥当之后，我们才可以开始打包待发布的代码。
为方便理解，我们结合shell发布脚本来一起讲解。截至当前，我们可以快速写出下面这样的shell脚本，命名为publish.sh并保存到项目得当的目录下。
#!/bin/bash# 一键发布# @author dogstar 20180318# Step 1. 选择发往的环境if [ $# -lt 1 ]; then echo "Usage: $0 <pre|prod>" echo " - $0 pre # publish to preview environment" echo " - $0 prod # publish to product environment" exit 1fi
首先，让发布职员选择是发往哪个环境，pre表示预发布环境，prod表示生产环境。接下来，选择须要发布的代码并进行打包操作。把稳，这里可选择发布的范围，并不是项眼前的全部文件都要发布，只有须要才发布。例如对付日志目录就不须要发布，又例如这里打消了单元测试目录。这时用到了第一个shell命令，即tar打包命令。
# Step 2. 打包待发布的文件tar -czf ./examples.tar.gz \ ./config \ ./src \ --exclude ./tests \ ./public \ ./statics \ ./data
这里待打包的目录和文件，须要根据你的项目情形进行调度，你可追加须要发布的目录和文件，也可以打消不须要用到的目录和文件。
再接下来，便是进行发布中的操作，即传输待发布的代码到各做事器。这里的IP地址都是虚拟的，可以根据自己的情形进行修正。分别是预发布的IP地址，和生产环境做事器集群的IP地址。这时须要利用到scp命令。
# Step 3. 传输待发布的代码到各做事器API_ROOT="/home/apps/projects/www.examples.com"USER="apps"IPS=("192.168.1.1" "192.168.1.2" "192.168.1.3") # 生产环境if [ "$1" == "pre" ]; then IPS=("192.168.1.100") # 预发布环境fifor ip in ${IPS[]}do echo -e "[$ip] start to scp ..." scp ./examples.tar.gz $USER@$ip:$API_ROOTdone
当全部的发布包都传输完毕后，我们就可以实行批量解压，让PHP代码险些同时生效啦。把稳，是全部传输再一同解压，而不是传输完一台做事器就解压一台做事器。这样可以只管即便缩短代码同时生效的韶光间隔。这里利用了末了一个命令，ssh。
# Step 4. 解压待发布的代码并完成发布的扫尾事情cmd="tar -xzf $API_ROOT/examples.tar.gz -C $API_ROOT"for ip in ${IPS[]} do echo "[$ip] start to run: $cmd ..." ssh -t $USER@$ip "$cmd"done
将以上shell代码片段连起来，并在最前面加入备份操作，以及发布后进行干系操作外，我们就初步搭建好了一键发布的自动化流程。合成后的代码如下：
#!/bin/bash# 一键发布# @author dogstar 20180318# Step 0. 备份cp ./examples.tar.gz ./examples.bak.tar.gz# Step 1. 选择发往的环境if [ $# -lt 1 ]; then echo "Usage: $0 <pre|prod>" echo " - $0 pre # publish to preview environment" echo " - $0 prod # publish to product environment" exit 1fi# Step 2. 打包待发布的文件tar -czf ./examples.tar.gz \ ./config \ ./src \ --exclude ./tests \ ./public \ ./statics \ ./data# Step 3. 传输待发布的代码到各做事器API_ROOT="/home/apps/projects/www.examples.com"USER="apps"IPS=("192.168.1.1" "192.168.1.2" "192.168.1.3") # 生产环境if [ "$1" == "pre" ]; then IPS=("192.168.1.100") # 预发布环境fifor ip in ${IPS[]}do echo "[$ip] start to scp ..." scp ./examples.tar.gz $USER@$ip:$API_ROOTdone# Step 4. 解压待发布的代码并完成发布的扫尾事情cmd="tar -xzf $API_ROOT/examples.tar.gz -C $API_ROOT"for ip in ${IPS[]}do echo "[$ip] start to run: $cmd ..." ssh -t $USER@$ip "$cmd"done# Step 5. TODO: 发布后的操作echo "Finish!"
关于上面的发布操作，我们在背后还隐蔽了一些其他的细节。例如，为了能免密码远程操作，我们须要在各远程做事器上的/home/apps/.ssh/authorized_keys文件内，添加操作发布的电脑的RSA公钥。但只要大家能理解全体发布过程的紧张环节，至于如何详细实现，则可以灵巧进行调度和扩展。
在一键发布时，我们特意考虑到了须要发布回滚的操作，故此提前做好版本备份的事情。对付如何进行发布回滚，实在和正常的发布是类似的，这里不再赘述。感兴趣的同学可当作练习，自己亲自实践一下。
这里描述了一键发布的基本轮廓，大家可以在实际运用中进行细化。在这根本上，我们就可以在后续实现更快速、更稳定地进行发布操作。特殊当须要增加新的做事器时，只须要稍加配置，追加到上面的IPS配置，就可以实现对新做事器的发布。同样地，当须要摘除某台做事器时，也只须要在IPS变量中删除相应的做事器IP即可。这是一个好的开始。
3.1.4 建立更完善的发布流程
当项目发展到更大规模时，对线上环境的发布操作会移交给专门的团队来卖力。这时须要更完善的发布流程，而这些流程化的操作则会通过更友好的界面，集成度更广的发布系统来表示。将上面的一键发布整合并升级为完全的发布系统，又将是项目发展的一大里程碑。
虽然要完成的事情还有很多，但我们可以更方便地进行整合和集成。界面化的操作，终极都可以归为在Linux上的命令操作。当底层的脚本命令已经基本形成时，在上面再加上界面化就轻而易举了。
3.2 生产环境把稳事变
我们从大略的发布开始，演进到一键发布，末了通过发布系统建立了更完善的发布流程。这是否意味着发布就此结束了呢？
不，恰好相反，这只是一个开始。由于当代码发布莅临盆环境之后，正是一系列操作和事情的开始。为保障系统的安全性、稳定性、健壮性，我们还须要完成以下短期性或长期性的事情。
变动默认端口开启缺点日记开启慢日志进行做事器监控对数据库进行备份下面分别大略解释。
3.2.1 变动默认端口
在当前环境下，网络安全一贯都是个严厉的问题。即便没有专业的安全专家，我们也可以通过大略的办法来加强我们做事器对外办的戒备。个中之一便是变动默认端口。例如变动SSH登录下默认的22端口，修正MySQL数据库默认的3306端口，以及Redis和Memcache的默认端口，以增加外界暴力破解的难度。
3.2.2 开启缺点日记
开启缺点日记，能方便我们碰着问题时快速定位到详细的缘故原由。这里可以开启Nginx的缺点日志，例如前面配置的：
error_log /var/log/nginx/www.examples.com.error_log;
此外，还可以开启PHP-FPM的缺点日志，例如/etc/php-fpm.conf配置里的：
error_log = /var/log/php-fpm/error.log
3.2.3 开启慢日志
除了要通过缺点日志关注非常情形外，还要通过慢日志来关注系统的相应速率。例如开启PHP-FPM的慢日志，可以修正/etc/php-fpm.d/www.conf配置文件中的：
slowlog = /var/log/php-fpm/www-slow.logrequest_slowlog_timeout = 2s
当PHP要求的相应韶光超过2秒时，将会在/var/log/php-fpm/www-slow.log日志文件内产生一笔记载。
例如，我们可以编写一个慢日志的测试脚本test_slow.php，并放置以下代码。
// $ vim ./public/test_slow.php<?phpecho "start to run ...";sleep(1);$arr = range(0, 10);sleep(1);$arr = range(0, 10);sleep(1);$arr = range(0, 10);echo "finish to run ...";
在这里，我们故意分别就寝了三次，每次1秒。以是通过浏览器访问后，我们可以看到类似这样的慢日志。
slow_query_log = 1slow_query_log_file = /var/log/mysql_slow_query.loglong_query_time = 2
特殊对付数据库，更须要开启慢查询，以便及时对数据库的慢查询语句进行针对性的优化。修正/etc/my.cnf配置文件，并往里面添加以下配置，可以开启MySQL数据库的慢查询日志。
slow_query_log = 1slow_query_log_file = /var/log/mysql_slow_query.loglong_query_time = 2
同样地，当数据库查询语句实行韶光超过2秒时，将会产生一条慢日志。
3.2.4 做事器监控
除了对PHP、Nginx和MySQL开启缺点日志和慢查询日志外，我们还须要对网站赖以生存的系统环境进行监控，以便及时创造做事器在CPU、内存、硬盘空间和网络IO等方面的指标性能。例如你可以选择利用Zabbix进行全方位的监控。
3.2.5 对数据库进行备份
末了，还有一个建议是非常主要的，这个建议很有可能在日后为你的公司挽回数十万的经济丢失。那便是，定时对数据库进行备份。通过在不同的做事器物理机上，对当前系统利用的数据库进行自动化数据备份，以应对人为缺点操作、机房做事器被外界成分毁坏等不可控的风险。
例如，对付MySQL数据库，可以利用automysqlbackup进行备份。大略配置后，再结合crontab操持任务，我们就可以实现定时自动化数据库备份了。
#数据库备份303/usr/bin/automysqlbackup/etc/automysqlbackup/automysqlbackup.conf
如上面的crontab操持任务配置，就可以实现了在每天凌晨3点半时，根据automysqlbackup.conf配置文件进行MySQL数据库的备份。
成功备份后，可以看到在CONFIG_backup_dir配置的备份目录下，有类似如下目录，分别存放了逐日、每周、每月备份的数据。更多利用解释，可参考automysqlbackup的干系文档先容。
.|-- daily| |-- mysql| |-- performance_schema| `-- test| `-- daily_test_2018-03-19_21h54m_Monday.sql.gz|-- fullschema|-- latest|-- monthly|-- status|-- tmp`-- weekly `-- test `-- weekly_test_2018-03-19_21h54m_12.sql.gz
通过前面先容的一键发布脚本或者更为强大的发布系统，我们已经向天下发布了我们的代码。但是除了发布以外，在项目支配和架构搭建上，如果办法不对，会产生入侵式的设计。我曾见过因入侵式设计而苦苦挣扎在个中的团队，下面看下哪些是不合理、会导致毁坏原有体系的做法。
3.3.1 触电式架构
在编程天下里，对付类、文件和模块之前的依赖，一贯都有着类似的原则。例如只管即便利用单向依赖而不是双向循环依赖，高层模块不应该依赖于底层模块。
在C++中，若两个类须要相互依赖，那么在代码编写上须要一点技巧，也会引入一些繁芜性。如果相互间的依赖过于繁芜，就会随意马虎产生持续赓续的问题，正所谓“剪不断，理还乱”。DLL地狱便是这类问题的史证。
那这些和利用PHP开拓的网站项目有什么关系呢？重点来了，由于PHP是动态脚本，是阐明性编程措辞，不须要编译就能直接运行，并且在文件引入和类引入上更为灵巧。灵巧滋长混乱。在编写C++程序时，程序员须要严格遵照规范和标准，使得编写的代码符合哀求，通过编译。比较明显的哀求便是你在实例化某个类之前，这个类须要先存在，并且将要调用的类成员函数也是确定的。而在编写PHP程序时，你可以动态实例化某个类，也可以动态调用某个类成员函数，乃至通报的参数也是动态变革的。这些灵巧的语法特性，在带来了编程开拓便利性的同时也会随意马虎被人滥用，从而产生不能事先确定、非线性逻辑的代码。顺便提及一下，大概PHP措辞还不是最为繁芜的，由于还有更为灵巧、通过代码天生代码的元编程措辞，例如Ruby。
我们暂时不进行过多的发散，下面回归正题。我们先通过一些代码片段示例，看下PHP都有哪些灵巧性。再来看下在这根本上，为何会随意马虎构建出触电式架构。
“一样平常的开源框架，是若何做到根据指定URL实行相应PHP代码的？你能详细解释一下吗？”
在口试中，有时口试官或问到这样的问题。对付这个问题，回答的核心正是PHP如何动态实行某个类的某个成员函数。假设客户端访问的URL是：
http://localhost/?c=Site&a=Index
个中，参数c表示Controller掌握器（即：类名），a表示Action动作（即：方法名）。终极对应实行SiteController类的actionIndex方法，如下：
<?php$controller = $_GET['c'] . 'Controller';$action = 'action' . $_GET['a'];$instance = new $controller();$instance->$action();
那怎么实现这一动态实行的过程呢？
为突出如何动态实行这一关注点，我们暂时不考虑路由，也不考虑文件引入。在PHP中，须要动态实行类的某个方法，是比较大略的，并且实现办法可以有多种。大略地，可以直接这样：
<?php$controller = $_GET['c'] . 'Controller';$action = 'action' . $_GET['a'];$instance = new $controller();// 把稳末了这一行，实行回调函数call_user_func(array($instance, $action));
为大略起见，这里也省略了对参数的校验以及非常情形的处理。
其余，我们也可以通过call_user_func()函数来实现。目前这里不须要通报参数列表，结合恰当的回调类型的表示办法，还可以这样实现：
<?php$controller = $_GET['c'] . 'Controller';$action = 'action' . $_GET['a'];$instance = new $controller();// 把稳末了这一行，实行回调函数call_user_func(array($instance, $action));
你还可以利用call_user_func_array()函数来实现调用，不过其用法和call_user_func()函数类似，不同的是可以把参数列表作为一个数组动态传入。
对付动态实行某个函数，其做法也是类似的。那这样会随意马虎带来什么问题呢？这里有两个要点须要关注的，第一点是PHP是阐明性措辞，不须要经由编译就能实行，这意味着即便存在语法缺点的PHP文件，项目也能正常事情，条件是不触发实行这些有问题的PHP文件即可。更直白来说，哪怕你往网站项目中故意放入了一些有问题的PHP代码，或者添加其他项目的代码也没什么大不了的，只要别踩到这些“地雷”。第二点是，PHP是动态实行的，你将要实行的类静态方法、类成员函数和普通函数，事先是不愿定的。你可能找得到它们，也可以找到了但无法实行，比如试图调用protected级别的成员函数，或者通报的参数列表不符。
而这两点，不须要全部符合语法规范以及不愿定的动态实行，在项目级别和系统架构级别造就了更大的灵巧性。随着公司业务的发展，最初只有一个PHP网站项目，然后PHP项目数量增长到2个、3个、5个、12个……原来只是项目内的依赖关系，现在为梦想方便、或者是短缺考虑、或者是其他历史缘故原由，逐步扩散到不同项目之间。即项目A，严重依赖于项目B的代码；项目B直接依赖于项目C的底层代码；项目C又须要调用项目A的函数获取最新商品数据。这就逐步形成了触电式的架构，一旦某个项目的函数出问题了，就会影响其他项目的正常运行。
触电式架构是一种反模式，我以为应该武断抵制。触电式架构为线上系统带来了极其薄弱性和不稳定性，项目与项目之间就像手拉手的一群人，只要个中一个人触电了，其他全部人都会随着受累。而且，由此而引入的繁芜性也是高得吓人。深陷在触电式架构内的项目，它的繁芜度不是在于它自身业务规则的繁芜度，也不在于内部模块与模块之间错乱的调用关系，而是在于它与外部项目的直接依赖关系！
由于PHP代码在逻辑上（类与类、函数与函数间的调用）以及物理上（文件与文件之间的include/require引用），终极也决定了这些有依赖的不同项目，都须要支配在同一台做事器上，从而产生了更大层面的依赖。如果某个网站项目由于访问量过高而导致做事器性能负载过高，就会直接影响其他网站项目的正常运行。这种整机支配的策略，暗含了巨大的不愿定性和薄弱性。但大概，这还不是最糟糕的。除了在代码上，在做事器支配上有依赖外，根据破窗理论，在触电式架构这一大背景下，开拓团队也就“顺其自然”地在数据这一领域上也产生了严重的依赖。他们常日会联表跨库查询和操作，由于既然代码都“在一起”了，数据库也该当“在一起”。
从选择了PHP这门编程措辞开拓网站开始，得益于PHP的灵巧性，我们能快速进行迭代，但如果掌握不好也会因其灵巧性而产生不恰当的依赖关系。当类与类之间不恰当的依赖关系，蔓延到模块与模块之间，再蔓延到项目与项目之间，就会发生由量变到质变的转换。随之而来的，便是做事器支配上的依赖，和数据库上的依赖。逐步地，就编织了一张更大的网、更大的坑。
图3-3 触电式架构示例
形成触电式架构的关键决策点在于，第二个项目出身时如何约束依赖关系。新项目如果须要利用底层的公共函数和配置，该如何处理？新项目如果须要调用最初项目的某个模块完成特定业务功能时，又该如何设计？新项目在不同的业务场景上须要依赖第一个项目的数据库数据时，又该如何应对？如果不加考虑，为了梦想方便，或者迫于上线韶光压力，一旦把第二个项目和第一个项目直接支配在一起，并且通过PHP代码直接相互调用，还许可操作其他项目的数据库，那么后来的新项目也会陆续效仿这一做法。如果不加以掌握、调度和约束，假以时日，触电式架构就会形成，牵一发而动全身。
普通来说，触电式架构便是“你中有我，我中有你”，说得动情一点便是共赴患难，有难一起当。但是这种做法是不可取的，除非有分外的缘故原由（实际上，我也想不出有任何充足的情由），不要采取这种做法。在支配发布第二个项目时，一定要回过分稽核评估是否有类似触电式架构这般强依赖的关系网的存在。如果有，请说不！
关于触电式架构，我们暂时说到这里。下面再来看下压缩环境。
3.3.2 压缩环境
平时我们都会吃到压缩饼干，这些饼干将小麦粉、糖、油脂、乳制品等紧张质料压缩成饼干，方便食用。但如果追求更康健的生活，我们不能长期只急急缩饼干，还要补充维生素、微量元素、蛋白质等，均衡饮食。同样，在开拓网站项目过程中，我们可能也会用到压缩环境。常日而言，支配的环境按项目的不同阶段和不同利用职员，可以分为：开拓环境，测试环境，回归环境，预发布环境，生产环境。但小团队或者小公司，出于低本钱，都喜好利用压缩环境。例如只利用开拓环境和生产环境，而没有测试、回归、预发布这些环境。更有甚者，如前面所说，只利用生产环境，即开拓环境与生产环境利用同一个。这些便是我们所说的压缩环境。
在触电式架构下，别人发布了新的代码，有可能会导致你的项目首页无法访问，间接无辜受到影响，而且这种影响是不可控、不可预见的。对付利用压缩环境而言，类似地，如果开拓环境与生产环境共用一套，就会随意马虎造成因功能开拓调试过程影响线上环境的稳定性。如果开拓环境与测试环境是同一个，那么开拓职员和测试职员就会随意马虎产生冲突。测试职员正在进行功能验收的代码，却被开拓职员修正或者切换了；而开拓职员正在进行测试的数据，又会被测试职员用于进行功能验收。由于关注点不同，参与的角色越多，集成的系统越多时，压缩环境就会越随意马虎产生更频繁的冲突。
当然，我们须要做到平衡，实现均衡发展。一开始就搭建全部环境也是不现实的，但当确实须要那么多不同的环境却依然利用压缩环境时也是不应该的。须要把稳的是，在不同的环境上，应只管即便保持同等的支配办法，通过前面搭建的一键发布，我们可以很随意马虎实现这点。
3.3.3 不同环境，不同域名
即便已经根据须要，采取了不同的环境。但如果对付域名的分配和利用办法不对的话，也会产生另一种入侵式的设计。乃至是利用压缩环境，也会有这个问题。这种反模式便是：不同环境，不同域名。尤其表示在测试环境的域名与正式线上环境的域名不同。
实现这种反模式可以有几种做法，分别是：
通过不同顶级域名区分不同环境例如，假设生产环境域名是www.examples.com，那么测试环境则利用.cn域名，即测试环境域名是www.examples.cn。由于利用了不同域名，除了不能共享session会话外，也不能共享客户端COOKIE，这会对开拓造成一定的困惑。此外，还会由于不同域名而产生跨域问题，例如前端Javascript在发起Ajax要求时，如果未在不同环境时进行相应切换，就会发生在测试环境跨域要求了生产环境，或者在生产环境跨域要求了测试环境。前者的影响只是会让开发职员产生困惑，而后者一旦发布上线就会直接导致故障的发生。通过添加前缀区分不同环境另一种区分的办法是，利用相同的顶级域名，但利用不同的域名前缀来区分。例如，生产环境域名是www.examples.com，测试环境域名是test.www.examples.com。这在一定程度上可以缓解或办理COOKIE共享、Ajax跨域和静态资源引用的问题，由于可以利用相对路径而非绝对路径来实现。但当须要和外部系统进行交互或者集成时就会碰着问题。例如在测试环境分享了一个链接，到外网却打不开。通过动态开拓分支名切换不同环境末了，还有一种办法是利用分层存储，动态根据开拓时的分支名称，切换到不同环境。例如master分支的访问域名是www_master.examples.com，dev分支的访问域名是www_dev.examples.com，依此类推。默认的则是生产环境的域名www.examples.com。这种办法常日是运用在压缩环境。不管是通过何种办法，一旦不同环境所用的域名不一样，就会产生入侵式的设计。首当其冲便是对代码编写上的影响。网站开拓职员在编写PHP代码时，常常要根据不同的环境手动或自动切换到不同的域名，并且还要时候记得在测试通过、上线发布前把域名规复为正式域名，否则就会产生故障。不同环境，不同域名，不仅为开拓阶段带来了额外的包袱，还为测试阶段引入了不必要的繁芜性，更让人不能接管的是在线上环境会随意马虎滋长故障。例如发布后，线上环境引用了测试环境的静态资源，导致因短缺Javascript文件而报错，或因短缺CSS样式文件而布局错乱。又或者，由于前端Javascript或者后端PHP内部系统在生产环境调用访问了测试环境的接口链接，无法获取或获取了缺点的数据信息。
不同环境利用不同域名，这种做法造成的影响是直接且深远的。对付前端开拓员，他们要把稳Ajax接口要求、静态资源文件引用上的差异；后端开拓职员须要时候关注根据不同环境进行切换和调度才能担保内部接口调用和系统之间的精确访问；测试职员则要在回归测试时当心创造不同环境下有没相互穿越错乱的征象，并及时知会技能职员进行改动；产品职员则时时时要担心会不会在线上环境再次发布类似的故障。
本章小结
发布是一件可大可小的事情。说它小，是由于你可以直接通过很大略的办法就能实现线上代码的更新和同步；说它大，是由于如果想做到完全全面，须要考虑的问题会很多，除了要搭建自动化一键支配外，还须要配套集成度更高的发布系统。建立起完善的发布流程，实现项目的快速发布，将会帮助你在项目迭代过程中实现小步快跑。
生产环境是暴露给天下访问的，它处于现实天下的残酷和危险之中。为了最大化保护我们的网站、我们的系统和我们的做事器，须要把稳以下事变：
变动默认端口开启缺点日记开启慢日志进行做事器监控对数据库进行备份除了在生产环境做足了准备外，还须要戒备入侵式的设计，例如：触电式架构、压缩环境和不同环境不同域名。任何一种入侵式设计，都会对今后的项目迭代产生深远的负面影响。
发布代码到线上环境，只是一个开始。除了要留神把稳事变和戒备入侵式设计，我们还会陆续欢迎到更大的问题、更严厉的寻衅。不过不要急于立时投入到实际商业产品、项目或系统的开拓中，先来回顾一下PHP开拓干系的知识，看下我们是否遗漏或忽略了某些主要信息。
