Java分布式

网关的技术选型

1. 网关的作用

   1. 动态路由（用的多）

   • 前端所有的流量不会说，直接打到后端服务中去，这样前端得写死一些服务地址

   • 网关可以根据 注册中心，感知到 后端服务的增减，将流量转发到对应的服务上去

   2. 灰度发布（用的多）

   • 代码，新旧版本部署到不同的机器上，网关把流量部分分配（按照百分比/用户标示）到新机器上

   3. 授权认证（用的多）

   • 没有授权的流量，直接在网关层拦截，不会打到后端服务中去

   4. 性能监控

   • 每个接口性能，响应时间，错误率，QPS

   5. 系统日志

   6. 数据缓存

   • 把一些数据缓存起来

   7. 限流熔断（用的多）

2. 几种技术选型

   1. Kong，基于 Nginx

   2. Zuul，基于java，spring cloud

   • 高并发的能力不强

   • java语言开发，可以二次开发封装各种需要功能

   3. Nginx + lua (OpenResty)

   • 高并发能力强

   • 精通 nginx 源码，c语言，定制

3. 有些公司也没有网关，前端直接请求到nginx中，在nginx中直接配死，什么请求路由到哪台机器；

   1. 这样做就是一个nginx直接做一个负载均衡，没有专业网关的那些功能

   2. 如果新加机器，得还在nginx中去改配置等，没有动态的

实现网关对服务的动态路由

1. 基于 DB

   1. 做一张表，记录路由的信息，如 /order/* 转发到哪里

   2. 每隔5秒钟，会拉取最新的路由表，刷新网关路由

2. 也可以基于 redis，zookeeper，apollo，Nacos，配置中心来实现，总之就是让网关层，动态获取最新的路由

   1. Nacos、Apollo、Config 配置中心选型

服务注册中心

• 市面上的注册中心

  1. zookeeper 注册中心集群。如果一个服务上下线，一个zk会瞬时通知上百个zk，可能会把网卡打爆（据说zk不适合线上，他的反向通知机制高并发的承受不了）

  2. Eureka 注册中心架构，发送各自的心跳，每个服务自己拉取注册表，自己发现

• 自研注册中心架构

  1. 问题：市面上每个 Eureka 和 zk 都是维护全量的注册表，同步集群中其他机器，瞬时瓶颈大

  2. 解决：

     1. 可以分表，每个 Eureka 只维护部分的注册表，保证高可用的话，可以再加一个 master + slave 机制，两个机器保证数据一致，一台挂了，切换主从

     2. 每个服务A 变动的时候，只在对应的 Eureka 注册，维护心跳也是在对应的注册中心

     3. 如果有其他服务D 要请求服务A 的，只用服务D 在 Eureka （A）中拉取就好

node分布式

1. node 特性:

   1. 单线程：node 中的 js 与其他线程无法共享状态的

      1. 优点：不需要关注其他线程；没有线程切换的开销；不用担心死锁

      2. 缺点：cpu利用率不充分；无法进行大量计算；报错会引起系统崩溃

2. 异步 i/O 流

   1. 每当有io请求时，node为这个请求，提供一个io 线程，然后node就不管了，继续请求主线程的事

3. 事件驱动

   1. event loop 去感知io任务完成，执行回调

4. node 分布式架构：

   1. nginx：调度，负载均衡

   2. node集群：处理业务逻辑

   3. redis:同步状态

5. node 集群层的使用

   1. 启动多线程

   2. 轮询请求数据库