菜你都做好了，如何端给用户？

前言

《外包公司，等你长大》这一篇预告很久了，一直没有成笔，今天写的可以算是其中一小点，只是聚焦于应用分发和交付的问题，为什么会写这一篇，这一切，都要从一只蝙蝠说起。。。

因为疫情的缘故，高校最近密集上了包括健康打卡、不见面办理、视频会议和网络教学等相关的应用。各个信息化部门也乘机在里面夹带了各种私货，包括推广某些平时很难推动的平台，对师生进行信息素养教育提高等等工作。每一次危机，其实都伴随着机遇，就看你如何能够及时把握。

这些应用都有高并发高流量的需求，而且时间紧，需求变化快。如何快速平稳交付是一个比较大的问题。

在这里，云平台也冒出来了。高校原先是比较排斥云的，不知道什么缘故，大家总认为，物理上在学校内部，才是自主可控的。但是这次不同，师生都在校外，只有云和 CDN 才是最接近用户的。

云存储和 CDN 有毒，用了就停不下来。

然后在我最近跟他们交流中，我发现了一些应用交付上的问题。

大部分外包公司，都还是很原始的手工部署，而且部署人员的技术水平和安全意识在公司整体属于比研发低一点。

如果从 DevOps 来说，这也有研发的锅。研发开发完成，哪管你运维人员怎么部署。

外包公司总是向我们拿更多的 CPU、更多的内存、更高的空间占用，拿硬件负载均衡，拿 Oracle。因为这些在我们这边是增加成本，但是对他们是节省成本，节省软件框架优化的成本。外包公司还会向我们拿更多的系统维护停机时间，更长的小版本更新周期，更长的操作系统和基础软件更新周期。这些在我们这里是影响用户体验和系统安全的，让信息化部门被用户打低分的。对他们来说，还是节省成本。为了性能，CPU、内存等等我们也会愿意给，但是这要有一个度，因为一个应用，如果不从框架或代码方面去做优化，给多少资源都是没用的。甚至于，有些应用，我们想给更多的资源，但是他消耗不了。

所以我认为，如果可以，外包公司请尽快迁移到自动化部署上去吧。如果能直接二进制打包 War、Docker 给我们更好，因为现在存储实在太便宜，我们不再需要为了解决空间占用而带来的各种依赖共享、动态加载、各种不同版本化的库。然而大的外包公司，历史包袱重，转身很难，如果一个老的 CTO，只求稳不寻求技术更新，那新技术就很难推进。迁移肯定是有阵痛的，短期内成本是上升的，但是长期会以另外一种形式补贴你。对客户来说，能给你提意见的才是优质客户，批评越重，那都是真爱，希望你成长为 101 年的企业，毕竟你死了，大家都不好过。

自动化部署

> 我们维护 400 个学校的 2000 台机器

这时候更需要自动化部署，自动化部署具有高效率和较快的部署能力，而且不容易出错。不同学校不同的配置文件进入.gitignore 隔离。当然，自动太自动了，脚本出错影响面也很大。这是另外一个问题。

比如，自动化，也不推荐只用一台主控机。我们一般自动化部署，会有 Test 机器列表，Staging 机器列表，Production 机器列表，通过不同脚本跑，假设你使用工作用机来当主控机，所以你所有机器列表要对主控机都开通 SSH 防火墙，然后有天你手抖了，正在 Test 上修改配置，然后跑了 Production 脚本，就悲剧了。所以一般都建议，主控机根据不同环境分隔开来。

Test 或者 Staging 环境

这些环境应当和 Production 环境一致，然后定期同步数据库和共享文件。现在一般很少这么做，成本较高，或者 Production 环境部署 10 台，但是 Test 环境才 2 台，而且数据不一定同步。这些都会造成一些问题，比如压力测试可能就做不了，查错还是 OK 的。

多个环境一定要非常小心，特别是 rsync，mysqldump，再困再累，也要对命令行左右路径 double check 一下。

小版本升级、迁移正确的打开方式

如果完全按 DevOps 的理念，不可变服务器，每次升级，都重新构建一台全新的服务器，然后扔掉旧服务器，这个很多学校还做不到。如果还遇到大版本升级，或者有架构方面大的升级，还需要更长的停机时间。

