软件架构-掌握dubbo常规应用（上）
回顾上次的文章，讲了分布式的历史和发展的背景，通过一个场景一个公司的项目想换成分布式的项目，但是真正的要把一个系统改成成为一个分布式系统的时候，过程并非那么容易，需要整个公司一起来配合，包括业务部门和技术部门，才能把系统做好，其实单体变成分布式的不仅仅是技术发生了改变，公司的运作流程和系统的版本发布，都已经做了改变。如果一个系统要更改成分布式系统，一定要把相关的干系人都召集到一起开个会，评估下。技术人员只需要做到对业务的波动降低到最低，开发成本一定要可控，评估好，不要做成一个烂尾的项目。分布式架构是把双刃剑，必须根据公司的实际情况，确实需要这种横向扩展能力的时候，迫切的需要提升性能，其他没有除了更改分布式这种好办法了（数据库优化，代码优化做尽了）。如果垂直架构可以搞定的话，不建议搞成分布式架构，垂直业务也分开了，业务进行垂直拆分了。
Dubbo （一）
•① 历史
直到2011年10月27日，阿里巴巴开源了自己的SOA服务化治理方案的核心框架Dubbo，服务治理和SOA的设计理念开始逐渐在国内软件行业中落地，并被广泛应用。Dubbo作为阿里巴巴内部的SOA服务化治理方案的核心框架，在2012年时已经每天为2000+个服务提供3,000,000,000+次访问量支持，并被广泛应用于阿里巴巴集团的各成员站点。Dubbo自2011年开源后，已被许多非阿里系公司使用，其中既有当当网、网易考拉、国美电器等互联网公司，也有中国人寿、青岛海尔等传统企业。
• ② 官网
http://dubbo.apache.org/zh-cn/
•③ 介绍
dubbo 阿里开源的一个SOA服务治理框架，从目前来看把它称作是一个RCP远程调用框架更为贴切。单从RPC框架来说，功能较完善，支持多种传输和序列化方案。所以想必大家已经知道他的核心功能了：就是远程调用。
•④ 简单的实例演示
idea新建立一个java项目，源码：源码文件夹/『互联网架构』软件架构-掌握dubbo常规应用（40），项目名称：dubbo-study
1.pom文件
2.provider
可以通过小广播的形式，也可以通过redis 和zookeeper，后面会重点说协议的。先看如何编写。
3.consumber.xml
可以通过小广播的形式，也可以通过redis 和zookeeper，后面会重点说协议的。先看如何编写。消费者的小广播multicast://224.5.6.8:1235 一定要跟生产者保持一致。
4.Proivider.java
5.Consumber.java
开发pom.xml > dubbo-provider.xml > Provider.java> spring-dubbo-consumer.xml > Consumer.java
6.运行顺序，运行Provider.java，运行Consumer.java
•⑤ dubbo架构简要讲解
1.Provider(提供者)绑定指定端口并启动服务（20880）。2.提供者连接注册中心，并发本机IP、端口、应用信息和提供服务信息发送至注册中心存储。3.Consumer(消费者），连接注册中心 ，并发送应用信息、所求服务信息至注册中心。4.注册中心根据消费者所求服务信息匹配对应的提供者列表发送至Consumer 应用缓存。配置文件里面的interface来匹配。5.Consumer 在发起远程调用时基于缓存的消费者列表择其一发起调用。缓存，是虚线，性能提升，注册中心挂了不影响。6.Provider 状态变更会实时通知注册中心、再由注册中心实时推送至Consumer。7.一定要记住，真正的调用跟注册中心没关系，而是cosumber直接调用的provider。
• ⑥ 这么设计的意义
1.Consumer 与Provider 解偶，双方都可以横向增减节点数。2.注册中心对本身可做对等集群，可动态增减节点，并且任意一台宕掉后，将自动切换到另一台。3.去中心化，双方不直接依赖注册中心，即使注册中心全部宕机短时间内也不会影响服务的调用。4.服务提供者无状态，任意一台宕掉后，不影响使用。
PS：搞明白Registry，Consumber，Porvider这3方一定要搞明白他们是如何调用的，通过架构图了解虚线和实现的关系。调用的顺序，如果注册中心挂了，不用影响Registry 和Consumber的通信，但是本身dubbo有自检机制会爆连接不到注册中心，但是不影响调用。