xhj的博客

中间件：请求管道 什么是中间件？中间件是位于传入请求和控制器/处理程序之间的函数（或组件）。 它可以： 检查请求 修改请求 阻止请求 修改响应 记录请求 添加安全检查 在你的控制器运行之前。 将中间件视为： 进入主楼前的安全检查站。 🏗 中间件在流程中的位置客户↓中间件1↓中间件2↓中间件3↓控制器（处理程序）↓服务↓存储库↓数据库 每个请求在到达控制器之前都会经过中间件。 为什么需要中间件？没有中间件： 控制器过载 安全逻辑被重复 记录逻辑到处重复 难以执行全球政策 中间件解决： 集中安全 集中记录 集中验证 更清洁的控制器 更好的可扩展性 它解决了什么问题？重复问题而不是在每个控制器中编写身份验证逻辑： 12if not verify_token(): return 401 真实示例流程用户发送请求： 12GET /profileAuthorization: Bearer eyJhbGciOiJIUzI1NiIs... 步骤 1️⃣ CORS 中间件 检查：此前端域是否允许？ 如果不是：立即拒绝请求 步骤 2️⃣ 速...

什么是后端？后端是在服务器上运行的应用程序的一部分监听 HTTP、WebSocket、gRPC（gRPC 远程过程调用）或其他协议等请求。 它负责： 接收来自客户端的请求（浏览器、移动应用程序、其他服务） 处理逻辑 与数据库和外部服务通信 将响应发送回客户端 后端服务在特定端口上运行（例如3000、5000、8080）以便客户可以通过互联网访问它们。 后端被称为服务器，因为它提供以下服务： 静态文件（HTML、CSS、JS） 动态数据（JSON、文件、媒体） 前端和移动应用程序使用的 API 后端如何工作（高级流程）生产中的典型请求流程： 客户端（浏览器/应用程序）→ DNS 服务器（解析域）→ 负载均衡器（AWS/云）→ 防火墙/安全规则→ 服务器实例（EC2/虚拟机/容器）→ 网络服务器（Nginx / Apache）→ 后端应用程序（Node.js、Java 等）→ 数据库/外部服务→ 回复客户 为什么我们需要后端？考虑这个例子： 您喜欢您朋友在 Instagram 上发布的帖子。您的朋友立即收到...

三层模式（真实项目的干净架构）在构建可扩展的后端系统（API、机器人、Web 应用程序）时，我们将职责分层。 为什么？ 因为将所有内容混合在一个文件中会导致： 意大利面条代码 硬调试 硬测试 硬缩放 客户改变需求时的痛苦 所以我们使用： 什么是三层模式？它是一种代码组织结构，将应用程序分为三个逻辑层： 1.处理层（表示层）2.服务层（业务逻辑层）3. 存储库层（数据层） 每一层都只有一个职责。 简单的想法。强大的影响力。 为什么需要它？想象一下您的 OMR Streamlit 应用程序。 如果您： 检测图像 分析答案 转换为 JSON 存储在 MongoDB 中 返回响应 全部都在一个函数内…… 现在客户说： “存储在 PostgreSQL 而不是 Mongo 中。” 现在你必须修改一切😵 但如果你使用图层： 仅存储库层发生变化。 应用程序的其余部分保持不变。 这就是清洁工程。 它解决了什么问题？ 无层 分层 乱码 清洁分离 调试困难 轻松调试 难以测试 简单的单元测试 紧耦合 松耦合 改变打破一切 更改仅影响一层 该模式解...

