完全体

基于性能、可靠性、生态等核心维度，结合真实生产经验，给出可落地的选型建议。附对比矩阵和场景化推荐。多语言方案：通过Proxy代理层（如RocketMQ-Proxy）提供HTTP接口。：关键业务用RocketMQ+非关键日志用Kafka。与Spark/Flink等大数据工具无缝集成。灵活的路由规则（直连/主题/扇出交换器）事务消息+死信队列确保资金操作可靠性。轻量级AMQP协议适合设备资源限制。选择没有银弹，只有最适合！超高吞吐适配日志批量传输。使用惰性队列减少内存压力。：设计可替换的消息抽象层。

每个⽉固定发布新版本，以分⽀的形式保存到代码仓库中。测试环境- ⽣产环境 -开发测试环境SIT-集成测试环境-压测环境STR-预投产环境-⽣产环境PRD。：自动回滚机制（Prometheus+Argo Rollouts）敏捷开发： ⽬的就是为了提⾼团队的交付效率，快速迭代，快速试错。：多阶段构建减小镜像体积（从1.2GB→150MB）：修改功能时只需关注单个模块，避免牵一发而动全身。的敏捷效能，同时将生产事故降低92%。：每个微服务采用「领域模块化」而非「技术分层」：每个微服务由5-8人全功能团队负责。

中台跟DDD结合： DDD会通过限界上下⽂将系统拆分成⼀个⼀个的领域， 而这种限界上下⽂，天生就成了中台之间的逻辑屏障。上层的战略设计能够很好的指导中台划分，下层的战术设计能够很好的指导微服务搭建。中台是企业级能力复用平台，通过整合核心业务能力，形成可快速响应的数字化「弹药库」，支撑前台业务快速创新。所谓中台，就是将各个业务线中可以复⽤的⼀些功能抽取出来，剥离个性，提取共性，形成⼀些可复⽤的组件。：统一提供弹药（用户系统）、情报（数据分析）、医疗（风控能力）：战略指挥部（ERP、财务等重型系统）

什么是DDD： 在2004年，由Eric Evans提出了， DDD是⾯对软件复杂之道。大泥团： 不利于微服务的拆分。大泥团结构拆分出来的微服务依然是泥团机构，当服务业务逐渐复杂， 这个泥团⼜会膨胀成为大泥团。就像城市规划师先理解市民需求（领域），再划分商业区、住宅区（限界上下文），最后设计道路和公共设施（模型与架构）。用「城市规划师」的思维理解DDD，结合实战案例和可视化模型，彻底掌握这一复杂系统的设计方法论！示例：电商系统中的「订单上下文」vs「支付上下文」：划分业务边界，明确系统模块关系。

高内聚低耦合，是⼀种从上⽽下指导微服务设计的⽅法。实现高内聚低耦合的⼯具主要有 同步的接⼝调用 和 异步的事件驱动 两种⽅式。用「模块化机器人」类比微服务设计，结合领域驱动设计（DDD）和现代架构原则，提供可落地的设计方法。：让服务间像「邮局与寄件人」——通过标准接口通信，无需了解内部运作。"每个微服务应有自己的私有数据库，就像每个家庭有自己的私人储物间"：让每个微服务像「瑞士军刀中的独立工具」——功能完整且自包含。一样——每个齿轮（服务）完美协作又互不干扰！：模拟依赖服务宕机，验证降级能力。

用「乐高积木重组」类比微服务拆分，结合业界主流方法论和实战经验，为你呈现可落地的拆分策略！微服务之前只能通过接⼝进⾏服务调⽤，⽽不能绕过接⼝直接访问对⽅的数据。每个服务配置2-Pizza Team（6-8人）：服务调用链路过深（如A→B→C→D→E）：合并相关服务，采用SAGA模式管理长事务。若3个以上答案为"是"，则适合拆分！通过这套方法论，你的微服务拆分将像。：订单状态更新了，物流服务未同步。能补偿不用事务（SAGA模式）能本地不跨服务（数据冗余）引入GraphQL聚合查询。：团队结构是否与服务匹配。

