噔噔！欢迎来到我的空间

恭喜来到这个课题的最后一个 Day 。

假设您已经掌握了之前的所有内容——那么现在的您，应该已经拥有了初步的开发程序并将它在生产环境下运行起来的能力。如果没有也没关系，因为今天内容中也会再提及一些先前的内容，或许能给您带来更多的思考与理解。

今天主要是以我个人的部署流程习惯为主题，讲讲一些剩下的细细碎碎的内容。这里没有太多的技术性知识，更多的是一些探讨，分析一些过去出现过的问题，以及我如何想办法去解决（或缓解）它们的思路。

实名制

有些人可能以为网购实名制是中国特色，但其实不尽如此。在涉及法币交易的场合，国际的一些服务商也会使用名为 KYC (Know your customer) 的反洗钱 (AML) 政策进行用户身份认证，并且个别 boomer 也要求用户使用护照上的真实姓名进行注册。

当然，也不是所有的商家都是如此刁难。主流的商家使用信用卡认证，即在注册时登记信用卡信息，它们会在信用卡上发起一笔小数额（一般是 1 美分，有时也可能会更多）的测试交易，确认信用卡是有效的之后就认为用户不是欺诈。一般这笔交易都会在几天内撤销，但也有些商家不撤销交易而是将其作为账号余额保存。

部分商家会对用户注册和下单时使用的 IP 地址进行检测，如果用户使用的是机房的 IP （例如一般的代理服务器）的话会认为这是欺诈的订单。这没什么办法，找一个干净点的 IP ，或者弄一张境外手机卡开漫游流量注册吧。

部分后付费服务的商家的实名认证策略会相对较为严格一些，但一般也都是上传护照信息人工审核之后就会放行。个别商家存在歧视国人的现象，看到的时候注意需要避避雷。

但这并不意味着可以随便在个人信息里面乱写，比如 ashjihdifuai 这样的 Street Name 肯定就不像是一个正常用户能填出来的东西了。

心仪的服务器

是否需要服务器

现在很热门的一个潮流话题是云计算，或者说「无服务器计算」(Serverless computing)，例如 FaaS 或是 PaaS 等。它的一大好处就是让开发者可以免于 DevOps 工作，由服务提供商来实现运行平台的统一和应用的部署工作。

一些比较经典的服务类型比如：

各种托管静态网站的 Pages 服务（如 GitHub Pages 或 Cloudflare Pages ）
无服务器函数部署服务（如 Vercel 或 Cloudflare Workers ）
容器级别的应用部署（如 Heroku 或 DigitalOcean App ）

对我来说，因为我同时掌握一些开发和运维的知识，所以我还是更喜欢将服务器掌握在自己手里的感觉。但不得不承认的是，使用面板管理服务器可能会导致各式各样的安全隐患，而直接使用命令行执行一些底层的维护工作也实在有些劝退一般初学者，所以如果只是想专注于开发工作但又找不到好的伙伴来帮助打理服务器的话，可能确实使用无服务器计算方案会比较方便安全——通常只要付远远更多的钱就行了。

但对于一些静态网站托管服务，例如 Cloudflare Pages 或是 GitHub Pages ，我也是用得不少的——免费又方便，何乐而不为呢。只是写写前端项目的话，使用它们就完全足够了。

如果想要入门运维知识，接触一些服务器基础管理相关的指令的话，可以先从一些入门配置的服务器入手尝试。

VPS 还是独服

从操作逻辑上来讲， VPS （Virtual Private Service ，虚拟私有服务器）和独服（独立服务器，也有人谐音称「杜甫」）不存在什么区别；但从资源利用的角度来讲，由于 VPS 广泛存在超售现象，实际可用的性能往往受到邻居的限制，在需要性能的场合体验并不如独服好（即便是所谓独占方案的 VPS ，本质上都是虚拟化资源划分出来的，真要独占了几个核心商家那得是做多大的慈善啊）。因而，在需要资源的场合，我还是尽量推荐找独服商家，即使是洋垃圾也比被瓜分走的洋垃圾要好多了。

但在不需要性能，只需要一个能用的服务器的场合，那么一般使用 VPS 的价格会比独服更便宜一些。

