为什么用dubbo
来源:互联网 发布:如何规划高中知乎 编辑:程序博客网 时间:2024/06/06 11:40
需求
特点
错综复杂的引用关系,配置特别容易出错
为什么使用不使用开源RPC框架
跨语言调用型的 RPC 框架有 Thrift、gRPC、Hessian、Hprose 等。这类 RPC 框架侧重于服务的跨语言调用,能够支持大部分的语言进行语言无关的调用,非常适合多语言调用场景。但这类框架没有服务发现相关机制,实际使用时需要代理层进行请求转发和负载均衡策略控制。
国内比较大的互联网公司都会有自己的RPC框架,要不针对每个服务都进行服务发现和负载均衡的处理确实很麻烦。包括:dubbo,基于dubbo扩展的doubbx,微博的Motan RPC,天猫hsf,京东的,聚美优品。
服务调用的发展过程
第一阶段:简单集群
特点
1.增加一台ServerM-N都需要配置ServerM-1的集群地址
2.增加一台ServerM-N需要在F5增加一个节点,并且设置检查心跳脚本
3.配置项:
K+2K(N-1)其中:K为M-1集群服务F5配置;2K(N-1):F5配置其他机器服务K(N-1),每一层调用上一层K,总计K(N-1)
缺点
F5/Haproxy/Nginx/DNS负载器都一样,一个内部服务需要提供负载均衡,一定要在入口处负载,1、浪费入口资源; 2、不支持动态部署生效; 3、配置项多,容易出错;4、完全依懒于设备或者前端软件的负载均衡策略
第二阶段:集群+服务注册发现
特点
1.增加一个服务中不只需要配置zookeeper地址即可,之间的调用自动发现
2.内部服务不依懒于负载均衡设备,节省负载均衡设备的资源
3.配置项:2K项。
现实中的情况:服务发现+负载均衡
特点:
1.外网通过DNS负载来做,F5/Nginx/Haproxy做二层负载
2.内网调用复杂,类zookeeper的服务注册管理的来实现
总结
负载根据自己的业务发展来做,一般小网站在第一个阶段就可以满足很多需求。
参考文档
http://mp.weixin.qq.com/s?__biz=MzAwMDU1MTE1OQ==&mid=2653547134&idx=1&sn=44b97d6a5105498abd7aa3bba406157a&scene=23&srcid=0510CLC9lFT89Y2ESdkbcg58#rd
http://dubbo.io/
- 为什么用dubbo
- 为什么选择dubbo?
- 为什么要使用dubbo
- dubbo为什么用到了zookeeper
- dubbo为什么用到了zookeeper
- dubbo为什么用到了zookeeper
- dubbo为什么用到了zookeeper
- 既然有http 请求,为什么还要用rpc(dubbo接口)调用?
- dubbo服务提供者注册后为什么要有心跳机制
- 项目中为什么首先spring cloud,而不是dubbo
- 微服务领域,为什么选SpringCloud而不是Dubbo?
- dubbo
- Dubbo
- dubbo
- dubbo
- dubbo
- dubbo
- Dubbo
- apt-get update 和 upgrade 的区别
- 对inetd、xinetd与TCP_Wrapper的基本了解
- Struts2 Hello World 实例
- Android 动画之RotateAnimation应用详解(旋转动画效果 )(转载)
- 自定义事件函数Event
- 为什么用dubbo
- NYOJ 106 背包问题
- (OK) 编译cBPM-CentOS7-codeblocks
- TCP/IP协议族
- Android 动画之TranslateAnimation应用详解(位移动画效果 )(转载)
- HDU 2084 数塔
- 【持久化框架】SpringMVC+Spring4+Mybatis3集成,开发简单Web项目+源码下载
- JavaScript 数组
- (OK) cBPM(段错误(吐核))—((EndWorkflowEvent*)evt)->getProcessID()—getenv 返NULL