微服务（Microservices）是一种软件架构风格，它将一个大型单体应用（Monolithic Application）拆分为一组小型、独立、松耦合的服务

微服务Microservices是一种软件架构风格它将一个大型单体应用Monolithic Application拆分为一组小型、独立、松耦合的服务。每个微服务通常围绕特定业务能力构建拥有自己的数据库、代码库和生命周期可通过轻量级通信机制如HTTP/REST、gRPC或消息队列相互协作。核心特征包括单一职责每个服务聚焦于一个明确的业务功能独立部署与扩展可单独开发、测试、部署、升级和水平伸缩技术异构性不同服务可选用最适合的语言、框架或数据库去中心化治理与数据管理避免共享数据库强调API契约与事件驱动弹性与容错设计通过熔断、降级、重试等机制提升系统韧性基础设施自动化依赖CI/CD、容器化如Docker、编排平台如Kubernetes支撑运维。典型挑战包括分布式事务一致性、服务间网络延迟、监控复杂性、测试难度增加及运维成本上升。# 示例使用FastAPI定义一个简单用户微服务端点fromfastapiimportFastAPI appFastAPI(titleUser Service)app.get(/users/{user_id})defget_user(user_id:int):return{id:user_id,name:Alice,role:customer}在微服务架构中由于服务间物理隔离、数据库独立传统ACID事务无法跨服务保证强一致性因此需采用最终一致性和补偿机制等分布式事务模式。以下是主流且经过实践验证的处理策略✅1. Saga 模式推荐将一个跨服务的业务流程拆解为一系列本地事务每个服务内执行每个步骤配有对应的补偿事务Compensating Transaction。若某步失败则按反向顺序执行已成功步骤的补偿操作。两种实现方式Choreography编排式服务间通过事件驱动通信无中心协调者如订单服务发“创建订单”事件 → 库存服务扣减库存 → 若失败则发“回滚库存”事件。Orchestration编排式由专门的Saga协调器Orchestrator控制流程如使用Camunda、Axon或自研状态机。✅2. TCCTry-Confirm-Cancel模式要求每个服务提供三个幂等接口Try预留资源如冻结账户余额、预占库存不真正提交Confirm确认执行仅当所有Try成功后调用真正扣减Cancel取消预留任一Try失败时调用释放资源。适用于对一致性要求高、业务逻辑可明确拆分为三阶段的场景如金融支付。✅3. 基于消息队列的可靠事件Reliable Events服务在本地事务中同时写业务数据 写入消息表或使用事务性发件箱模式通过后台任务/监听器将消息投递到MQ如Kafka、RabbitMQ下游服务消费事件并执行本地操作配合幂等设计 死信队列 人工干预通道保障可靠性。→ 实现松耦合与异步最终一致。⚠️ 不推荐方案两阶段提交2PC性能差、阻塞性强、缺乏微服务原生支持一般仅用于同构数据库集群不适用于跨异构服务。全局锁或分布式锁强行串行化严重损害可用性与扩展性违背微服务设计初衷。 关键支撑能力幂等性设计所有接口需支持重复调用不产生副作用分布式追踪如Jaeger定位事务链路补偿日志与可观测性记录每步状态便于故障恢复与审计业务容忍度评估是否允许短暂不一致能否接受“下单成功但库存延迟扣减”。# 示例Saga编排式伪代码订单创建流程defcreate_order_saga(order_id):try:order_service.create(order_id)# Try 1inventory_service.reserve_stock(order_id)# Try 2payment_service.charge(order_id)# Try 3exceptExceptionase:# 触发逆向补偿按反序payment_service.refund(order_id)# Cancel 3inventory_service.release_stock(order_id)# Cancel 2order_service.cancel(order_id)# Cancel 1raise