应用写好之后，总要找个地方跑起来。本地电脑扛不住长时间访问，自己买机器搭机房，前期投入和后续维护都不小，所以大多数团队最后还是落到云服务器上。业务能不能稳定跑下去，很大程度取决于部署在云上的云服务器应用程序怎么设计、怎么上线。
云服务器应用程序是什么
说白了，它就是跑在云端虚拟主机上、通过网络给别人用的软件。网站后台、订单系统、小程序接口都属于这一类。和装在电脑里的单机软件相比，它要同时应对很多用户的请求，数据要长期保存，机器出故障时服务要能接上，访问量上来了还得能加机器。这几件事只要漏掉一件，上线后通常就会出问题。
动手前先想清楚三件事
很多人一上来就挑配置，其实先把下面三件事问清楚，选型会省很多力气。
- 访问规模：日活几千和几十万，对计算资源和带宽的要求差很多。先估一个峰值，比凭感觉买配置靠谱。
- 数据敏感度：涉及用户隐私或支付信息的系统，网络隔离、数据加密和访问权限要提前设计，事后补会很被动。
- 团队能力：如果没人长期盯运维，数据库和容器这类组件尽量用云厂商的托管服务，把精力留给业务本身。
案例一：小型电商从平台迁到自建商城
一家本地手作品牌原本在第三方店铺平台卖货，手续费和流量限制让利润越来越薄，于是决定自建商城。他们选了一台4核8G的云服务器，跑基于Node.js的商城应用，数据库用云厂商的托管MySQL。
第一版只做了商品展示、下单和支付回调，功能范围收得很小。后来加了负载均衡和定时备份，大促期间的并发访问达到日常的六倍，系统仍然稳住了。数据库交给托管服务后，主从切换和备份脚本不用团队自己维护，运营同学能把时间放在选品和活动上。
案例二：在线教育平台的弹性扩容
一家编程培训机构每周只有几场直播课，但每次课前半小时访问量会瞬间涨上来。最开始只用一台服务器，直播时经常卡。后来他们把视频转码和答题服务拆成独立应用，分别部署在不同的云服务器上，并设置了按负载自动增减实例的伸缩策略。
调整之后，课前高峰的响应时间从三秒多降到不到一秒。闲时实例自动缩减，月度费用反而降了约30%。这个例子里起作用的有两点：一是把压力大的服务单独拆出来，二是让伸缩规则跟着负载走，而不是靠人手动加机器。
部署上线的基本步骤
中小团队一般可以按下面的顺序推进，每一步都有一个容易被跳过的细节。
- 本地开发时，数据库密码、第三方接口密钥等敏感信息放进环境变量或独立的配置文件，别直接写进代码，更别提交到代码仓库。
- 根据应用依赖选操作系统镜像，装好Java、Python或Node.js等运行环境。版本号尽量和本地保持一致，避免出现“本地能跑、线上报错”的情况。
- 用SSH密钥登录服务器，并关闭密码登录。代码通过拉取仓库或镜像仓库的方式更新，应用交给systemd、PM2之类的进程管理工具守护，进程挂掉能自动拉起。
- 前面挂Nginx或云负载均衡做反向代理，证书申请好后强制跳转HTTPS。对外只开放80和443端口，应用端口只允许本机访问。
- 上线前配好监控和告警，至少覆盖CPU、内存、磁盘和接口错误率。数据库要定期备份，并在测试环境真正演练一次恢复。没演练过的备份，等于没有备份。
上线后最容易踩的坑
- 所有功能挤在一台服务器上。机器一重启或出故障，整个业务都会停。这在初期很常见，但至少要清楚风险在哪。
- 一直用默认端口和弱密码，安全组又全部放开。服务器很快就会被扫描到，轻则被爆破，重则被挖矿程序盯上。
- 只看实例单价，不算流量费、存储费和快照费。账单出来才发现，带宽或日志往往占了大头。
- 上线后不看日志，也没有监控。出了问题只能等用户反馈，这时候通常已经丢了一段时间的订单或注册。
安全和成本要一起考虑
应用的安全一部分由云厂商的基础设施保证，另一部分要靠自己的配置。安全组只开放必要端口，系统补丁和依赖库定期更新，敏感数据加密存储，关键操作留下审计日志。这些做起来并不复杂，但最好在上线前完成，等出事了再补，成本会高很多。
成本上，业务波动大的部分可以用按量计费，稳定运行的核心服务适合包年包月。闲置的测试机和没人用的快照，记得及时释放，否则它们会每个月悄悄计费。
先跑通，再优化
对多数团队来说，先用一个简单的架构把业务跑通，比一开始就搭复杂的分布式系统更实际。等监控数据告诉你瓶颈在哪里，再去拆服务、加缓存、做伸缩，目标会清楚得多。
