微服务概览

1、微服务起源

大家经常谈论的是一个叫SOA（面向服务的架构模式，它和微服务又是什么关系？你可以把微服务想成是SOA的一种实践。

• 小即是美：小的服务代码少，bug也少，易测试，易维护，也更容易不断迭代完善的精致进而美妙。
• 单一职责：一个服务也只需要做好一件事，专注才能做好。
• 尽可能早地创建原型：尽可能早的提供服务API，建立服务契约，达成服务间沟通的一致性约定，至于实现和完善可以慢慢再做。
• 可移植性比效率更重要：服务间的轻量级交互协议在效率和可移植性二者间，首要依然考虑兼容性和移植性。

2、微服务定义

围绕业务功能构建的，服务关注单一业务，服务间采用轻量级的通信机制，可以全自动独立部署，可以使用不同的编程语言和数据存储技术。微服务架构通过业务拆分实现服务组件化，通过组件组合快速开发系统，业务单一的服务组件又可以独立部署，使得整个系统变得清晰灵活：

• 原子服务
• 独立进程
• 隔离部署
• 去中心化服务治理

3、微服务设计

• 微服务网关

  • 用于鉴权限流等中间件

• BFF层

  • 用于服务数据聚合

• 微服务节点

  • 服务划分-根据业务划分

4、GRPC

1、HEALTH CHECK

1. RPC运行中：

   1. client 检测 HEALTH CHECK 接口 如果接口正常，则表示可以访问，如果接口异常，则将其从本地的连接池中移除

2. 启动RPC（平滑发布）：

   1. 进行自身应用的初始化
   2. 打开health check接口 ，特定检查服务检查HEALTH CHECK 接口
   3. 外部服务访问HEALTH CHECK 接口，如果健康检测正常，则将服务信息注册到注册中心（外挂式服务注册）

3. 终止RPC（平滑退出）：

   1. 收到KILL 信号准备退出
   2. 告诉服务发现 服务终止
   3. 关闭 HEALTH CHECK 接口 ，当client 进行健康检测时，发现接口异常，则会将其从本地连接池中移除（防止因为某些原因导致client不能从服务发现获取正确的结果）
   4. 使用GRPC 的 SHUT DOWN 接口
   5. 如果进程不能正常退出 则 KILL -9 强制杀进程

5、服务发现

1. 客户端发现（优点：比服务端发现少一次连接，缺点：每个客户端需要实现一次负载均衡算法）

   1. 客户端从服务发现获取服务的注册列表

   2. 再客户端使用负载均衡算法，进行服务的选择

2. 服务端发现（优点：无需关注服务发现具体细节，缺点：引入了其他的复杂性）

   1. 客户端请求服务中插入了一个负载均衡中间件（NGINX），由负载均衡器来获取服务的注册表，然后将客户端请求进行转发

   2. 实行方案：

      1. Consul Template + NGINX
      2. K8S + ETCD（ETCD是CP架构，不太扛得住）

3. 技术选型

   1. ZOOKEEPER 保证强一致性，每个服务会建立一个ZOOKEEPER的SESSION 在滚动发布的时候，会导致雪崩
   2. NACOS 【推荐使用】

6、多集群

场景：对于特别重要的服务考虑多集群，比如账号服务，给每套服务分配一个账号集群

• 出现的其他问题：
  • 如果出现CACHE 未命中，比如用户只使用一部分功能，如果该功能的账号集群挂了，切换到其他集群的账号服务，会出现缓存穿透
  • 解决方案：
    • 集群全连，互热缓存
  • 服务过多长连接 导致 HEALTH CHECK 占用高
  • 解决方案：
    • 子集算法（出自google SRE）选取一部分作为子集，选一部分连接

7、多租户

场景：

• 全链路压测
• 多套测试环境

核心思路：

• 参照GIT，给节点染色，请求携带染色的HEADER，将CLIENT的服务发现：从[]nodes 修改成 map[nodeColor][]nodes

• 根据header的color进行微服务节点选择