做 .NET 后端的人到了一定阶段都会碰到一个绕不开的问题业务越来越复杂单体应用里的代码越堆越乱几个模块互相牵连改一个功能牵扯出一堆回归流量稍微上来单机扛不住缓存和负载均衡都听过但真正要把 DDD 领域建模、Redis 缓存、Nginx 负载均衡组合到一起落地时又不知道从哪一步下手。这篇文章要聊的就是一套比较典型的企业级 .NET 落地组合AI 辅助 DDD 领域建模 Redis 高性能缓存 Nginx 负载均衡。这套组合解决的不是某一个接口的性能问题而是从业务建模、代码分层、缓存加速到流量分发的完整链路。适合已经写过一段时间 .NET、想往架构方向进阶的开发者也适合小团队在启动中大型项目前做技术选型参考。我会按实际落地顺序来拆先讲 AI 辅助 DDD 建模时怎么提问、怎么校对再讲项目骨架和 Redis 集成然后是 Nginx 反向代理与负载均衡配置最后给一套验收标准和排查链路。文章里给出的代码和配置都是常见的工程写法具体版本、端口、路径要以你的实际环境为准。1. 先想清楚DDD、Redis、Nginx 各自解决什么问题1.1 DDD 管的是业务复杂度不是技术复杂度DDD也就是领域驱动设计很多人一上来就背概念实体、值对象、聚合根、领域事件、限界上下文。背完后还是不知道怎么用。实际上 DDD 要解决的核心问题只有一个当业务规则足够复杂时怎么让代码结构跟业务结构保持一致而不是让业务迁就代码。如果你做一个简单的增删改查后台CRUD 就够了强行上 DDD 反而增加成本。但当你面对的是订单、库存、支付、对账、风控这些彼此关联的业务模块领域规则经常变化比如“下单时库存不足怎么办”“支付成功但订单已取消怎么处理”这时候用 DDD 把每个业务模块的边界划清楚把规则收敛到领域模型内部后期改需求才不会到处救火。企业级架构里先谈 DDD是因为负载均衡和缓存解决的是“系统快不快、稳不稳”而 DDD 解决的是“业务对不对、代码能不能持续演进”。顺序不能反。1.2 Redis 管的是高频读和跨节点共享Redis 不是所有场景都需要。它最擅长做的事是把热点数据放到内存里让高频读请求不压到数据库在多个服务实例之间共享会话、分布式锁、计数器、排行榜这类状态。企业级架构里 Redis 常见的定位是旁路缓存也就是先读缓存缓存没有再去查数据库再回填缓存。它跟 DDD 并不冲突DDD 负责领域模型的正确性Redis 负责读取路径的速度。你可以把聚合根序列化后放进 Redis也可以只缓存应用层组装好的视图模型关键看业务对一致性的要求。1.3 Nginx 管的是入口流量和可用性当同一个 .NET 服务部署了多个实例就需要一个入口把请求分发到不同实例上避免一台机器被打满、其他机器闲着。Nginx 在这里做的事情就是反向代理和负载均衡。反向代理的含义是客户端只访问 Nginx 的地址Nginx 再把请求转发到后面的真实服务。这样做的好处有三个一是对外只暴露统一入口二是可以按权重、连接数、IP 哈希等方式分发流量三是一台后端实例挂了Nginx 可以把流量切到其他健康实例提升整体可用性。这三层合起来才是一个相对完整的企业级架构DDD 保证业务模型稳定Redis 保证热点路径快Nginx 保证入口不单点。2. 用 AI 辅助 DDD 领域建模最怕的不是 AI 不聪明2.1 先画清限界上下文再让 AI 生成聚合根AI 辅助 DDD 建模本质上是把 AI 当成一个“熟悉 DDD 概念但完全不熟悉你业务的顾问”。它能快速给出模板、候选模型和常见反例但它不知道你的业务规则也不知道你的历史包袱。所以正确的顺序是你自己先梳理业务再让 AI 帮你补全和纠错。第一步是划分限界上下文。我一般会先把核心业务列成几个高层次的业务域比如订单域、库存域、支付域、用户域。每个域内部有自己独立的模型域与域之间通过接口或事件通信。这一步不要急着写代码先在文档或白板上把每个域的职责边界写清楚。当你有了这个上下文清单再让 AI 帮你细化某一个域。比如你可以在对话里这样提问“我现在要设计一个电商系统的订单域限界上下文已经确定订单域主要负责下单、取消、支付结果处理。请帮我梳理订单域内的候选聚合根、实体和值对象并标注出聚合根应该负责哪些不变式。”这种提问方式比“帮我设计一个电商系统”有效得多。因为你先给 AI 限定了边界它的输出才能收敛在你需要的范围内。2.2 让 AI 产出候选模型然后人工校对AI 给出的建模结果要当成“候选人简历”不是“最终录用名单”。常见的做法是让 AI 分别输出三样东西候选实体清单、聚合根划分建议、聚合根内的不变式规则。举个例子AI 可能会建议把 Order 和 OrderItem 放在同一个聚合内理由是“订单明细必须跟随订单一起持久化保证总金额和明细一致”。这个建议通常是合理的因为 OrderItem 离开 Order 没有独立意义而且修改明细时你必须重新校验订单总金额。但 AI 也可能会建议一些看起来合理、实际和你的业务冲突的模型比如把支付单也放进订单聚合里。如果你的业务允许一个订单分多次支付或者允许支付单独立退款、独立对账那支付就应该单独拆成聚合而不是塞进 Order。这种判断只能由懂业务的人来做。我建议把 AI 生成的模型拿到业务评审会上过一遍问几个关键问题一个聚合里修改两个对象时事务边界是否清晰业务上的不变式比如“订单金额 明细金额合计”是否只能在聚合根内部保证两个聚合之间的数据一致性是接受最终一致还是必须强一致这些问题 AI 不能替你回答但它能帮你把问题提得更具体推动评审会讨论到点子上。2.3 领域层代码结构怎么组织AI 辅助建模完成之后落到 .NET 项目里通常按四层结构组织代码目录可以直观对应 DDD 的概念避免把领域逻辑散落在 Controller 里。OrderService.sln src/ Order.Domain/ # 领域层实体、值对象、聚合根、领域事件、仓储接口 Order.Application/ # 应用层命令、查询、DTO、应用服务、模型映射 Order.Infrastructure/ # 基础设施层EF Core 实现、Redis 缓存、外部接口 Order.Api/ # 表现层Controller、Middleware、配置绑定 tests/ Order.UnitTests/ # 单元测试重点覆盖领域规则 Order.IntegrationTests/ # 集成测试覆盖仓储和缓存领域层不引用任何基础设施这是 DDD 里很关键的一条约束。它的意思是Order 聚合根不关心数据是存在 SQL Server 还是 MySQL也不关心 Redis 的 key 怎么设计。这些属于基础设施层的实现细节。聚合根的写法有一个典型的模板public class Order : AggregateRoot { public Guid Id { get; private set; } public string OrderNo { get; private set; } public decimal TotalAmount { get; private set; } public OrderStatus Status { get; private set; } private readonly ListOrderItem _items new(); public IReadOnlyCollectionOrderItem Items _items; private Order() { } public static Order Create(string orderNo, Guid customerId) { var order new Order { Id Guid.NewGuid(), OrderNo orderNo, Status OrderStatus.Pending }; return order; } public void AddItem(string productName, decimal unitPrice, int quantity) { if (quantity 0) throw new DomainException(商品数量必须大于0); _items.Add(new OrderItem(productName, unitPrice, quantity)); TotalAmount unitPrice * quantity; } }像上面这种代码没有必要一定让 AI 写。AI 在这个阶段更大的价值是帮你识别“哪些行为和状态应该收进聚合根”而不是帮你把每个属性写出来。直接让 AI 生成大量缺乏业务语义的类会把建模过程变成代码生成过程DDD 就失去了意义。3. 项目骨架搭好之后再接入 Redis 缓存3.1 基础设施准备接入 Redis 之前先把环境准备好。最常见的方式是本地用 Docker 启动一个 Redis 实例开发机上用可视化客户端看 key 和过期情况。示例如下docker run -d --name redis-dev -p 6379:6379 redis:7如果你的团队需要模拟多实例场景可以再起一个主从结构从节点挂到主节点下面做数据同步。这里给的是通用启动命令具体镜像版本和端口映射以你本地的 Docker 环境为准。开发时建议装一个可视化客户端比如 Redis Desktop Manager 或者 Another Redis Desktop Manager用来查看 key 的分布、剩余过期时间、内存占用。排查缓存问题时有没有可视化工具效率差别很大。.NET 接入 Redis 的常用方式有两种使用Microsoft.Extensions.Caching.StackExchangeRedis基于IDistributedCache抽象适合做键值缓存。直接使用StackExchange.Redis的ConnectionMultiplexer适合需要操作 Redis 数据类型、分布式锁、发布订阅等高级场景。我的建议是如果只是读写缓存用IDistributedCache就够了如果要做分布式锁、排行榜、消息队列直接用StackExchange.Redis不要强行包一层抽象。3.2 Redis 数据模型怎么选很多人面试背 Redis 数据类型背得很熟String、Hash、List、Set、ZSet。但落到业务里选型经常是反过来的先看业务读写模式再决定用哪种类型。订单详情、商品详情这种“按一个 key 读一个 JSON 对象”的场景用 String 存序列化后的 JSON 最直接。需要频繁修改某个对象的部分字段比如用户信息里的昵称和头像用 Hash 存储可以只修改某个 field不用整个反序列化再写回。需要做榜单、计分排名的场景比如“销量周榜”用 ZSetscore 就是排名依据。需要做限流队列、延时任务的场景可以考虑 List 和 ZSet 的组合。举个订单详情缓存的例子在应用服务里用IDistributedCache做旁路缓存public async TaskOrderDto GetOrderAsync(Guid orderId) { var cacheKey $order:detail:{orderId}; var cached await _cache.GetStringAsync(cacheKey); if (cached ! null) { return JsonSerializer.DeserializeOrderDto(cached); } var order await _orderRepository.GetByIdAsync(orderId); if (order null) return null; var dto _mapper.MapOrderDto(order); await _cache.SetStringAsync(cacheKey, JsonSerializer.Serialize(dto), new DistributedCacheEntryOptions { AbsoluteExpirationRelativeToNow TimeSpan.FromMinutes(10) }); return dto; }这里有几个参数值得注意过期时间 10 分钟是示例实际要按业务对数据新鲜度的容忍度来定。订单状态变化频繁的模块缓存时间应该短甚至写后立即失效。key 的命名建议带上业务前缀和对象 ID比如order:detail:{orderId}。这样在 Redis 里按前缀搜索时能快速找到同类缓存。序列化方式要统一。团队里如果既有 Newtonsoft.Json 又有 System.Text.Json缓存格式会乱排查很痛苦。3.3 缓存更新最麻烦的三个场景缓存看起来简单真正出问题的永远是更新路径。穿透、击穿、雪崩这三个场景做企业级架构时基本都会遇到。缓存穿透查询一个根本不存在的订单 ID缓存和数据库都没有每次请求都打到数据库。解决思路是缓存空值并设置较短的过期时间或者在接口层做一个简单的参数校验和布隆过滤器。缓存击穿某个热点 key 过期的一瞬间大量请求同时打到数据库。解决思路是加分布式锁只让一个请求去回源其他请求等待。缓存雪崩大量 key 在同一时间段过期数据库压力瞬间增大。解决思路是给过期时间加随机偏移量避免同一秒内集体失效。击穿场景用 Redis 分布式锁是常见做法。在 .NET 里可以用IDistributedCache的LockTake/LockRelease方法public async TaskOrderDto GetOrderWithLockAsync(Guid orderId) { var cacheKey $order:detail:{orderId}; var cached await _cache.GetStringAsync(cacheKey); if (cached ! null) return JsonSerializer.DeserializeOrderDto(cached); var lockKey $lock:order:{orderId}; var lockToken Guid.NewGuid().ToString(); var acquired await _cache.LockTakeAsync(lockKey, lockToken, TimeSpan.FromSeconds(10)); if (!acquired) { // 拿不到锁说明别的线程正在回源等一小段时间后重试读取缓存 await Task.Delay(100); var retry await _cache.GetStringAsync(cacheKey); return retry ! null ? JsonSerializer.DeserializeOrderDto(retry) : null; } try { // 再次检查缓存可能上一把锁的持有者已经回填 cached await _cache.GetStringAsync(cacheKey); if (cached ! null) return JsonSerializer.DeserializeOrderDto(cached); var order await _orderRepository.GetByIdAsync(orderId); if (order null) return null; var dto _mapper.MapOrderDto(order); await _cache.SetStringAsync(cacheKey, JsonSerializer.Serialize(dto), new DistributedCacheEntryOptions { AbsoluteExpirationRelativeToNow TimeSpan.FromMinutes(10) }); return dto; } finally { await _cache.LockReleaseAsync(lockKey, lockToken); } }锁的超时时间不能设得太短。如果业务回源时间超过锁超时时间锁提前释放其他线程就会同时进到数据库查询锁就失效了。我一般会根据数据库查询耗时估算查询慢的例子会把锁超时放到 10 到 30 秒再配合数据库连接超时一起控制。3.4 Redis 主从和持久化别放到最后才想起开发环境单机 Redis 没问题生产环境则要考虑高可用。常见做法是 Redis 主从加哨兵或者直接用云厂商的托管 Redis。如果团队本地用 Docker 搭建主从做验证大致流程是先启动一个主节点再启动从节点并执行REPLICAOF指定主节点地址。关键点是确认从节点同步状态是connected否则主从配置写了等于没写。Redis 持久化也是生产环境必须确认的项。默认配置下重启可能导致部分数据丢失如果缓存丢了还能回源数据库影响不大但如果 Redis 里存了分布式锁、未结算的计数字段丢数据就会出问题。到底用 RDB 快照还是 AOF 日志取决于你对数据丢失的容忍度。这里不展开讲具体配置建议在项目启动前先确定 Redis 的定位它只是可丢失的缓存还是承担了一部分状态存储两者的持久化策略完全不同。4. Nginx 负载均衡把流量分发做到可控4.1 Nginx 在企业 .NET 架构里的位置Nginx 通常部署在服务前面作为统一的入口网关。当你有两台服务器部署了同一个 .NET API客户端不需要知道具体 IP只需要访问 Nginx 的地址。Nginx 根据配置把请求分发给不同的后端实例。在企业架构里Nginx 承担的事情可以拆成几类反向代理接收外部请求转发给内部 .NET 服务。负载均衡在多台实例之间分配流量避免单点过载。静态资源处理图片、前端静态文件可以直接由 Nginx 返回不经过 .NET 进程。统一超时和重试对后端连接超时、读取超时做控制避免一个慢请求拖垮整体。如果你的团队还没装 Nginx先去官网下载对应操作系统的版本或者用 Docker 启动一个 Nginx 容器做本地验证。配置文件的语法容易出现低级错误比如漏了分号、花括号没闭合所以每次修改配置后一定先执行下面的命令检查语法nginx -t确认输出没有错误再执行nginx -s reload让配置生效。这个习惯能帮你避免很多线上事故。4.2 最小可用配置示例以下是一个面向 .NET API 的 Nginx 反向代理配置。upstream order_api { least_conn; server 192.168.1.11:5000 max_fails3 fail_timeout30s; server 192.168.1.12:5000 max_fails3 fail_timeout30s; keepalive 32; } server { listen 80; server_name api.example.com; location / { proxy_pass http://order_api; 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_connect_timeout 5s; proxy_read_timeout 10s; proxy_send_timeout 10s; } }几个关键点分开说。upstream块定义后端服务器组server指令列出后端地址。least_conn表示把请求分给当前活跃连接数最少的实例比默认的轮询更适合后端处理时间不均匀的场景。如果你的接口对请求来源有粘性要求可以用ip_hash让同一个客户端的请求固定到同一台后端实例。proxy_set_header这一组必须认真配。Host不传后端可能拿不到正确的域名X-Real-IP和X-Forwarded-For不传后端日志和审计拿不到真实客户端 IPHTTPS 场景下不传X-Forwarded-Proto后端无法区分请求是 HTTP 还是 HTTPS。max_fails3和fail_timeout30s表示 30 秒内失败 3 次就认为这台后端实例不可用暂时停止向它分发请求。这个参数不是越大越好如果设成 10 次等于允许 10 个请求都失败后再摘除节点用户已经感知到错误了。4.3 健康检查、会话和日志Nginx 开源版自带的健康检查比较简单就是上面说的被动健康检查请求失败一定次数后摘除节点。它的缺点是摘除有滞后性而且摘除前用户已经遇到了失败请求。如果团队用的是 Nginx Plus可以做主动健康检查定期探测后端的健康接口。开源环境下更稳妥的做法是让后端提供一个/health接口再由外部监控系统定期探测有问题时通过 DNS 或配置变更把流量切走。负载均衡下还要考虑会话问题。传统 ASP.NET 应用的 Session 默认存在进程内存里请求分发到 A 实例时写入的 Session下一次分发到 B 实例就读不到。这就是为什么企业级架构里会把 Redis 作为分布式缓存和会话存储。让多个 .NET 实例共享同一个 RedisSession 和缓存数据才能跨实例可见。如果你用 JWT 这类无状态令牌后端不需要保存 Session会话问题基本不存在这也是现在微服务和前后端分离架构更倾向 JWT 的原因之一。日志方面建议给每个location配置独立的 access_log把 Nginx 访问日志和后端应用日志分开。排查慢请求时先看 Nginx 的响应耗时再看后端日志的耗时就能判断耗时发生在连接建立、后端处理还是响应传输阶段。这里的配置不追求复杂关键是日志里有$request_time、$upstream_response_time、$upstream_addr这些字段。5. 整套链路怎么验证怎么判断效果5.1 一次完整请求的流转架构搭完之后一定要拿一个真实业务场景从头走一遍不要只测“能通”。以一个查询订单详情的请求为例完整链路是这样的客户端请求到达 NginxNginx 根据地址解析出订单服务所在的后端实例。.NET API 的 Controller 接收请求把参数转换为应用层命令或查询。应用服务先读取 Redis 缓存如果命中直接返回 DTO。如果没有命中应用服务通过仓储接口读取领域模型经过映射组装成 DTO再写回 Redis。响应返回到 NginxNginx 记录访问日志最终返回给客户端。每一步都可以验证。验证 Nginx 分发了哪些实例看 access log 里的$upstream_addr验证缓存是否命中看 .NET 应用日志里有没有输出缓存命中的标识或者直接看 Redis 里的 key 和过期时间。我一般建议先用小流量验证再放大流量。小流量的意思是写一个测试脚本连续请求 100 次同一个订单接口观察缓存命中率、后端实例的分布、有没有错误请求。能跑通之后再用压测工具模拟并发逐步放大。5.2 主要验证指标不要只凭“感觉变快了”来判断架构有效。建议关注下面几类指标缓存命中率命中率高说明缓存设计有效数据库压力小太低说明 key 设计或过期时间不合理。单次请求耗时关注 P95 和 P99而不是平均值。平均值会被极少数快请求拉低P99 才能反映真实体验。后端实例分布轮询或最少连接策略下各实例的请求数应该大致均衡。如果一台机器请求量明显偏多检查负载均衡策略和后端权重。错误率Nginx 返回 502、504 的比例。502 通常是后端实例挂了504 通常是后端响应超时。资源占用Redis 内存增长趋势、Nginx 连接数、后端实例的 CPU 和内存。资源长期在高位说明架构可扩展性已经接近上限。这些指标不一定一开始就全部搭建但至少要能回答三个问题缓存有没有生效、流量有没有被分散、后端有没有异常请求。5.3 预期管理这套组合不是银弹搭了 DDD、Redis、Nginx不等于系统就高枕无忧。有几个边界情况要提前说清楚。DDD 只解决业务复杂性的组织问题不解决性能问题。一个聚合根如果设计得过大一次操作加载很多子对象反而可能更慢。Redis 是缓存不是数据库。如果业务要求强一致比如“库存扣减后必须实时可查且不能超卖”单纯依赖缓存和过期时间是不够的必须结合分布式锁、数据库事务和乐观并发控制一起设计。Nginx 解决了入口高可用但没有解决后端实例内部的状态问题。如果 .NET 服务里自己启动了一个后台任务进程这个任务在多个实例上可能被重复执行。这时候需要 Redis 分布式锁或者分布式任务调度框架来保证只有一个实例执行。认清这套架构的边界比多花时间堆功能更重要。6. 真实落地时最容易踩的坑和排查链路6.1 缓存不生效或数据不一致先按顺序排查缓存出问题时的第一反应不要是“回滚代码”先按下面的顺序排查。第一步看 key。同一个业务对象的 key 在写入和读取时是否完全一致包括大小写、前后缀、参数序列化方式。很多缓存失效问题本质是读取时的 key 和写入时的 key 对不上。第二步看过期时间。如果写入时设置了 10 分钟过期但业务侧预期的数据保鲜期只有 30 秒那缓存命中率低是正常的不是缓存代码写错了。第三步看序列化。反序列化报错时看缓存里存的值是不是被别的服务或者手动操作改过。Redis 可视化客户端手动改了值格式不对读取时就会报 JSON 解析异常。第四步看更新路径。数据修改后是主动删除缓存还是更新缓存删除缓存之前有没有可能另一个线程刚好回填了旧数据企业级场景里“先更新数据库再删缓存”是常见做法但删缓存也可能失败所以还要有兜底机制比如给缓存设置较短的过期时间避免脏数据长期存在。6.2 Nginx 转发后接口偶发失败后端偶发 502、504很多人第一反应是改大proxy_read_timeout。这个方向不一定错但要先确认根因。如果是某个接口本身耗时超过 10 秒而正常业务不该这么慢优先查的是后端慢查询和数据库锁而不是无脑调大超时。超时调大只是让用户多等几秒问题依然存在。如果多实例中只有某台机器偶发失败检查这台机器的负载、磁盘、日志。磁盘满了日志写不进去接口会表现得很奇怪。如果请求量上去后失败率上升检查 Nginx 的worker_connections和系统文件句柄限制。连接数打满后新请求会被拒绝表现就是大量 502。排查顺序建议是先看 Nginx error log再看$upstream_addr是不是集中到某一台机器再看那台机器的应用日志最后看数据库连接池是否耗尽。6.3 AI 建模建议不能直接照搬AI 辅助 DDD 建模最大的坑是把 AI 的输出当成需求文档直接进入开发。AI 生成聚合根和实体速度很快但它的训练数据来自大量公开项目而你的业务规则是独有的。直接照搬会出现两种问题第一种是模型过度设计。AI 喜欢把每个字段都变成值对象把每个操作都变成领域事件代码结构很漂亮但实际业务根本不需要这种灵活性团队维护成本反而上升。第二种是模型和业务不一致。AI 不知道你的业务里“取消订单”到底是只改状态还是要回滚库存、释放优惠券、通知仓库所以它给出的 Cancel 方法往往只有一个状态变更。这种规则必须由领域专家和开发一起补充。我的建议是AI 输出的每个聚合根都要回答三个问题它的生命周期是由谁创建的它在哪些操作下会改变状态它和外部系统的交互边界在哪里三个问题能说清楚再让 AI 帮你生成代码骨架说不清楚先继续讨论业务。7. 给进阶者的几点落地建议整套架构落到真实项目里顺序比技术更重要。我建议按照下面的节奏推进。第一步先用一个小型但真实的业务模块验证 DDD。别一上来就把整个系统重构成 DDD选择一个业务规则最复杂的模块比如订单或结算先做领域建模让团队熟悉分层和聚合根的写法。第二步把缓存加到这个模块的读路径上。先做单条数据的旁路缓存验证命中率和数据一致性再逐步扩展到批量查询和分布式锁场景。第三步部署两个后端实例用 Nginx 做负载均衡。这时候重点验证的是会话、缓存和定时任务的跨节点行为。你会发现很多单机环境下没问题的事情多实例之后就变成了问题比如日志分散、后台任务重复执行、缓存预热重复触发。第四步补监控和排查工具。Redis 的可视化客户端、Nginx 的访问日志格式、 .NET 应用的结构化日志这三样在问题真正发生时能帮你省下大量时间。最后一件事这套组合不一定适合所有项目。如果是内部管理系统用户量一两百一台服务器就够了Redis 和 Nginx 可以等真正有需要时再加。如果业务规则本身很简单强行上 DDD 只会拖慢交付。架构选型要跟业务阶段匹配这句话听起来像正确的废话但实际执行时最容易被忽略的就是它。我认为对大多数想进阶的 .NET 开发者来说真正有价值的不是把这套架构原样照搬而是理解每一层解决什么问题、边界在哪里、出问题时怎么排查。把 DDD 的建模思路、Redis 的缓存策略、Nginx 的负载均衡配置分别跑通再串成一条完整链路就已经比很多只写 CRUD 的项目具备更强的架构能力。这也是这篇文章最值得你带走的东西。