如果现在让你在 Linux 上部署一个 Web 服务，大多数人的第一反应还是 Nginx。

这很正常。

Nginx足够成熟，性能也没什么好怀疑的。反向代理、静态文件、负载均衡、HTTPS，基本什么都能干。

所以第一次看到 Caddy 时，我其实也有一个疑问：

Nginx 都这么成熟了，还有必要再写一个 Web Server 吗？

而且 Caddy 还是 Go 写的。

后来真正用过以后，我觉得 Caddy 有意思的地方，并不是"Go 写的，所以比Nginx 更先进"。

它真正重新考虑的是另外一个问题：

如果今天重新设计一个 Web Server，它默认应该帮开发者做好哪些事情？

这篇就来聊聊 Caddy。

1. Caddy 到底是什么？

简单来说，Caddy 就是一个使用 Go 编写的现代 Web Server。

它可以做：

静态文件反向代理HTTPS负载均衡HTTP Gateway

比如最常见的反向代理：

api.example.com {    reverse_proxy localhost:8080}

如果只是看这个功能，其实没什么特别的。

Nginx 一样能做。

Caddy 真正让我觉得舒服的，是后面的事情它也顺手帮你做了。

比如 HTTPS。

2. Caddy 最出名的能力：自动 HTTPS

以前部署 HTTPS，一般是：

Nginx  +Let's Encrypt  +Certbot

然后还要考虑：

证书申请证书保存自动续期Nginx Reload

这套方案已经非常成熟，也没什么问题。

但 Caddy 的想法更直接：

既然现在 HTTPS 已经是网站的标配，为什么还要把它当成一个额外功能？

所以你只需要：

example.com {    reverse_proxy localhost:8080}

只要域名、DNS、80/443 端口这些条件正常，Caddy 就会自动处理证书。

整个过程变成：

Domain  |Caddy  |ACME  |Certificate  |HTTPS

证书续期也是自动的。

这其实就是 Caddy 和很多传统 Web Server 最大的思路差异之一：

HTTPS 不是"配置出来的功能"，而是默认能力。

3. Caddyfile 为什么这么简单？

再看一个稍微完整一点的例子。

前端：

example.com {    root * /var/www/web    try_files {path} /index.html    file_server}

后端：

api.example.com {    reverse_proxy localhost:8080}

一个典型的：

Vue / React    |Caddy    |Go API

基本几行配置就结束了。

如果项目不复杂，我个人其实挺喜欢这种方式。

配置短，能看懂，也没太多魔法。

Caddyfile 的设计目标本来就不是把所有底层细节暴露出来，而是尽量描述：

我想让这个域名做什么。

4. 但 Caddyfile 其实不是它真正的配置格式

这里有一个挺有意思的设计。

Caddy 真正的原生配置其实是：

JSON

Caddyfile 更像是给人写的配置语言。

流程大概是：

Caddyfile    |Config Adapter    |   JSON    |  Caddy

为什么这么设计？

因为：

Caddyfile

适合人维护。

而：

JSON

更适合程序生成和修改。

这就引出了 Caddy 另外一个我觉得比较有意思的地方。

5. Caddy 不只是读配置文件，它还有 Admin API

传统 Web Server 的配置方式通常是：

修改配置   |检查配置   |Reload

Caddy 当然也能这么用。

但它同时提供 Admin API。

也就是说：

程序 |HTTP API |Caddy |更新配置

你可以让其他程序去动态修改：

RouteUpstreamHandlerTLS

这时候 Caddy 就不只是一个"读配置文件启动"的 Web Server 了。

它开始有一点：

Programmable Web Server

的感觉。

如果以后要做自己的运维平台、网关管理程序或者动态路由系统，这种设计就很有价值。

6. 为什么这种设计很适合现在的基础设施？

以前服务器变化不大：

一台机器几个服务IP 基本固定

改一次 Nginx 配置，可能几个月都不用动。

但现在越来越多系统变成：

ContainerKubernetesService DiscoveryDynamic RoutingAutomation

配置不一定来自人。

也可能来自：

平台ControllerAPI自动化程序

所以 Caddy 的：

JSON Config+Admin API

其实很符合现在这种基础设施越来越动态的方向。

不过有一点要注意。

Admin API 权限很高，生产环境不要随便暴露到公网。

这个和数据库管理端口一个道理。

7. Caddy 和 Traefik 有什么区别？

前面我们刚写过 Traefik。

它们有不少共同点：

GoReverse ProxyHTTPS动态配置云原生

但两者的重心还是不太一样。

Traefik 最有代表性的设计是：

Provider