HTTP 基础知识HTTP（超文本传输协议）是网络上的交流。 HTTP 的核心基于两个基本思想： 无状态模型 客户端-服务器模型 1.无状态模型HTTP 遵循 无状态 通信模型。 无状态意味着服务器不记得之前与客户的任何互动。每个 HTTP 请求都被视为一个全新的请求。 无状态意味着什么？ 每个请求都包含所有必需的信息 信息通过以下方式发送： 标题 网址 方法（GET、POST 等） 身体（如果需要） 一旦服务器发送响应，它就会丢弃该请求 下一个请求被认为是独立的 换句话说，HTTP 请求是独立的。 无状态模型的好处1. 简单无状态系统更容易设计和维护因为服务器不需要存储客户端会话数据。 2. 可扩展性由于服务器上没有存储会话状态，请求可以分布在多个服务器上使用负载平衡器。 3. 可靠性如果一台服务器出现故障，另一台服务器可以处理请求而不丢失会话数据。 4. 状态管理的灵活性虽然HTTP本身是无状态的，应用程序可以使用以下方式保持连续性： 饼干 会议 令牌（JWT、OAuth） 这些机制构建于HTTP之上，不是 HTTP 本身的一部分。 2. 客户端-服务器模型HT...

错误处理和容错系统 后端工程师实用参考——技术深度、浅显易懂 1. 心态错误是不可避免的您无法阻止每个错误 - 目标是快速检测、遏制和恢复。停止思考*“我如何阻止它损坏？”并开始思考“当*损坏时会发生什么？” 容错心态在最坏的情况发生之前就进行设计。即使内部组件出现故障，构建良好的系统也能保证用户交易无缝进行。 2. 常见错误类型A. 逻辑错误 🔴 最危险的类型 — 无声故障，没有崩溃或异常 系统继续运行——没有崩溃，没有例外——但它产生错误的结果。这些都是无声的杀手：表面上一切看起来都很好，但实际上却有错误的数据流过。 为什么它们很难捕捉： 没有可见的崩溃或堆栈跟踪 该应用程序似乎运行正常 通常是通过错误的输出或用户投诉发现的——为时已晚 现实世界的例子： 电子商务折扣计算中的错误导致系统“向用户付款”而不是向他们收费——负交易价值仅出现在财务报告中。 根本原因： 误解业务需求 算法实现不正确 未考虑边缘情况 预防策略： 强大的单元+集成测试 边缘情况验证（例如最低价格 = 0） 专注于业务逻辑的代码审查 监控异常输出值（例如负交易金额） 影...

1. 问题：关系数据库的限制⚠️ 效率低下带通配符的标准 LIKE 查询（例如 %laptop%）会触发全表扫描，这使得它们的计算成本很高，并且随着数据集扩展到数百万条记录而变得越来越慢。 ⚠️缺乏相关性传统的 SQL 查询返回匹配没有排名或相关性评分。这意味着结果没有优先顺序，例如，一本“关于”机器学习的书与仅简要提及它的书被视为相同。 ⚠️ 可扩展性问题随着系统扩展（例如，亚马逊或谷歌等平台），需要亚毫秒级搜索延迟。传统的关系数据库很难有效地满足这些性能需求。 用于搜索的关系数据库的其他限制⚠️ 全文搜索支持不佳关系数据库并非专为高级全文搜索功能而设计，例如： 代币化 词干提取（例如，“运行”→“运行”） 同义词处理与专用搜索引擎相比，这使得搜索不太智能。 ⚠️没有内置排名算法没有对相关性评分算法（例如 TF-IDF 或 BM25）的本机支持，而这些算法对于对搜索结果进行有意义的排名至关重要。 ⚠️ 难以处理拼写错误和模糊搜索关系数据库面临以下问题： 拼写错误（例如，“laptpo”而不是“laptop”） 近似匹配实现模糊搜索既复杂又低效。 ⚠️ 有限的水平可扩展性...

使用 PostgreSQL 掌握数据库核心概念为什么选择数据库？从本质上讲，数据库是一个旨在跨不同会话保留信息的系统。持久性确保数据即使在创建数据的程序或进程终止后也能继续存在。 存储层次结构：RAM 与磁盘现代后端系统通过利用不同的存储介质来平衡速度和成本： 特色 内存中 (RAM) 磁盘（SSD/HDD） 速度 极快 比 RAM 慢 成本 贵 相对便宜 坚持 易失性（断电后丢失） 非易失性（持久） 示例 Redis、Memcached PostgreSQL、MongoDB、MySQL 数据库管理系统 (DBMS)DBMS 是一个软件层，其唯一职责是高效地向客户端提供 CRUD 操作： Create：插入新数据。 Read：查询现有数据。 Update：修改当前记录。 Delete：删除数据。 DBMS 的职责：1）数据的组织——DBMS 定义了数据的结构方式（通常为表、行和列），以确保数据以逻辑方式存储并可以有效地检索。它管理磁盘上的物理存储，因此开发人员不必担心原始文件管理。 2）访问——CRUD操作该系统提供标准化接口（如 SQ...

