接入微服务架构后面临的问题，如果得知哪些机器上部署了我需要的服务，不知道该调用哪个节点
单体的服务一般直接是localhost:8080的形式
方式一：IP直连
直接通过IP+端口来通信，比如服务A是192.168.23.11:8080，服务B是192.168.23.11:8090，直接访问这两个地址就可以请求服务。
缺点：IP是变动的，很难维护
一般用于开发环境联调或是使用灰度节点debug的时候，使用IP直连通信
方式二：域名+DNS
请求域名服务器获取service_a.com域名对应的IP地址，然后直接请求这个IP地址。
因为解析域名有开销，一般会在客户端缓存解析域名的结果。
优点：简单好用，无需额外组件
缺点：如果客户端不缓存DNS结果，每次调用都需要多了一次通信；如果不缓存DNS结果，无法及时更新本地的可用节点列表。
方式三：注册中心
方式二的问题是节点变化后域名服务器没有及时通知客户端，优化一下就是让域名服务器主动通知节点变化，即注册中心，基本的思路是：
- 服务器启动的时候在注册中心注册
- 客户端在第一次发起调用之前查询注册中心，然后缓存可用节点
- 注册中心在服务端节点发生变动的时候，主动通知客户端
缺点：在大规模集群下有瓶颈
方式四：服务自省
在方式三的注册中心里，随着集群规模增长和微服务框架复杂度上升，导致注册中心的数据越来越多，更新越来越频繁，从而导致注册中心成为瓶颈。
服务自省就是为了解决这种问题，基本思路是：
保留注册中心，但是注册中心里只有最小化的数据
剩余的跟服务有关的元数据，通过一个元数据服务来暴露
正常来说只需要查询一次元数据，因为元数据一般不会有变化。
不常用
方式五：借助网关服务
客户端发请求到网关，网关和域名一般是匹配的，或是把网关的节点地址写在特定的配置项里；网关把请求转发到真实服务端上，需要知道服务端的地址，这部分也是一个服务注册与发现的过程，可以借助注册中心或是DNS。