它特别擅长从：

DockerKubernetesConsul

这些基础设施里自动发现服务。

所以我更愿意把 Traefik 理解成：

面向动态基础设施的入口网关。

而 Caddy 更像：

重新设计过使用体验的通用 Web Server。

简单粗暴一点：

Traefik    |Docker / Kubernetes 更有优势 Caddy    |VM / 单机 / 通用 Web / 自动 HTTPS 很舒服

当然，这不是绝对边界。

只是选型时可以先这么理解。

8. 为什么 Caddy 要用 Go？

这个问题其实很容易被带偏。

有人会直接变成：

Go vs CCaddy vs Nginx谁性能更高？

我觉得没太大必要。

Caddy 选择 Go 真正明显的收益，是工程层面的：

单二进制跨平台内存安全并发模型简单网络标准库成熟部署方便

比如一个 Caddy：

caddy

拷过去基本就能运行。

Linux、macOS、Windows、Container 都比较自然。

所以：

Caddy 的重点不是用 Go 把 Nginx 重写一遍，而是利用 Go 重新做一套 Web
Server 的工程体验。

这两件事区别还是挺大的。

9. Caddy 的模块化也很有 Go 味道

Caddy 2 的核心是高度模块化的。

很多能力都可以扩展：

HTTP HandlerDNS ProviderStorageAuthenticationLayer 4Security

整体可以理解成：

Caddy Core               |     +---------+---------+     |         |         |    HTTP      TLS      Storage     |         |         |  Modules   Modules   Modules

核心负责框架。

具体能力通过模块扩展。

这种：

Interface+Composition

的设计，对 Go 开发者应该很熟悉。

10. Caddy 适不适合 Go Web 项目？

我觉得挺适合。

例如一个很普通的项目：

Browser   | Caddy   |+------+------+|             |Vue          Go API              |          PostgreSQL

Caddy 可以负责：

HTTPS静态文件反向代理压缩访问日志

Go 服务就专心写业务。

如果只有一两台服务器，又没有复杂网关需求，我甚至觉得这种方案比一上来Kubernetes + Ingress 简单太多。

能解决问题就行。

完全没必要为了"云原生"把简单项目搞复杂。

11. 什么情况下我还是会选 Nginx 或 Traefik？

如果是成熟传统服务器环境：

Nginx

依然很稳。

如果大量使用：

DockerKubernetesIngressService Discovery

那我会优先看看：

Traefik

如果是：

VM / 单机Go Web自动 HTTPS简单反向代理

我会很愿意用：

Caddy

简单总结：

场景                                     我更倾向

成熟传统 Web 基础设施             Nginx  

Docker / Kubernetes 动态网关   Traefik  

单机 / VM / 中小型 Web            Caddy  

自动 HTTPS 优先                     Caddy  

已有大量 Nginx 配置资产            Nginx

没有谁一定替代谁。

场景不同而已。

12. Caddy 有没有缺点？

当然有。

首先，生态和历史积累肯定没法和 Nginx 比。

遇到一个非常偏门的问题：

Nginx

大概率搜一下就有人踩过。

Caddy 的资料量还是少一些。

其次，如果项目高度依赖：

OpenRestyLua复杂 Rewrite公司内部 Nginx Module

那迁移 Caddy 基本没什么必要。

另外 Caddy 自动化程度比较高。

好用的时候很舒服。

但出了问题，你还是得懂：

DNSTLSACMECertificateHTTPReverse Proxy

所以自动 HTTPS 并不意味着：

不需要懂 HTTPS。

只是不用每次重复配置而已。

总结

Caddy 从来都不是：

把 Nginx 用 Go 重写一遍。

如果只是这么理解，其实就把它看小了。

它真正重新设计的是：

今天的 Web Server，默认应该帮开发者做好什么？

Caddy 给出的答案大概是：

HTTPS 默认自动配置尽量简单程序可以动态控制核心保持模块化现代协议持续跟进最终还是一个二进制

Nginx 依然成熟，也依然值得用。

但成熟并不意味着没有重新设计的空间。

如果是大型公司，已经有完整 Nginx 运维体系，我不会为了用 Caddy 而用Caddy。

但如果是一个新的中小型 Go Web 项目，几台服务器，需要HTTPS、静态文件和反向代理，我现在反而会很愿意先试试 Caddy。

原因也很简单：

能让 Web Server 自己解决的事情，就没必要再额外维护一套脚本和工具。

Caddy 最吸引我的地方，其实也就是这一点。

没有想取代谁。

只是把很多以前需要手工处理的事情，变成了默认能力。

阅读原文：原文链接