配置管理 控制应用程序行为方式的一切 - 无需触及任何逻辑代码。 核心类比 角色 🧠 代码 大脑——逻辑 🧬 配置 DNA——行为规则 ⚙️ 结果 相同的代码 + 不同的配置 = 完全不同的行为 如果 DNA 很混乱 → 即使是健康的大脑也会表现出不可预测的行为。 01 — 配置实际涵盖什么配置经常被误认为只是“秘密”。事实上，它控制的更多： 应用程序设置 端口号 日志级别（debug / info / error） 连接池大小 超时持续时间 数据库配置 主机和端口 用户名/密码 数据库名称 连接字符串 外部服务 电子邮件 API（例如 SendGrid） 付款（例如 Stripe） 身份验证（例如职员） 云存储 功能标志 仅为测试版用户启用功能 A/B 测试和逐步推出 终止开关可立即禁用有缺陷的功能 业务规则 最大订单限制 会话到期时间 折扣门槛 速率限制 性能和日志记录 缓存大小 重试限制 队列并发 日志详细程度（开发中的调试，产品中的错误） 02 — 环境及其优先级相同的代码库...

什么是缓存？缓存是一种机制，旨在通过在高速存储层中存储数据子集来减少延迟和计算开销。这使得对该数据的后续请求的处理速度比从其主要（且速度较慢）源获取数据的速度快得多。 现实世界的例子 平台 使用案例 效益 谷歌搜索 缓存常见查询的结果（例如“天气”） 避免为每次搜索重新运行昂贵的排名算法 Netflix 边缘站点的 CDN（内容交付网络） 通过从最近的服务器提供视频来最大限度地减少缓冲 X（推特） 将“热门话题”存储在 Redis 等内存存储中 避免实时分析数十亿条推文 🌦 缓存 Google 天气数据此示例演示了用于处理缓慢变化数据的高频请求的**Cache-Aside（延迟加载）**策略。 🛠 工作流程 用户请求： 用户搜索“伦敦天气” 缓存查找： 后端检查 Redis（内存存储） 是否有键 weather_london 缓存命中：找到数据→在<1ms内返回 **缓存未命中：**数据丢失/过期 → 转到步骤 3 Heavy Lift： 从 外部天气 API（例如 OpenWeather）获取新数据 慢（~500ms） 每...

从第一原理学习后端工程的好处假设您是一名软件工程师，并且您被分配到修复大型生产代码库中后端错误的任务。 您可能会面临几个挑战： 后端语言或框架可能不熟悉 代码库可能庞大且复杂 可能没有明确的起点 您必须遵循现有的架构和标准 你无法承担破坏生产系统的后果 或者想象一下您被要求从头开始构建一个 API。问题立即出现： 我应该从哪里开始？ 我应该如何构建代码？ 我如何遵守公司标准？ 我如何设计它以实现可扩展性和可维护性？ 现在考虑另一种情况：您主要使用 TypeScript 或 Go，但是您需要修复的错误是用 FastAPI 或其他不熟悉的堆栈编写的。逐行阅读文档既缓慢又低效。 这就是从第一原理学习后端变得强大的地方。 从第一原理学习意味着什么？从第一原理学习意味着理解后端系统的核心是如何工作的，而不是记住语法、框架或库。 它的重点是： 请求如何流经系统 数据如何验证、处理和存储 不同后端组件如何交互 为什么系统以某种方式设计 主要优点1. 纵观全局的能力而不是迷失在复杂的代码库中，您可以在心里将系统分解为以下组件： 路由 控制器 服务 中间件 数据库层 您开始识别模式...