微服务是⼀种更彻底的⾯向服务的架构，将系统中各个功能个体抽成⼀个个⼩的应⽤程序，基本保持⼀个应⽤对应的⼀个服务的架构。分布式架构是指将单体架构中的各个部分拆分，然后部署不同的机器或进程中去，SOA和微服务基本上都是分布式架构的。SOA是⼀种⾯向服务的架构，系统的所有服务都注册在总线上，当调⽤服务时，从总线上查找服务信息，然后调⽤。：SOA的治理思想 + 微服务的敏捷性（如Apache Camel K）：直接采用微服务 + 服务网格（如Istio）：美团外卖（独立部署订单/配送/支付服务）

服务熔断是指，当服务A调⽤的某个服务B不可⽤时，上游服务A为了保证⾃⼰不受影响，从⽽不再调⽤服务B，直接返回⼀个结果，减轻服务A和服务B的压⼒，直到服务B恢复。服务降级是指，当发现系统压⼒过载时，可以通过关闭某个服务，或限流某个服务来减轻系统压⼒，这就是服务降级。像飞机氧气面罩：当舱压异常（主服务故障），自动掉落面罩（降级方案），保证乘客生存（核心功能）。像家庭电闸跳闸：当电路短路（服务故障）时，保险丝（熔断器）立即断开，避免火灾（系统崩溃）。：熔断常触发降级，但降级不一定需要熔断（如主动降级应对大促）

信号量隔离：客户端需向依赖服务发起请求时，⾸先要获取⼀个信号量才能真正发起调⽤，由于信号量的数量有限，当并发请求量超过信号量个数时，后续的请求都会直接拒绝，进⼊fallback流。线程隔离：Hystrix会给每⼀个Command分配⼀个单独的线程池，这样在进⾏单个服务调⽤的时候，就可以在独⽴的线程池⾥⾯进⾏，⽽不会对其他线程池造成影响。，当电流过载（服务调用过多）时自动熔断，保护整个系统不崩溃，并提供备用方案（如返回缓存数据或默认值）。统计成功，失败（由客户端抛出的异常），超时和线程拒绝。

使⽤相同的hash算法计算数据的hash值，映射到圆环，顺时针寻找，找到的第⼀个服务器就是 数据存储的服务器。hash slot：将数据与服务器隔离开，数据与slot映射，slot与服务器映射，数据进⾏hash决定存放的slot，新增及删除节点时，将slot进⾏迁移即可。hash算法：根据key进⾏hash函数运算、结果对分⽚数取模，确定分⽚ 适合固定分⽚数的场景， 扩展分⽚或者减少分⽚时，所有数据都需要重新计算分⽚、存储。：节点数变化时（如从10→11），90%的缓存需要重新分配。

添加数据时：将数据进⾏hash得到hash值，对应到bit位，将该bit改为1，hash函数可以定义多个，则⼀个数据添加会将多个（hash函数个数）bit改为1，多个hash函数的⽬的是减少hash碰撞的概率。位图：int[10]，每个int类型的整数是4*8=32个bit，则int[10]⼀共有320 bit，每个bit⾮0即1，初始化时都是0。查询数据：hash函数计算得到hash值，对应到bit中，如果有⼀个为0，则说明数据不在bit中，如果都为1，则该数据可能在bit中。

每隔⼀定的时间，会扫描⼀定数量的数据库的expires字典中⼀定数量的key（是随机的）， 并清除其中已过期的key。通过调整定时扫描的时间间隔和 每次扫描的限定耗时，可以在不同情况下使得CPU和内存资源达到最优的平衡效果。只有当访问⼀个key时，才会判断该key是否已过期，过期则清除。每个设置过期时间的key都需要创建⼀个定时器，到过期时间就会⽴即清除。但是会占⽤⼤量的CPU资源去处理过期的数据，从⽽影响缓存的响应时间和吞吐量。定期过期的优化，将过期时间点相近的key放在⼀起，按时间扫描分桶。

页面和浏览器缓存，APP缓存，H5缓存，localStorage 和 sessionStorage CDN缓存：内容存储：数据的缓存，内容分发：负载均衡。用「城市物流系统」类比分布式缓存，帮你理解不同层级的缓存策略！掌握这些方案，你的分布式系统就能像。：减少分布式调用，降低下游压力。：减少网络调用，提升用户体验。：跨服务共享数据，保证一致性。Redis缓存库存等动态数据。：静态资源、用户个性化配置。：降低数据库压力，加速查询。CDN缓存HTML模板。应用层缓存商品基础信息。