有没有推荐的商家

这就是一个很值得展开来讲讲的问题。

市面上主要分为两种商家：

一种是卖服务 (service) 的，比如 AWS GCP Azure 阿里云腾讯云这种，特点是乱七八糟的计费点又多又杂，稀奇古怪的计费条目鳞次栉比，计费率极其恐怖，一不小心稍微多用点资源（比如半夜服务器被人打了）一觉醒来就要砸锅卖铁还欠债的；但好处是出了任何它们的可用性 (SLA) 降级问题都可以逮着它们要求对业务损失给出赔偿；
另一种是卖服务器 (server) 的，就是字面意义上的提供服务器，价格标得清清楚楚，一般也不会太计较流量费用（机房共享大带宽网络，占用别太过分就行，一些奇葩提供商除外），基本上又便宜又好用，但遇到什么非设备问题基本只能自己想办法解决（硬件问题商家会换，只需要处理好这段维修时间的停服损失就行了，或者自建集群来提升容灾能力）。

作为一个一般用户，我肯定会推荐第二种商家，并且强调除非必要否则千万别碰第一种商家，见到过太多前一天还是热情满满的初学者，一醒来发现自己成了倾家荡产的大负翁的案例了。

但需要注意的是这并不意味着第二种商家全都是好东西：比如此处点名批评 Vultr ，不知道为什么总是有好多新手被忽悠着去买了它们家的服务（价格也不便宜啊，咋回事捏， aff 给的高所以各路博主拼命推？）。它们会平白无故因为完全无厘头并且哪里都没写的理由封禁用户账号，并且前段时间还爆出了宣布对用户在它们处托管的数据拥有完全永久商业化权力的用户条款。

为避免可能存在的商业推广嫌疑，这里就不写具体的商家名称了。熟悉我的伙伴们应该知道我喜欢用哪家的服务，或者如果不太熟悉的话，也可以去看看各方面的评测和推荐。作为一个提示：许多家没有特点的 $5/mo 1C 1G 的 VPS 已经算贵的了，市面上有更便宜更好用的服务器可以选择。

以及，主流的国际服务商大多是提供 Visa 或者 MasterCard 这两大发卡机构的信用卡支持的。如果您想使用更多更好更棒的服务器，推荐您去办理一张对应卡标的信用卡。

心仪的域名

互联网的流量入口曾经是域名，是网站，是一个任何设备上都能打开运行、不需要任何安装配置的、全平台通用的东西。而不应该是一大坨「包罗万象」的垃圾桶吃掉越来越多的存储空间。

在我们暂时还有余力坚持本心的情况下，先来回顾一下这一段曾经鼎盛时期的辉煌成就吧。

注册一个域名

注册一个域名，说简单也简单，说难也难。简单的是随便找个合规的注册商，选中域名，付钱，结束。难的是为啥那么多人被骗去高价注册商（比如 GoDaddy ）交莫名其妙的学费？

在具体了解这一些之前，我们先要了解一些和域名相关的基础知识。

域名的分类

一般的 TLD （Top-level domain ，顶级域名，就是比如 nya.one 这种）分为两类： gTLD 和 ccTLD 。

gTLD 是指一般的顶级域名，这些域名由 ICANN 审核对应提交的申请，并分发交由大型机构或公司管理。这些域名的末尾最少为 3 位，不设上限。
ccTLD 是指国别（country-code）域名，例如中国的 .cn ，美国的 .us ，日本的 .jp ，欧盟的 .eu ，台湾的 .tw 等。值得一提的是，一些乍看之下不像国别域名的 .me .io 这类，其实也是国别域名。简单来说，所有两字母的都是国别域名。这些域名交由对应国的政府机构委派公司进行管理。

gTLD 的好处就是它不受不同国别地区的政治影响（如苏联解体后 .su 域名可以视作绝版了），代价则是为避免撞车，它最短也是三位后缀，这使得它在提供简单好记的短链接上并不如 ccTLD 来得好用。而一些 ccTLD 也有对应的注册要求，如 .eu 域名要求注册人是欧盟公民， .cn 域名要求注册人实名认证等等。对我来说，非特殊情况下我会尽可能选择 gTLD 而不是 ccTLD ，但一些使用广泛的 ccTLD 其实也没什么问题。选择自己最喜欢的就好。