• 提前一段时间通知用户即将停机维护
• 在进入停机模式，Nginx 接管所有流量，给用户一个维护模式页面
• 如果可以，应先在备用环境演练迁移时间，将所有时间压缩到最低，比如数据库可以使用 binlog 传输变化量就不需要整库倒数据，文件传输 rsync 传输变化量等等。

能不能从 Web 小版本升级

用过 WordPress 的人都体验过从 Web 安装，从 Web 自动升级，能否引入这种机制，不要再从 SSH 跑命令升级了，让升级更傻瓜一点。当然，要做到这步，考虑需要更多，比如安全性问题，脚本运行超时问题等等。

VPN 和堡垒机

> 我们维护的院校，60% 是需要 VPN 的，30% 是需要堡垒机的，光 VPN 软件就几十种。

>

> 当前维护一个学校，只能登录 1 个学校的 VPN，比如我在维护厦门大学的时候，就无法同时部署清华大学、北京大学

这里面存在 2 个误解。

• 有责任的外包公司，如果看到学校的服务器维护居然可以不用 VPN，不用双因素认证的堡垒机，应当不是窃喜而是告知学校，这样子很不安全！
• 是可以同时拨号 10 个学校 VPN 并通过路由指定网段走哪个 VPN 网关的。

当然，这有学校的问题，90% 以上的高校的 VPN 设置手册可能都是一大堆图文并茂告诉用户如何一步步设置 VPN，很多管理员不知道其实可以直接打开 PowerShell 窗口（Windows8、Windows10 以上）输入以下命令一键配置，并且拷贝黏贴保证不会出错：

“`powershell

Add-VpnConnection -Name “XmuIKEv2” 

-ServerAddress “mask.xmu.edu.cn” 

-TunnelType “IKEv2” 

-EncryptionLevel “Optional” 

-AuthenticationMethod Eap 

-RememberCredential

“`

注意后面一定不要有 -PassThru，宁愿再跑一次 Get-VpnConection，否则会污染 rasphone.pbk 文件。

针对以上外包公司来说，他只要加参数 -SplitTunneling $True 取消默认网关，然后就可以通过 Add-VpnConnectionRoute 。这个方案比 route -p ADD 好的地方在于，不会永久破坏你的路由表，只会在拨号 VPN 后生效。或者你也可以每次拨号 VPN 后手动 route ADD。

查看你加了多少路由没有 Get-VpnConnectionRoute 命令，通过以下查看：

“`powershell

$conn = Get-VpnConnection -Name “XmuIKEv2”

$conn.routes

“`

SaaS、Semi-SaaS、On-Premises

如果能打包成容器部署更好，当然容器也在不停演进，安全性不是太乐观，内核漏洞和容器漏洞都会导致容器逃逸。最新的有安全容器，在容器外面再套一层轻量级的虚拟化都是可以研究的。

因为交付很麻烦，有些外包公司直接给你提供 SaaS 服务。也有提供半 SaaS 服务，你多给点钱，他帮你在云平台开虚拟机部署，甚至还可以给你机器密码，纯的 SaaS 你是拿不到数据库权限，半 SaaS 可能可以拿到。但是这里就要注意到安全问题，半 SaaS 服务为了方便，他们可能直接 SSH 端口直接对外全部开放，不走堡垒机等等问题。

多台 Web

Web 不是说想扩就扩的，Web 要变多台，你必须处理几台 Web 共享数据和状态问题。而且 Web 扩完后日志也不是集中的。多台 Web 升级代码也是比较麻烦的。这里一般采用滚动升级或者使用负载均衡引流灰度升级。比如我部署的一个应用，前端一台 Nginx，后端 10 台 Web，我单独划出一台给我自己在线调试查错，就简单通过 Nginx 判断 remote_addr 是我的 IP，直接引流到某台 Web。

整个应用对外也应当对 CDN 友好，最近上了 CDN 我才发现，CDN 针对动态网页、静态资源、流媒体点播、云存储等不同缓存的价格是不同的，所以有能力应当使用多个域名隔离这些资源，使得对 CDN 友好，节省学校的带宽成本。

