02-注册中心和网关面试实战
注册中心面试实战
注册中心面试实战
注册中心技术选型：
在分布式系统中，注册中心肯定是必不可少的，那么对于注册中心如何选择呢？
如果使用 Dubbo 作为服务框架，那么 Dubbo 底层的注册中心使用的就是 ZooKeeper
如果使用 SpringCloud 作为服务框架，一般注册中心都会选择 Eureka 或者 Nacos，配套进行使用
注册中心原理：
那么注册中心的 原理 肯定是要了解的，通过注册中心可以用来做那些事情：
- 如何注册服务信息？
- 如何进行服务发现？
- 注册中心如何集群部署？
这些都是具体的原理方面的内容，不放在这里展开说了，主要了解一下在注册中心这里，会问哪些内容
我的专栏里就有 ZooKeeper 的内容，可以去查看一下
CAP 理论：在分布式系统中，被讨论最多的一个就是 CAP 理论，即一致性 (Consistency)、可用性 (Availability)、分区容错性 (Partition tolerance)无法同时满足，最多只能满足两个，因此大多数场景下都是满足 CP 或者 AP ，而注册中心就是用于分布式系统中的，因此需要去了解使用的注册中心符合 CAP 中的哪两个：
- 在 ZooKeeper 中，只有一个 Leader 可以写数据，写完数据之后会同步给其他的 Follower，如果 Leader 挂了，就会去重新选举一个 Leader，选举期间会出现短暂的
写服务不可用情况，因此 ZK 中为了保证 C 而放弃了 A，所以 ZK满足了 CP - 在 Eureka 中，
满足 AP，为了保证可用性而放弃了数据的一致性，怎么做的呢？Eureka 中各个节点都是平等的，所以某个节点宕机不会影响其他节点的工作，如果从一台机器中查询数据失败，那么可以尝试从其他的机器中查询，这里查到的数据可能不是最新的（不保证数据的一致性）
大规模服务实例场景下的表现：
对于 ZooKeeper 和 Eureka 来说，其实都不适合大规模的服务实例，因为如果服务实例数量达到几千上万，如果服务上下线，那么对于 zk 来说，需要去通知其他节点服务上下线，那么会导致 zk 的 网络瞬时流量很大，可能直接给 zk 所在机器的网络带宽打满，甚至直接打挂掉
对于 Eureka 来说也是，接收很多服务实例的请求，大量的心跳请求会导致 Eureka 压力太大
ZooKeeper 和 Eureka 一般也就能支撑几百上千的服务实例，
注册中心生产环境可以抗多少并发请求呢？
注册中心，一般会使用比较高配置的机器来部署，如 8C16G 或者 16C32G
那么一般来说，使用 8C16G 的机器部署，每秒钟抗几千的并发请求还是没有问题的，那么如果使用 16C32G 甚至 32C64G，可以抗更大数量的请求，并且对于注册中心以及后边要将到的网关，都会使用比较好的机器来部署，因为这些是 基础性的系统，如果出问题会导致服务大面积瘫痪
一般注册中心怎么部署呢？
可以去看一看 ZooKeeper 如何集群部署，部署细节可以简单了解一下，也不会问具体部署细节，但是要清楚 部署的流程
问的话，可能就是问 ZK 一般集群部署几台机器？部署的机器什么配置？
机器配置以及可以扛下请求数量在上边已经说过了，zk 部署集群的话，一般都是 小集群部署，1 主 2 从即可，zk 本身就不适合大集群部署，这与 zk 的架构设计有关，因为数据写入 Leader 之后，需要同步给 Follower 的，如果 Follower 数量过多，会导致同步速度很慢，影响 zk 的写性能
网关系统面试实战
技术选型方面
这一块的话，主要是考察对 网关技术 的了解，比如你使用了分布式系统，那你整个系统前肯定是有一个网关的
那你是如何去对网关进行技术选型的呢？这其实就是考察你对常见的几种网关是否熟悉，常用的几种网关以及优缺点如下：
Nginx：性能高，成熟，但是可扩展性不足，并且 Nginx 使用 c 编写，很难根据源码去进行定制化开发Zuul：Zuul 有两个大的版本 Zuul1 和 Zuul2，是基于 Java 实现的，核心功能比较简单，如果需要一些灰度发布、限流、动态路由之类的功能，需要自己二次开发Spring Cloud Gateway：目的就是为了替换 Zuul1，功能比较完善，性能相对于 Zuul1 来说好了很多自研网关：目前许多互联网都自研自己的网关，自研网关的好处就是可以根据自己业务特点提供一个定制化、高性能、可扩展的 API 网关解决方案，例如美团技术团队就自研了 Shepherd API 网关，可以参考文章：tech.meituan.com/2021/05/20/…
上边只是简单的提到了一些优缺点，如果你去面试，并且在简历中有较多的分布式相关的项目，一定要去对这些技术选型好好了解一下，不要对每个问题都只是知道个大概，再问就什么不知道了！
网关的核心功能：
那么如果系统中使用了网关，你是希望去使用它的什么功能呢？一定要了解网关的 应用场景，因为很可能讲完这个之后，会问你，让你自己设计一个网关，你会怎么设计呢？这不正是考察网关的功能以及对每个功能点如何进行设计的吗？
这里将网关的功能按照重要顺序列一下，重要的列在前边：
- 动态路由：新上线某个服务，可以动态的将请求路径和服务的映射关系
热加载到网关里去，服务增加或减少机器，网关也可以自动感知到 - 灰度发布：新功能正式上线之前，将新功能在少量机器上进行发布测试
- 授权认证：对发送到网关的请求进行授权认证
- 限流熔断
- 性能监控：监控每个接口的
耗时、成功率、QPS - 系统日志：打印接口请求日志
- 数据缓存
网关部署的机器配置：
这是属于网关系统在生产环境部署的内容了，这个之前在讲注册中心也讲过机器配置的问题，这里再啰嗦一下，多看看就记住了
常用的机器配置就是 4C8G、8C16G、16C32G、32C64G
那么像注册中心、网关系统，这种都是属于 基础架构类型的系统，一定要上配置高一点的机器，8C16G 以上的
网关系统部署在 8C16G 的机器上，每秒钟抗几千的请求是可以的
16C32G 的话，抗上万的请求也是没问题的
将机器配置和对应的请求量级大概可以对应起来就可以
并且网关系统一般是使用集群部署的，通过 Nginx 将请求再分散到多个网关系统上，可以抗更多请求，因为网关系统一般不会是整个系统的性能瓶颈
网关在整个系统中所处的地位如图所示：
1705069429175
网关中一些核心技术实现思路
可以去了解一下网关中核心技术是如何实现的，这里就以 动态路由 和 灰度发布 来简单说一下实现思路
- 动态路由
动态路由目的就是让 网关系统可以感知到服务上下线，你可以想一下学到的哪一个技术可以实现这个功能呢？
这个不就是 通知 功能吗？
那么直接通过 RocketMQ 就可以实现了，新服务上线，发送一个 MQ 通知，让网关系统去拉取最新的服务地址，如果机器下线，也可以发送 MQ 通知，让网关系统剔除掉这个服务即可
- 灰度发布
这里说一下实现灰度发布的一个思路
首先，需要创建一张灰度发布表，包含字段如下：
id int(11)
service_id varchar(255)
path varchar(255)
enable_gray_release int(11)
通过定时任务去查灰度发布表，存入 Map 中
再做一个灰度发布的 拦截器，比对请求路径是否启用灰度发布，如果启用灰度发布，就将流量转发到新部署的机器上去
这里将新版本的系统设置一个标志位，比如 ReleaseVersion，如果这个值为 NEW 的话，表示是新部署的系统，那么就可以根据这个标志位判断哪些机器上部署的系统是新版本了，将流量散发到这些新版本的机器上去
1705071035492
获取更多干货内容，记得关注我哦。