注册局与注册商

简单来说，注册局 (registry) 就是背后实际管理域名的 to-B 机构，注册商 (registrar) 则是和注册局达成某些交易之后面向终端用户销售域名的 to-C 机构。注册局将域名额度批发给注册商，注册商再稍微加一些管理手续费销售给用户，这样大家都开心。

有的注册商良心大大滴坏，会加上各种乱七八糟巧立名目的收费让原本便宜的域名卖出天价，请注意注册局并不会因此受益——它们也被蒙在鼓里，并且只要注册商和它们正常交易那么它们也不会在乎。而也有的注册商非常良心，从高价区稍微多收点钱补贴低价区的域名，让大家都用得起域名，注册局也不会因此损失；但有时低价区的用户会比对应区的总人口数量还要多，聪明的您知道这是为什么吗？

溢价域名

有的域名很好记，对吧？注册局也知道，所以它们会专门挑出来这些域名标上高价，这就是溢价域名。溢价域名一般以短域名（少数字母或数字）、单词或特定组合的域名为主，根据注册局的不同会有不同的注册与续费政策：如有些域名的注册价高而续费正常价，有些域名的注册价和续费价都很高。一般注册商在提供查询服务时候都会给出注册价和续费价，如果没有的话选择两年的价格减去一年的价格一般也就是续费价了。

我对溢价域名的看法是：如果价格可以接受，并且续费价格正常，那么可以入手试试。我也有一些溢价域名，但因为相关的事项排得比较满，很多项目还没具体部署起来所以实际上还在吃灰。谨慎买米。

注册年限

ICANN 规定的域名注册的有效期最多为十年，即比如今年 2024 年注册，那么最多能注册到 2034 年。续费时也是最多延长到十年，比如 2028 年续费一次，那么它能延长到 2038 年，而不是 2044 年。

一般来说我会建议用一年续一年，但考虑到目前各种主流域名都在涨价（万恶的始作俑者 Verisign ），对一些确实喜欢的域名就还是直接拉满十年吧。

同时，这也意味着所有超过十年的注册期都是不可信的。有人说能提供百年服务？拜托洗洗睡吧，百年老字号公司也才几家呢，十年之后世界说不定就大变样了，百年之后更是想都不敢想了。

无理由退货期

是的，有些注册商也提供域名的试用服务——在注册的一段时间内（例如 3 天）撤销订单的话，可以全额退款（手续费除外）。需要注意的是这条规则与注册商自己的策略有关，并不是所有的注册商都提供这种服务，因而一般在下单域名的时候还请谨慎，不是抢注的时候多检查检查总是好的。

但对于一些尴尬的情况，例如大半夜赶项目不小心打错了域名，或者发现原定的域名之前被滥用上了广告拦截黑名单之类的，那么这个策略就会显得非常救命稻草了。

不过溢价域名未必会享受同等的服务，具体还是参见相关的注册商策略，并且最好不要用到它吧。

查询注册信息

域名的注册信息称为 Whois 信息，在 ICANN 于 2018 年规定注册商使用 Whois 信息保护策略之后，除了个别国别域名有规定外其他的域名均已经实现了注册商信息保护，因而不用担心相关的隐私信息泄露，目前 Whois 的主要用途就是查询域名的状态了。

ICANN 有一个官方的 Whois 查询工具，但它支持的域名并不多，遇到它不支持的情况的时候就还是选择其他的查询提供者吧。查询 Whois 信息是免费的，虽然未必会有人借此恰烂钱（说不定还真有？），但还是值得在这里强调一句的。

有没有推荐的商家

是的，又是这个老生常谈的问题了。同样为了避免商业推广嫌疑，这里我也不详细展开说商家的名称了。熟悉我的伙伴们知道我喜欢哪一家的服务，不熟悉的也可以试试阅读一下其他人的推荐资料，例如 tld-list 这个信息整合网站，它们提供了更全面详细的域名级别注册商比较（但它收了好处的，还请注意火眼辩真相）。

免费域名与 Public Suffix