共享 Session

编程语言一般都可以设置 Session 保存到一个集中的数据库，比如关系型数据库，甚至内存数据库。当然，你如果保证可以 ip_hash 到同一台 Web，Session 可以直接放在 Web，但是这个不够健壮。如果 Web 当了一台，Session 会丢失。

共享 Cache

一些全局的 Cache 也可以考虑类似 Session 来处理。

Cache

必须大量采用 Cache。页面必须解构，动态内容和静态内容分开，缓存时间不同的分开，JavaScript、Image 全部版本化，输出 Cache-Control。我最近在安装 Moodle，Moodle 这方面做得非常完美。

共享存储

NFS 已经进化到 v4 了，但是因为有网络参与，速度还是不容乐观，考虑用户传一个 1G 的文件到 NFS，他需要先经过 CDN->Nginx->Web->NFS，至少 Web 和 NFS 会有两次落盘读写，时间会被延长 20%。所以这个需要权衡。当然，如果有异步机制，这个时间可以省下来，后端多台 Web 再和 NFS 进行 rsync 同步。或者直接上分布式文件存储，云存储，并且跟 CDN 做好对接，应当可以缓存有权限判断的文件。

数据库

不要一上来就拿 Oracle，是否可以采用 MySQL，分库分表？读写分离？

版本化

版本化一切，包括源代码和数据库。如果用过开源软件，或者类似 Django 的 Database Migrate 机制就会很清楚。数据库有自己的版本，一个版本字符串写在表结构内。Web 来访问必须匹配版本号，否则无法运行，提示升级。这样子可以防止，假如你有 10 台 Web，但是运维没睡好，只升级了其中 9 台，漏了一台，也不会影响数据库的安全。这 10% 的用户就会收到一个提示，也可以更快发现错误。如果你可以把学校代码也写入源代码和数据库，就不会出现清华大学的代码误传到厦门大学并跑起来了。

定制呢？_改首页呢？

这个我们也遇到过，明明一个错误已经修正了，怎么又跑出来？原来是运维升级错版本了，覆盖客制化内容了。升级好了，首页怎么乱了？客制化忘记修正了。所以这里一定要做好各个不同学校的内容的隔离，使用配置文件。git flow 要认认真真去学习，如何做个主 master 仓库，如何 develop，hotfix，feature，release，不同学校的 release 版本。

当然对于学校来说，尽量减少定制，即使要定制，也要争取定制内容进入公司产品主仓库。定制是恶魔。

压力测试

一般公司会说我们在哪个学校试过压力测试，可以达到多少并发等等。但是这个不准，各个学校硬件环境和数据库内容差异很大，没有可比性，如果可以的话，尽量应当在本地直接压力测试。

因为压力测试录制脚本很麻烦，还需要处理登录问题，如果可能，应当有专门的代码，直接从数据库生成 JMeter 脚本，对登录做 Hack，直接通过某种机制绕过登录，在跟生产环境基本一致的服务器上做压力测试。也就是，压力测试也是要自动化，想要跑就可以跑的。

监控和日志

在我以前说过，如果请外包公司做运维，应当将监控和日志向运维公司开放。因为你一旦将 Web 拓展到多台以后，查找 Log 是非常麻烦的，你很难知道自己被 ip_hash 到哪台 Web 了，所以必须中心化日志。并且要定期查看 500 错误，不要等用户来报。

很多外包公司认为这个是学校的事情，确实，监控和日志是安全合规的事情，学校一般也会已经建立，但是是否可以分权限给你查看这个得看学校买的日志集中化产品的支持，甚至得看你能否进入学校安全核心网段。所以如果有能力，应当自己采用开源软件也建立一套简单的日志采集工具，只给自己定位错误使用。

备份

备份友好也要考虑。比如你将文件都写入数据库很省心，会造成数据库很大，很难备份。或者文件写的路径尽量按上传时间分离而不是某个奇怪的 hash 算法。当然备份学校也会有一套自己的规则，可以不用考虑太多。知悉学校的备份策略，也为自己运维人员操作留下后路。

（免责声明：本网站（https://c.shenzhoubb.com）
内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。）