从零搭建网站：像搭积木一样组合云服务

假设你想做一个叫「周末去哪儿」的小网站，记录自己的周末出游。第一篇就写《周末去海边》，放上几张照片，再把链接发给朋友。

听起来很简单。可一打开云服务的页面，迎面就是云服务器、数据库、对象存储、DNS、CDN。一篇游记还没发出去，先被一堆名字挡住了。

我们就从这个小网站出发：先让朋友能看到文章，等他们想留言了，再添新功能。每遇到一个具体问题，就认识一块能帮上忙的「积木」。

云服务，先理解成网上可以租用的几种能力

一篇文章放在自己的电脑上，你能打开，朋友却不能直接从网上看到。你当然可以把自己的电脑配置成服务器，但还要让它持续开机、联网，并且能够接收外面的访问。

云服务把这些工作拆成了可以直接使用的服务：需要一台能运行程序的电脑，就租计算能力；需要地方保存照片，就租存储空间。机器实际仍然放在机房里，只是你通过网络使用它们，不用自己去买机器、接电源和网线。

这种通过网络、按需要取得计算和存储等资源的方式，就是云计算的一部分。对搭网站来说，可以先记住一句话：把通用的能力交给云服务，自己决定网站的内容和功能。

网站本身仍然需要准备。你可以自己写页面、套一个模板，或者使用现成的博客程序。云服务负责给它一个能被访问、能运行、能保存东西的地方。

先发出第一篇游记：静态托管

先把网站做得很简单：首页只有一段自我介绍，一篇《周末去海边》，再配三张照片。做好以后，它们是一组网页文件和图片文件。

把这组文件交给静态托管服务，服务就负责保存它们，并在朋友访问时发送给浏览器。「托管」可以直接理解为：交给别人帮你放着、对外提供访问。

你交给服务：介绍页、海边游记、三张照片。

服务给你：一个可以打开网站的访问地址。

朋友点开链接：浏览器拿到这些文件，显示出文章和照片。

这里的「静态」说的是网页文件已经提前准备好。页面可以有动画，也可以点按钮切换照片；这些效果能在朋友的浏览器里完成。比如一个介绍自己的作品集，就很适合从这一步开始。

过了一周，你又写了《周末去爬山》。重新生成并上传网站文件，朋友就能看到新文章了。这个把新版本放到网上的动作，通常叫「部署」。

到这里，一个能分享的个人网站已经有了。先用托管服务给的地址就可以，不必一开始把所有云服务都开通。

想给网站一个自己的名字：域名、DNS 和 HTTPS

服务给的地址可能比较长。你希望朋友记住一个属于自己的名字，以后网站搬家，发出去的地址也能继续用。

域名就是这个容易记住的名字。下面用 www.example.com 作示意。注册域名，得到的是在约定期限内使用这个名字的权利；文章和照片仍然放在前面的网站托管里。

DNS负责回答「这个名字现在指向哪里」。它很像通讯录：你记住朋友的名字，通讯录帮你找到电话号码；浏览器拿到域名后，通过 DNS 查询找到网站的入口地址。

域名：www.example.com，是朋友输入的名字。

DNS：告诉浏览器，这个名字对应的网站入口在哪里。

托管服务：真正把文章和照片发给朋友。

所以，买好域名以后还要接两头：在托管服务里告诉它「这个域名属于我的网站」，再按提示设置 DNS，让这个名字指向服务给出的目标。将来更换托管服务，就相应地更新这两头的设置。

HTTPS则保护浏览器与网站之间的连接。例如，你登录后台写文章时，密码不该明文传过网络。HTTPS会加密传输，浏览器也会检查网站提供的证书与所访问的域名是否匹配。

许多托管服务会协助配置和续期证书。先确认自己的域名能通过 https:// 正常打开即可。域名管名字，DNS 帮忙找地址，HTTPS 保护连接，它们各做一件事。

朋友想在文章下面留言：应用托管和数据库

现在，假设朋友小林在游记下面问了一句：「周日人多吗？」他希望点一下「提交」，你明天打开网站还能看到，其他朋友也能读到。

这时，提前准备好的网页文件就不够了。需要一段运行在网上的程序，接收小林的留言，检查内容，再把它保存起来。这样负责处理请求的程序，通常叫「后端」。

应用托管给这段程序提供运行的地方。你把程序交给平台，再告诉它怎样启动，平台负责把它运行起来、接收访问。具体怎样判断留言是否合适、谁能删除留言，还是由程序来决定。

