本周的系统设计复习：
- 负载均衡器 vs API 网关
- 什么是 MCP？
- REST vs gRPC
- 基于会话 vs 基于 JWT 的身份认证
- 最常用 Linux 命令速查表
负载均衡器 vs API 网关
负载均衡器和 API 网关都位于客户端和后端服务器之间。但它们做的事情非常不同，混淆它们会在架构中造成实际问题。
负载均衡器只有一项工作：分发流量。客户端从 Web、移动或 IoT 应用发送 HTTP(s) 请求，负载均衡器将这些请求分散到多个服务器实例上，这样没有单个服务器会承受所有负载。
它处理：
- 流量分发
- 健康检查以检测宕机的服务器
- 故障转移
- L4/L7 负载均衡，取决于你是按 IP 还是按实际 HTTP 内容路由
API 网关的功能远不止于此。它也接收来自相同类型客户端的 HTTP(s) 请求，但它不只是转发流量，而是控制什么可以通过以及如何通过。
- 速率限制以防止滥用
- API 聚合，这样客户端不需要调用五个不同的服务
- 可观测性用于日志记录和监控
- 身份认证和授权，在请求接触后端之前就处理
- 请求和响应转换，在客户端和服务格式之间重塑负载
在大多数生产设置中，负载均衡器和 API 网关一起使用。API 网关在前面处理智能工作——速率限制、认证、路由到正确的微服务。然后它后面的负载均衡器在该服务的实例之间分发流量。
它们不是竞争工具。一起使用时效果最好。
什么是 MCP？
模型上下文协议（Model Context Protocol，MCP）是 Anthropic 引入的一个新系统，用于使 AI 模型更强大。
它是一个开放标准（也作为开源项目运行），允许 AI 模型（如 Claude）连接到数据库、API、文件系统和其他工具，而无需为每个新集成编写自定义代码。
MCP 遵循客户端 - 服务器模型，有 3 个关键组件：
- Host（主机）：AI 应用程序（如 Claude），为 AI 交互提供环境，以便可以访问不同的工具和数据源。主机运行 MCP 客户端。
- MCP Client（MCP 客户端）：AI 模型（如 Claude）内部的组件，允许它与 MCP 服务器通信。例如，如果 AI 模型想要来自 PostgreSQL 的数据，MCP 客户端将请求格式化为结构化消息发送到 MCP 服务器。
- MCP Server（MCP 服务器）：这是连接 AI 模型到外部系统（如 PostgreSQL、Google Drive 或 API）的中间人。例如，如果 Claude 分析来自 PostgreSQL 的销售数据，PostgreSQL 的 MCP 服务器充当 Claude 和数据库之间的连接器。
MCP 有五个核心构建块（也称为原语）。它们在客户端和服务器之间分配：
- 对于客户端：Roots（安全文件访问）和 Sampling（请求 AI 帮助完成任务，如生成数据库查询）
- 对于服务器：Prompts（指导 AI 的指令）、Resources（AI 可以引用的数据对象）和 Tools（AI 可以调用的函数，如运行数据库查询）
REST vs gRPC
在 REST 和 gRPC 之间选择起初看起来很简单，但最终会影响你的服务如何通信、扩展甚至崩溃。
两者都试图解决相同的问题：服务如何相互通信。但它们的方法不同。
数据格式
- REST 通常使用 JSON。它是人类可读的、易于调试的、到处都能用
- gRPC 使用 Protocol Buffers（Protobuf）。它是二进制的、体积更小、处理更快
你在性能密集型系统中开始注意到这种差异。JSON 很方便，但 Protobuf 是为效率而建的。
API 风格
- REST 是基于资源的：
/users/101配合 GET、POST、PUT、DELETE - gRPC 是基于方法的：
GetUser()、CreateUser()、UpdateUser()
REST 非常适合公共 API。gRPC 则更像是在调用另一个服务上的函数。
通信模型
- REST 是简单的请求/响应。一个请求，一个响应
- gRPC 支持更多模式：unary、服务器流式、客户端流式和双向流式
当你需要实时更新或长连接时，流式变得非常有用。
API 合同和类型安全
- REST 合同通常单独定义（OpenAPI/Swagger），仍然可能出现不匹配
- gRPC 使用共享的.proto 文件，具有严格的类型和代码生成
使用 gRPC，客户端和服务器都来自相同的定义，因此在集成过程中遇到的问题更少。
缓存和浏览器支持
- REST 与 HTTP 缓存、CDN 和浏览器配合良好
- gRPC 浏览器支持有限（通常通过 gRPC-Web），且与 HTTP 缓存不太适配
基于会话 vs 基于 JWT 的身份认证
每个 Web 应用都需要身份认证。但登录后的管理方式比大多数开发人员意识到的更重要。
有两种主流方法：基于会话和基于 JWT。它们解决相同的问题但方式不同。
基于会话的身份认证：用户登录，服务器创建会话并将其存储在会话存储中。客户端获得一个 session_id cookie。在后续每个请求上，浏览器发送该 cookie，服务器查找会话以验证它。
状态存在于服务器上。这是关键权衡。它很简单且易于撤销，但现在你的后端必须管理该会话存储。
基于 JWT 的身份认证：用户登录，服务器验证凭据，然后使用密钥或私钥创建并签名令牌。该令牌发送回客户端。在后续每个请求上，客户端将其作为 Bearer 令牌在 Authorization 头中发送。服务器验证签名并读取声明。不需要会话存储。
状态存在于令牌本身中。服务器保持无状态，这使得水平扩展变得简单。
Linux 常用命令速查表
Linux 有数千个命令。大多数工程师每天使用大约 20 个左右的命令，不是因为 Linux 有限，而是因为这个核心集合处理了大部分实际工作：导航文件、检查日志、调试进程、检查系统健康状态以及在压力下修复问题。
这个速查表按类别映射了最常用的 Linux 命令：
- 文件管理基础：ls、cd、cp、mv、rm，你经常无意识地使用它们
- 文件查看和编辑：cat、less、head、tail、nano、vim，当日志很大且时间紧迫时
- 文本处理：grep、awk、sort、diff，将原始日志转换为答案
- 权限：chmod、chown，因为某些东西总是因访问问题而崩溃
- 网络命令：ssh、scp、curl、ping、ss、ip，用于调试远程系统
- 进程和系统检查：ps、top、htop、df、free、uname，查看机器实际在做什么
- 归档、包管理、系统控制和帮助命令，将所有内容粘合在一起
本文为学习目的的个人翻译，译文仅供参考。
原文链接：EP208: Load Balancer vs API Gateway。
版权归原作者或原刊登方所有。本文为非官方译本；如有不妥，请联系删除。