以前经常会看到说可以在 Freenom 注册免费的 .tk 或是 .ml 之类的域名，但它们在 2023 年被 Meta (Facebook) 起诉导致停止了服务，不知道未来还是否能注册。

另外一种比较有趣的是 Public Suffix ，这是一种理论上免费的二级域名（不是顶级域名），但与一般二级域名不同的是它们可以被完整地设置 DNS 、扩充次级域名等，基本可以理解为一种等效的 TLD (effective TLD) 来使用。

Public Suffix 的不同注册商也有各自的规则，有些注册商也提供免费的服务，一般请以对应注册商制定的规则为准。

需要注意的是 Public Suffix 并不受 ICANN 的保护，这也意味着如果注册商作恶（例如针对大流量域名收保护费，或是劫持域名等等），并没有什么机构可以来约束它们。请自行斟酌相关的风险。

配置 DNS 提供商

有了域名之后，就需要找一个合适的 DNS 提供商负责解析服务了。

一般来说注册商自己会带一个 DNS 解析服务，通常情况下来说已经足够使用，但出于方便管理和使用的角度考虑，我目前还是使用了 Cloudflare 作为我们的 DNS 服务的提供商。

免费的 DNS 提供商一抓一大把，如果有什么机构向您收取所谓的 DNS 管理费用，那么这大概率不是个好东西。

DNS 服务也不需要实名制，如果有什么商家要求您实名认证之后才可以使用，那么我的建议是立刻跑，跑得越远越好。

为域名配置 DNS 非常简单，在注册商处修改形如 Name Servers 的记录就可以，一般 DNS 提供商会提供对应的教程以供参考。

使用 CDN 优化网络访问

有些 DNS 提供商同时提供 CDN (Content Delivery Network) 服务。什么是 CDN ？

从定义上来说， CDN 就是一个专门负责内容分发的网络。通常的 CDN 有缓存和回源两大流量方向，在设置了规则之后可以选择将静态资源缓存以便直接分发给终端用户，而将 API 调用之类和具体数据相关的请求回源给源站负责处理。并且针对需要回源的请求， CDN 也可以通过内部精选的路由设计，根据不同的使用场合需求，以延迟低或是带宽大的路径进行回源优化，让用户获得比直接请求源站更好的使用体验。

提供商的解决方案

经典的 CDN 解决方案较为依赖网络基础设施建设，因而主要以大型服务商提供的商业服务为主，并且许多都是卖服务而不是卖服务器的商家。但这里要点名表扬一位造福大众的 CDN 提供商 Cloudflare ，它们提供越来越多的免费服务造福一般用户，并且包含了自带的源站保护策略，某种意义上也可以称为一种互联网行业的慈善组织了。

可惜的是，因为它们太好了，所以中国政府特意利用 GFW 劣化了国内网络与 Cloudflare 的几大数据中心之间的互通性，让默认解析得到的 Cloudflare IP 丢包率高到基本不可用的程度。 Cloudflare 确实有中国网络优化的合作方案，但那是在企业版中才有的套餐，非企业版用户使用 Cloudflare 可能反而会变成减速器。

自己动手优化链路

有什么办法能优化一下中国用户的国际互联网使用体验呢？这就要提到一些选择网络的技巧了。因为相关的内容我并不专业，所以在这里也就不多展开来讲了。

获得了针对中国的跨境流量优化服务器之后，我们就可以自己动手来实现一些类似 CDN 的反向代理加速功能，以优化一些墙内用户的使用体验。

但需要注意的是，如果没有特殊的分地区 DNS 解析设置，而是让所有的流量都从代理站经过的话，可能对于墙外用户来说体验未必良好。对于目标用户群体较为广泛的服务请谨慎配置反向代理加速。

选择一个 Web Server

一个 Web Server 作为主要的业务服务入口，承载着支撑起大部分业务流量的任务，因而选择一个合适的 Web Server 就显得非常重要了。

不同场景，不同方案

如果您面向的是较为早期的系统开发，那么一定遇到过推荐使用 Apache httpd 的服务。事实上随着它的不断发展，要说它过时的话倒也大可不必，它现在也已经支持了 TLS 1.3 甚至是 HTTP/2 这种新时代的科技。但因为过去它的性能并不如 nginx 好，所以很多时候会遇到使用 httpd 作为承接 PHP 应用的 vhost 层（ .htaccess 确实方便），使用 nginx 作为前端反向代理和静态资源缓存层的组合配置方案。

