百万并发场景
在百万并发场景（如电商秒杀、社交直播或在线支付高峰），微服务架构的核心支撑在于服务拆分。
将传统单体应用、或粗粒度服务，拆分为粒度适当的微服务单元。
这不是简单“切块”，而是基于业务边界、自治性和弹性扩展的设计实践。
通过适当粒度拆分，系统能实现独立部署、针对性扩展和高可用，避免单点瓶颈放大为系统级崩溃。
业务边界优先：按DDD（领域驱动设计）拆分，确保服务间交互最小化。
在百万QPS下，高负载服务（如搜索/推荐）独立扩容至100+实例，低负载服务（如通知）保持单实例。
数据自治：每个服务拥有独立数据库，避免共享锁竞争。
并发读写分离后，单服务TPS（Transactions Per Second）从1万升至10万。
数据拆分
分库分表的核心是水平拆分（Horizontal Sharding），将单表的数据行按规则分散存储。
不同于垂直拆分（按字段切），水平拆分针对大数据量和高TPS场景。
分库：将数据分散到多个物理数据库实例（如MySQL主库1、2、3），按业务域或哈希路由。
分表：单库内将单表拆为多个逻辑表（如order_0、order_1），按行切分。
分片键（Shard Key）：路由依据，如用户ID、订单时间，确保数据均匀分布。
路由机制：SQL执行时，根据分片键计算目标库/表（e.g., user_id % 4 → 库0表0）。
服务限流
限流，是在入口或关键服务处控制并发请求速率，防止突发流量耗尽资源。
常见限流策略包括固定窗口、滑动窗口、令牌桶与漏桶算法。
实践中可在API网关、负载均衡层或服务端点实现全局限流、用户维度限流或接口维度限流。
结合降级与队列化（将超载请求排入异步队列）可缓解突发流量。
限流还应支持动态调整与熔断联动，并通过监控与告警及时反馈系统压力状况。
服务熔断
熔断机制用于在下游服务异常或延迟增大时快速切断调用，避免故障蔓延并为下游争取恢复时间。
常采用基于错误率或响应时间的窗口统计，当命中阈值后进入熔断（拒绝或短路）并在熔断期后尝试半开探测。
熔断器设计需注意阈值设置、冷却时长与探测策略，结合熔断日志与告警有助于快速定位问题。
与限流配合，可在流量高峰或故障期间协同保护系统稳定性。
服务降级
降级，是主动降低功能质量以保核心业务可用的策略。
常见降级方式包括返回缓存数据、只保留核心功能路径、关闭非必要功能（例如推荐、统计）或返回简化结果。
实施降级需明确业务优先级、设计可配置的开关与回退策略，并保证降级动作是可监控与可回滚的。
结合灰度发布，可以在小范围内验证降级效果，避免大面积影响用户体验。
作者简介
陈睿|mikechen，10年+大厂架构经验，BAT资深面试官，就职于阿里巴巴、淘宝、百度等一线互联网大厂。
关注作者「mikechen」公众号，获取更多技术干货！
后台回复【架构】，即可获取《阿里架构师进阶专题全部合集》，后台回复【面试】即可获取《史上最全阿里Java面试题总结》