【WIT】编程百问一

01 什么时postman？

Postman 是一款专门用于帮助开发人员处理 API 的工具，它的作用主要有以下几个方面：

• 方便调试 API：就像你打电话给别人要先拨对号码一样，开发人员要让不同的软件系统之间通过 API 进行通信，也需要发送正确的请求。Postman 可以让开发人员很容易地创建各种类型的请求，比如 GET、POST、PUT、DELETE 等，然后发送给 API，并查看 API 返回的响应。这就好像你拨了号码后，能立刻听到对方的回答，帮助你判断这个 “电话” 有没有打通，以及对方有没有给你正确的信息。

• 测试 API 功能：开发人员可以使用 Postman 来编写测试脚本，检查 API 的响应是否符合预期。比如，你可以设置一个测试，要求 API 返回的状态码必须是 200（表示成功），或者返回的内容中必须包含某个特定的字段。这就像是给 API 出了一套试卷，通过 Postman 来批改试卷，看看 API 是否合格。

• 管理 API 请求：一个项目中可能会有很多个 API，Postman 可以把相关的 API 请求组织成集合，就像把同类的文件放在一个文件夹里一样，方便开发人员进行管理和复用。这样，当需要再次使用某个 API 请求时，就可以直接从集合中找到，而不用重新编写。

• 模拟 API 响应：在开发过程中，有时候前端开发人员需要等待后端开发人员完成 API 才能进行测试，这会浪费很多时间。Postman 的 Mock Server 功能可以模拟 API 的响应，让前端开发人员可以先假设后端 API 已经完成，并且按照自己的需求来设置 API 返回的数据，从而提前进行开发和测试。这就好像你在等朋友来给你送东西，但你可以先自己假装朋友已经把东西送来了，然后继续做自己的事情。

• 生成 API 文档：Postman 可以根据你创建的 API 请求和测试用例，自动生成 API 文档。这些文档可以帮助其他开发人员了解 API 的功能、请求方式、响应格式等信息，就像一本使用说明书，让大家都能清楚地知道如何使用这个 API。

02 什么是微服务架构？

要理解微服务架构，先从生活里的例子入手 —— 比如把 “一家大餐厅” 和 “一条美食街” 做对比：

假设你要做一个复杂的系统（比如外卖平台、电商 App），传统的做法是把所有功能都塞进一个 “大程序” 里（像一家大餐厅，后厨又要做炒菜、又要做甜品、又要做饮品，收银、外卖打包也都在同一个店里）；而微服务架构，就是把这个 “大程序” 拆成一个个独立的 “小服务”（像一条美食街，有专门做炒菜的店、专门做甜品的店、专门负责收银的店、专门负责外卖配送的店），每个 “小店” 只干自己最擅长的事，彼此之间通过 “电话 / 消息” 沟通配合，最终一起完成整个系统的工作。

微服务的核心特点（用 “美食街” 再解释）：

1. 每个服务只干一件事
   比如 “用户服务” 只管用户注册、登录、存用户信息；“订单服务” 只管创建订单、查订单状态；“支付服务” 只管对接微信 / 支付宝付款 —— 就像美食街里 “面馆只做面，奶茶店只做奶茶”，不跨界，专注高效。

2. 服务之间独立运行
   就算 “订单服务” 临时出问题（比如打印机坏了），“用户服务”（用户登录）、“商品服务”（看商品）照样能正常用 —— 不会像大餐厅后厨着火，整个餐厅都停业。

3. 服务之间能 “沟通”
   当用户下订单时，“订单服务” 会主动找 “商品服务” 确认 “这个商品还有货吗”，找 “用户服务” 确认 “这个用户是正常用户吗”，找 “支付服务” 发起 “付款请求”—— 就像面馆接到订单后，会喊 “配菜店” 送菜、“饮料店” 搭饮料，彼此靠 “喊话（接口）” 配合。

4. 每个服务能独立升级 / 修改
   比如想给 “支付服务” 加一个 “刷脸支付” 功能，只需要改 “支付服务” 这一个小模块，不用动其他所有服务 —— 就像奶茶店想加 “无糖选项”，只改自己的菜单，不用通知面馆、水果店。

为什么要用微服务？（解决传统 “大程序” 的痛点）

传统做法（叫 “单体架构”）就像把所有东西塞一个大箱子里：

• 箱子越装越满，找个东西要翻半天（代码越来越复杂，改个小功能要动一大片）；

• 箱子某一个角坏了，整个箱子都没法用（一个小功能出 bug，整个系统崩溃）；

