托管与云

这个板块涵盖什么

运行应用的各类场所：从代码仓库直接部署的托管平台、容器服务、虚拟机，以及附带几百种服务的完整云服务商。

正确答案与其说取决于规模，不如说取决于您愿意自己承担多少运维工作。您多拿一层控制权，就多添一份责任，而这份责任总在不方便的时刻找上门。

数据库有自己的分类，见数据库。上线之后的观察工作则属于监控。

四种控制程度

托管平台接收代码并负责运行。部署来自代码仓库，扩缩容只是一项设置，大部分基础设施决策都替您做好了。它们是上线最快的途径，但遇到特殊需求时最不灵活。

容器服务低一个层级，运行您自己构建的镜像，编排由您配置。工作更多，控制更多，产物也可在不同服务商之间迁移。

虚拟机给您一个操作系统以及随之而来的一切，包括打补丁、安全和备份。

完整的云服务商三者兼备，还有一整套托管服务目录，代价是复杂度，以及需要时刻留意的账单。

决定性能的几个问题

• 区域选择：靠近用户，也靠近数据库。
• 冷启动：针对在请求间隙缩容到零的任何服务。
• 持久连接：部分无服务器模式处理得很差。
• 构建与部署时间：十分钟的部署会改变大家发布的频率。
• 静态分发：缓存在访客附近，而不是每次都从源站提供。

应用与数据之间的距离，是最常见的自找麻烦。一个页面跨区域查询五十次，网站就会很慢，前端再怎么优化也救不回来。

可靠性，以及出事那天会怎样

可用性承诺值得细读，而不是轻信。多数承诺只覆盖服务商自己的控制平面，赔付方式是服务抵扣金，这并不等于故障给您造成的损失。

问一问故障域：您的实例在一个可用区还是多个，重新部署对线上流量有什么影响，回滚是一个按钮还是一次重新构建。问问日志保留多久，在控制台打不开时您还能不能拿到。

然后问问由您掌控的恢复能力。如果数据在别处有副本，部署又能重现，服务商的故障就是可以挺过去的。这两点默认都不成立。

成本，以及悄悄变大的几项

计算资源是定价页上的数字，而账单通常由五项组成。

出站流量按流出服务商的数据量每GB计费，在视频、下载和区域之间的流量中累积最快。存储只增不减。托管服务各有自己的计量。在每次推送都重新构建的平台上，构建分钟数要计费。在基础档之上，几乎所有地方的支持套餐都要另外付费。

开发和预发布环境会让其中大部分翻倍，除非缩小规格或夜间停机。请问清楚流量为当前三倍时总价是多少，因为那才是您真正会遇到的数字。这类计量被藏起来的惯常做法，在定价页面不会告诉您的事中有说明。

可移植性，以及如何保持

这个分类里的锁定很少是戏剧性的，它是一项项方便的服务逐渐累积起来的。

容器和标准运行时可以迁移。专有的函数、队列、身份服务和数据库则不行，每采用一个，离开的成本就高一分。当服务确实省下实际工作时，这是合理的取舍；如果只是省了一个下午，就不划算。

把基础设施定义成文件，而不是在控制台里点出来，并且完整地从零搭建一遍。从这次练习中学到的东西，比任何对比表都更有价值。

让平台匹配应用

带数据库的标准Web应用，托管平台就能很好地胜任，对几乎任何没有专职运维人员的团队来说，省下的时间都值得多付的溢价。

后台处理、队列和定时任务会改变局面，因为无服务器模式处理长时间运行的任务很差，有些平台甚至根本没有地方放它们。

任何有特殊要求的场景，无论是特定硬件、持续高流量，还是严格的数据驻留，往往会把选择推向原生云或专用机器。

静态网站属于低价一端，要正经地提供服务，常常一分钱不用花。

请根据工作负载的形态来决定，而不是根据公司的规模。小团队也会运行要求苛刻的应用，大公司也常常只运行简单的应用。