缓存击穿是指缓存中没有但数据库中有的数据（⼀般是缓存时间到期），这时由于并发⽤户特别多，同时读缓存没读到数据，⼜同时去数据库去取数据，引起数据库压⼒瞬间增⼤，造成过⼤压⼒。和缓存雪 崩不同的是，缓存击穿指并发查同⼀条数据，缓存雪崩是不同数据都过期了，很多数据都查不到从⽽ 查 数据库。缓存雪崩是指缓存同⼀时间大面积的失效，所以，后⾯的请求都会落到数据库上，造成数据库短时间内 承受⼤量请求⽽崩掉。缓存穿透是指缓存和数据库中都没有的数据，导致所有的请求都落到数据库上，造成数据库短时间内承 受⼤量请求⽽崩掉。

优先考虑业务查询模式改进分区设计对必须的非分区键查询建立监控（如Prometheus记录慢查询）采用分层存储策略：热数据索引+冷数据扫描。

唯一性：通过时间戳+机器标识+序列号保证性能：本地生成避免网络开销可用性：不依赖中心节点有序性：时间戳前缀使ID大致有序其他常见方案比较：UUID：简单但无序，存储空间大数据库序列：有性能瓶颈Redis原子操作：依赖外部服务Leaf(美团)：结合数据库和Snowflake优点选择依据应取决于具体业务场景的QPS要求、ID长度限制、有序性需求等因素。

日志显示同一分片路由。执行计划含。

但需满足两个条件：分片规则完全一致。JOIN条件匹配分片键。

减少CDC链路环节（如Binlog→Kafka→Flink→DB改为Binlog→DB）。使用高性能序列化（如Protobuf替代JSON）。

基因位长度 ≥ log₂(用户数)（如10万用户需至少17位基因，2^17=131072）。使用一致性哈希替代简单取模，均匀分布数据。

适合新建系统，需从业务层改造订单ID生成逻辑。

没有不能拆的数据，只有不愿付出的代价。” —— 根据业务容忍度，在数据局部性和系统扩展性之间寻找平衡。自定义分片算法。

以用户维度切分，保证同一用户的所有数据（如订单、日志）落在同一分片，适合强关联查询。：以订单维度切分，分散写入压力，适合高并发下单但用户查询较少的场景。：订单ID离散分布，避免单个用户高频写入导致热点。分片：图书馆按读者ID分区，同一读者的书放在一起。：同一用户的订单在同一个库，避免跨库JOIN。分片：图书馆按书编号分区，新书随机上架。业务以用户维度查询为主（＞80%请求）。需要跨表关联查询（如订单+用户信息）。写入压力远高于查询（如秒杀系统）。），实现既分散写入又能按用户查询。（如社交网络）：优先。

动态扩容的核心目标是在不停服的情况下，水平扩展系统容量，需解决两个关键问题：数据迁移：如何将旧分片数据平滑迁移到新分片？路由一致性：如何保证迁移过程中，新旧分片的数据读写不受影响？设计思想：逻辑分片 vs 物理节点解耦：通过一致性哈希或范围分片，使新增节点不影响分片逻辑。渐进式迁移：类似“搬家时逐个房间整理”，而非“一次性搬空整栋楼”。以ShardingSphere的弹性伸缩模块为例：元数据管理（）：记录分片规则（如 → ）。数据迁移（）：基于CDC（Change Data Capture）监听源库Binl

XA协议（适合金融场景），但需数据库支持XA。

代理层方案：ShardingSphere-Proxy、MyCat。客户端方案：Sharding-JDBC、TDDL。

Eureka各个节点都是平等的，⼏个节点挂掉不会影响正常节点的⼯作，剩余的节点依然可以提供注册和 查询服务。⽽Eureka的客户端在向某个Eureka注册时如果发现连接失败，会⾃动切换⾄其他节点，只要有⼀台Eureka还在，就能保证注册服务可⽤（保证可⽤性），只不过查到的信息可能不是最新的（不保证强⼀致性）同时当eureka的服务端发现85%以上的服务都没有⼼跳的话，它就会认为⾃⼰的⽹络出了问题，就不会从服务列表中删除这些失去⼼跳的服务，同时eureka的客户端也会缓存服务信息。

