1. 架构
1.1. 问题
1.1.1. (2) 微服务的特点 (优缺点), 如何实现服务发现和负载均衡
- 特点
- 单一职责: 本身是内聚的, 所以微服务通常比较小
- 自治: 独立部署升级
- 优点
- 逻辑清晰
- 简化部署
- 可扩展
- 灵活组合
- 计数异构
- 高可靠
- 缺点
- 复杂度高
- 运维复杂
- 影响性能
- 服务发现
- ServiceRegistry, 加入服务时需要注册, 心跳检测服务的存活
1.1.2. 均衡负载算法有哪些
- URL 散列
- 随机算法
- 轮询与加权轮询
- 哈希算法
- 最小连接与加权最小连接
- IP 地址散列
1.1.3. 服务发现是怎么实现的
为什么要有服务发现
服务太多，服务自身有动态性，随着服务发布、扩容时，服务对外的域名、IP 会发生变化，服务的访问者需要一种方式避免去感知和处理这个事情。
另外微服务中通常一个服务会有多个副本，需要均衡负载来实现最佳的性能。
基于注册中心实现
服务提供者启动时将自己服务的信息注册到服务中心，服务消费者从服务中心获取服务配置调用服务。
注册中心通常是一个高可用的服务，有 Nacos、ETCD、ZooKeeper、Eureka、Consul 等。
1.1.4. 熔断是怎么实现的 (熔断原理? 熔断的三个状态关系?)
熔断原理
当下游服务不可用或部分不可用时，降低对其的请求次数，直接返回给上游错误信息，避免占用服务过多资源，降低对下游服务的压力，避免服务雪崩。
熔断三个状态
正常状态
下游出现错误，降低请求次数
错误比例降低，增加请求次数
1.1.5. 熔断会影响性能吗? 有遇到过线上发生熔断吗? 不加会怎么样?
会，部分请求会直接跳过请求下游服务，直接返回错误。
不加熔断可能产生的问题
服务故障会蔓延：下游服务已经部分不可用时，客户端可能会不断的重试，导致下游压力增加，进而导致更高的不可用，最终导致当前服务也挂掉，使得原本正常的功能也无法提供。
1.1.6. id生成器是怎么实现的, 如何实现全局递增
中心服务生成
中心服务生成可以保证 id 不重复，缺点是性能低，服务挂掉时拿不到 id。
本地生成
本地生成需要加锁，或保证生成器生成的 id 是唯一的。
全局递增可以考虑用 redis increase 原子增来实现。