『互联网架构』软件架构-掌握dubbo常规应用（上）（40）
回顾上次的文章，讲了分布式的历史和发展的背景，通过一个场景一个公司的项目想换成分布式的项目，但是真正的要把一个系统改成成为一个分布式系统的时候，过程并非那么容易，需要整个公司一起来配合，包括业务部门和技术部门，才能把系统做好，其实单体变成分布式的不仅仅是技术发生了改变，公司的运作流程和系统的版本发布，都已经做了改变。如果一个系统要更改成分布式系统，一定要把相关的干系人都召集到一起开个会，评估下。技术人员只需要做到对业务的波动降低到最低，开发成本一定要可控，评估好，不要做成一个烂尾的项目。分布式架构是把双刃剑，必须根据公司的实际情况，确实需要这种横向扩展能力的时候，迫切的需要提升性能，其他没有除了更改分布式这种好办法了（数据库优化，代码优化做尽了）。如果垂直架构可以搞定的话，不建议搞成分布式架构，垂直业务也分开了，业务进行垂直拆分了。
（一）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文件
4.0.0
com.idig8
dubbo-study
1.0-SNAPSHOT
war
dubbo-study Maven Webapp
https://idig8.com
UTF-8
1.7
1.7
com.alibaba
dubbo
2.5.3
redis.clients
jedis
2.2.0
commons-pool
commons-pool
1.6
dubbo-study
maven-clean-plugin
3.1.0
maven-resources-plugin
3.0.2
maven-compiler-plugin
3.8.0
maven-surefire-plugin
2.22.1
maven-war-plugin
3.2.2
maven-install-plugin
2.5.2
maven-deploy-plugin
2.8.2
2.provider
可以通过小广播的形式，也可以通过redis 和zookeeper，后面会重点说协议的。先看如何编写。
<!---->
3.consumber.xml
可以通过小广播的形式，也可以通过redis 和zookeeper，后面会重点说协议的。先看如何编写。消费者的小广播multicast://224.5.6.8:1235 一定要跟生产者保持一致。
<!---->
4.Proivider.java
package com.idig8.provider;
import org.springframework.context.support.ClassPathXmlApplicationContext;
public class Provider {
public static void main(String[] args) throws Exception {
ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext(
"config/spring-dubbo-provider.xml");
context.start();
System.out.println("dubbo multicast 服务启动成功 ");
System.in.read(); // press any key to exit
}
}
5.Consumber.java
package com.idig8.consumer;
import com.idig8.service.DemoService;
import org.springframework.context.support.ClassPathXmlApplicationContext;
public class Consumer {
public static void main(String[] args) throws Exception {
ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext(
"config/spring-dubbo-consumer.xml");
context.start();
DemoService demoService = (DemoService) context.getBean("demoService"); // obtain proxy object for remote invocation
String hello = demoService.sayHello("world"); // execute remote invocation
System.out.println(hello); // show the result
while (true) {
byte[] b = new byte[1024];
int szie = System.in.read(b);
if (new String(b, 0, szie).trim().equals("send")) {
System.out.println(demoService.sayHello("hanmeimei"));
}
}
}
}
开发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有自检机制会爆连接不到注册中心，但是不影响调用。
>>原创文章，欢迎转载。转载请注明：转载自IT人故事会，谢谢！
>>原文链接地址：上一篇:
已是最新文章
About The Author