在它们出现的年代，容器化和云计算还没这么盛行，因而它们的配置都是非常严谨、精确的，这也意味着它们不够灵活。举个例子来说，一说到 nginx 对反向代理站点的配置文件，您脑海里浮现出来的一定是一大段一大段的模板化配置，但既然它们都可以被模板化了，又没有什么办法直接就省略掉这些重复的东西呢？

新时代的 Web Server，例如我在单机部署服务时常用的 Caddy ，或是在 k8s 集群部署服务常用的 traefik ，则可以更好地胜任快速发展的新需求。一个 Caddy 配置块最短只需要三行就可以完成一个反向代理站点的配置，并且会自动获取管理 TLS 证书； traefik 支持动态配置加载技术，设置使用集群模式之后，它会自动从标签中拉取需要代理的服务配置信息，无需任何手工重载操作就能自动化实现管理。

例如，如果我们想承接 nya.one 的流量反向代理到本地的 3000 端口，可以这样写：

Caddyfile

nya.one {
    reverse_proxy localhost:3000
}

如果是 nginx 的话，是这样的：

nya_one.confrevproxy.conf

server {
  listen 443 ssl;
  listen [::]:443 ssl;
  http2 on;
  server_name nya.one;

  ## SSL
    ssl_certificate /etc/nginx/ssl/nyaone/cert.pem;
    ssl_certificate_key /etc/nginx/ssl/nyaone/key.pem;

  ## Reverse proxy
    location / {
      proxy_pass http://127.0.0.1:3000;
      client_max_body_size  0;
      include conf.d/shared/revproxy.conf;
    }
}

proxy_http_version 1.1;
proxy_cache_bypass $http_upgrade;
proxy_set_header   Upgrade             $http_upgrade;
proxy_set_header   Connection          "upgrade";
proxy_set_header   Host                $host;
proxy_set_header   X-Real-IP           $remote_addr;
proxy_set_header   X-Forwarded-For     $proxy_add_x_forwarded_for;
proxy_set_header   X-Forwarded-Proto   $scheme;
proxy_set_header   X-Forwarded-Host    $host;
proxy_set_header   X-Forwarded-Port    $server_port;

因此从我的个人看法讲，如果您需要部署服务，我一定会推荐 Caddy 或是 traefik ，现代化的工具多香呀。但这并不意味着 nginx 就过时了，很多管理面板还是喜欢使用 nginx 作为主要的 Web Server ，如果您需要使用面板的话，或许稍微多了解一些 nginx 相关的知识会更方便理解一些吧。

负载均衡

还记得我们在 Day 6 里提到的容器水平扩容吗？当我们为容器分配了一些连读的端口之后，应该怎样有效地反向代理它们呢？

以 Caddy 为例，直接写连续的端口就行了，就像这样：

Caddyfile

nya.one {
    reverse_proxy localhost:3001-3008
}

Caddy 也可以指定更多负载均衡参数，具体可以参见 Caddyfile 文档的 Load balancing 部分的详细说明，此处就不多赘述了。

如果您使用的是其他的 Web Server ，例如 nginx 或是 traefik ，它们也有各自的负载均衡策略，具体可以参见各自的文档。

签发 TLS 证书

以前请可信 CA 签一张 TLS 证书是很贵的，要花不少钱才能申请办理，并且因为这些机构都没有 to C 的业务所以经常需要找分销商加价购买。但自从 Let's Encrypt （或简称 LE ）这个慈善组织开始提供免费证书起，免费的 TLS 加密快速发展，如今甚至已经简化到什么都不用配置，就能使用网页服务器自动完成 TLS 证书的签发和管理工作了。目前也有不少机构，例如 ZeroSSL 或是 Google 也支持免费的证书签发，因而可以在不同的提供商之间选择自己最喜欢的那个。

您可能听说过使用 acme.sh 或是 certbot 配合 nginx 来实现自动化的证书签发与管理工作。而使用 Caddy ，我们可以什么都不用做！ Caddy 在默认情况下就会尝试为服务签发证书，除非使用 tls 选项指定使用证书，并且证书中包含了待使用的域名才可以绕过。

