什么是Dubbo框架？ _Dubbo框架

1. 什么是分布式框架<<分布式原理与范型>>
分布式系统是若干独立系统的集合,但是用户使用起来像是在使用一套系统
为什么需要分布式系统?
规模的扩大和业务的复杂,单台计算机扛不住双十一那样的流量,三个臭皮匠抵一个诸葛亮
2. 应用架构的发展演变1. 单一架构
当网站流量很小的时候,我们将所有的应用(业务)放到一台服务器上,打包运行
公司管理系统/超市收银系统
优点:开发简单,部署简单
缺点:扩展不容易(怎么处理日益增长的流量),谁都改一个,维护不容易,性能提升难
2. 垂直应用架构
将大应用拆分成为小应用(一般按照业务拆分),根据不同的访问频率决定各自业务部署的服务器数量
优点:扩展容易
缺点:页面一改,可能造成整个项目重新部署,业务和界面没有分离开,随着业务种类增加,怎么解决业务之间的互相调用问题,订单服务器和用户服务器交互效率的问题
3. 分布式架构(基于RPC:远程过程调用)
将业务拆分后,用某种方式实现各个业务模块的远程调用和复用,这时一个好的RPC框架就决定了你的分布式架构的性能,怎么调用,何时调用,服务器挂了怎么办......我们需要一个框架来帮我们解决这个问题(当然大大神可以自己写一个,但是应对大流量的集大成者莫过于中国的阿里巴巴公司,顶住了淘宝双十一的流量,反观12306和研招网,甚至一些学校内部的选课系统,对于大流量时只有两个字--宕机)
这时,我们本套课程的主人公就出现了(Dubbo),Dubbo是一个高性能的RPC框架,解决了分布式中的调用问题
优点:解决了分布式系统中互相调用的问题
缺点:假设有100台服务器,50台用户业务服务器,50台订单业务服务器,但是在上线后发现用户服务器使用率很小,但是订单服务器压力很大,最佳配比应该是1:4,这时候就要求我们还有一个统一管理的调度中心
4.流动计算架构
基于第3点中提到的资源浪费问题,我们需要一个能够实时根据调度情况来分配算力的架构,这就是流动计算架构
5. 微服务解决什么问题
微服务要解决什么问题 (高可用>一直可以用[创建副本],高并发,高性能)
造成一切的原因:网络是不可靠的
客户端如何访问这么多的服务?
用户不可能要用什么服务就访问该服务地址,这样做是低效的,我们应该给用户提供一个统一入口
服务聚合,API网关
服务与服务之间怎么通信
同步通信
– HTTP(Apache Http Client)
– RPC(Dubbo 只支持JAVA,别的有Apache Thrift,gRPC)
异步通信
– 消息队列 kafka RabbitMQ RocketMQ
这么多服务如何管理?
服务治理>服务的注册与发现
– 基于客户端的服务注册与发现
Apache Zookeeper
– 基于服务端的服务注册与发现
NetFlix Eureka
服务挂了(宕机)怎么办
– 重试机制
– 服务熔断
– 服务降级
– 服务限流
3.一些问题1. 什么是SOA
以下内容摘自百度百科

面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。

SOA类似于OOP,只是一种思想,既然是思想,那么就有落地的实现,Dubbo就是其中的一个

2. SOA和微服务区别
其实没有很大的区别,微服务也是一种思想,是SOA的延伸和升华,在本质上并没有什么大的区别
微服务是在SOA基础上加上了组件化的思想,微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”,原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。
3. SpringCloud 和 Dubbo区别和对比
如果一个人问"SpringCloud 和 Dubbo"哪个好,说明这个人一定是个小白
首先SpringCloud是为了解决在分布式开发中可能遇到的一揽子问题
而Dubbo是一个RPC框架,只解决远程调用的问题
他们没有好不好的问题,记住一句话技术没有好坏,只有适合不适合
甚至本文中学习的一些技术,在我们未来开发中会发现使用了这个技术反而让开发维护变得复杂,但是性能没有什么大的提升
这是因为我之前所说的:技术没有好坏,只有适合不适合