一、为什么使用Dubbo?
为什么使用Dubbo
?因为项目需要。
作为一直学习开发小项目的我,自然是不需要考虑高并发、微服务、分布式的啦,当然也考虑不到T.T,用不着这么高大上的技术,不过时代在改变呀,要想不被甩在马路牙子上哭,就得不停的学习新的知识,安慰完自己的小心灵了,那么,就开始学习Duboo吧!
学习每样技术前,我们都要了解它的前因后果,一句话,它是怎样产生地。
在以前,我们只需要一个服务器,将我们写好的程序打包发布这个服务器里就好,但是随着互联网时代的发展,现在人人都可以在网上购物、看资讯,对于中大型企业来说争取最大的访客量就是首要任务,然而访客量是增多了,可服务器带不起来了呀,这还不是普普通通的卡机,而是直接“殁了”,毕竟在2020年3月,淘宝月度活跃用户可是达到了8.46亿啊!!!
那之前的架构是啥样子的呢?PS:可能不太严谨~
1.单一服务架构
2.应用和数据库单独部署
3.应用和服务器集群
4.数据库读写分离
5.数据库分库分表
6.应用拆分为不同类型
发展到现在,我们可以发现应用与应用的 关系已经很十分复杂了,于是矛盾就出现啦,(以下摘自Dubbo官网)
1.当服务越来越多时,服务 URL 配置管理变得非常困难,硬件负载均衡器的单点压力也越来越大。
2.当进一步发展,服务间依赖关系变得错踪复杂,甚至分不清哪个应用要在哪个应用之前启动,架构师都不能完整的描述应用的架构关系。
3.接着,服务的调用量越来越大,服务的容量问题就暴露出来,这个服务需要多少机器支撑?什么时候该加机器?
于是Dubbo出现啦,当然能够解决这些问题的不止Dubbo,还有著名的Spring Cloud,咱们慢慢来,解决一座山才能到达下一座山咧。
Q: 当服务越来越多时,服务 URL 配置管理变得非常困难,F5 硬件负载均衡器的单点压力也越来越大。怎么办!?
A: 此时需要一个服务注册中心,动态地注册和发现服务,使服务的位置透明。并通过在消费方获取服务提供方地址列表,实现软负载均衡和 Failover,降低对 F5 硬件负载均衡器的依赖,也能减少部分成本。
也就是说这一个个应用类型太多啦,咱能记住一个两个三个四个名字地址,那,十几个呢?想想就瑟瑟发抖,所以我们就需要一个人来帮我们记住,于是注册中心出现啦,Dubbo官方提供参考的注册中心有Zookeeper、Nacos、Redis等,技术无好坏,具体就看你使用哪一种啦,透露一下,我打算先用Zookeeper来学习~
Q: 当进一步发展,服务间依赖关系变得错踪复杂,甚至分不清哪个应用要在哪个应用之前启动,架构师都不能完整的描述应用的架构关系。怎么办!?
A: 这时,需要自动画出应用间的依赖关系图,以帮助架构师理清关系。
Q: 接着,服务的调用量越来越大,服务的容量问题就暴露出来,这个服务需要多少机器支撑?什么时候该加机器?怎么办!?
A: 为了解决这些问题,第一步,要将服务现在每天的调用量,响应时间,都统计出来,作为容量规划的参考指标。其次,要可以动态调整权重,在线上,将某台机器的权重一直加大,并在加大的过程中记录响应时间的变化,直到响应时间到达阈值,记录此时的访问量,再以此访问量乘以机器数反推总容量。
总而言之,言而总之,当你的项目架构发挥到这个阶段,就需要考虑使用Dubbo啦!
二、Dubbo架构
来,上图!
来自官方的懵图,无从下手啊,来看看下面的几种角色介绍吧。
节点 | 角色说明 |
---|---|
Provider | 暴露服务的服务提供方 |
Consumer | 调用远程服务的服务消费方 |
Registry | 服务注册与发现的注册中心 |
Monitor | 统计服务的调用次数和调用时间的监控中心 |
Container | 服务运行容器 |
看了这个之后们就发现,好像也不是难理解啦,这和生产者-消费者模式好像呀,只是加入了注册中心和监控中心,那么整个流程变成了这样:
- 启动容器,连接注册中心;
- 服务提供者启动时,将自己的服务注册发布到注册中心;
- 服务消费者启动时,会在注册中心订阅自己所需要的服务。
如果订阅失败或者服务变更,就要考虑到:
- 如果有变更,注册中心将基于长连接推送变更数据给消费者。
- 服务消费者,从提供者地址列表中,基于软负载均衡算法,选一台提供者进行调用,如果调用失败,再选另一台调用。
- 服务消费者和提供者,在内存中累计调用次数和调用时间,定时每分钟发送一次统计数据到监控中心。
通过这番讲解,我相信我已经大致了解了Dubbo结构,那么就要开始入手啦~~~
PS:哪里不对,请点评论通知我!