关于阿里Dubbo的一点总结

1. 说到Dubbo不得不说的、

传统系统架构模式
这里要说的传统应用的架构模式就是指的MVC三层架构；也就是业务层，持久层，表现层；这是在传统的web应用系统中被常用到的开发架构模式；根据一个应用系统中不同的业务来区分的三个实现层；使开发变得更高效和责任分离；尤其是对于一些访问量和规模不算很大的web应用来说，这样的架构模式已经很好用；
然而现在，这样的被称为单系统架构模式，已经在系统业务越来越庞大的情况下，展现出了很多的不足：

1.所有项目都会使用相同的一个代码库，每一个团队成员（UI\前端\程序猿）都会提交维护代码库的内容，当内容逐渐增多，效率就变得低下。
2.如果采取多模块开发模式，模块间相互依赖，极小的改动都会引起其它开发环境同步更新，如果有已上线运行的产品，那么发布也是个很大的工作量。
3.单系统的架构模式，虽然采用了三层架构来区分不同层的责任与任务，但是从实际的操作中来看，难免存在责任交叉，因此某些地方的改动可能会带来其它层的同步变动，失去了分层的独立性。
4.有很多团队分为开发团队和运营支持团队，开发团队只负责开发，在完成后交于运营团队管理，虽然运营团队能很好地处理一些日常问题，但遇到系统危机问题时，也不得不求助于开发团队。
5.当业务逐渐增长，单系统可能被拆解为多个独立的子系统，但系统间是存在一定业务关联的，这时解决基础服务公用的问题就势在必行，需要开发者将通用服务独立发布以便于其它系统调用。

微服务
将产品或项目分解为众多独立的服务，这些服务独立地部署，并且不依赖于其它服务。
这是基于传统架构模式的不足而提出的概念；更粗暴一点的理解就是将一个web系统中的每一个单一的模块（商品库存，订单，支付，物流等。。）都单独作为一个项目来开发部署；每个模块的相关负责人就只需要关心自己的代码，数据库；甚至每个模块的开发语言都是不同的；这样一来，开发人员就不会为点开一个项目找自己的代码都要找半小时而烦恼（说笑了）；对应模块的开发人员可以完全集中到自己的一个服务中，代码量也会减少，代码也能更好的把握；
微服务确实有很高效的开发作用；一个整体的项目它的不同模块虽然已经单独出来成了一个服务集中开发，但是服务与服务之间必然是有要进行相互调用的时候；这时高效的管理服务之间的调用，就需要使用到分布式服务管理框架(RPC);
这里贴一张网上找来的系统架构图；可以看看系统架构的演变；其中就有分布式服务管理架构；

2. Dubbo分布式服务管理框架

Dubbo简介
Dubbo是阿里巴巴开发的一款分布式服务管理框架；致力于提供高性能和透明化的RPC远程服务调用方案；和spring无缝集成；开源；国内大量的的大型平台基于Dubbo完成服务的分布式访问；也有不少的公司对它做了更多的功能扩展，最出名的应该的当当网做的Dubbox；现在已经称为Apache基金会孵化项目；
Dubbo采用的是一种非常简单的模型，要么是提供方提供服务，要么是消费方消费服务，所以基于这一点可以抽象出服务提供方（Provider）和服务消费方（Consumer）两个角色
Dubbo主要解决的问题：

1. 当服务越来越多时，服务URL配置管理变得非常困难，F5硬件负载均衡器的单点压力也越来越大。
   此时需要一个服务注册中心，动态的注册和发现服务，使服务的位置透明。
   并通过在消费方获取服务提供方地址列表，实现软负载均衡和Failover，降低对F5硬件负载均衡器的依赖，也能减少部分成本。
2. 当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。 这时，需要自动画出应用间的依赖关系图，以帮助架构师理清理关系。
3. 接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？
   为了解决这些问题，第一步，要将服务现在每天的调用量，响应时间，都统计出来，作为容量规划的参考指标。
   其次，要可以动态调整权重，在线上，将某台机器的权重一直加大，并在加大的过程中记录响应时间的变化，直到响应时间到达阀值，记录此时的访问量，再以此访问量乘以机器数反推总容量。

