您还没有登录,请您登录后再发表评论 相关推荐
-
dubbo最新版本2.0.9 下载
Dubbo 是阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和 Spring框架无缝集成。 主要核心部件： •Remoting: 网络通信框架，实现了 sync-over-async ...
-
阿里巴巴开源服务框架Dubbo2.0.9发布
链接：[url]http://www.iteye.com/news/23690[/url]
-
dubbo2.0.8 下载
Dubbo 是阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和 Spring框架无缝集成。 主要核心部件： •Remoting: 网络通信框架，实现了 sync-over-async ...
-
DUBBO使用指南
DUBBO用户指南 标签：dubbo| 发表时间：2014-04-28 06:08 | 作者：jy02718805 分享到： 出处：http://www.iteye.com 入门 (+) (#) 背景 (#) 随着互联网的发展，网站应用的规模...
-
DUBBO用户指南
入门 (+) (#) 背景 (#) 随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，亟需一个治理系统确保架构有条不紊的演进。 单一应用架构 当网站...
-
Nacos 2.0 性能提升十倍，贡献者 80% 以上来自阿里之外
Nacos 是阿里巴巴在 2018 年开源的一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台，也可以理解为微服务的注册中心 + 配置中心。 来源 |阿里巴巴云原生公众号 3 月 20 日，Nacos 2.0 正式发布...
-
Java开发 - 数风流人物，还看“微服务”
Spring Cloud的提供者主要有： Spring自己编写的框架和软件 Netflix(奈非):早期提供了很多(全套)微服务架构组件 alibaba(阿里巴巴):新版本SpringCloud，推荐使用(正在迅速占领市场) 我们目前使用的Spring Cloud大多...
-
SpringBoot笔记
Spring是一个开源框架，2003 年兴起的一个轻量级的Java 开发框架，作者：Rod Johnson 。 Spring是为了解决企业级应用开发的复杂性而创建的，简化开发。 为什么能简化开发，因为自动装配 Spring是如何简化Java开发的...
-
spring 包的依赖问题
Seata：阿里巴巴开源产品，一个易于使用的高性能微服务分布式事务解决方案。 Alibaba Cloud ACM：一款在分布式架构环境中对应用配置进行集中管理和推送的应用配置中心产品。 Alibaba Cloud OSS: 阿里云对象存储...
-
关于SpringCloud的所有笔记
广义上指代Spring的所有产品 Spring Cloud的内容 内容的提供者 Spring自己提供的开发出来的框架或软件 Netflix(奈非):早期的很长一段时间,提供了大量的微服务解决方案 alibaba(阿里巴巴):新版本的SpringCloudAlibaba...
-
k8s 部署spring cloud项目
微服务架构是一项在云中部署应用和服务的新技术。大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务，而红帽说API应该是重点。 微服务可以在"自己的程序"中运行，并通过"轻量级设备与HTTP型API...
-
《Java工程师修炼之道》学习笔记
典型的 MVC 框架如 SpringMVC、 Jersey、国人开发的 JFinal 以及阿里的 WebX。 loC 框架 ： 可实现依赖注入／控制反转的框架。 Java 中最流行的 Spring 框架的核心 就是 IoC 功能。 ORM 框架 ： 是能够...
-
Spring Boot基础笔记
Dubbo与ZooKeeper Dubbo ZooKeeper Linux下ZooKeeper的下载安装与启动 Dubbo-admin下载与打包 远程服务注册与调用 注册 调用 第一个Spring Boot程序 创建一个SpringBoot项目 这里的包名默认会在后面自动拼接项目名,...
-
Spring Boot
Spring是一个开源框架，2003 年兴起的一个轻量级的Java 开发框架，作者：Rod Johnson 。 Spring是为了解决企业级应用开发的复杂性而创建的，简化开发。 2、Spring是如何简化Java开发的 为了降低Java开发的复杂性，...
-
kubernetes部署spring cloud微服务项目
微服务架构是一项在云中部署应用和服务的新技术。大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务，而红帽说API应该是重点。 微服务可以在"自己的程序"中运行，并通过"轻量级设备与HTTP型API...
-
SpringBoot快速入门
Spring Boot的主要优点： 为所有Spring开发者更快的入门 开箱即用，提供各种默认配置来简化项目配置 内嵌式容器简化Web项目 没有冗余代码生成和XML配置的要求 2、微服务 微服务：架构风格（服务微化） 一个应用应该...
-
基于springboot大学生就业信息管理系统源码数据库文档.zip
基于springboot大学生就业信息管理系统源码数据库文档.zip
-
基于java的驾校收支管理可视化平台的开题报告.docx
基于java的驾校收支管理可视化平台的开题报告
-
原木5秒数据20241120.7z
时间序列 原木 间隔5秒钟 20241120
-
毕业设计&课设_基于 Vue 的电影在线预订与管理系统：后台 Java（SSM）代码，为毕业设计项目.zip
毕业设计&课设_基于 Vue 的电影在线预订与管理系统：后台 Java（SSM）代码，为毕业设计项目.zip
45 楼 javatar 2011-12-22 21:51
多谢支持。
44 楼 grantbb 2011-12-22 16:06
既然你认为自己的“孩子”怎么都好，我就没必要说什么了。开源的东西完全靠活跃度支撑，当然如果你把in-house的东西拿出来就认为是开源，做贡献了，那只能说中国的开源之路还很长。
嗯，开放源代码的只是开源的很小一步，开源社区的建立，贡献反馈机制的形成，文档及经验的传承，相关产品集成的生态链，等等，才是开源的关键，Dubbo只是开了个头，不敢说有多大贡献，只是希望抛砖引玉，有个开源的意识。
前面回你那么多内容，不是我们不清楚Dubbo的劣势，公司层面开源的产品，肯定会受制于内部需求的影响，只是想说明我们已经在尽力避免，不只是简单的拿一个现成的产品，直接开放源代码就了事。
我理解你们的难处，但是你要明白，好的开元产品就是来自于大公司的实际应用，但问题在于，你如何把你们日常工作中的产品抽象和封装的完美之后做成开元产品，而不是直接拿来就开源，这是有本质区别的。
或者换句话说，你如果只是拿出一个核心的小部分，然后做成开元项目，让大家慢慢理解你的核心，我觉得这个更靠铺，而不是一下子就是一大坨（不好意思，修辞不当，但是看了你们的文档，源代码，包括分层的图纸后，这是一个直观的感受）。
话虽然糙点，但是，我看来看去好像国内taobao属于最吸引技术人员的公司了，所以，也希望你们可以真的用心做。
既然你认为自己的“孩子”怎么都好，我就没必要说什么了。开源的东西完全靠活跃度支撑，当然如果你把in-house的东西拿出来就认为是开源，做贡献了，那只能说中国的开源之路还很长。
嗯，开放源代码的只是开源的很小一步，开源社区的建立，贡献反馈机制的形成，文档及经验的传承，相关产品集成的生态链，等等，才是开源的关键，Dubbo只是开了个头，不敢说有多大贡献，只是希望抛砖引玉，有个开源的意识。
前面回你那么多内容，不是我们不清楚Dubbo的劣势，公司层面开源的产品，肯定会受制于内部需求的影响，只是想说明我们已经在尽力避免，不只是简单的拿一个现成的产品，直接开放源代码就了事。
我理解你们的难处，但是你要明白，好的开元产品就是来自于大公司的实际应用，但问题在于，你如何把你们日常工作中的产品抽象和封装的完美之后做成开元产品，而不是直接拿来就开源，这是有本质区别的。
或者换句话说，你如果只是拿出一个核心的小部分，然后做成开元项目，让大家慢慢理解你的核心，我觉得这个更靠铺，而不是一下子就是一大坨（不好意思，修辞不当，但是看了你们的文档，源代码，包括分层的图纸后，这是一个直观的感受）。
话虽然糙点，但是，我看来看去好像国内taobao属于最吸引技术人员的公司了，所以，也希望你们可以真的用心做。
谈到最后越来越和谐了。阿里系近两年还是在不断努力的，也能看到一些成果，虽然跟世界级的还有差距，但是这个必须要靠开源社区，靠大家这些开发者一起努力。我个人认为这个框架，至少是一个有用的框架，很多网站发展到一定的规模后，比如：pv上亿，应用和服务非常多的时候，就非常需要这样的解决方案。
支持一下，回头会用一下。
43 楼 lonelybug 2011-12-22 07:19
既然你认为自己的“孩子”怎么都好，我就没必要说什么了。开源的东西完全靠活跃度支撑，当然如果你把in-house的东西拿出来就认为是开源，做贡献了，那只能说中国的开源之路还很长。
嗯，开放源代码的只是开源的很小一步，开源社区的建立，贡献反馈机制的形成，文档及经验的传承，相关产品集成的生态链，等等，才是开源的关键，Dubbo只是开了个头，不敢说有多大贡献，只是希望抛砖引玉，有个开源的意识。
前面回你那么多内容，不是我们不清楚Dubbo的劣势，公司层面开源的产品，肯定会受制于内部需求的影响，只是想说明我们已经在尽力避免，不只是简单的拿一个现成的产品，直接开放源代码就了事。
我理解你们的难处，但是你要明白，好的开元产品就是来自于大公司的实际应用，但问题在于，你如何把你们日常工作中的产品抽象和封装的完美之后做成开元产品，而不是直接拿来就开源，这是有本质区别的。
或者换句话说，你如果只是拿出一个核心的小部分，然后做成开元项目，让大家慢慢理解你的核心，我觉得这个更靠铺，而不是一下子就是一大坨（不好意思，修辞不当，但是看了你们的文档，源代码，包括分层的图纸后，这是一个直观的感受）。
话虽然糙点，但是，我看来看去好像国内taobao属于最吸引技术人员的公司了，所以，也希望你们可以真的用心做。
42 楼 cs_liwei 2011-12-21 09:41
41 楼 javatar 2011-12-20 23:38
既然你认为自己的“孩子”怎么都好，我就没必要说什么了。开源的东西完全靠活跃度支撑，当然如果你把in-house的东西拿出来就认为是开源，做贡献了，那只能说中国的开源之路还很长。
嗯，开放源代码的只是开源的很小一步，开源社区的建立，贡献反馈机制的形成，文档及经验的传承，相关产品集成的生态链，等等，才是开源的关键，Dubbo只是开了个头，不敢说有多大贡献，只是希望抛砖引玉，有个开源的意识。
前面回你那么多内容，不是我们不清楚Dubbo的劣势，公司层面开源的产品，肯定会受制于内部需求的影响，只是想说明我们已经在尽力避免，不只是简单的拿一个现成的产品，直接开放源代码就了事。
40 楼 lonelybug 2011-12-20 21:46
我大概明白你的初衷，但是，随着后来需求增加，我感觉你们是一直再堆砌的构架这个framework，并没有说设计一个完整的，什么都有，最后就是什么都没有，因为已经把核心的领域完全的淹没在你的各个功能之中了。
我觉得如果按你的blog说得知识打算提供一个平台可以调用各种service，包括服务和资源的共享，我觉得你们应该从新设计一下，把真正该抽象的抽象了，而不是，看见什么抽象什么，比如要AOP就抽象method变成invoker和invocation（invocation在这里打不到你说得一个context的目的，包括从context这个字面上理解上也没有达到），但其实你们的事要提供新的service的install，然后可以让其他的service知道有这么一个service的存在，然后调用它，其实说白了OSGi已经达到了你们的要求了。
Dubbo和OSGi以及Spring是没有可比性的，OSGi和Spring本身就是做组件生命周期管理容器的，而Dubbo只管理自身扩展点，有意做了一些简化。
OSGi也有服务的调用机制，但它的设计初衷是跨bundle之间的调用，可能也能抽象远程服务，但总有些阻抗，而Dubbo将远程服务调用作为一等公民，模型比OSGi也要简单很多，可能越通用越难用，Dubbo只是取一个平衡点而已。
Dubbo还有一个原则是，保持在原有功能的基础上增量式扩展，而不是扩充原有简单功能的概念，比如要加一个支持会话的传输，Dubbo是不会在传输上加个标记说是否支持会话，而是会新起一个扩展模块来支持会话功能，这样就能保持原有功能的简单性，不会使原有功能多出不需要的概念。
当然，Dubbo也有很多设计不优雅的地方，但整体抽象还是比较一致的。
既然你认为自己的“孩子”怎么都好，我就没必要说什么了。开源的东西完全靠活跃度支撑，当然如果你把in-house的东西拿出来就认为是开源，做贡献了，那只能说中国的开源之路还很长。
39 楼 javatar 2011-12-19 22:57
我大概明白你的初衷，但是，随着后来需求增加，我感觉你们是一直再堆砌的构架这个framework，并没有说设计一个完整的，什么都有，最后就是什么都没有，因为已经把核心的领域完全的淹没在你的各个功能之中了。
我觉得如果按你的blog说得知识打算提供一个平台可以调用各种service，包括服务和资源的共享，我觉得你们应该从新设计一下，把真正该抽象的抽象了，而不是，看见什么抽象什么，比如要AOP就抽象method变成invoker和invocation（invocation在这里打不到你说得一个context的目的，包括从context这个字面上理解上也没有达到），但其实你们的事要提供新的service的install，然后可以让其他的service知道有这么一个service的存在，然后调用它，其实说白了OSGi已经达到了你们的要求了。
Dubbo和OSGi以及Spring是没有可比性的，OSGi和Spring本身就是做组件生命周期管理容器的，而Dubbo只管理自身扩展点，有意做了一些简化。
OSGi也有服务的调用机制，但它的设计初衷是跨bundle之间的调用，可能也能抽象远程服务，但总有些阻抗，而Dubbo将远程服务调用作为一等公民，模型比OSGi也要简单很多，可能越通用越难用，Dubbo只是取一个平衡点而已。
Dubbo还有一个原则是，保持在原有功能的基础上增量式扩展，而不是扩充原有简单功能的概念，比如要加一个支持会话的传输，Dubbo是不会在传输上加个标记说是否支持会话，而是会新起一个扩展模块来支持会话功能，这样就能保持原有功能的简单性，不会使原有功能多出不需要的概念。
当然，Dubbo也有很多设计不优雅的地方，但整体抽象还是比较一致的。
38 楼 lonelybug 2011-12-19 21:44
我大概明白你的初衷，但是，随着后来需求增加，我感觉你们是一直再堆砌的构架这个framework，并没有说设计一个完整的，什么都有，最后就是什么都没有，因为已经把核心的领域完全的淹没在你的各个功能之中了。
我觉得如果按你的blog说得知识打算提供一个平台可以调用各种service，包括服务和资源的共享，我觉得你们应该从新设计一下，把真正该抽象的抽象了，而不是，看见什么抽象什么，比如要AOP就抽象method变成invoker和invocation（invocation在这里打不到你说得一个context的目的，包括从context这个字面上理解上也没有达到），但其实你们的事要提供新的service的install，然后可以让其他的service知道有这么一个service的存在，然后调用它，其实说白了OSGi已经达到了你们的要求了。
37 楼 lonelybug 2011-12-19 21:22
我实话实说，我没看源代码，我倒是看了你们的文档(http://code.alibabatech.com/wiki/display/dubbo/Developer+Guide)
你觉得每一个框架和系统的抽象首先要有一个核心领域，围绕着这个核心领域来做封装和抽象。
如果这个系统框架是分层了，那么应该是单一方向的调用，要不是从上到下，要不是从下到上，不应该是双向的，双向的结果就是乱，非常混乱，到最后你自己都回晕，比如那个filter和invoker的调用关系，你的protocol, cluster和proxy都有filter或者invoker，这些interface是一样东西么？
其次，消费和生产两个贯穿了所有的层。很让我费解。我以为你的consumer和producer因该市说得service级别的。
在有就是contribution spi，我没太明白你这个spi是说得service provider interface么？如果是的话，你可以看一下java源代码里面关于声音codec那个包的一个spi，简单易懂。
就事论事，我也没有必要抨击你的设计，不过，以我设计的经验来看，我没找到你这个框架的核心功能到底是什么？（当然你说了我大概知道是RPC之类的）设计一个框架抽象的不单单是interface还是class这么简单，他也跟设计一个系统一样，需要知道核心领域在那里。
我觉得先把最简单的核心问题设计好了，其他的都迎刃而解，虽然你们成功的部署了这个在taobao上，但是不代表这个框架是well design。
最后你说的内部使用时过度设计，我没明白你要说啥，如果是内部使用都过渡设计了，那你开源之后这个项目又有多少人愿意去贡献代码呢？没有一个核心的清晰的设计思路，别人很难贡献代码，当然，你要是觉得知识把in-house的东西拿出来就叫做对开源社区作贡献了，我觉得图自己一个乐呵还是很不错的。
说了一些零零散散，不到的地方见谅。
多谢你提出的看法，这样可以更深层的交流。
我也说说我的看法：
首先，从分层上看：
Developer Guide 的设计图上，右边有黑色向下的箭头，表示层之间的从上下向依赖的，没有任何循环或反向依赖。
1. 在RPC中，Protocol是核心层，也就是只要有Protocol + Invoker + Exporter就可以完成非透明的RPC调用，然后在Invoker的主过程上Filter拦截点。
2. 图中的Consumer和Provider是抽象概念，只是想让看图者更直观的了解哪些类分属于客户端与服务器端，不用Client和Server的原因是Dubbo在很多场景下都使用Provider, Consumer, Registry, Monitor划分逻辑拓普节点，保持统一概念。
2. 而Cluster是外围概念，所以Cluster的目的是将多个Invoker伪装成一个Invoker，这样其它人只要关注Protocol层Invoker即可，加上Cluster或者去掉Cluster对其它层都不会造成影响，因为只有一个提供者时，是不需要Cluster的。
3. Proxy层封装了所有接口的透明化代理，而在其它层都以Invoker为中心，只有到了暴露给用户使用时，才用Proxy将Invoker转成接口，或将接口实现转成Invoker，也就是去掉Proxy层RPC是可以Run的，只是不那么透明，不那么看起来像调本地服务一样调远程服务。
4. 而Remoting实现是Dubbo协议的实现，如果你选择RMI协议，整个Remoting都不会用上，Remoting内部再划为Transport传输层和Exchange信息交换层，Transport层只负责单向消息传输，是对Mina,Netty,Grizzly的抽象，它也可以扩展UDP传输，而Exchange层是在传输层之上封装了Request-Response语义。
5. Registry和Monitor实际上不算一层，而是一个独立的节点，只是为了全局概览，用层的方式画在一起。
再者，从领域划分上看：
先说理论，Dubbo按服务域，实体域，会话域进行划分：
1. 服务域指产品主要功能入口，同时负责实体域和会话域的生命周期管理，比如：Spring的ApplicationContext，Velocity的Engine。
2. 实体域表示你要操作的对象模型，不管什么产品，总有一个核心概念，大家都绕围它转，比如：Spring的Bean，Velocity的Template。
3. 会话域表示每次操作瞬时状态，操作前创建，操作后销毁，比如：Velocity的Context。
这种划分的好处是服务域可以无状态，实体域可以成为不变类，而会话域保持所有可变状态，且会话域只在线程栈内使用，从而三者都是线程安全的。
在Dubbo的核心领域模型中：
1. Protocol是服务域，它是Invoker暴露和引用的主功能入口，它负责Invoker的生命周期管理。
2. Invoker是实体域，它是Dubbo的核心模型，其它模型都向它靠扰，或转换成它，它代表一个可执行体，可向它发起invoke调用，它有可能是一个本地的实现，也可能是一个远程的实现，也可能一个集群实现。
3. Invocation是会话域，它持有调用过程中的变量，比如方法名，参数等。
谢谢你的回复，我一会要去上班，所以，没有时间仔细看，不过，我已经看了一下源代码和你说的东西。
我还是有一个问题，需要你清晰回答一下，这个框架的主要实现的目的是为了解决一个什么问题？或者提供什么样的服务帮助其他人解决一个什么问题呢？
我之所以文上面的问题是，你一上来说得很清楚RPG是protocol invoker exporter的组合，我也看了一下，这三个的借口设计都听清晰简洁的，但是，当你开始设计其他各个“层”的时候，就开始什么都封装，又什么都暴露了！
之所以我把你说的“层”加了引号是因为，这应该不是层的概念，你应该是package的概念，或者是Module的概念作的transport, exchange, monitor之类的，因为，如果是曾的设计，最后暴露的应该是最上层给用户，SPI也应该是暴露扩展性接口，不应该是每一个“层”都在暴露，包括核心逻辑。
还是希望你现能帮我解决我的迷惑，回答一下我这个问题。谢谢先。
36 楼 javatar 2011-12-19 11:46
我实话实说，我没看源代码，我倒是看了你们的文档(http://code.alibabatech.com/wiki/display/dubbo/Developer+Guide)
你觉得每一个框架和系统的抽象首先要有一个核心领域，围绕着这个核心领域来做封装和抽象。
如果这个系统框架是分层了，那么应该是单一方向的调用，要不是从上到下，要不是从下到上，不应该是双向的，双向的结果就是乱，非常混乱，到最后你自己都回晕，比如那个filter和invoker的调用关系，你的protocol, cluster和proxy都有filter或者invoker，这些interface是一样东西么？
其次，消费和生产两个贯穿了所有的层。很让我费解。我以为你的consumer和producer因该市说得service级别的。
在有就是contribution spi，我没太明白你这个spi是说得service provider interface么？如果是的话，你可以看一下java源代码里面关于声音codec那个包的一个spi，简单易懂。
就事论事，我也没有必要抨击你的设计，不过，以我设计的经验来看，我没找到你这个框架的核心功能到底是什么？（当然你说了我大概知道是RPC之类的）设计一个框架抽象的不单单是interface还是class这么简单，他也跟设计一个系统一样，需要知道核心领域在那里。
我觉得先把最简单的核心问题设计好了，其他的都迎刃而解，虽然你们成功的部署了这个在taobao上，但是不代表这个框架是well design。
最后你说的内部使用时过度设计，我没明白你要说啥，如果是内部使用都过渡设计了，那你开源之后这个项目又有多少人愿意去贡献代码呢？没有一个核心的清晰的设计思路，别人很难贡献代码，当然，你要是觉得知识把in-house的东西拿出来就叫做对开源社区作贡献了，我觉得图自己一个乐呵还是很不错的。
说了一些零零散散，不到的地方见谅。
多谢你提出的看法，这样可以更深层的交流。
我也说说我的看法：
首先，从分层上看：
Developer Guide 的设计图上，右边有黑色向下的箭头，表示层之间的从上下向依赖的，没有任何循环或反向依赖。
1. 在RPC中，Protocol是核心层，也就是只要有Protocol + Invoker + Exporter就可以完成非透明的RPC调用，然后在Invoker的主过程上Filter拦截点。
2. 图中的Consumer和Provider是抽象概念，只是想让看图者更直观的了解哪些类分属于客户端与服务器端，不用Client和Server的原因是Dubbo在很多场景下都使用Provider, Consumer, Registry, Monitor划分逻辑拓普节点，保持统一概念。
2. 而Cluster是外围概念，所以Cluster的目的是将多个Invoker伪装成一个Invoker，这样其它人只要关注Protocol层Invoker即可，加上Cluster或者去掉Cluster对其它层都不会造成影响，因为只有一个提供者时，是不需要Cluster的。
3. Proxy层封装了所有接口的透明化代理，而在其它层都以Invoker为中心，只有到了暴露给用户使用时，才用Proxy将Invoker转成接口，或将接口实现转成Invoker，也就是去掉Proxy层RPC是可以Run的，只是不那么透明，不那么看起来像调本地服务一样调远程服务。
4. 而Remoting实现是Dubbo协议的实现，如果你选择RMI协议，整个Remoting都不会用上，Remoting内部再划为Transport传输层和Exchange信息交换层，Transport层只负责单向消息传输，是对Mina,Netty,Grizzly的抽象，它也可以扩展UDP传输，而Exchange层是在传输层之上封装了Request-Response语义。
5. Registry和Monitor实际上不算一层，而是一个独立的节点，只是为了全局概览，用层的方式画在一起。
再者，从领域划分上看：
先说理论，Dubbo按服务域，实体域，会话域进行划分：
1. 服务域指产品主要功能入口，同时负责实体域和会话域的生命周期管理，比如：Spring的ApplicationContext，Velocity的Engine。
2. 实体域表示你要操作的对象模型，不管什么产品，总有一个核心概念，大家都绕围它转，比如：Spring的Bean，Velocity的Template。
3. 会话域表示每次操作瞬时状态，操作前创建，操作后销毁，比如：Velocity的Context。
这种划分的好处是服务域可以无状态，实体域可以成为不变类，而会话域保持所有可变状态，且会话域只在线程栈内使用，从而三者都是线程安全的。
在Dubbo的核心领域模型中：
1. Protocol是服务域，它是Invoker暴露和引用的主功能入口，它负责Invoker的生命周期管理。
2. Invoker是实体域，它是Dubbo的核心模型，其它模型都向它靠扰，或转换成它，它代表一个可执行体，可向它发起invoke调用，它有可能是一个本地的实现，也可能是一个远程的实现，也可能一个集群实现。
3. Invocation是会话域，它持有调用过程中的变量，比如方法名，参数等。
35 楼 lonelybug 2011-12-19 08:28
不过不愿意听我还是要说一句，这个不能叫做一个什么开源框架，确切地说是一个你们自己用这比较顺手的框架，然后你们贡献出来。
国内的开源框架，很多人都是那种各种功能的堆积品，并不是真正把问题抽象化之后的一种工具类产品，更确切地说，大部分都是因为满足一个很窄的应用面，而不是像spring，ASM这种类型的框架，提供一个抽象型的工具产品。
这两种有本质上的区别。换句话说，你可以用ASM，或者Spring来做很大或者很小的应用，但是你不能用这个陶宝框架开发一个小型的应用或者定制成你自己的应用。
OSGI级别的框架就更达不到了。
我不知道你有没有看过Dubbo的代码，但Dubbo确实是一个抽象过的框架，而不是一个为内部特定场景写的固化产品，Dubbo为开源做了很多工作，如果只是用内部，可以说有些过度设计。
我实话实说，我没看源代码，我倒是看了你们的文档(http://code.alibabatech.com/wiki/display/dubbo/Developer+Guide)
你觉得每一个框架和系统的抽象首先要有一个核心领域，围绕着这个核心领域来做封装和抽象。
如果这个系统框架是分层了，那么应该是单一方向的调用，要不是从上到下，要不是从下到上，不应该是双向的，双向的结果就是乱，非常混乱，到最后你自己都回晕，比如那个filter和invoker的调用关系，你的protocol, cluster和proxy都有filter或者invoker，这些interface是一样东西么？
其次，消费和生产两个贯穿了所有的层。很让我费解。我以为你的consumer和producer因该市说得service级别的。
在有就是contribution spi，我没太明白你这个spi是说得service provider interface么？如果是的话，你可以看一下java源代码里面关于声音codec那个包的一个spi，简单易懂。
就事论事，我也没有必要抨击你的设计，不过，以我设计的经验来看，我没找到你这个框架的核心功能到底是什么？（当然你说了我大概知道是RPC之类的）设计一个框架抽象的不单单是interface还是class这么简单，他也跟设计一个系统一样，需要知道核心领域在那里。
我觉得先把最简单的核心问题设计好了，其他的都迎刃而解，虽然你们成功的部署了这个在taobao上，但是不代表这个框架是well design。
最后你说的内部使用时过度设计，我没明白你要说啥，如果是内部使用都过渡设计了，那你开源之后这个项目又有多少人愿意去贡献代码呢？没有一个核心的清晰的设计思路，别人很难贡献代码，当然，你要是觉得知识把in-house的东西拿出来就叫做对开源社区作贡献了，我觉得图自己一个乐呵还是很不错的。
说了一些零零散散，不到的地方见谅。
34 楼 javatar 2011-12-18 21:49
不过不愿意听我还是要说一句，这个不能叫做一个什么开源框架，确切地说是一个你们自己用这比较顺手的框架，然后你们贡献出来。
国内的开源框架，很多人都是那种各种功能的堆积品，并不是真正把问题抽象化之后的一种工具类产品，更确切地说，大部分都是因为满足一个很窄的应用面，而不是像spring，ASM这种类型的框架，提供一个抽象型的工具产品。
这两种有本质上的区别。换句话说，你可以用ASM，或者Spring来做很大或者很小的应用，但是你不能用这个陶宝框架开发一个小型的应用或者定制成你自己的应用。
OSGI级别的框架就更达不到了。
我不知道你有没有看过Dubbo的代码，但Dubbo确实是一个抽象过的框架，而不是一个为内部特定场景写的固化产品，Dubbo为开源做了很多工作，如果只是用内部，可以说有些过度设计。
33 楼 lonelybug 2011-12-18 02:33
或者说，可以做成Intranet Open API。
嗯，通过消息队列解耦也是一种常用方式，公司也有相应产品解决此类问题，但公司并没有采用全异步消息总线模式的架构，对于数据查询居多的服务，实时调用可以简化双向交互，也能减少三方队列的部署，另外消息的延迟和堆积，也常会制约其适用性。
同样，公司也有OpenAPI产品，主要关注于安全认证，流量控制，协议转换，对于内部交互，可能在大并发性能，软负载均衡，自动发现，运维治理等方面需要处理的的更多，内部网络的安全性，内部协议的可统一性，使得安全，流控，转换，都相对可以弱一些，只需防君子误用，不用防小人，我们也正在整合内部服务框架和对外服务网关。
不过不愿意听我还是要说一句，这个不能叫做一个什么开源框架，确切地说是一个你们自己用这比较顺手的框架，然后你们贡献出来。
国内的开源框架，很多人都是那种各种功能的堆积品，并不是真正把问题抽象化之后的一种工具类产品，更确切地说，大部分都是因为满足一个很窄的应用面，而不是像spring，ASM这种类型的框架，提供一个抽象型的工具产品。
这两种有本质上的区别。换句话说，你可以用ASM，或者Spring来做很大或者很小的应用，但是你不能用这个陶宝框架开发一个小型的应用或者定制成你自己的应用。
OSGI级别的框架就更达不到了。
32 楼 javatar 2011-12-18 01:09
开源的整个RPC框架是完整的，只是裁剪了和内部其它系统或产品有集成或交互的扩展模块，因为相关产品没有开源，开源出来也没法用，包括内部的监控中心，内部的注册中心，内部的异步消息队列集成等。
31 楼 小牛犊 2011-12-18 00:54
30 楼 shuaiji 2011-12-16 09:35
29 楼 javatar 2011-12-16 01:49
不知你是不是说的Dubbo的Version类中，获取Dubbo的jar包和服务接口的jar包版本的问题，
因为不是所有项目都使用Maven，所以没有从maven的version.properties中获取版本号，而是采用Java标准的jar包版本获取方式，读取MANIFEST.MF中的版本，如果MF中没有，则通过jar包名猜测版本号，
如果使用Maven，只需在pom中声明生成jar包MANIFEST版本即可：
<plugin> <artifactId>maven-jar-plugin</artifactId> <configuration> <archive> <manifest> <addDefaultSpecificationEntries>true</addDefaultSpecificationEntries> <addDefaultImplementationEntries>true</addDefaultImplementationEntries> </manifest> </archive> </configuration> </plugin>28 楼 javatar 2011-12-16 01:04
上次发现用windows当服务器，时间长了发现rmi会出现连接被断开、且连接被会被一直拒绝，只能重启服务才ok，不知道是怎么回事。
下次可以尝试使用下dubbo
原生RMI确实存在的连接断开后一直拒绝请求的问题，所以在遇到特定异常时需要重建Stub，或采用池化多个Stub做连接检测，可以参照Spring对RMI问题的做法：
http://kickjava.com/src/org/springframework/remoting/rmi/RmiClientInterceptor.java.htm，看其中invoke()方法的异常处理方式，Dubbo对RMI协议的支持是直接桥接到Spring实现的。
27 楼 javatar 2011-12-16 00:47
或者说，可以做成Intranet Open API。
嗯，通过消息队列解耦也是一种常用方式，公司也有相应产品解决此类问题，但公司并没有采用全异步消息总线模式的架构，对于数据查询居多的服务，实时调用可以简化双向交互，也能减少三方队列的部署，另外消息的延迟和堆积，也常会制约其适用性。
同样，公司也有OpenAPI产品，主要关注于安全认证，流量控制，协议转换，对于内部交互，可能在大并发性能，软负载均衡，自动发现，运维治理等方面需要处理的的更多，内部网络的安全性，内部协议的可统一性，使得安全，流控，转换，都相对可以弱一些，只需防君子误用，不用防小人，我们也正在整合内部服务框架和对外服务网关。
26 楼 lonelybug 2011-12-15 21:15
Dubbo是一个RPC框架，比如你需要跨部门调用服务，或者因SOA架构需要垂直拆分应用，可能就需要远程服务调用，但用RMI,Hessian等RPC方案都需要F5等硬件负载均衡器处理集群问题，用Dubbo就可以通过软负载均衡处理集群，再者，服务多了，服务的地址很难配置，这个时候可以用Dubbo的注册中心进行服务发现，大家只要知道注册中心地址，不需要关心各服务部署在哪台机器上，另外服务多了，你可能需要看应用间的依赖关系，服务的调用次和调用时间，可能需要在运行期进行服务路由等等，这些就是Dubbo要做的。
好奇问问，为什么不用JMS之类的消息驱动框架作为降低服务间的依赖关系和对具体的服务器的配置？
或者说，可以做成Intranet Open API。