在使用 HTTP-01 验证的情况下，只需要将域名解析到我们的服务器，就可以自动完成证书的认证和签发。而如果我们想要使用泛域名证书 (wildcard) ，我们需要使用 DNS-01 验证：在 DNS 上添加一条指定的 TXT 记录，用来验证自己拥有对这个域名的管理权。

这也就是为什么我们要使用一个热门的 DNS 提供商了，因为对于热门提供商来说往往会有优化的支持和文档帮助。证书管理工具未必会支持一些冷门提供商的 DNS 管理 API ，这就意味着有时可能会需要多引入一些组件来完成证书签发，不但增添了不稳定性，而且可能会导致更多的维护问题。

另外，如果您使用 CDN 来优化访问的话，有时您可以自己签发源站证书——它们使用起来更方便，并且可以设置很长的有效期，面向终端用户的请求则由 CDN 提供商来实现加密工作。

管理好服务器

为了能更为有效地管理好服务器，这是我想到的一些办法。

监测实时运行状态

正如 Day 6 中提到的那个 docker-compose 项目所述，我们可以使用 Grafana + Prometheus + NodeExporter 的组合来获取服务器的所有信息，并配合相关的信息状态及时给出可能需要的告警数据。

在我的配置里， NodeExporter 运行在各个具体的服务器上，负责暴露服务器的所有数据指标； Prometheus 和 Grafana 运行在专用于状态监控的服务器上，由 Prometheus 定时轮询记录各个服务器的数据， Grafana 负责可视化它们。

是谁没有收到邀请？是 influxdb ，它是用来接收来自 Proxmox VE 主动向它请求发送的状态数据的，如果您有部署 Proxmox VE 的需求，记得不要忘记带上它哦。

或者，您可能听说过 netdata 这个项目。它曾经也是非常好用的，但随着它们的商业化气息越来越严重，我感到的只有一些说不出的难受滋味。所以现在我们只保留了一个公开服务的数据面板使用的是 netdata ，内部的数据监测就还是更多地使用 Grafana 了。

我以前也听说过 Zabbix 并尝试搭建过，但我没弄明白它的配置是怎么回事，就放弃了。

安全无小事

保护服务器的安全总是一件很重要的事，要是辛辛苦苦攒钱抢购买到的服务器因为配置安全隐患导致被攻击者抢走做成了肉鸡就麻烦了。我并不是做安全的专家，因此我只能从一些非常浅显的角度来讲一讲我目前正在使用的安全策略，希望能给您带来一些启发。如果您有更好的安全建议，也非常欢迎发在评论区，帮助每一位阅读者一起进步。

使用 VPN 保护服务器入口
这里的 VPN 是狭义上的 Virtual Private Network ，也就是通过一些软件将公网上的服务器组成一个私有的虚拟局域网，从而确保一些未经加密的数据不会直接在公网上裸奔的工具；不是指那些被谬传成 VPN 的正向代理 (forward proxy) 工具。
部署的方案有很多，比如可以基于 WireGuard 自己搭建 p2p 的虚拟局域网，或是使用如 ZeroTier 或 Tailscale 这样的中心化商业 VPN 提供服务的解决方案。但因为 p2p 的网络配置起来相当麻烦，中心化商业服务存在数据安全隐患，所以我实际使用的是 nebula 这个工具。它有些类似主从架构但又同时兼顾了 p2p 的高容错性，只需要配置好几个主服务器（在 nebula 架构里叫做 lighthouse 灯塔），让其他的从服务器都连接到这些主服务器就可以实现各个服务器之间的互通了。
例如，我们将 sshd 设置为仅监听来自这个内网 IP 的请求，并在 nebula 配置中设置为仅允许来自指定 tag 的客户端连接：这样即使某天我们的某个服务器忘记设置禁止 root 登录和禁止密码认证了，攻击者依然没有办法通过公网发起暴破攻击。
避免源证书泄露
在 nginx 的默认配置里，如果没有创建一个用于给 443 端口 fallback 的 default server 的话，它会自动使用第一个 443 端口的 server 用于 fallback 。不巧的是，如果刚好这个 server 使用了一张名称与域名对应的 TLS 证书，那么这就会被扫描工具发现，从而间接泄露源站地址。
可以创建一个形如这样的 server 块来避免出现上述这种情况：
```
server {
  listen 443 ssl default_server;
  listen [::]:443 ssl default_server;
  server_name _;
  ssl_reject_handshake on;
}
```
1
2
3
4
5
6
在防火墙配置入站白名单
如果一种防护工作能在防火墙完成，那么就没有必要再让应用端承受无谓的流量冲击。
例如，可以在防火墙仅开放 80 和 443 的 TCP 端口和 VPN 使用的端口，拒绝其他所有端口的连接，以避免有时因配置失误导致意外安全隐患的出现。
防火墙也是尽可能选择靠前的，如果提供商有提供边缘防火墙的话，就尽可能使用它，避免让流量落到服务器上：即使是把流量黑洞掉也是需要消耗资源的，如果入站请求量太大的话光是防火墙的处理也会耗尽服务器的资源。

