炙伦云终端分享嘉宾:

无规则，不成方圆，标准化一切！
    2.1 什么是标准化？
    

    在讨论标准化是什么之前，我们先来思考这些问题：
    1. 业务维护：手工模式可以维护一套系统的开发、测试和部署，如果是十套，一百套，甚至更多呢？
    2. 业务交接：业务交接代价太高了，能不能让新来的人几分钟就能理解整套系统的维护逻辑？
    3. 服务部署：手工部署很麻烦，搭建环境很痛苦。我可以一键部署，剩下的时间去喝咖啡吗？
    标准化可以帮助我们解决以上的这些问题，我对标准化的定义就是：针对企业内部的业务系统技术栈进行梳理，规划出一套开发和部署规范，并且在各个环境(Dev/Test/Prod)严格执行。
    标准化对可变部署模式最为有效，通过标准化，企业内部的每一套系统，每一个环境，都保持一致，然后把规范化后的部署方案整理好，落实到自动化平台，就可以实现自动化部署而无需过多的人工干预。
    试想一下，如果是一百套不同的系统，自动化平台根本做不起来，业务维护、交接和部署的成本简直不可想象。
    
那么问题就来了，如何做标准化？
    
    PS：什么是部署模式？
    实际环境中，部署模式分为2种，一种是可变部署模式，一种是不可变部署模式。
    可变部署模式:
    是指任何的版本变更操作，都会在原来的版本上进行，例如升级、回滚、卸载、安装，这些变更操作会直接影响到原来的版本的服务，技术术语中把使用了可变部署模式的服务器称之为：Mutable Monster Server（随之时间推移逐渐变成不可控的怪物服务器）。
    例如：ver1.0 发布之后，更新至ver2.0时，需要把服务器上的ver1.0的服务停止，删除版本文件，然后把 ver2.0的版本文件安装上去，再启动服务；
    因此，如果版本回滚的时候，也是同样的操作，把 ver1.0 的安装回去。
    
    不可变部署模式:
    不可变部署模式，和可变部署模式相反，一旦当前的版本发布后，就不能再对该版本做任何的操作，如果要进行版本变更操作，就需要重新发布一个新的不可变版本，这些变更操作不会影响原来的版本的服务，不可变部署模式的目前代表是 Docker 镜像发布模式。
    例如：ver1.0 的镜像发布后，更新至 ver2.0时，只需要把 ver2.0 的镜像发布出去，运行起来，然后把流量切换到 ver2.0 的容器实例上即可；
    因此，如果版本回滚的时候，就把流量切换回去 ver1.0 的容器实例上；