公司项目使用Duboo技术架构也有一段时间，做下简单的经验总结，不喜勿喷。
还是先说下Dubbo技术的来源，直接上截图：
拥有的阿里背景的Dubbo，给使用者带来的丝丝安慰，毕竟阿里那么大的平台都在使用，相对小型一些的平台使用应该也是没有问题。那么在设计过程中，应该注意哪些呢？
一，模块划分。
模块划分很重要，模块划分的合理性决定了后续服务的扩容性。进行模块划分时，应尽量将业务模块进行抽离、独立。比如，我们的项目会划分为：用户模块、订单模块、资源模块、微信模块等。
二，服务抽离。
这里的服务抽离，是针对每个模块里面的服务进行抽离。比如：用户模块。在针对用户模块的服务抽离的时候，会区分是查询服务，还是修改更新服务。将查询与更新分开，因为对于更新操作，会涉及到事务处理等。
三，网络设置
针对不同的服务模块，设置的网络超时应该不用。比如，如果一个模块完全属于内部开销，则网络超时设置可以根据业务逻辑的复杂性，自身硬件环境配置等因素来选择超时时间；而如果服务模块设计到对外通讯，比如微信模块，服务内部需要跟微信进行通讯，则服务调用则还需要考虑与微信端通讯网络超时时长的限制。防止自身服务调用网络超时时长短与外部系统调用超时时长而导致的业务处理正常服务调用异常的情况。网络超时设置的标签属性为timeout：
<dubbo:reference timeout="3000"interface="com.ylp.facade.user.service.UserLoginService"id="userLoginService"/>
四，启动检测设置
Duboo的属性标签中，可以设置启动初始化时，是否检测相应服务生产者是否正常提供服务。具体使用情况可以根据项目自身情况而定，属性标签为：check。
<dubbo:reference timeout="3000"check="false" interface="com.ylp.facade.user.service.UserLoginService"id="userLoginService"/>
五，重试
服务调用时，Dubbo服务默认是会在出现调用异常的情况下，尝试重新调用。好像默认的是调用3次。这种重试对于查询类操作，当然没有太大问题（数据量大的应防止因为查询而把库拖死）。但是，对于插入修改类的服务操作，就会存在数据安全性问题。这也是为什么做服务抽离时，将查询类与修改类分开的原因。解决方式就是不让服务重试，即将retries属性设置为0.
<dubbo:reference retries="0"timeout="3000" check="false"interface="com.ylp.facade.user.service.UserLoginService"id="userLoginService" />
目前，先总结以上。后续有时间，将继续总结其他使用技巧。在文底也顺便推荐一套免费的教程。个人觉得讲解的比较不错，里面还会涉及到Dubbo管控台的安装、ZooKeeper的安装等其他的内容，非常实用。
http://www.roncoo.com/details?cid=f614343765bc4aac8597c6d8b38f06fd
本文出自 “Peter” 博客，谢绝转载！
原文地址：http://peterhu001.blog.51cto.com/3871883/1770602
