Dubbo是阿里巴巴内部的SOA服务化治理方案的核心框架,天天为2000+ 个服务提供3,000,000,000+ 次访问量支持,并被普遍应用于阿里巴巴集团的各成员站点。Dubbo自2011年开源后,已被许多非阿里系公司使用。 java
Dubbo是一个分布式服务框架,以及SOA治理方案。其功能主要包括:高性能NIO通信及多协议集成,服务动态寻址与路由,软负载均衡与容错,依赖分析与降级等。
可参见:
http://alibaba.github.io/dubbo-doc-static/Home-zh.htm
当网站变大后,不可避免的须要拆分应用进行服务化,以提升开发效率,调优性能,节省关键竞争资源等。
当服务愈来愈多时,服务的URL地址信息就会爆炸式增加,配置管理变得很是困难,F5硬件负载均衡器的单点压力也愈来愈大。
当进一步发展,服务间依赖关系变得错踪复杂,甚至分不清哪一个应用要在哪一个应用以前启动,架构师都不能完整的描述应用的架构关系。
接着,服务的调用量愈来愈大,服务的容量问题就暴露出来,这个服务须要多少机器支撑?何时该加机器?等等……
在遇到这些问题时,均可以用Dubbo来解决。
可参见:
Dubbo的背景及需求
该框架具备极高的扩展性,采用微核+插件体系,而且文档齐全,很方便二次开发,适应性极强。
可参见:
开发者指南 - 框架设计
Dubbo运行JDK1.5之上,缺省依赖javassist、netty、spring等包,但不是必须依赖,经过配置Dubbo可不依赖任何三方库运行。
可参见:
用户指南 - 依赖
Dubbo经过长链接减小握手,经过NIO及线程池在单链接上并发拼包处理消息,经过二进制流压缩数据,比常规HTTP等短链接协议更快。在阿里巴巴内部,天天支撑2000多个服务,30多亿访问量,最大单机支撑天天近1亿访问量。
可参见:
Dubbo性能测试报告
Dubbo主要针对内部服务,对外的服务,阿里有开放平台来处理安全和流控,因此Dubbo在安全方面实现的功能较少,基本上只防君子不防小人,只防止误调用。
Dubbo经过Token令牌防止用户绕过注册中心直连,而后在注册中心上管理受权。Dubbo还提供服务黑白名单,来控制服务所容许的调用方。
可参见:
Dubbo的令牌验证
在阿里内部,除淘系之外的其它阿里子公司,都在使用Dubbo,包括:中文主站,国际主站,AliExpress,阿里云,阿里金融,阿里学院,良无限,来往等等。
开源后,已被:去哪儿,京东,吉利汽车,方正证劵,海尔,焦点科技,中润四方,华新水泥,海康威视,等公司普遍使用,并不停的有新公司加入,社区讨论及贡献活跃,获得用户很高的评价。
可参见:
Dubbo的已知用户
分布式事务可能暂不会支持,由于若是只是支持简单的XA/JTA两阶段提交事务,实用性并不强。用户能够自行实现业务补偿的事件,或更复杂的分布式事务,Dubbo有不少扩展点能够集成。
在多语言方面,Dubbo实现了C++版本,但在内部使用面极窄,没有获得很强的验证,而且C++开发资源紧张,没有精力准备C++开源事项。
Dubbo采用Apache License 2.0开源协议,它是一个商业友好的协议,你能够免费用于非开源的商业软件中。
你能够对它进行改造和二次发布,只要求保留阿里的著做权,并在再发布时保留原始许可声明。
可参见:
Dubbo的开源许可证
Dubbo共有六个开发人员参与开发和测试,每个开发人员都是颇有经验,团队合做很默契,开发过程也颇有节奏,有完善质量保障流程。团队组成:
- 梁飞 (开发人员/产品管理)
- 刘昊旻 (开发人员/过程管理)
- 刘超 (开发人员/用户支持)
- 李鼎 (开发人员/用户支持)
- 陈雷 (开发人员/质量保障)
- 闾刚 (开发人员/开源运维)
从左至右:刘超,梁飞,闾刚,陈雷,刘昊旻,李鼎
可参见:
Dubbo的团队成员
Dubbo的RPC框架已基本稳定,将来的重心会放在服务治理上,包括架构分析、监控统计、降级控制、流程协做等等。
可参见:
http://alibaba.github.io/dubbo-doc-static/Roadmap-zh.htm