目录
一、之前程序存在的问题
在consumer中，我们把url地址硬编码到了代码中，不方便后期维护
在consumer需要记忆user-service的地址，如果出现变更，可能得不到通知，地址将失效
consumer不清楚user-service的状态，服务宕机也不知道
user-service只有一台服务，不具备高可用性
即便user-service形成集群，consumer还需自己实现负载均衡
其实上面说的问题，概况一下就是分布式服务必须面临的问题：
服务管理
如何自动注册和发现
如何实现状态监督
如何实现动态路由
服务如何实现负载均衡
服务如何解决容灾问题
服务如何实现统一配置
二、Eureka注册中心
问题分析
在刚才的案例中，user-service对外提供了服务，需要对外暴露自己的地址。而consumer（调用者）需要记录服务提供者的地址。将来地址出现变更，还需要及时更新。这在服务较少的时候并不觉得有什么，但是在现在日益复杂的互联网环境，一个项目肯定会拆分出十几，甚至数十个微服务，此时如果还认为管理地址，不仅开发困难，将来测试、发布上线都会非常麻烦，这与DevOps的思想是背道而驰的。
Eureka与服务提供方之间通过“心跳”机制进行监控，当某个服务提供方出现问题，Eureka自然会把它从服务列表中剔除。
这就实现了服务的自动注册、发现、状态监控。
原理结构图
Eureka：就是服务注册中心（可以是一个集群），对外暴露自己的地址
提供者：启动后向Eureka注册自己信息（地址，提供什么服务）
消费者：向Eureka订阅服务，Eureka会将对于服务的所有提供者地址列表发送给消费者，并且定期更新
心跳（续约）：提供者定期通过http方式向Eureka刷新自己的状态
创建modul子项目eureka-server
导入eureka服务端相关jar
不需要写版本，因为父工程已经管理了所有spring cloud的依赖jar版本
创建启动类
增加eureka注解
书写端口
启动访问
但是后台有报错信息
配置注册地址
启动
添加应用名称
启动
解决eureka启动查询地址慢的问题
客服端的调整
user-service项目（服务的提供方）
引入eureka客户端jar
@EnableEurekaClient和@EnableDiscoveryClient的区别
如果注解写成了@EnableEurekaClient，那么注册中心只能是eureka
如果使用@EnableDiscoveryClient，可以兼容eureka或者zookeeper等任意注册中心
配置文件中配置好应用名，以及对应连接的注册中心
consumer-demo项目（服务的消费方）
引入eureka的依赖jar
注解同样
修改配置文件
动态获取对应服务
获取服务实例
由于在实际环境中，同一个服务可能建立多个集群，每一个tomcat部署的服务就是一个实例
动态获取IP地址
662
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