一些零碎的补充

使用 CI/CD 自动化部署与发布
很多工作都可以交给自动化流水线来实现，设置好之后一劳永逸地自动管理，并且不容易出错。
目前主流的代码托管平台都已经具备了自带的 CI/CD 功能，如 GitHub 有 Actions ，GitLab 有 Pipeline ， Forgejo / Gitea 有类似于 GitHub 的 Actions 。对于一些不具备上述功能的代码托管平台来说，一些像是 Jenkins 的第三方解决方案也可以满足自动化相关的需求。
具体到各平台的配置也都大同小异，主要就是遵照着官方文档，把构建的流程走一遍就可以。或者说其实 Dockerfile 也是一种 CI 工作流定义，如果有需要的话直接参考它来准备流程也很不错？
存储与运算分离
这算是一个程序设计的思路：对于一些以文件形式管理的数据，可以使用比如说 S3 的兼容服务，将它们分离到独立的存储优化服务器上面去，或是直接部署到一些提供商对应的在线存储平台中。
虽然 AWS 确实是 S3 的开山鼻祖，但它的价格实在太劝退了，换用其他费用合理一点的服务商吧。

今日总结

大概主要还是一些碎碎念的内容，反正差不多当个闲聊的话题看看就行，没有特别实际的东西所以也不用太记在心上。

可能唯一有价值的是几个列入黑名单的商家？我看到太多被这些家伙坑害的友友了，能多救一个是一个。

今天也没有什么课后挑战，好好休整一下，想想之前几个 Day 的内容，有什么感兴趣的再多多去尝试尝试，这大概就算是一个可以长期坚持的有趣挑战吧。

噔噔！欢迎来到我的空间 ​

实名制 ​

心仪的服务器 ​

是否需要服务器 ​

VPS 还是独服 ​

有没有推荐的商家 ​

心仪的域名 ​

注册一个域名 ​

域名的分类 ​

注册局与注册商 ​

溢价域名 ​

注册年限 ​

无理由退货期 ​

查询注册信息 ​

有没有推荐的商家 ​

免费域名与 Public Suffix ​

配置 DNS 提供商 ​

使用 CDN 优化网络访问 ​

提供商的解决方案 ​

自己动手优化链路 ​

选择一个 Web Server ​

不同场景，不同方案 ​

负载均衡 ​

签发 TLS 证书 ​

管理好服务器 ​

监测实时运行状态 ​

安全无小事 ​

一些零碎的补充 ​

今日总结 ​

噔噔！欢迎来到我的空间

实名制

心仪的服务器

是否需要服务器

VPS 还是独服

有没有推荐的商家

心仪的域名

注册一个域名

域名的分类

注册局与注册商

溢价域名

注册年限

无理由退货期

查询注册信息

有没有推荐的商家

免费域名与 Public Suffix

配置 DNS 提供商

使用 CDN 优化网络访问

提供商的解决方案

自己动手优化链路

选择一个 Web Server

不同场景，不同方案

负载均衡

签发 TLS 证书

管理好服务器

监测实时运行状态

安全无小事

一些零碎的补充

今日总结