微服务项目之乐优--2.之前程序存在的问题及Eureka注册中心的简单使用
目录
一、之前程序存在的问题
在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地址