• 想给箱子加个小格子，得把整个箱子拆了重拼（想加新功能，要重新部署整个系统）。

而微服务就像把大箱子拆成多个小盒子，每个盒子独立：

• 找东西只翻对应小盒子（改功能只动单个服务）；

• 一个小盒子坏了，其他正常用（故障不扩散）；

• 加新功能，直接加个新小盒子（新增服务，不用动旧的）。

举个实际例子：外卖 App 的微服务拆分

打开外卖 App 的一个 “下单” 动作，背后是这些独立服务在配合：

1. 你点 “下单” → 先调用「订单服务」，创建你的订单；

2. 「订单服务」找「商品服务」：“用户买的这 3 个菜还有货吗？”（确认库存）；

3. 「订单服务」找「用户服务」：“这个用户地址对不对？有没有黑名单记录？”（确认用户信息）；

4. 「订单服务」找「支付服务」：“发起支付，金额 29 元”（跳转付款）；

5. 支付成功后，「支付服务」告诉「订单服务」：“钱收到了”；

6. 「订单服务」再告诉「配送服务」：“有个订单要送，地址是 XX”（分配骑手）。

整个过程中，每个服务各司其职，缺了谁都不行，但谁出问题都不影响其他环节。

最后补一句：微服务不是 “越拆越小越好”

就像美食街不会拆成 “只煮面条的店”“只切葱花的店”—— 拆得太细，服务之间要沟通的次数就太多（比如煮面要找切葱花的、找煮蛋的、找盛碗的），反而会变麻烦。所以微服务的核心是 “合理拆分”，拆到每个服务既能独立负责一块功能，又不用频繁和其他服务沟通。

03 什么是 nginx 的代理转发功能

Nginx 的代理转发功能可以简单理解为 “中间人” 或 “中转站” 的作用 —— 它能接收来自客户端的请求，然后把这个请求转发给其他服务器（比如后端 API 服务、静态资源服务器等），再把服务器的响应结果返回给客户端。

举个生活例子：你（客户端）想联系小明（后端服务），但不知道小明的电话，于是你打给了小李（Nginx），小李知道小明的电话，他帮你把话传给小明，再把小明的回复告诉你。这里小李就扮演了 “代理转发” 的角色。

代理转发的核心作用：

1. 隐藏真实服务器地址
   客户端只需要知道 Nginx 的地址，不用知道后端真正处理请求的服务器地址，提高安全性。比如你访问 www.xxx.com（Nginx 地址），实际请求可能被转发到内网的 192.168.1.100 服务器，但你感知不到。

2. 解决跨域问题
   前端开发时，浏览器有 “跨域限制”（比如前端在 localhost:5173 不能直接访问 localhost:8000 的接口）。这时可以让 Nginx 接收前端请求，再转发到后端，因为 Nginx 转发不算浏览器的跨域请求。

3. 统一入口管理
   一个系统可能有多个后端服务（比如用户服务、订单服务），可以通过 Nginx 按路径转发到不同服务。例如：

   • 所有 /api/user 开头的请求，转发给用户服务（192.168.1.101）

   • 所有 /api/order 开头的请求，转发给订单服务（192.168.1.102）
     客户端只需要访问 Nginx 一个入口，不用关心具体哪个服务处理。

简单配置示例（核心代码）：

假设 Nginx 运行在 localhost:80，要实现：

• 访问 http://localhost/api 时，转发到后端 API 服务（localhost:8000）

• 访问 http://localhost 时，返回前端静态页面（本地 dist 文件夹）

nginx

# Nginx 配置文件片段
server {listen 80;  # Nginx 监听 80 端口server_name localhost;# 前端静态资源：直接返回本地文件location / {root /path/to/frontend/dist;  # 前端打包后的文件夹路径index index.html;}# API 请求：转发到后端服务location /api/ {proxy_pass http://localhost:8000/;  # 转发目标地址（后端服务）proxy_set_header Host $host;  # 传递原始请求的主机信息proxy_set_header X-Real-IP $remote_addr;  # 传递客户端真实 IP}
}

这样配置后：

• 当你在浏览器访问 http://localhost，Nginx 会返回前端页面；

• 当前端代码请求 http://localhost/api/user，Nginx 会转发到 http://localhost:8000/user，后端处理后，结果再通过 Nginx 返回给前端。

总结：

Nginx 的代理转发就像一个 “智能中转站”，帮客户端对接各种后端服务，同时解决跨域、地址隐藏、请求分流等问题，是前后端分离架构中非常常用的功能。