引入:远程调用时,url是写死的
String url = "http://127.0.0.1:9090/product/"+ orderInfo.getProductId();
解决思路:
比如(医院,学校等)机构的电话号码发生变化,就需要通知各个使⽤⽅, 但是这些机构的使⽤⽅群体是巨⼤的, 没办法做到⼀⼀通知, 怎么处理呢?
机构电话如果发⽣变化, 通知114. ⽤⼾需要联系机构时, 先打114查询电话, 然后再联系各个机构
同样的, 微服务开发时, 也可以采⽤类似的⽅案.
服务启动/变更时, 向注册中⼼报道. 注册中⼼记录应⽤和IP的关系.
调⽤⽅调⽤时, 先去注册中⼼获取服务⽅的IP, 再去服务⽅进⾏调⽤.
服务提供者(Server):⼀次业务中, 被其它微服务调⽤的服务. 也就是提供接⼝给其它微服务.
服务消费者(Client):⼀次业务中, 调⽤其它微服务的服务. 也就是调⽤其它微服务提供的接⼝.
服务注册中⼼(Registry): ⽤于保存Server 的注册信息, 当Server 节点发⽣变更时, Registry 会同步
变更. 服务与注册中⼼使⽤⼀定机制通信, 如果注册中⼼与某服务⻓时间⽆法通信, 就会注销该实例.
服务提供者和服务消费者是相对的
服务注册:服务提供者在启动时, 向 Registry 注册⾃⾝服务, 并向 Registry 定期发送⼼跳汇报存活状
态.
服务发现: 服务消费者从注册中⼼查询服务提供者的地址,并通过该地址调⽤服务提供者的接⼝. 服务
发现的⼀个重要作⽤就是提供给服务消费者⼀个可⽤的服务列表.
CPA理论:
⼀致性(Consistency) :CAP理论中的⼀致性, 指的是强⼀致性. 所有节点在同⼀时间具有相同的数据(多个数据库中,主数据库和从数据库的数据同步要完全一致)
可⽤性(Availability): 保证每个请求都有响应(响应结果可能不对)(对所有的请求都有响应)
分区容错性(Partition Tolerance): 当出现⽹络分区后,系统仍然能够对外提供服务(一个服务器出现错误时,其他的服务器能够做出响应)
生活中:以银行举例:银行利率下调,这个通知需要发到各个工作人员(这个通知下发是需要一定的时间的)
一致性:所有的银行工作人员,对客户讲的利率都是一样的
可用性:不论何时,银行工作人员对客户咨询利率都是有答案的(这个答案可能是就的)
分区容错性:如果其中一个工作人员请假了,银行依然可以对外提供服务
常见的注册中心:
1. Zookeeper
Zookeeper的官⽅并没有说它是⼀个注册中⼼, 但是国内Java体系, ⼤部分的集群环境都是依赖
Zookeeper来完成注册中⼼的功能.
2. Eureka
Eureka是Netflix开发的基于REST的服务发现框架, 主要⽤于服务注册, 管理,负载均衡和服务故障
转移.
官⽅声明在Eureka2.0版本停⽌维护, 不建议使⽤. 但是Eureka是SpringCloud服务注册/发现的默认
实现, 所以⽬前还是有很多公司在使⽤.
3. Nacos
Nacos是Spring Cloud Alibaba架构中重要的组件, 除了服务注册, 服务发现功能之外, Nacos还⽀持
配置管理, 流量管理, DNS, 动态DNS等多种特性.
1.搭建Eureka Server(eureka server是一个独立的微服务器)
1.1创建eureka-server子模块
2.2引⼊eureka-server依赖
1.3 项⽬构建插件
1.4 完善启动类
1.5编写配置⽂件
1.6 启动服务
启动服务, 访问注册中⼼: http://127.0.0.1:10010/
2.服务注册
2.1加入eureka依赖
2.2.添加eureka配置信息
2.3启动服务
3.服务发现
3.1加入eureka依赖
3.2添加eureka配置信息
3.3修改远程调用代码
这里用了三个product-service端口,所以
请求次数 1 2 3 4 5 6 7 8 9
实例 1 2 0 1 2 0 1 2 0
取余:请求计数器%实例数
3.4启动服务器
Eureka和Zookeeper都是⽤于服务注册和发现的⼯具,区别如下:
1. Eureka是Netflix开源的项⽬, ⽽Zookeeper是Apache开源的项⽬.
2. Eureka 基于AP原则, 保证⾼可⽤, Zookeeper基于CP原则, 保证数据⼀致性.
3. Eureka 每个节点 都是均等的, Zookeeper的节点区分Leader 和Follower 或 Observer, 也正因为这
个原因, 如果Zookeeper的Leader发⽣故障时, 需要重新选举, 选举过程集群会有短暂时间的不可⽤