⼀次性：⼀旦被触发就会移除，再次使⽤需要重新注册，因为每次变动都需要通知所有客户端，⼀次性可以减轻压⼒，3.6.0默认持久递归，可以触发多次。当 ZooKeeper 中的节点发⽣变化时，会通知客户端，客户端会调⽤相应 Watcher 对象中的回调⽅法。Watch事件是⼀个⼀次性的触发器，当被设置了Watch的数据发⽣了改变的时候，则服务器将这个改变发送给设置了Watch的客户端。是否有采用补充校验机制？你走出教室（会话断开）期间的所有广播，回来时班长（ZK客户端）会给你补发一份书面通知（Sync同步）

被命名的实体可以是集群中的机器，服务的地址，或者是远程的对象等。⼀些分布式服 务框架（RPC、RMI）中的服务地址列表，通过使⽤命名服务，客户端应⽤能够根据特定的名字来获取 资源的实体、服务地址和提供者信息等。zookeeper可以方便集群机器的管理，它可以实时监控znode节点的变化，⼀旦发现有机器挂了，该机器就会与zk断开连接，对应的临时⽬录节点会被删除，其他所有机器都收到通知。znode会发⽣变化时，可以通过改变zk中某个⽬录节点的内容，利⽤watcher通知给各个客户端，从而更改配置。

除此以外，他们必须是唯⼀的，也就是说每⼀个路径只有⼀个表示，因此这些路径不能改变。Znode 具有原⼦性操作，读操作将获取与节点相关的所有数据，写操作也将 替换掉节点的所有数据。持久节点：⼀旦创建、该数据节点会⼀直存储在zk服务器上、即使创建该节点的客户端与服务端的会话关闭了、该节点也不会被删除。数据仅存储在内存是很不安全的，zk采⽤事务⽇志⽂件及快照⽂件的⽅案来落盘数据，保障数据在不丢失的情况下能快速恢复。有序节点：不是⼀种单独种类的节点、⽽是在持久节点和临时节点的基础上、增加了⼀个节点有序的性 质。

服务端提供发送token的接⼝，业务调⽤接⼝前先获取token,然后调⽤业务接⼝请求时，把token携带过去,务器判断token是否存在redis中，存在表示第⼀次请求，可以继续执⾏业务，执⾏业务完成后，最后需要把redis中的token删除。每次操作，都根据操作和内容⽣成唯⼀的id，在执行之前先判断id是否存在，如果不存在则执行后续操作，并且保存到数据库或者redis等。"在贵司的架构中，如何处理分布式环境下幂等控制的性能瓶颈？多次调用接口产生的影响与一次调用一致（如支付扣款1次和重复调用只扣1次）

RPCRMI直接或间接实现接⼝ java.rmi.Remote 成为存在于服务器端的远程对象，供客户端访问并提供⼀定的服务远程对象必须实现java.rmi.server.UniCastRemoteObject类，这样才能保证客户端访问获得远程对象 时，该远程对象将会把⾃身的⼀个拷⻉以Socket的形式传输给客户端，此时客户端所获得的这个拷⻉称为“存根”，⽽服务器端本身已存在的远程对象则称之为“⻣架”。其实此时的存根是客户端的⼀个代理，

1、采用无状态服务，抛弃session2、存⼊cookie（有安全风险）3、服务器之间进⾏ Session 同步，这样可以保证每个服务器上都有全部的 Session 信息，不过当服务器数量⽐较多的时候，同步是会有延迟甚⾄同步失败；4、 IP 绑定策略使⽤ Nginx （或其他复杂均衡软硬件）中的 IP 绑定策略，同⼀个 IP 只能在指定的同⼀个机器访问，但是这样做失去了负载均衡的意义，当挂掉⼀台服务器的时候，会影响⼀批⽤户的使⽤，⻛险很大；5、使⽤ Redis 存储。

