1.什么是服务发现

RPC：解决服务间通信的问题

服务发现：解决服务寻址的问题

用一个类似域名的通信即可与下游服务进行通信

1.1Nginx

nginx：反向代理组件（将自己包装成一个消费者），将请求转发到实际处理的机器上（等待处理结果，并返回实际的消费者）

服务发现：Nginx的方向代理就是服务发现的过程

实现方式：直接配置在文件中Nginx.conf中

相同的，早期的服务可以直接在代码中配置下游服务的地址

1.2没有服务注册的问题

出现的问题（不灵活，出现问题就要修改代码）：

• 紧急扩容需要修改客户端代码，重启客户端
• 下游服务故障，需要修改代码重启服务端
• 无法流量摘除，会造成慢请求甚至请求失败

1.3注册中心组件

• 比如说老派的 ZooKeeper、Kubernetes 使用的 ETCD
• 阿里的微服务注册中心 Nacos、Spring Cloud 的 Eureka 等等

1.4注册中心的基本功能

• 提供服务地址的存储
• 存储内容变更时，需要将变更内容推送到客户端

服务注册发现的过程（disf会采用本地文件配置进行通信，接收到通知后，由agent主动去拉取配置）

• 客户端会与注册中心建立连接，并且告诉注册中心，它对哪一组服务感兴趣
• 服务端向注册中心注册服务后，注册中心会将最新的服务注册信息通知给客户端
• 客户端拿到服务端的地址之后就可以向服务端发起调用请求了

关闭服务的手段

• 直接上服务器下线，造成部分请求丢失失败
• 先停掉服务，待没有流量后关闭服务器

新的问题

• 如果下游服务器异常（断电，网络异常），导致不能与注册中心通信，怎么做到服务的摘除

2.怎么管理服务状态

针对下游服务的异常情况，怎么做到服务状态的管理

• 主动探测
• 心跳监测

2.1主动探测

做法：将RPC服务打开一个端口，注册中心每间隔一段时间端侧服务是否可用

新的问题：

• 所有的服务都需要开放一个统一端口进行探测，端口可能会被占用
• 探测成本较高，探测时间长，造成延迟

2.2心跳模式

当前主流的方案：Eureka，Zookeeper

做法：由服务节点主动向注册中心发送心跳，注册中心根据心跳间隔时间判断服务是否挂掉

应该避免服务器的过度摘除（服务注册中心可能会出现bug）

通知风暴解决（注册中心压力大，需要发送变更通知）

• 服务注册中心管理的服务集群
• 扩容注册中心节点
• 规范使用方式
• 加入保护策略

3.总结

计算机世界一切皆二进制，协议，文件格式的目的只是提供一种公共写和读规范。

每个程序运行在一个进程之上

服务治理包括（集群看作是一个微型的城市，把道路看作是组成集群的服务，把行走在道路上的车看作是流量，那么服务治理就是对于整个城市道路的管理）：

• 服务的注册和发现
  • 新增街道、关闭街道
• 服务的监控
  • 监控道路车流
• 熔断以及引流
  • 暂时关闭某些道路
• 分布式追踪
  • 对事故进行定位和分析
• 负载均衡
  • 疏导所有车辆，避免负载不均衡