
在构建现代web服务时,三层架构(通常包括表示层/应用层、业务逻辑层/服务层和数据访问层/持久层)因其清晰的职责分离和良好的可维护性而广受欢迎。fastapi作为一款高性能的web框架,非常适合实现这种架构。
然而,在实际开发中,我们经常会遇到一个挑战:某些API端点需要的数据并非来自单一服务,而是需要聚合多个独立服务的数据。例如,一个名为get_transaction的端点,可能需要从用户服务获取用户信息、从产品服务获取产品详情、以及从销售服务获取销售记录,最终将这些信息整合成一个完整的交易对象(TransactionDto)返回给客户端。
在这种复杂场景下,架构师和开发者面临一个关键决策:应如何组织这些跨服务的数据聚合逻辑?是让应用层直接协调多个服务,还是引入一个专门的聚合服务来封装此逻辑?
描述: 在这种策略中,API端点(属于应用层)直接负责调用所有必要的底层服务,然后将这些服务返回的数据进行组合,构建出最终响应对象。应用层充当了一个“编排者”的角色。
优点:
缺点:
示例代码:
# app/schemas/transaction.py
from pydantic import BaseModel
class UserInfo(BaseModel):
id: str
name: str
email: str
class ProductInfo(BaseModel):
id: str
name: str
price: float
class SaleDetails(BaseModel):
order_id: str
quantity: int
total_amount: float
class TransactionDTO(BaseModel):
id: str
user_info: UserInfo
product_info: ProductInfo
sale_details: SaleDetails
# app/services/user_service.py (示例,实际可能通过HTTP请求或ORM)
class UserService:
async def get_user_by_transaction(self, transaction_id: str) -> UserInfo:
# 模拟从用户服务获取数据
print(f"Fetching user data for transaction {transaction_id}")
return UserInfo(id="user123", name="John Doe", email="john@example.com")
# app/services/product_service.py
class ProductService:
async def get_product_by_transaction(self, transaction_id: str) -> ProductInfo:
# 模拟从产品服务获取数据
print(f"Fetching product data for transaction {transaction_id}")
return ProductInfo(id="prod456", name="Laptop Pro", price=1200.00)
# app/services/sale_service.py
class SaleService:
async def get_sale_details(self, transaction_id: str) -> SaleDetails:
# 模拟从销售服务获取数据
print(f"Fetching sale data for transaction {transaction_id}")
return SaleDetails(order_id="ord789", quantity=1, total_amount=1200.00)
# app/api/endpoints.py
from fastapi import APIRouter, Depends
from app.services.user_service import UserService
from app.services.product_service import ProductService
from app.services.sale_service import SaleService
from app.schemas.transaction import TransactionDTO, UserInfo, ProductInfo, SaleDetails
router = APIRouter()
# 依赖注入函数
def get_user_service():
return UserService()
def get_product_service():
return ProductService()
def get_sale_service():
return SaleService()
@router.get("/transactions/{transaction_id}", response_model=TransactionDTO)
async def get_transaction_option1(
transaction_id: str,
user_service: UserService = Depends(get_user_service),
product_service: ProductService = Depends(get_product_service),
sale_service: SaleService = Depends(get_sale_service)
) -> TransactionDTO:
"""
策略一:应用层直接协调多服务
"""
print("Executing Option 1: Application layer orchestration")
# 应用层直接调用并聚合数据
user_data = await user_service.get_user_by_transaction(transaction_id)
product_data = await product_service.get_product_by_transaction(transaction_id)
sale_data = await sale_service.get_sale_details(transaction_id)
# 组合数据构建TransactionDTO
transaction_dto = TransactionDTO(
id=transaction_id,
user_info=user_data,
product_info=product_data,
sale_details=sale_data
)
return transaction_dto描述: 在这种策略中,我们引入一个全新的服务,例如TransactionService,专门负责封装交易数据的聚合逻辑。这个聚合服务内部会调用UserService、ProductService和SaleService,并将它们的数据组合成一个完整的Transaction对象,然后将这个对象返回给应用层。应用层只需调用这个聚合服务即可。
优点:
缺点:
示例代码:
# app/services/transaction_service.py
from app.services.user_service import UserService
from app.services.product_service import ProductService
from app.services.sale_service import SaleService
from app.schemas.transaction import TransactionDTO, UserInfo, ProductInfo, SaleDetails
class TransactionService:
def __init__(
self,
user_service: UserService,
product_service: ProductService,
sale_service: SaleService
):
self.user_service = user_service
self.product_service = product_service
self.sale_service = sale_service
async def get_transaction_details(self, transaction_id: str) -> TransactionDTO:
"""
聚合逻辑封装在TransactionService中
"""
print(f"TransactionService: Aggregating data for transaction {transaction_id}")
user_data = await self.user_service.get_user_by_transaction(transaction_id)
product_data = await self.product_service.get_product_by_transaction(transaction_id)
sale_data = await self.sale_service.get_sale_details(transaction_id)
transaction_dto = TransactionDTO(
id=transaction_id,
user_info=user_data,
product_info=product_data,
sale_details=sale_data
)
return transaction_dto
# app/api/endpoints.py (续)
from fastapi import APIRouter, Depends
# 假设已经定义了UserService, ProductService, SaleService和TransactionDTO
from app.services.transaction_service import TransactionService
# 依赖注入函数
def get_transaction_service(
user_service: UserService = Depends(get_user_service),
product_service: ProductService = Depends(get_product_service),
sale_service: SaleService = Depends(get_sale_service)
):
return TransactionService(user_service, product_service, sale_service)
@router.get("/transactions_v2/{transaction_id}", response_model=TransactionDTO)
async def get_transaction_option2(
transaction_id: str,
transaction_service: TransactionService = Depends(get_transaction_service)
) -> TransactionDTO:
"""
策略二:应用层调用专用聚合服务
"""
print("Executing Option 2: Application layer calls aggregate service")
# 应用层只负责调用聚合服务
return await transaction_service.get_transaction_details(transaction_id)选择上述两种策略的关键在于对聚合数据(在本例中是“交易”)的“身份”和业务重要性进行判断。
是否存在独立的业务“身份”? 如果聚合后的数据(如Transaction)在业务领域中具有独立的含义、生命周期、业务规则,甚至可能对应独立的存储或唯一的标识符,那么它就拥有自己的“身份”。在这种情况下,为其创建一个专用的聚合服务(如TransactionService)是更合适的。这个服务将成为该业务实体的主人,负责其所有相关的业务逻辑和数据聚合。
聚合的复杂度和重用性? 如果聚合逻辑非常简单,且只在少数几个端点使用,可能直接在应用层处理即可。但如果聚合逻辑复杂,涉及多个数据源的转换、校验,并且可能在系统的多个部分被复用,那么将其封装在一个独立的聚合服务中,将大大提高代码的可维护性和复用性。
是否属于BFF (Backend for Frontend) 或聚合服务模式?
总结而言:
无论选择哪种策略,都应关注系统的长期可扩展性和可维护性。
在FastAPI中处理多服务数据聚合时,没有一刀切的最佳方案,但以下建议有助于做出明智的决策:
最终,对于像get_transaction这样需要整合用户、产品、销售等多个领域数据的复杂场景,创建TransactionService来封装聚合逻辑通常是更健壮、更具可扩展性和可维护性的选择。它使得“交易”这一核心业务概念在架构中拥有了明确的归属,并促进了更清晰的职责分离。
以上就是FastAPI三层架构中复杂端点多服务协作与聚合策略的详细内容,更多请关注php中文网其它相关文章!
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移,垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是,许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号