Dubbo核心要点
1.服务的定义：服务的定义的围绕服务的提供方和服务的消费方的；简单理解就是服务提供方提供一个接口到一个服务注册中心；服务的消费方到注册中心去订阅需要的服务，也就拿到这个接口，便可以远程调用该接口中实现的方法；
2.服务注册：第一点提到服务提供方在提供服务的时候其实的提供一个接口到服务中心，这其实就是服务注册；但是由于应用系统最后不断的扩大，服务数量和类型不断的变化，以及服务消费方对服务的调用越来越多；就需要有大量的服务需要管理；而且，作为服务提供方和服务消费方，它们本身也是兼具这两种角色的，既提供服务，也消费服务；
因此将大量的服务统一起来管理，可以更好的优化系统内部对服务的发布和调用；而dubbo提供的服务注册中心，就可以有效的管理服务的发布/调用；并且提供了集中服务注册中心的类型：
Multicast(多播/组播)注册中心（开发测试用）、Zookeeper注册中心（生产环境用官方推荐）、Redis注册中心、Simple注册中心
3.服务监控：不管是服务提供方，还是服务消费方，都应该对服务调用的状态做实时的监控；因为每个服务是在独立开发的，有自己独立的系统日志，如果没有监控，那么等你调用某个服务的时候，那个服务是否还能正常运行都不得而知；所以实时的监控可以有效的即使维护服务；
4.远程通信与信息交换
远程通信需要指定通信双方所约定的协议，在保证通信双方理解协议语义的基础上，还要保证高效、稳定的消息传输。Dubbo继承了当前主流的网络通信框架，主要包括如下几个：Mina、Netty、Grizzly

服务调用关系说明

0. 服务容器负责启动，加载，运行服务提供者。
1. 服务提供者在启动时，向注册中心注册自己提供的服务。
2. 服务消费者在启动时，向注册中心订阅自己所需的服务。
3. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
4. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
5. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

3. Dubbo简单操作

1.获取dubbo
Maven中央仓库：
http://central.maven.org/maven2/com/alibaba/dubbo

<dependency>
	<groupId>com.alibaba</groupId>
	<artifactId>dubbo</artifactId>
	<version>2.6.2</version>
</dependency>

2.简单测试
可以根据官网的快速开始简单测试一下Dubbo做理解；
a.根据Dubbo的核心，先定义服务提供方；服务提供方提供接口和接口实现；并将接口注册到服务注册中心；这里做测试可以使用Multicast(多播/组播)注册中心;但是我使用Zookeeper注册中心；这相当于一个广播中心，在同一个网络环境下，如果广播中心相同，那么注册的服务也会在一个服务中心里；
因为现在要做的是分布式服务管理，一个模块独立成一个项目；但是每个模块应该是在一个大项目下的；称为要给父项目；

将order订单模块作为服务提供方；user用户模块作为服务消费方；

服务提供方提供服务接口：因为这个接口是要注册到服务中心，也就是说要暴露出来给服务消费方使用；因此接口应该是要提供到一个公共的服务中；所以定义dubbo-api；其中定义服务接口；而实现在服务提供方中；

public interface DemoService {
        String sayHello(String name);
}

服务提供方中实现方法：

package cn.itsource.impl;

import cn.itsource.DemoService;

public class DemoServiceImpl implements DemoService {
    public String sayHello(String name) {
        return "Hello " + name;
    }
}

重点
用 Spring 配置声明暴露服务：根据官网的代码修改provider.xml配置文件；这是定义在服务提供方中的；

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:dubbo="http://dubbo.apache.org/schema/dubbo"
       xsi:schemaLocation="http://www.springframework.org/schema/beans        http://www.springframework.org/schema/beans/spring-beans-4.3.xsd        http://dubbo.apache.org/schema/dubbo        http://dubbo.apache.org/schema/dubbo/dubbo.xsd">

    <!-- 提供方应用信息，用于计算依赖关系 -->
    <dubbo:application name="dubbo-order"  />

    <!-- 使用multicast广播注册中心暴露服务地址 -->
    <!--<dubbo:registry address="multicast://224.5.6.7:1678" />-->
    <dubbo:registry address="zookeeper://localhost:2181" client="zkclient" />

    <!-- 用dubbo协议在20880端口暴露服务 -->
    <dubbo:protocol name="dubbo" port="20880" />

    <!-- 声明需要暴露的服务接口 -->
    <dubbo:service interface="cn.itsource.DemoService" ref="demoService" />

    <!-- 和本地bean一样实现服务 -->  
    <bean id="demoService" class="cn.itsource.impl.DemoServiceImpl" />
</beans>

服务提供方加载配置文件：发布服务到注册中心；

import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration("classpath:provider.xml")
public class Provider {
    @Test
    public void testRun() throws Exception{
        System.in.read();
    }
}

测试服务发布
在provider.xml中我是使用 <dubbo:registry address=“zookeeper://localhost:2181” client=“zkclient” />；做为服务中心，因此注册的时候是将服务发布到zookeeper中；这里要使用dubbo的监控和管理中心Dubbo Admin来查询发布的任务；
启动步骤：
先启动zookeeper：zkServer.cmd
在启动Dubbo Admin：运行dubbo-admin-0.0.1-SNAPSHOT.jar 包；这里要注意修改该jar包中的dubbo-admin.xml 文件；

<beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:dubbo="http://dubbo.apache.org/schema/dubbo"
       xmlns="http://www.springframework.org/schema/beans"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-4.3.xsd
       http://dubbo.apache.org/schema/dubbo http://dubbo.apache.org/schema/dubbo/dubbo.xsd">

    <dubbo:application name="dubbo-admin"/>
    <!--使用zookeeper时开启使用-->
    <dubbo:registry address="zookeeper://127.0.0.1:2181"/>
    <!--使用multicast://224.5.6.7:1678 广播中心的时候开启使用-->
	<!--<dubbo:registry address="multicast://224.5.6.7:1678"/> -->
	
    <dubbo:reference id="registryService" interface="com.alibaba.dubbo.registry.RegistryService" check="false"/>

</beans>

以上两个程序运行后；使用http://localhost:7001 访问Dubbo Admin;
默认登陆密码：root root;

下一步：启动测试类发布服务；如果服务发布成功，那么在Dubbo Admin中就可以看到以下画面：

服务消费方
同样的根据官网教程实现服务消费方；其实目的很简单，现在服务提供方中有一个实现类实现了一个接口；而这个接口已经通过服务管理注册到服务关心中心；消费方现在就是到服务管理中心订阅这个接口，实现在不同的服务间的调用；
1.通过 Spring 配置引用远程服务consumer.xml;注意的是消费方中注册中心的配置和接口的路径配置要一致；

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:dubbo="http://dubbo.apache.org/schema/dubbo"
    xsi:schemaLocation="http://www.springframework.org/schema/beans        http://www.springframework.org/schema/beans/spring-beans-4.3.xsd        http://dubbo.apache.org/schema/dubbo        http://dubbo.apache.org/schema/dubbo/dubbo.xsd">

    <!-- 消费方应用名，用于计算依赖关系，不是匹配条件，不要与提供方一样 -->
    <dubbo:application name="dubbo-user"  />

    <!-- 使用multicast广播注册中心暴露发现服务地址 -->
    <!--<dubbo:registry address="multicast://224.5.6.7:1678" />-->
    <dubbo:registry address="zookeeper://localhost:2181" client="zkclient" />

    <!-- 生成远程服务代理，可以和本地bean一样使用demoService -->
    <dubbo:reference id="demoService" interface="cn.itsource.DemoService" />
</beans>

2.加载Spring配置，并调用远程服务
这里使用的是main方法在调用远程服务；也可以使用测试，注解注入服务接口的方式测试；

package cn.itsource;

import org.springframework.context.support.ClassPathXmlApplicationContext;

public class Consumer {
    public static void main(String[] args) throws Exception {
        ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext(new String[] {"consumer.xml"});
        context.start();
        DemoService demoService = (DemoService)context.getBean("demoService"); // 获取远程服务代理
        String hello = demoService.sayHello("world"); // 执行远程方法
        System.out.println( hello ); // 显示调用结果
    }
}

要点：
这里有个坑，就是服务提供方暴露的接口要打包，并在服务提供方和消费方共享；
而这里就是接口需要通过pom.xml在服务提供方和消费方中引用；
公共接口所在项目的pom：

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <parent>
        <artifactId>dubbo-parent</artifactId>
        <groupId>dubbo-parent</groupId>
        <version>1.0-SNAPSHOT</version>
    </parent>
    <modelVersion>4.0.0</modelVersion>
    <artifactId>dubbo-api</artifactId>
</project>

服务提供方和消费方的pom中添加以下代码；就是根据公共接口的pom来的：

<dependency>
     <groupId>dubbo-parent</groupId>
     <artifactId>dubbo-api</artifactId>
     <version>1.0-SNAPSHOT</version>
</dependency>

注解方式注入
1.首先需要在服务提供方可消费方的配置文件中开启注解；
同时也要将原有的接口和实现类的注入注释掉；

<dubbo:annotation package="cn.itsource" />

2.服务提供方的实现类上添加注解@Service；注意导入的包：import com.alibaba.dubbo.config.annotation.Service;
3.服务消费方中注入接口service；注意使用@Reference 注入，导包：import com.alibaba.dubbo.config.annotation.Reference
原因：因为dubbo的注解继承了spring的注解，但是又实现了更多自己的功能，所以这里使用@Autowired 不能完整注入；

import com.alibaba.dubbo.config.annotation.Reference;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration("classpath:consumer.xml")
public class Consumer {
    /**
     * 注解方式
     */
    @Reference
    private DemoService demoService;

    @Test
    public void testConsumer() throws Exception{
        String hello = demoService.sayHello("你好！"); // 执行远程方法
        System.out.println( hello );
    }
}

这样一来，就可以实现不同的项目独立开发；要相互之间做调用，只需要暴露一个接口到服务中心；这样还可以有效的提高代码的安全性；接口的暴露就可以让调用者实现想要的功能而又不用让调用者知道实现的方式；

总结：
Dubbo的使用还有很多要注意的地方；这里只是根据官网做简单的测试；涉及到均衡策略等一系列问题就有空再补充了；并且在项目中，使用分布式服务管理还有很多要注意的地方，前路漫漫，任重道远！

                                                                                 2018.11.07