上半节已经下载好了 Zookeeper, 以及新建了两个应用 provider 和 consumer, 这一节我们就结合 dubbo 来测试一下分布式可不可以用.
现在就来简单用一下, 注意: 这里只是涉及最简单的部分, 新手入门用的, 详细的内容要学习的可以自己查一查资料; 然后再说说用 Zookeeper 当作注册中心的一个特点.
话说注册中心是一个类似第三方软件的东西, 那么我们能不能用 Dubbo + 其他注册中心呢? 其实也是可以的, 比如 Redis, 有兴趣的可以查查资料自己试试, 原理都差不多.
1. 导入依赖
两个模块都要导入这两个依赖 (这两个依赖千万要正确, 我就是因为自己导入依赖导错了, 愣是找了好几个小时最后才发现是依赖的问题, 我导入的组 id 是 com.alibaba.spring.boot, 太像了.... 细节细节!!!)
这里有一些版本问题, 我去官方文档截了一下图, 版本问题我也碰到了, 还是官方文档靠谱! 还有具体的版本对应我也截图了, 可以看看.
2.provider 模块新建一个服务
说是创建一个服务, 其实就是新建一个 service 层的接口, 写个实现
目录结构以及接口 + 实现
配置文件稍微配置一下, 其实就是配置自己服务在哪里, 还有 Zookeeper 的位置及端口 (Zookeeper 可以是在其他电脑或者虚拟机里), 其实还能配置很多东西, 这里列举最简单最实用的几个;
可以尝试启动一下, 没报错说明服务提供者完成!(那个 Zookeeper 服务端一定要开着)
3.consumer 模块消费服务
说是消费服务, 其实就是写个 controller, 注入 service 接口, 调用方法
看看 consumer 的目录结构和 controller 内容
简单配置一下配置文件:
4. 测试
首先保证 Zookeeper 服务端一直开着, 然后运行服务提供者应用, 然后再运行服务消费者应用, 再到浏览器输入 url, 结果如下:(应该打印服务提供者才对, 消息方面的东西看多了都打错字了, 问题不大, 嘿嘿!)
5. 简要说说 Zookeeper 作为注册中心的特点
服务注册中心在分布式系统会大量运用, 是分布式系统不可或缺的组件.
有需求就有利益, 有利益就会有动力! 正是因为服务注册中心这么重要, 所以很多公司都注重这方面的研发, 咳, 比如 rocketmq 的 NameServer,hdfs 的 Namenode,dubbo 的 Zookeeper,spring cloud 的 eureka,Consul 等等..
其中, 对于这两个: dubbo 的 Zookeeper,spring cloud 的 eureka 之间, 以及 Dubbo 和 Spring Cloud 之间哪种比较好的各种争论, 可谓是太多太多, 各有各的说法, 每个人都能举出一大堆理论, 对于我们来说, 其实无所谓的, 跟我们关系不大; 就像问你 hibernate 和 mybatis 哪个好啊? 只能说各有利弊吧!
不扯这么远了, 说一个分布式系统的原理 CAP:
绝大部分的分布式系统都会满足一个叫做 CAP 理论的东西 (当然也有很多争议, 暂且不提)
C(Consistency): 数据一致性, 例如多台服务器中对于存的同一用户的数据要一致
A(Availability): 可用性, 无论怎么了你都能访问这个系统; 例如其中一台或几台服务器挂掉了, 你还是能够正常使用, 服务器会响应成功 (可能响应的是更新之前的数据), 而不是一直在阻塞, 这点比较关键
P(Partition Tolerance): 分区容错性, 就是当用户在一台服务器修改了自己的数据, 但是由于网络等问题, 还没有来得及同步到其他的服务器, 于是就产生了分区; 怎样解决分区问题是分布式系统不可避免的问题.
而我们说的 Zookeeper 选的是 CP, 而 spring cloud 的 eureka 选的是 AP, 那么, 到底是选 CP 好还是 AP 好呢?
不好说, 只能是看什么需求;
选 P: 选了这个才能支持分布式, 才能进行横向扩展.
选 C: 注重一致性, 那就是要在多台服务器上数据要一致, 假如服务器同步数据的时候断网了, 那么你就要一直等待了, 直至同步成功; 典型的是银行转账系统, 这对数据的一致性是十分苛刻的, 一点都不能让步, 如果出错, 宁可停止服务;
选 A: 注重可用性, 例如你更新自己的数据, 然后服务器之间同步数据的时候断网了; 那么你再查询, 查询的可能还是原来更新之前的数据, 等待服务器数据同步完成你才会查询到最新数据; 互联网公司用这个比较多, 即使向用户响应更新之前的数据也总比让用户一直等待要好得多.
可见, 没有什么好不好, 只有适不适合你的需求.
现在有个大概的了解就好, 而且后面我可能会慢慢说说这两个分布式框架 Dubbo 和 Spring Cloud, 话说这两个分布式框架的争论随便查一下都有很多, 千万不要陷入其中, 重要的我们学到了什么东西!
Dubbo 是阿里巴巴内部开发并使用, 然后开源的一个很厉害的分布式框架, 再加上很多阿里的人出来在其他公司工作推行了 Dubbo 的使用, 虽然停止更新一段时间 17 年又恢复更新了, 但是在国内估计还是基于 Dubbo 的分布式系统占主流吧!(是不是主流我也不知道是不是, 道听途说而已).
而 Spring Cloud 是 Spring 家族的一个分布式框架, 里面功能十分健全, 可以说是一站式框架了, 在国外的话估计名气比 Dubbo 高.
要使用 Dubbo 还是 Spring Cloud, 看需要吧! 孰好孰坏也不是我们该担心的, ok, 就到这里吧!
下一节说说 Spring Cloud + eureka 简单用用分布式系统, 入门一下!
来源: https://www.cnblogs.com/wyq1995/p/10093877.html