数据库负责把一条条记录保存下来，并按条件找出来。可以先把它想成网站使用的一本有条理的记录簿。小林的留言会成为这样一条记录：

属于哪篇文章：《周末去海边》

谁留的言：小林

留言内容：周日人多吗？

第二天，你打开这篇游记，程序向数据库查找「属于这篇文章的留言」，再把结果交给页面显示。程序负责做事，数据库负责记住事情。这也是动态网站的一种常见工作方式。

同一套分工还能做别的功能。比如活动报名页：程序检查你填的姓名和人数，数据库留下报名记录；再比如在线写作：程序接收你刚写的文章，数据库保存标题和正文。

托管数据库，就是把数据库的安装和部分维护工作交给平台。你仍要告诉网站程序数据库的地址、账号和密码。建好数据库以后，留言功能不会自动出现，还得有程序把它们接起来。

已有的静态页面也能接上这样的留言服务，不一定要把整站推倒重来。也可以直接使用现成的评论系统，由它提供相应的后端和存储。

那云服务器又是做什么的？

你可能会发现，上面还没有单独买过「云服务器」。其实，运行这些服务的背后都有计算机，只是你交给平台管理的事情不同。

云服务器可以先理解为一台通过网络使用的电脑。你在上面安装网站程序，让程序一直运行，也可以自己安装数据库、保存图片。自由度比较高，软件更新、数据备份等事情也要自己安排。

• 静态托管：我准备好网页文件，你帮我把它们发给访客。

• 应用托管：我准备好程序，你帮我把它运行起来。

• 云服务器：给我一台远程电脑，我自己安装和管理需要的软件。

比如同样一个支持留言的博客程序，可以装在云服务器上，也可以交给支持它的应用托管。选哪一种，主要看程序能运行在哪里，以及你愿意自己照料多少事情。

照片越积越多：对象存储

写了几十篇游记以后，照片从三张变成了几百张。你想给照片找一个单独的地方，以后修改网站页面时，也不用把所有照片一起重新上传。

对象存储就是可以通过网络存取文件的服务，适合放照片、视频、音频和下载附件。「对象」这个名字不用想得太复杂，在这里，先把它看成一个文件，加上用来找到这个文件的名字或编号。

对象存储里：保存海边照片 seaside.jpg。

文章里：记录这张照片的访问地址或文件标识。

朋友读游记时：浏览器按照图片地址，把照片取回来显示。

数据库和对象存储的分工因此很直观：数据库记着「文章标题是《周末去海边》，配图是哪几张」，对象存储放着照片文件本身。前者方便查记录，后者方便存取文件。

这是一种常见搭法，并非每个小网站都要拆开。只有几张图片时，跟网页一起放在静态托管里就很好。需要单独管理文件时，再确认网站程序支持所选的对象存储服务。

公开游记的配图可以按公开资源提供；如果是只想给家人看的照片，还需要限制访问。把文件上传到云端，并不等于它会自动变成私有相册。

来看的人多了，图片有点慢：CDN

假设你的游记被转发了，很多地方的朋友都来打开同一组照片。每次都去原来的存储位置取，可能会等待较久，也会反复给原来的服务增加负担。

CDN，中文叫「内容分发网络」，会在不同地点的服务器上保存可重复使用的内容副本。读者再要同一张照片时，如果合适的副本已经存在，就有机会从更近的地方拿到。

可以把它想成分布在各地的小仓库。同一本书，不必每次都从总仓库远途寄出；当地有货，就从当地发。这里的「货」，就是图片、网页文件等内容。

这些临时保留的副本叫「缓存」。所以，换了照片以后，也要让旧缓存及时更新；而后台、私人照片这类内容，不能随意放进给所有人共用的缓存。很多网站托管已经包含 CDN，先看现有服务有没有，就不必重复加一层。

把这些积木连起来，看两件小事

不用把所有服务名称同时塞进一张图。我们就看朋友在网站上做的两个动作。下面假设网站已经有了留言功能，也把照片单独放进了对象存储。

所谓「连接服务」，落到实际操作上往往就是几件具体的事：在文章里填上图片地址，把数据库的地址、账号和密码交给后端程序，再让域名指向网站入口。数据库密码由后端程序保管，不能写进发给所有访客的网页文件里。

这些能力可以来自同一个平台，也可以分开使用。一个服务也可能已经包办几块积木。真正要看的是：它能帮网站做哪些事，还缺什么。

换一个网站，积木怎么选？

个人作品集：放自我介绍、项目说明和几张截图。先用静态托管；想有自己的地址，再接域名和 HTTPS。没有在线写入的需求，就不急着加数据库。

