微服务是大型架构核心，下面我详解微服务并发方案@mikechen
百万并发场景
微服务拆分，是高并发架构的基石。
首先，将业务拆分为粒度适当的微服务，尽量设计为无状态或将状态外置。
拆分应以业务边界、和数据自治为依据，确保单一服务职责明确、耦合度低且便于独立扩展。
粒度既不能过粗以致成为新的单体瓶颈，也不能过细导致分布式复杂性与通信开销激增。
通常采用领域驱动设计（DDD）识别边界上下文，结合访问频次、扩展需求及团队组织结构。
比如：按领域边界拆（DDD：Bounded Context）。
每个服务代表一个独立业务域（订单、库存、支付、用户、搜索等）。
确定服务边界，并确保服务之间通过轻量、可靠的 API 或消息队列进行通信。
对外网关（API Gateway）做认证、限流、灰度、熔断。
跨服务调用用短超时、断路器、重试（指数退避）并实现幂等。
数据拆分
垂直拆分（按业务/表）：不同功能放不同库（比如把日志/审计/统计放独立库）。
适合：不同表之间无强事务、容量差异大。
水平分表（sharding）：把某张大表按某个维度切分为多张表，多库多表。
shard = hash(user_id) % N
db = dbs[shard]
table = "orders_" + (user_id % M)
db.execute("INSERT INTO " + table + " (...) VALUES (...)")
切分键常见：user_id、order_id、地域、时间（按月/按日）。
目录表 + 时间分区：日志、审计类按时间自动分表/分区（MySQL partition 或分表）。
分片路由策略：范围分片、哈希分片（一致性哈希）或复合策略（hash+range）。
服务限流
限流，防止流量超出系统承受阈值（令牌桶、滑动窗口、漏桶）。
常见算法：
令牌桶（Token Bucket）：允许突发流量，平滑长期速率。
漏桶（Leaky Bucket）：平滑输出速率，限制峰值。
固定窗口 / 滑动窗口（计数）：简单实现，滑动窗口更平滑。
分布式限流：Redis + Lua 脚本（原子操作）、Guava RateLimiter（单节点）。
-- keys: bucket_key, timestamp_key -- ARGV: rate, capacity, now -- 返回是否允许
服务熔断
当下游服务失败或延迟升高时，快速断开对下游的调用，避免级联故障并给下游恢复时间。
常见实现（Hystrix/Resilience4j/Sentinel）
状态机：CLOSED(open calls), OPEN(tripped, short-circuit), HALF-OPEN(testing).
触发条件：失败率阈值（例如 50%）且最小请求数（例如 20 请求/窗口）或延迟阈值。
恢复策略：等待时间后进入 HALF-OPEN，允许少量探测请求，成功则关闭。
服务降级
某些功能依赖不可用或延迟高时，提供降级结果（简化功能、缓存数据或友好提示），保证系统核心可用。
常见降级策略
功能降级：关闭非关键功能（推荐/个性化、统计、日志写入等）。
数据降级：返回缓存数据或旧数据（接受最终一致性）。
响应降级：返回默认值/简化页面或“服务暂不可用”的友好提示。
限速降级：对低优先级用户限流或延迟处理。
比如：订单查询遇到库存服务不可用：返回缓存订单状态 + 显示“库存处理中”提示，而不是抛 500。
mikechen睿哥
10年+大厂架构经验，资深技术专家，就职于阿里巴巴、淘宝、百度等一线互联网大厂。