FastAPI 与微服务架构

1. 先理解“单体”与“微服务”想象一家全能餐厅一个厨房做所有菜炒菜、蒸菜、凉菜、甜点、结账、洗碗……所有员工在一个大空间里工作如果某个环节出问题比如洗碗机坏了整个餐厅可能都要暂停这就是单体架构一个程序一个代码库、一个进程包含了所有功能。现在想象美食广场每个档口独立拉面档口、披萨档口、奶茶档口、收银台独立拉面档口有自己的厨房、食材、员工一个档口坏了不影响隔壁档口继续卖这就是微服务架构把一个大型应用拆成多个小型独立服务每个服务专注做一件事各自运行、各自部署。2. 微服务的核心特点极简版单一职责每个服务只做一件明确的事比如“用户服务”只管理用户注册、登录“订单服务”只处理订单。独立部署修改订单服务不需要重新发布用户服务。独立数据每个服务有自己的数据库可以不同种类MySQL、Redis、MongoDB。轻量级通信服务之间通过 HTTP/HTTPS、gRPC 或消息队列互相调用。3. FastAPI 在微服务中的角色FastAPI 是构建微服务的绝佳工具因为它快性能接近 Node.js 和 Go适合高并发。自带异步async/await方便调用其他服务不会阻塞。自动生成 API 文档每个微服务都自动有/docs调试和协作方便。数据校验和序列化Pydantic 帮你保证服务之间传递的数据格式正确。依赖注入轻松复用认证、数据库会话等逻辑。简单说你用 FastAPI 写一个“用户服务”再写一个“订单服务”它们各自独立运行互相通过 HTTP 请求调用。4. 一个具体的例子电商微服务假设我们拆成三个服务服务名称职责FastAPI 入口用户服务注册、登录、查询用户信息http://user-service:8000商品服务商品增删改查、库存管理http://product-service:8001订单服务创建订单、查询订单http://order-service:80024.1 用户服务简化版# user_service/main.pyfromfastapiimportFastAPI appFastAPI()users_db{1:{name:张三,email:zhangexample.com}}app.get(/users/{user_id})asyncdefget_user(user_id:str):returnusers_db.get(user_id,{error:user not found})app.post(/users)asyncdefcreate_user(name:str,email:str):user_idstr(len(users_db)1)users_db[user_id]{name:name,email:email}return{user_id:user_id}4.2 订单服务需要调用用户服务# order_service/main.pyfromfastapiimportFastAPI,HTTPExceptionimporthttpx appFastAPI()orders[]app.post(/orders)asyncdefcreate_order(user_id:str,product:str):# 调用用户服务检查用户是否存在asyncwithhttpx.AsyncClient()asclient:respawaitclient.get(fhttp://user-service:8000/users/{user_id})ifresp.status_code!200:raiseHTTPException(400,用户不存在)order_idlen(orders)1orders.append({order_id:order_id,user_id:user_id,product:product})return{order_id:order_id,status:created}关键点订单服务不直接查数据库而是通过 HTTP 请求询问用户服务。两个服务完全独立。5. 服务之间怎么互相找到服务发现在小例子中我们写死了地址http://user-service:8000。但在真实生产环境中服务可能随时迁移 IP、增减实例。这时候就需要服务发现工具如 Consul、etcd、Nacos或简单的反向代理如 Nginx、Traefik。不过作为小白你先记住微服务之间通过网络通信你需要一种方式知道“用户服务现在在哪里”。6. 微服务带来的挑战只提一下不展开分布式事务下单需要扣库存、创建订单、扣钱跨服务很难保证原子性。调试困难一个请求可能经过 5 个服务排查问题需要链路追踪如 Jaeger。部署复杂需要容器编排Kubernetes来管理几十个服务。数据一致性每个服务有自己的数据库数据同步需要最终一致性。但是不要怕对于很多中小项目先写成一个 FastAPI 单体等真正遇到瓶颈再拆微服务。不要为了“微服务”而微服务。7. 总结FastAPI 微服务的正确姿势前期用 FastAPI 写一个完整单体应用快速验证业务。中期把相对独立的模块如用户、支付、通知抽成独立的 FastAPI 服务。通信使用httpx异步请求、或 gRPC。部署每个服务打成一个 Docker 镜像用 Docker Compose 或 Kubernetes 管理。FastAPI 的优秀设计异步、类型提示、OpenAPI 自动生成让你在拆分微服务时依然保持高效开发。8. “走通感觉”的迷你实验在你自己的电脑上开两个终端。终端1 – 用户服务保存为user.pyfromfastapiimportFastAPI appFastAPI()app.get(/me)asyncdefme():return{name:Alice,id:1}运行uvicorn user:app --port 8000终端2 – 订单服务保存为order.pyfromfastapiimportFastAPIimporthttpx appFastAPI()app.get(/order)asyncdefcreate_order():asyncwithhttpx.AsyncClient()asclient:userawaitclient.get(http://localhost:8000/me)return{user:user.json(),item:book}运行uvicorn order:app --port 8001访问http://localhost:8001/order你会看到订单服务成功调用了用户服务。9.Uvicorn 和微服务架构Uvicorn 是什么类型ASGI 服务器异步网关服务器接口。作用接收网络请求比如来自浏览器的 HTTP 请求然后把请求交给你的 FastAPI 应用处理最后把响应返回给客户端。类比Uvicorn 就像餐厅的“服务员”——负责接收顾客点单、传给厨房、再把菜端给顾客。它不决定餐厅是做大厨全包的“单体餐厅”还是“美食广场”微服务。微服务架构是什么类型一种设计模式指导你如何构建软件系统。核心思想把一个大型应用拆成多个独立运行、独立部署、拥有独立数据库的小服务。类比把餐厅改成美食广场每个档口独立经营、互相通过传菜窗网络调用协作。这个“美食广场”的设计蓝图就是微服务架构。微服务架构设计/架构层“我们系统采用微服务架构有用户服务、订单服务、商品服务”。Uvicorn实现/运行层 “每个微服务独立运行用 Uvicorn 启动 FastAPI 实例”。你可以用 Uvicorn 运行一个单体 FastAPI 应用也可以用 Uvicorn 分别运行多个微服务。Uvicorn 只是工具不决定架构。uvicorn 就是让 FastAPI 能够“听到网络上的敲门声”——也就是监听 HTTP 端口。Uvicorn 负责监听端口比如 8000、接收 HTTP 请求、解析请求、调用 FastAPI 应用、返回响应。FastAPI 本身定义了“当收到什么请求时执行什么代码”但它不会自己监听端口。