dubbo介绍
dubbo是阿里公司推出解决分布式服务问题的框架，是一个基于SOA面向服务体系结构的基础设施，提供了诸如服务发布注册、容错调用、部署、调用次数监控、每个服务的性能监控等很多功能。
一看觉得非常不错可以将我们各种服务做成远程服务调用，虽然看起来不错，如果要具体实施将一个或多个系统抽象成一个合理、稳定的SOA系统却不是一翠儿就，它需要遵循一些经验和原则，否则会曹成费力不讨好，事倍功半的效果。
优点
动态注册与发现服务
服务越来越多时，不需要我们手工配置每一个服务的URL调用地址，也不需要手工查找一个服务，添加或删除服务对我们来说是透明的、动态的，服务配置更加方便。
实现了软负载，可以通过配置dubbo集群策略为Failover，默认也是这个策略，失败自动切换。
依赖关系
由于服务变多，服务调用服务、依赖另一个服务成为常态，dubbo可以帮我们管理服务之间的依赖。
PS:服务虽然可以相互依赖但是不建议层次过多，一般不应超过三层，即A依赖B，B依赖C，则C不应该再依赖于D，如果真需要依赖，应该重新考虑是否服务划分粒度过细、过小，服务划分不易过小或过大，应尽量避开分布式事务带来的问题。
监控服务质量
服务既然已经抽取出来，那么对每个服务的最大调用量、每次调用的响应时间、多少台机器可以支撑多大访问量等等问题，需要时刻来动态监测，来保证服务器资源的既不浪费又合理利用，依赖于dubbo监控中心完成。
架构演变
1.单一应用
在这个阶段我们只是开发单个的应用程序或许应用很大或者很小，都是开发部署在一个应用程序里面这个时候典型的是类型于Struts+spring+ORM框架，常常见于中小型企业使用非常广泛，以至于大部分的培训机构都是培训SSH框架，这一框架在这时成为了主流，受到了很多程序员的追捧。
2.多个应用
在一些电商网站随着访问数量逐渐增大，尤其是到过年过节时下单用户量会暴增，单一应用无法解决访问量暴增的需求，于是把关键瓶颈节点垂直抽取出来做成单独应用来跑，在一定程度上解决了高访问量的问题。
3.RPC分布式服务
为了适用不断变化的市场需求，以及多个垂直应用之间数据交互方便，我们把公共的业务抽取出来作为独立的模块，为其他的应用提供服务，系统逐渐依赖于抽象和rpc远程服务调用。
4.管理服务
随着服务也越来越多，如果单靠程序员手工来管理折磨多的服务变的不肯能，需要一个管理、监控、调度服务接口的中心应用，基于SOA思想管理服务的框架营运而生。
用一幅图来概括dubbo的演化过程显着非常形象，如下：
应用场景
个人感觉dubbo何时使用都可以，小的网站项目未必不可以使用dubbo框架，只是小的项目使用dubbo可能会拖延开发周期，并且对开发人员的素质要求比较高，后台服务器也需要比普通项目消耗资源多，如果公司舍得出钱就可以，况且，公司也在发展为以后的扩展业务做好准备。
服务提供者
即实现服务接口的一方，服务说的通俗一些即我们常用的接口，把需要让别人调用的接口发布出去，以供其他应用使用但我们也要为接口实现方法，服务提供者即提供服务的一方。
根据项目开发，即我们项目里面service接口以及实现层以下部分，将此实现的调用地址发布到注册中心即完成了服务提供端的开发。
服务消费者
这个更好理解就是使用服务的一端，常常为web项目的Controller层，对于服务提供方与消费方不仅仅是写好接口和实现就万事大吉，dubbo不仅仅可以将一个接口和实现发布为远程服务，还可以为该接口提供性能、安全等保障。
配置cluster集群属性，默认为Failover失败自动切换；失败重试次数 retries="2",表示发三次请求不包括第一次；timeout="10000",超时；check="false",安全检查，默认true，但一般需配置为false，很可能会导致服务启动不起来；等等，还有很多性能参数来保证服务正常运行，对于参数的优先级服务消费者要高于服务提供者，如果两者都有配置，那么以消费端配置为准，服务端配置会被覆盖。
注册中心
一个用来管理和协调服务软件系统，可以管理后台很多的服务，避免出现服务死锁、服务当机、服务不够用等情况发生，即时对服务进行注册和发现，如果一个服务地址有变更，注册中心会即时将变更地址推送给服务消费者。
总结
公司也在使用dubbo开发项目，在使用过程中逐渐加深了对dubbo框架的理解，对架构调用流程更加清晰，不过，感觉对于框架只会用还是远不够的需要研究和理解框架的设计原理，要多学习框架里面的东西，设计思路和框架里面的代码，多看优秀的然后多去思考，学着使用才会和优秀的人框架逐渐靠近。