源地址哈希法：源地址哈希的思想是根据获取客户端的IP地址，通过哈希函数计算得到的⼀个数值，⽤该数值对服务器列表的⼤⼩进⾏取模运算，得到的结果便是客服端要访问服务器的序号。给配置⾼、负载低的机器配置更⾼的权重，让其处理更多的请；、最⼩连接数法：最⼩连接数算法⽐较灵活和智能，由于后端服务器的配置不尽相同，对于请求的处 理有快有慢，它是根据后端服务器当前的连接情况，动态地选取其中当前积压连接数最少的⼀台服务器 来处理当前的请求，尽可能地提⾼后端服务的利⽤效率，将负责合理地分流到每⼀台服务器。

Proxy 层封装了所有接⼝的透明化代理，⽽在其它层都以 Invoker 为中⼼，只有到了暴露给⽤户使⽤时，才⽤ Proxy 将 Invoker 转成接⼝，或将接⼝实现转成 Invoker，也就是去掉 Proxy 层 RPC 是可以 Run 的，只是不那么透明，不那么看起来像调本地服务⼀样调远程服务。cluster 路由层：封装多个提供者的路由及负载均衡，并桥接注册中⼼，以 Invoker 为中⼼，扩展 接 ⼝ 为 Cluster , Directory , Router , LoadBalance。

当程序员使⽤@Reference注解来引⼊⼀个服务时，Dubbo会将注解和服务的信息解析出来，得到当前所引⽤的服务名、服务接⼝是什么。"在贵司的微服务架构中，如何处理服务引入时的依赖冲突问题？然后根据查询得到的服务提供者信息⽣成⼀个服务接⼝的代理对象，并放⼊Spring容器中作为Bean。然后从注册中⼼进⾏查询服务信息，得到服务的提供者信息，并存在消费端的服务⽬录中。：默认每个服务提供者保持单连接（可配置连接数）添加Filter链（监控、重试、熔断等）Dubbo服务引入（服务引用）通过。

⾸先Dubbo会将程序员所使⽤的@DubboService注解或@Service注解进⾏解析得到程序员所定义的服务参数，包括定义的服务名、服务接⼝、服务超时时间、服务协议等等，得到⼀个ServiceBean。然后将服务信息注册到注册中⼼，如果有多个协议，多个注册中⼼，那就将服务按单个协议，单个注册中⼼进⾏注册。"在贵司的微服务架构中，是否有遇到服务导出时的性能瓶颈？将服务信息注册到注册中⼼后，还会绑定⼀些监听器，监听动态配置中⼼的变更。先本地导出（Injvm），后远程导出（DubboProtocol）

"在贵司的微服务架构中，是否有遇到Dubbo负载均衡策略不满足需求的场景？随机：从多个服务提供者随机选择⼀个来处理本次请求，调⽤量越⼤则分布越均匀，并⽀持按权重设置随机概率。最⼩活跃调⽤数：统计服务提供者当前正在处理的请求，下次请求过来则交给活跃数最⼩的服务器 来处理。轮询：依次选择服务提供者来处理请求， 并⽀持按权重进⾏轮询，底层采⽤的是平滑加权轮询算法。：确保同一用户的请求始终访问同一节点，维持会话状态。：相同参数请求固定路由（如用户ID决定服务节点）：默认策略，性能最好（时间复杂度O(n)）

同时Leader节点还是将当前写请求直接发送给Observer节点，Observer节点收到Leader发过来的写请求后直接执⾏更新本地内存数据。首先集群启动时，会先进⾏领导者选举，确定哪个节点是Leader，哪些节点是Follower和Observer。当Leader节点收到半数以上的Ack后，就会开始提交，先更新Leader节点本地的内存数据。集群在⼯作过程中，所有的写请求都会交给Leader节点来进⾏处理，从节点只能处理读请求。Leader节点收到⼀个写请求时，会通过两阶段机制来处理。

集群中每个节点都会经过同样的流程，pk的规则也是⼀样的，⼀旦改票就会告诉给其他服务器，所以最终各个节点中的投票箱中的选票也将是⼀样的，所以各个节点最终选出来的leader也是⼀样的，这样集群的leader就选举出来了。⼀个节点收到其他节点发过来的选票，经过PK后，如果PK输了，则改票，此节点就会投给zxid或myid更⼤的节点，并将选票放⼊⾃⼰的投票箱中，并将新的选票发送给其他节点。集群中各个节点⾸先都是观望状态（LOOKING），⼀开始都会投票给⾃⼰，认为⾃⼰⽐较适合作为leader。