摄影作品网站：从静态托管开始。照片很多、希望独立管理时，可以增加对象存储；读者分散、加载较慢时，再检查图片大小和 CDN 是否合适。

周末活动报名页：除了展示活动，还要接收姓名、人数、保存报名结果。这就需要处理提交的程序和存储；也可以接入现成的表单服务，让它包办这部分。

所以，搭积木的起点是你要做的功能。先说清「我要让朋友看到游记」或者「我要收集报名」，再找到对应的服务，会比先研究一整页产品名称容易得多。

积木越来越多，程序也要拆开吗？

认识云服务以后，还会遇到「单体」「微服务」「云原生」「无服务」这些名字。它们讨论的是：网站的功能怎样组织，谁来负责让这些功能一起工作。周志明的《凤凰架构》梳理了这些想法的来历。借着这条线，我们继续看看「周末去哪儿」可以怎样搭。

先放在一个程序里。写游记、管理照片、处理留言，都由同一个后端程序完成，修改后一起发布，这就是一种单体架构。一个人维护小网站时，这样容易理解，也方便调试。它仍然可以使用外部的数据库和对象存储，单体并不等于所有东西都得放在一台机器里。

有独立需要时，再拆出一块。假设网站后来加了活动报名，另一位朋友专门维护报名功能，还希望单独更新它，就可以考虑把它拆成独立服务。面向服务架构（SOA）早就探索过怎样让不同业务服务复用、协作；微服务更强调围绕业务划分，让各部分能独立开发、部署和维护。

拆开也有代价：原来程序内部就能完成的事情，现在可能要通过网络找另一个服务帮忙。对方没响应怎么办？报名已经保存，通知却没发出去怎么办？功能更独立了，也多了需要协调的地方。

把通用的照料工作交给平台。程序退出后重新启动，访问多时多运行几份，把请求分给这些副本，这些事情可以借助平台能力完成。《凤凰架构》把这条思路放在「后微服务时代」讨论，也是理解云原生的一个入口：设计程序时，就考虑怎样和平台提供的运行、调度等能力配合。平台接手了一部分工作，应用本身的逻辑和数据仍要安排好。

还有些小事，可以等事情发生时再做。比如上传一张照片，就触发一小段程序生成缩略图，再把小图存回对象存储。你提供「怎样缩图」的代码，平台负责在收到事件时运行它。这叫函数计算，是无服务（Serverless）的一种常见用法。服务器仍然存在，只是你不用亲自管理运行这段代码的机器；数据库、存储等也可以使用现成服务。函数的运行时长、启动等待和费用，仍要看它是否适合这项任务。

书里还有一个贯穿始终的想法：允许部件出问题，同时设法让整体继续可靠地工作。放回我们的网站，就是照片暂时加载失败时，游记文字仍能阅读；留言保存失败时，保留刚输入的内容并提示重试，而不是显示「提交成功」。这些体验需要我们设计，不能只靠多开几项云服务来保证。

这些思路可以按需要组合。我们的游记网站完全可以一直保持单体，同时使用云数据库、对象存储，再接一个生成缩略图的函数。先把眼前的功能做好，等某一块确实需要独立更新或扩展时，再决定怎么拆。

用起来以后，留意花费和自己的东西

云服务的费用通常跟你用了多少资源有关。有的按运行时间收费，有的按存了多少文件、传出了多少数据收费，也可能按套餐计费。具体要看所选服务，不能只看「开通」那一刻的价格。

举个纯粹用来算量的例子：假设每次打开相册都要下载 10 MB 图片，打开 1000 次，就是大约 10 GB 的传输量。即使你只上传过一次照片，很多人反复查看，仍然会产生传输量。实际用量还会受缓存、图片压缩等影响。

第一次搭站，可以先放少量内容，查看用量和账单，设置费用提醒。再给自己留一份文章和图片的副本，弄清留言记录怎样导出。以后不想继续用某项服务，也能带着自己的内容离开。

先把一个能打开的链接发给朋友

回到「周末去哪儿」：第一天，把海边游记和三张照片放到静态托管，拿到一个能分享的链接。想有自己的名字，就接域名；想留下朋友的留言，就加处理留言的程序和数据库；照片需要单独管理，再考虑对象存储。

我想说的「像搭积木一样建站」，就是这样的过程：每多一个愿望，就找到一块合适的服务，把它接到已有的网站上。先完成一件小事，再让网站慢慢长成自己想要的样子。

想继续看看「点开一个链接以后发生了什么」，可以接着读 《Life of a Request：一次请求的一生》。