C：Consistency，数据一致性

A：Availability，服务可用性

P：Partition-tolerance，分区容错性

CAP 理论告诉我们，一个分布式系统不可能同时满足数据一致性、服务可用性和分区容错性这三个基本需求，最多只能同时满足其中的两个

服务注册与发现的基本模型


举一个例子，你去一个陌生的城市出差，下班了想去吃个火锅，还得是重庆火锅。那么你怎 么知道这个城市哪里有重庆火锅？ 你可能会说，我在 App 里面搜一下。那么 App 又怎么知道这里有一家重庆火锅店呢？你继 续说，这肯定是商家去这个 App 注册过了呀！对，服务注册与发现模型就是这样。你扮演了 客户端的角色，火锅店扮演了服务端的角色，而 App 则是扮演了我们常说的注册中心的角 色。


1. 服务端启动的时候，需要往注册中心里注册自身的信息，主要是定位信息。
2. 注册成功之后，注册中心和服务端要保持心跳。
3. 客户端第一次发起对某个服务的调用之前，要先找注册中心获得所有可用服务节点列表， 随后客户端会在本地缓存每个服务对应的可用节点列表。
4. 客户端和注册中心要保持心跳和数据同步，后续服务端有任何变动，注册中心都会通知客 户端，客户端会更新本地的可用节点列表。
5. 客户端发送请求。
6. 服务端返回响应。

你们用了什么中间件作为注册中心以及该中间件的优缺点。确保自己在回答“你为什么用 某个中间价作为注册中心”的时候，能够综合这些优缺点来回答。 注册中心的集群规模。 读写 QPS（每秒查询率）。 机器性能，如 CPU 和内存大小。 最好准备一个注册中心出故障之后你排查和后续优化的案例。在讨论使用注册中心的注意 事项，或者遇到过什么 Bug 的时候可以用这个案例。

在注册中心选型上，重要的是 CAP 原理中应该选择 AP，比如说 Eureka，又或者 Nacos 启用 AP 模式。

高可用的服务注册与发现要围绕注册服务端崩溃检测、客户端容错和注册中心选型三个方面进行

负载均衡，本质上就是回答一个问题：我该把请求发给哪个服务端？

负载均衡算法

• 静态负载均衡算法，它们依靠的是统计学上的“最合适”。也就是说，如果请求都差不多，请求数量也足够多，那么它们能够挑选出比较合适的节点
  • 轮询与加权轮询
  • 随机与加权随机
  • 哈希与一致性哈希
• 动态负载均衡算法，或者说是实时检测负载均衡算法。这一类算法依赖于实时判断所有候选节点的状态，并且从里面挑选出最合适的节点。这一类算法包含最少连接数、最少活跃请求数、最快响应时间等算法

熔断可以给服务端恢复的机会

降级和熔断非常像

所以在一些场景下，你既可以用熔断，也可以用降级。比如说在响应时间超过阈值之后，你可以考虑选择熔断，完全不提供服务；你也可以考虑降级，提供有损服务。

如何降级？

怎么降这个问题的答案又可以分成两大类。

• 跨服务降级，当资源不够的时候可以暂停某些服务，将腾出来的资源给其他更加重要、更加核心的服务使用。比如大促暂停退款服务就是跨服务降级的例子。这种策略的要点是必须知道一个服务比另外一个服务更有业务价值，或者更加重要。

• 本服务提供有损服务，例如各大 App 的首页都会有降级的策略。在没有触发降级的时候，App 首页是针对你个人用户画像的个性化推荐。而在触发了降级之后，则可能是使用榜单数据，或者使用一个运营提前配置好的静态页面。这种策略的要点是你得知道你的服务调用者能够接受什么程度的有损。

比如 RTA 服务，超时，降级返回默认出价