做全屏式网站尺寸是多大郑州seo博客
引入：远程调用时，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发⽣故障时, 需要重新选举, 选举过程集群会有短暂时间的不可⽤