在微服务架构中，一个项目被拆分成多个服务，而每个服务可能会部署多个实例。当一个服务要调用另一个服务时，要知道另外一方的IP地址和端口号，如果采用硬编码，会面临以下问题：
- 动态扩容：活动高峰时一个服务加了十台机器部署，其他服务要访问只能修改配置文件并重启。
- 服务宕机：某个服务的一台机器挂了，其他服务依然向这台机器的服务发送请求，然后报错。
- 负载均衡：需要再搭建一台Nginx做负载均衡，使得维护更复杂了。
核心架构
三个角色
- 服务提供者（Provider）：对外提供接口的功能。
- 服务消费者（Consumer）：调用其他接口的服务。
- 注册中心（Registry）：存储所有服务的地址信息，监控各服务的状态。
四个动作
- 服务注册：提供者启动时，将自己的IP、端口、服务名上报给注册中心。
- 服务发现：消费者启动或需要调用时，向注册中心拉取提供者的地址列表并缓存在本地。
- 心跳续约：提供者定期向注册中心发送心跳。
- 健康检查与剔除：如果提供者长时间不发心跳，注册中心就将其从列表中删除，并通知消费者。