04-分布式服务

一、分布式服务体系

（一）分布式系统概述

​　　　　单体系统存在业务扩展性（任何业务的调整都需要发布整个系统）、性能扩展性（动态扩容对单体系统而言效率低下）、代码复杂度（修改一处代码容易引发连锁反应）的问题。

​　　　　系统扩展性，指的是当系统的业务需求发生变化时，我们对现在系统改动程度的一种控制能力。改动程度越大，扩展性就越差。对于单体系统而言，任何改动都需要整个系统进行重新构建和发布，所以扩展性较低，本质原因是无法对代码进行物理上的拆分，所以代码组件之间的边界往往很难清晰划分。

​　　　　伸缩性，指的是对系统性能的一种控制能力。如果通过简单扩容就能确保系统的性能得到等比例的提升，那么我们就认为该系统具备较好的伸缩性。对于单体系统而言，由于内存密集型和CPU密集型的代码都位于同一个服务器上，所以很难做到对资源的充分利用。

​　　　　分布式系统区别于单体系统的是，会将整个系统拆分成多个能够独立运行的服务，这些服务在物理上是隔离的，相互之间基于网络进行通信和协调。

​　　　　单体系统的拆分策略：

​　　　　　　纵向拆分：基于不同的业务拆分，例如互联网医院系统，可以拆分为医生子系统、就诊子系统、患者子系统、处方服务

​　　　　　　横向拆分：复用和组合业务能力，仍以互联网医院系统为例，拆分为医生子系统、就诊子系统、患者子系统、处方服务，前台使用分布式服务框架进行聚合。

​　　　　分布式系统固有特性，也是分布式存在的问题：

​　　　　　　网络传输的三态性：“成功”或“失败”、“超时”，区别与单体系统调用只有成功或失败，由于有了网络调用，因此存在超时的问题

​　　　　　　请求的容错性：调用链路上的异常扩散，雪崩效应

​　　　　　　系统的异构性：多种不同的技术体系

​　　　　　　数据的一致性：传统的事务机制无法生效

（二）构建分布式服务体系

​　　　　分布式系统核心技术点：

​　　　　　　　　可用：降级和限流机制、集群和负载均衡等

​　　　　　　　　性能：异步化、资源重用等

​　　　　　　　　扩展：SPI机制、异步消息等

​　　　　　　　　治理：服务注册和发现机制等

​　　　　分布式服务体系的组成包括功能性组件和非功能性组件，功能性组件是指必须要有的，如果没有就不能正常运行，包括网络通信、序列化、传输协议、服务调用；非功能性组件包括服务治理、服务路由、服务容错、服务监控。

​　　　　分布式服务框架有：Facebook Thrift、Twitter Finagle、Google gRPC、Alibaba Dubbo、Taobao HSF、Xinlang Motan

​　　　　分布式服务拆封后一般有三种类型：

​　　　　　　　　工具服务(Utility Service)：应用程序与技术基础设施之间的交叉点；遵循独立开发和管理生命周期；也是可重用服务，区别业务模型 ，例如分布式ID服务、加密算法服务等等

​　　　　　　　　实体服务(Entity Service)：无关功能上下文 ，主例如订单服务，只处理订单的增删改查；建立一种一致的方法访问和处理业务数据；可重用，一般被更高级的任务服务使用。

​　　　　　　　　任务服务(Task Service)：非无关功能上下文，服务组合，例如下单服务，最终要调用订单、支付等服务；关注实现复杂业务流程，很大程度上由组合逻辑组成；通常需要维护状态，决定事务边界。

（三）客服系统案例演进

​　　　　服务拆分策略 - 第一阶段：将项目拆分为客户服务、集成服务和其他模块，集成服务专门用来集成外包客服服务，最终的拆分结果为：

​　　　　　　distribution-cs-dependency：仍然是一个用来做同一版本依赖管理的项目

​　　　　　　distribution-customer-system：只保留定时任务和监控

​　　　　　　distribution-cs-infrastructure-utility：同一工具服务

​　　　　　　distribution-outsouring-system：外包客服系统

​　　　　以上都是和单体系统一样的，下面几个事新拆出来的

​　　　　　　distribution-customer-service：承载原distribution-customer-system项目中所有的MVC操作，通知调用distribution-intergation-service获取外部数据

​　　　　　　distribution-intergation-service：承载原distribution-customer-system项目中bus操作，即服务集成的通用流程操作

二、RPC架构

（一）RPC架构基础结构和示例

​　　　　RPC：Remote Process Call，远程过程调用，一切分布式系统的基础，包含分布式系统基本功能组件：网络通信、序列化/反序列化、传输协议和服务调用。

​　　　　对于RPC来讲，主要就是通过一种协议做远程调用，下图展示的就是一个极简版的RPC，服务端使用RpcAcceptor接收服务调用，客户端使用RpcConnector做服务连接，然后客户端和服务端使用相同的协议（RpcProtocol）进行交互。

​　　　　　　　　

​　　　　但是这样的结构还不够详细，具体RpcConnector和RpcAcceptor是怎么处理的，下图是一个演进的结果，首先在RPC框架的两端，都是通过API进行调用的，在客户端，使用RpcClient使用Caller调用API，然后API使用RpcCaller调用RpcConnector，在服务端，RpcAcceptor通过RpcInvoker调用API，然后API通过Callee调用RpcServer，即调用实现。同时客户端和服务端有一个相同的协议来保证通信。

​　　　　对于API、Caller、Callee来说，是使用接口的方式抽离出去的，其他的则是在客户端或服务端需要实现的。

​　　　　　　　　

​　　　　演进二虽然已经实现了RPC框架的基本功能，但是对于客户端来说，不想知道远程调用的IP等内容，那么可以加入RpcProxy来进行代理，并通过代理调用RpcCaller；服务端为了使用多线程等技术来提高性能，增加RpcProcessor，并用其调用RpcInvoker。

​　　　　　　　　

​　　　　以上演进的最终结果就是RPC规范，目前所有的RPC框架都是基于以上规范做的实现和落地。那么RPC规范包含了10个组件，每个组件的作用稍微做个介绍。

​　　　　　　RPC – 客户端组件与职责：

​　　　　　　　　RpcClient：负责导入(import)远程接口的代理实现

​　　　　　　　　RpcProxy：调用远程接口的代理实现

​　　　　　　　　RpcCaller：负责编码和发送调用请求到服务端并等待结果

​　　　　　　　　RpcConnector：负责维持连接通道和发送数据到服务端

​　　　　　　RPC – 服务端组件与职责：

​　　　　　　　　RpcServer：负责导出(export)远程接口

​　　　　　　　　RpcInvoker：负责调用服务端接口的具体实现并返回结果

​　　　　　　　　RpcAcceptor：负责接收客户端请求并返回请求结果

​　　　　　　　　RpcProcessor：负责在服务端控制调用过程，包括管理调用线程池等

​　　　　　　RPC – 通用组件与职责：

​　　　　　　　　RpcProtocol：负责协议的编/解码

​　　　　　　　　RpcChannel：充当数据传输的通道

​　　　　针对上述组件，可以实现一个自定义的RPC架构：

​　　　　　　Remote API：对于远程调用来说，使用UserService作为Remote API，提供一个简单的查询接口。

public interface UserService {
    String getUserNameByCode(String code);
}

​　　　　　　RpcProtocol：协议通俗的将就是通信双方约定好的规则，这里简单的定义了一个协议，传输时需要传递接口全限定名、方法名、参数类型和参数值

@Data
public class Protocol implements Serializable {

    //接口名称（包括完整类路径）
    private String interfaceName;
    //调用方法名
    private  String methodName;
    //参数类型按照接口参数顺序定义
    private Class[] paramsTypes;
    //参数的数据值
    private Object[] parameters;

    public Protocol() {
        super();
    }

    public Protocol(String interfaceName, String methodName, Class[] paramsTypes, Object[] parameters) {
        super();
        this.interfaceName = interfaceName;
        this.methodName = methodName;
        this.paramsTypes = paramsTypes;
        this.parameters = parameters;
    }
}

​　　　　　　RpcChannel：RpcChannel是Rpc通信的通道，这里使用 TCP Socket 来发送和接收信息。

​　　　　　　服务端：

​　　　　　　　　RpcAcceptor表示接收接受Socket请求，下面代码的service方法创建了一个ServerSocket，并使用其来接收请求，这里的ServerSocket就是上面的RpcChannel

​　　　　　　　　RpcProcessor表示线程/服务池调度，在RpcAcceptor接收到请求后，其并不会自己处理请求，而是会将请求交由RpcProcessor来处理，RpcProcessor可以管理调用线程等，在下面案例中，其将请求放到线程池中进行处理

​　　　　　　　　RpcInvoker表示反射响应请求，根据反射来获取具体实现，具体的实现在UserserviceImpl类中，其实现了Userservice接口。

@Data
public class RpcServer {
    // 自定义线程池相关内容
    private int threadSize = 10;
    private ExecutorService threadPool;
    //自定义缓存
    private Map<String, Object> servicePool;
    // 自定义端口
    private int port = 9000;

    public RpcServer(){
        super();
        synchronized (this){
            threadPool = Executors.newFixedThreadPool(threadSize);
        }
    }

    public RpcServer(Map<String, Object> servicePool, int threadSize, int port) {
        super();
        this.port = port;
        this.servicePool = servicePool;
        synchronized (this){
            threadPool = Executors.newFixedThreadPool(threadSize);
        }
    }

    public void service() throws IOException {
        ServerSocket serverSocket = new ServerSocket(port);
        // 执行请求
        while (true){
            Socket receiveSocket = serverSocket.accept();
            final Socket socket = receiveSocket;
            threadPool.execute(new Runnable() {
                @Override
                public void run() {
                    try {
                        // 处理请求
                        process(socket);
                        socket.close();
                    } catch (IOException | ClassNotFoundException | InvocationTargetException | NoSuchMethodException | IllegalAccessException | InstantiationException e) {
                        e.printStackTrace();
                    }
                }


            });
        }
    }

    // 处理请求
    private void process(Socket socket) throws IOException, ClassNotFoundException, InvocationTargetException, NoSuchMethodException, IllegalAccessException, InstantiationException {
        ObjectInputStream objectInputStream = new ObjectInputStream(socket.getInputStream());
        Protocol protocolMessage = (Protocol) objectInputStream.readObject();
        Object result = call(protocolMessage);
        ObjectOutputStream objectOutputStream = new ObjectOutputStream(socket.getOutputStream());
        objectOutputStream.writeObject(result);
        objectOutputStream.close();
    }


    //3.执行方法调用：RpcInvoker
    private Object call(Protocol protocol) throws ClassNotFoundException, NoSuchMethodException,
            IllegalAccessException, InstantiationException, InvocationTargetException {

        if(servicePool == null) {
            synchronized (this) {
                servicePool = new HashMap<String, Object>();
            }
        }

        //通过接口名称构建实现类
        String interfaceName = protocol.getInterfaceName();
        Class<?> serviceClass = Class.forName(interfaceName);

        Object service = servicePool.get(interfaceName);
        //判断servicePool对象是否存在，如果不存在，就创建新对象并放入池中
        if(service == null) {
            synchronized (this) {
                service = serviceClass.newInstance();
                servicePool.put(interfaceName, service);
            }
        }

        //通过实现类来构建方法
        Method method = serviceClass.getMethod(protocol.getMethodName(), protocol.getParamsTypes());

        //通过反射来实现方法的执行
        Object result = method.invoke(service, protocol.getParameters());
        return result;
    }
  
public class UserserviceImpl implements UserService {

    private Map<String, String> userMap = new HashMap();

    public UserserviceImpl(){
        userMap.put("1", "lcl1");
        userMap.put("2", "lcl2");
        userMap.put("3", "lcl3");
        userMap.put("4", "lcl4");
    }

    @Override
    public String getUserNameByCode(String code) {
        return userMap.get(code);
    }
}

​　　　　　　客户端：

​　　　　　　　　RpcProxy表示代理，未实现

​　　　　　　　　RpcCaller：组装请求并发送

​　　　　　　　　RpcConnector：发送Socket请求

public class RpcClient {

    private String serverAddress;
    private int serverPort;

    public RpcClient(String serverAddress, int serverPort) {
        this.serverAddress = serverAddress;
        this.serverPort = serverPort;
    }

    //RpcConnector + RpcInvoker
    @SuppressWarnings("resource")
    public Object sendAndReceive(Protocol protocol) {
        Object result = null;

        try {
            Socket socket = new Socket(serverAddress, serverPort);
            ObjectOutputStream objectOutputStream = new ObjectOutputStream(socket.getOutputStream());
            objectOutputStream.writeObject(protocol);

            ObjectInputStream objectInputStream = new ObjectInputStream(socket.getInputStream());
            result = objectInputStream.readObject();
        } catch (UnknownHostException e) {
            e.printStackTrace();
        } catch (IOException e) {
            e.printStackTrace();
        } catch (ClassNotFoundException e) {
            e.printStackTrace();
        }

        return result;
    }
}

（二）RPC架构核心组件 - 网络通信

​　　　　网络通信可以分为网络连接和IO模型。

​　　　　网络连接分为长连接和短连接，长链接是TCP连接建立后，可以连续发送多个数据包，优点是节省资源/时延较小；短连接是TCP连接建立后，数据包传输完成即关闭连接，优点是结构简单。RPC框架为了追求性能，常用长连接进行通信

​　　　　IO模型可以分为BIO、NIO、AIO，其中BIO是同步阻塞的IO模型，NIO是同步非阻塞的IO模型，NIO模型依赖与操作系统的I/O多路复用技术，如select、poll、epoll模型等，多路复用是使用reactor模式来实现的。AIO是异步非阻塞的IO模型。

（三）RPC架构核心组件 - 序列化

​　　　　序列化概念和方式：

​　　　　　　序列化：将对象转化为字节数组，用于网络传输、数据持久化或其他用途

​　　　　　　反序列化：把从网络、磁盘等读取的字节数组还原成原始对象，以便后续业务逻辑操作

​　　　　　　序列化和反序列化可以使用文本类序列化和二进制序列化两大类：

​　　　　　　　　文本类是可读的，例如XML和 JSON

​　　　　　　　　二进制类是不可读的，例如 Protocol Buffer 和 Thrift

​　　　　序列化怎么选择：

​　　　　（1） 跨语言支持：

​　　　　　　　　异构系统就可能需要跨语言，常见的跨语言支持序列化工具：Hession、Protocol Buffer、Thrift、Avro

​　　　　　　　　要做跨语言，就要牺牲某些语言的特性（其他语言没有的特性），例如是否支持泛型、是否支持Map/List等

​　　　　　　　　另外就是接口开发友好性，例如是否需要中间语言，由于是跨语言，因此要先生成中间语言，然后再生成序列化文件，例如Protocol Buffer需要.proto文件、Thrift需要.thrift中间语言，这种是对开发不友好的。

​　　　　（2）性能：

​　　　　　　　　性能主要从性能和空间两个维度来看，性能好就代表序列化和反序列化的时间，空间是指压缩的比例，压缩性能越好，压缩后占用的空间就越小，那么对于网络传输来说就更快。

​　　　　　　　　Java领域序列化工具对比：https://github.com/eishay/jvm-serializers

​　　　　　　　　

（四）RPC架构核心组件 - 传输协议

​　　　　通常在RPC框架中，为了性能和框架的扩展性，会自定义一些更合理的协议；主流的HTTP协议虽然很通用，通用的协议为了满足各个场景，会把各种东西都要兼容，复杂度就会很高，性能也不会很好，扩展性也不会很好。

​　　　　自定义协议主要考虑的是性能和扩展性，切入点有以下几个：

​　　　　　　　　1、自定义协议的通信模型和消息定义，也就是传输的消息本身是可以定制的

​　　　　　　　　2、支持点对点长连接通信

​　　　　　　　　3、使用NIO模型进行异步通信

​　　　　　　　　4、提供可扩展的编解码框架，支持多种序列化方式，例如可以同时支持Json、Protocol Buffer等

​　　　　自定义协议 - 协议消息定义：

​　　　　　　　　协议消息的定义实际上就是传输的消息体的定义，一般都是在原有七层网络模型上通过Header+Body的方式来定义消息内容，可以在每一层上加上自定义的消息头，消息头可以表示是否异步、序列化方式等等内容。

​　　　　　　　　

​　　　　　　　　以Dubbo协议来说，网络层用的还是 IP，传输层用的还是 TCP，但是在会话层，使用了自定义的Dubbo协议，其定义了高位魔数、低位魔数、序列化id、同异步标志、状态、请求id、消息长度等。

​　　　　　　　　

​　　　　RPC框架一般不会采用成熟的协议，因为要对性能和扩展上进行控制，同时也不会完全自己重写，因为重写的成本太高，一般会在原有的协议上进行修改。

（五）RPC架构核心组件 - 远程调用

​　　　　服务调用基本方式可以分为同步调用和异步调用

​　　　　服务调用扩展方式：

​　　　　　　并行调用：多个任务不存在互相依赖管理，逻辑上可以并行执行。典型场景：工作流引擎。

​　　　　　　泛化调用：提供泛化接口，对参数进行弱化，参数类型一般用Map，可以传输任何参数，不需要遵循 RPC 接口参数的定义，由于没有服务契约，所以要慎用。典型场景：测试集成。

三、使用Dubbo发布分布式服务

（一）引入Dubbo框架

​　　　　Dubbo框架：高性能和透明化RPC实现方案，同时还是SOA服务治理方案

​　　　　　　　　

​　　　　Dubbo框架RPC架构演进过程：

​　　　　　　　　PRC 的基础就是一对一远程访问组件，在Dubbo中对应的是Protocol层，用来做远程调用

​　　　　　　　　在客户端调用时像访问本地接口一样来访问远程接口，也就是远程访问本地化组件，在Dubbo中使用了Proxy做了代理封装

​　　　　　　　　客户端要选择服务端的一个地址进行访问，也就是集群访问和负载均衡，Dubbo使用Cluster来支持负载均衡和集群容错

​　　　　　　　　对于自定义协议，不是RPC所必须的，但是Dubbo基于性能和扩展的考虑，使用Remoting实现了Dubbo协议

​　　　　　　　　对于服务治理和监控，Dubbo使用Registry和Monitor完成了服务治理和服务监控。

​　　　　　　　　

​　　　　Dubbo中的RPC元素：

​　　　　　　　　Dubbo没有限制只能使用某一种元素，都是可以替换的，例如协议可以使用Dubbo、RMI、Hessian等。

​　　　　　　　　

​　　　　Dubbo开发方式：

​　　　　　　XML配置方式：服务框架对业务代码零侵入，扩展和修改方便，配置信息修改实时生效

<dubbo:service/>：用于发布服务
<dubbo:reference/>：用于引用服务
<dubbo:protocol/> ：用于指定传输协议
<dubbo:application/> ：用于指定应用程序
<dubbo:registry/>：用于指定注册中心

​　　　　　　注解方式：服务框架对业务代码零侵入，扩展和修改方便，修改配置需要重新编译代码

@EnableDubbo：启用Dubbo
@DubboService：服务发布
@DubboReference：服务引用

​　　　　　　API方式：对业务代码侵入性强，容易与某种具体服务框架绑定，修改之后需要重新编译代码

DubboBootstrap：启动Dubbo
ServiceConfig：服务发布配置
ReferenceConfig：服务引用配置

（二）Dubbo框架服务发布机制

​　　　　1、Dubbo服务发布流程：

​　　　　　　　　在Dubbo的服务发布流程中，有五个对象，分别是发布启动器、动态代理、发布管理器、协议管理器、注册中心。

​　　　　　　　　首先服务发布器根据服务信息和配置信息，低啊用动态代理将本地实现类封装成代理对象

​　　　　　　　　动态代理调用发布管理器创建服务发布类

​　　　　　　　　服务管理器调用协议服务器将服务发布成指定的协议，而协议服务器则创建指定的协议服务器，并启动监听

​　　　　　　　　发布管理器获取到发布的服务后，将发布的服务注册到注册中心，然后整个流程结束。
​　　　　　　　　
​　　　　　　　　
​　　　　2、Dubbo服务发布核心技术

​　　　　（1）上下文信息：

​　　　　　　　　请求地址、上下文、请求参数都存放当前调用过程中所需的环境信息，RpcContext的ThreadLocal 的临时状态记录器，根据请求控制状态变化

​　　　　　　　　下面代码是Dubbo的源码中提取的相关的环境信息，包括请求URL、请求方法名、请求参数类型、请求参数值、本地地址、远程地址

private URL url; //请求URL
private String methodName; //请求方法名
private Class<?>[] parameterTypes; //请求参数类型
private Object[] arguments; //请求参数值
private InetSocketAddress localAddress; //本地地址
private InetSocketAddress remoteAddress; //远程地址

​　　　　　　　　下面代码使用RpcContext.getContext()来获取相关的上下文信息并打印到日志。

public class UserServiceImpl implements UserService {
    private static final Logger logger = LoggerFactory.getLogger(UserServiceImpl.class);

    @Override
    public User getUserByUserName(String userName) {
        logger.info("getUserByUserName: " + userName + ", request from consumer: " +
                RpcContext.getContext().getRemoteAddress());
        return new User(...);
    }
}

​　　　　（2）多版本：

​　　　　　　　　一个接口可以有多个版本的实现。

​　　　　　　　　多版本可以作为服务接口多版本升级策略：当一个接口实现出现不兼容升级时，可以用版本号过渡，版本号不同的服务相互间不引用，在低压力时间段，先升级一半提供为新版本，再将所有消费者升级为新版本，然后将剩下的一半提供者升级为新版本。

​　　　　　　　　多版本代码实现：

public class UserServiceImpl1 implements UserService {
    @Override
    public User getUserByUserName(String userName) {
        return new User(...);
    }
}

public class UserServiceImpl2 implements UserService {
    @Override
    public User getUserByUserName(String userName) {
        return new User(...);
    }
}

​　　　　　　　　多版本配置

<!--发布版本1.0.0服务-->
<bean id="userService" class="com.dubbo.demo.provider.UserServiceImpl1"/>
<dubbo:service interface="com.dubbo.demo.UserService" ref="userService" version="1.0.0"/>
<!--发布版本2.0.0服务-->
<bean id="userService" class="com.dubbo.demo.provider.UserServiceImpl2"/>
<dubbo:service interface="com.dubbo.demo.UserService" ref="userService" version="2.0.0"/>
<!--分别引用版本1.0.0和版本2.0.0服务-->
<dubbo:reference id="userService" interface="com.dubbo.demo.UserService" version="1.0.0"/>
<dubbo:reference id="userService"interface="com.dubbo.demo.UserService" version="2.0.0"/>

​　　　　（3）隐式参数：

​　　　　　　　　请求过程想要传递一些其他参数而又无法改变原有的方法定义，例如调用的是三方库，怎么办？

​　　　　　　　　可以在服务消费方和提供方之间隐式传递参数，隐式参数（Implicit Parameter）。可以通过附件（Attachment）进行设置，对应RpcContext上的setAttachment 和getAttachment方法。

​　　　　　　　　setAttachment 示例：

public static void main(String[] args) throws Exception {
    ClassPathXmlApplicationContext context = new
            ClassPathXmlApplicationContext("spring/dubbo-consumer.xml");
    context.start();
    UserService userService = context.getBean("userService", UserService.class);
    RpcContext.getContext().setAttachment("parameter", "lcl");
    System.out.println("result: " + userService.getUserByUserName("*").toString());
}

​　　　　　　　　getAttachment 示例：

public class UserServiceImpl implements UserService {
    @Override
    public User getUserByUserName(String userName) {
        String value = RpcContext.getContext().getAttachment("parameter");
        return new User(...,value ,...);
    }
}

（三）客服系统案例演进

​　　　　Dubbo服务定义主要包括领域对象和服务定义两个部分。

​　　　　领域对象是包括对现实中具体业务数据的抽象 ，而服务定义是包括针对领域对象所需要暴露的操作，那么上面提到的distribution-customer-service服务承载原distribution-customer-system项目中所有的MVC操作，同时需要有一个distribution-customer-service-definition服务来作为领域对象，对外提供服务，distribution-intergation-service同样如此。

​　　　　这里演示distribution-intergation-service项目，主要用来做远程调用的整合，即之前的endpoint的处理。

​　　　　1、领域对象：distribution-customer-service-definition

​　　　　（1）首先定义实体　　　　

​　　　　　　原有定义的入参是OutsourcingSystem，出参是CustomerStaff，是一个实体对象，而对于远程调用来说，定义一个统一的对象用于传输的非常必要的，因此这里使用OutsourcingSystemDTO代替原有的OutsourcingSystem，使用PlatformCustomerStaff代替原有的CustomerStaff。

​　　　　　　对于远程传输的对象，必须实现序列化接口。

@Data
@EqualsAndHashCode(callSuper = false)
public class OutsourcingSystemDTO implements Serializable {
    /**
     * 系统名称
     */
    private String systemName;

    /**
     * 系统编码
     */
    private String systemCode;

    /**
     * 系统描述
     */
    private String description;

    /**
     * 系统访问URL
     */
    private String systemUrl;
}

​　　　　（2）创建distribution-integration-service-definition项目，对外提供调用接口

public interface CustomerStaffIntegrationService {

    List<PlatformCustomerStaff> fetchCustomerStaffs(OutsourcingSystemDTO outsourcingSystemDTO);
}

​　　　　2、服务定义

​　　　　　　创建distribution-intergation-service-provider项目，作为服务发布。

​　　　　（1）引入 Dubbo 依赖

<!-- dubbo的自动配置类 -->
<dependency>
   <groupId>org.apache.dubbo</groupId>
   <artifactId>dubbo-spring-boot-starter</artifactId>
</dependency>

<!-- dubbo对于zookeeper的集成 -->
<dependency>
   <groupId>org.apache.dubbo</groupId>
   <artifactId>dubbo-dependencies-zookeeper</artifactId>
   <type>pom</type>
   <exclusions>
      <exclusion>
         <groupId>org.slf4j</groupId>
         <artifactId>slf4j-log4j12</artifactId>
      </exclusion>
   </exclusions>
</dependency>

<!--替换curator默认版本，确保和Zookeeper服务器兼容-->
<dependency>
   <groupId>org.apache.curator</groupId>
   <artifactId>curator-framework</artifactId>
   <version>4.2.0</version>
</dependency>

​　　　　　　（2）Dubbo相关配置

dubbo:
  protocol:
    name: dubbo
    port: -1
  registry:
    address: zookeeper://192.168.249.130:2181
    file: /Users/aaa/Documents/workspace/customer-system/customer-system-distribution/dubbo-log
  scan:
    base-packages: org.geekbang.projects.cs
integration:
  service:
    version: 1.0.0

​　　　　（3）编写接口实现类，同时使用 @DubboService 注解发布服务

@DubboService(version = "${integration.service.version}")
public class CustomerStaffIntegrationServiceImpl implements CustomerStaffIntegrationService {

    @Autowired
    private CustomerStaffEndpoint customerStaffEndpoint;

    @Override
    public List<PlatformCustomerStaff> fetchCustomerStaffs(OutsourcingSystemDTO outsourcingSystemDTO) {
        return customerStaffEndpoint.fetchCustomerStaffs(outsourcingSystemDTO);
    }
}

​　　　　3、开启使用Dubbo

@SpringBootApplication
@EnableDubbo
public class IntegrationApplication {

​　　　　4、distribution-customer-service 处理

​　　　　distribution-customer-service服务承载原distribution-customer-system项目中所有的MVC操作。

​　　　　同上面的distribution-intergation-service，分为distribution-customer-service-definition服务和distribution-customer-service-provider服务服务

​　　　　（1）领域对象：distribution-customer-service-definition　　

public interface CustomerStaffSyncService {

    void syncOutsourcingCustomerStaffsBySystemId(Long systemId);
}

​　　　　（2）服务定义

​　　　　创建distribution-customer-service-provider项目来实现上述接口，也是需要使用@DubboService来发布dubbo服务，pom文件和配置与上面一致，同时引入ICustomerStaffService调用系统集成服务。

@DubboService
public class CustomerStaffSyncServiceImpl implements CustomerStaffSyncService {

    @Autowired
    private ICustomerStaffService customerStaffService;

    @Override
    public void syncOutsourcingCustomerStaffsBySystemId(Long systemId) {
        customerStaffService.syncGetOutsourcingCustomerStaffBySystemId(systemId);
    }
}

四、Zookeeper服务发布和订阅机制解析

（一）Dubbo服务注册中心

​　　　　1、注册中心基本模型：

​　　　　　　对于一个注册中心来说，要有一个 Server 进行独立部署；

​　　　　　　服务提供者在服务启动后将其注册到注册中心；

​　　　　　　而服务消费者通过订阅的方式来获取服务提供者的信息，同时如果服务提供者发生变更，注册中心也能及时的通知到服务消费者；

​　　　　　　服务消费者内部需要有本地缓存，确保注册中心宕机后仍然可以做远程调用，但是还要确保本地缓存与注册中心的一致性；

​　　　　　　　　

​　　　　2、注册中心能力包括：

​　　　　　　支持对等集群：注册中心需要集群化部署

​　　　　　　提供CRUD接口：可以增删改查服务

​　　　　　　订阅发布机制：可以订阅服务

​　　　　　　变更通知机制：服务变更后，订阅者需要能感知到

​　　　　3、Dubbo中注册中心功能特性包括

​　　　　　　Dubbo注册中心除了以上通用能力外，还提供了直连、只注册、只订阅、多注册中心等

​　　　　　　　　直连：联调时会用，不想用注册中心

<dubbo:reference id="xxxService" interface="com.alibaba.xxx.XxxService" url="dubbo://localhost:20890"/>

​　　　　　　　　只注册：

<dubbo:registry address="10.20.153.10:9090" register="false" />

​　　　　　　　　只订阅：

<dubbo:registry address="10.20.141.150:9090" subscribe="false" />

​　　　　　　　　多注册中心：同时调用两个不同注册中心中的服务，接口及版本号都一样，但连的数据库不一样

<!-- 多注册中心配置 -->
<dubbo:registry id="aRegistry" address="10.20.141.150:9090" />
<dubbo:registry id="bRegistry" address="10.20.154.177:9010" default="false" />
<!-- 引用中文站服务 -->
<dubbo:reference id="customerAService" interface="org.geekbang.projects.cs.CustomerService" version="1.0.0"
registry="aRegistry" />
<!-- 引用国际站服务 -->
<dubbo:reference id="customerBService" interface="org.geekbang.projects.cs.CustomerService" version="1.0.0"
registry="bRegistry" />

​　　　　4、Dubbo注册中心

​　　　　Dubbo注册中心支持Multicast 、Zookeeper、Redis、Consul、Nacos、Etcd3

​　　　　Dubbo中的注册中心定义：

public interface RegistryService {
    //注册
    void register(URL url);

    //取消注册
    void unregister(URL url);

    //订阅
    void subscribe(URL url, NotifyListener listener);

    //取消订阅
    void unsubscribe(URL url, NotifyListener listener);

    //根据URL查询对应的注册信息
    List<URL> lookup(URL url);
}

public interface NotifyListener {
    //针对不同URL执行注册中心变更通知
    void notify(List<URL> urls);
}

​　　　　Dubbo中的注册中心实现：

@SPI("dubbo")
public interface RegistryFactory {
    Registry getRegistry(URL url);
}

public interface Registry extends Node, RegistryService {
}

​　　　　　　　　注册中心工厂类结构：

​　　　　　　　　

​　　　　Zookeeper注册中心接口：

​　　　　　　　　

（二）Zookeeper功能特性

​　　　　1、Zookeeper框架

​　　　　　　核心是一个精简的文件系统，提供基于目录节点（ZNode）树方式的数据存储，以及一些额外的抽象操作，如排序，通知和监控。本质上是一种分布式协调工具。

​　　　　　　　　

​　　　　2、Zookeeper访问特性

​　　　　　　Zookeeper访问是通过路径被引用，具有原子性和顺序访问的特点。

​　　　　　　原子性访问：所有请求的处理结果在整个Zookeeper集群中所有机器是一致的

​　　　　　　顺序访问：从同一客户端发起的事务请求，会按照其发起顺序严格应用到Zookeeper

​　　　　3、Zookeeper操作模型

​　　　　　　会话：Zookeeper的会话是使用TCP连接来发送请求，同时可以接收Watch事件，节点分为临时节点(Ephemeral)和持久节点(Persistent)，主要区别是会话结束时节点是否自动删除。

​　　　　　　Watcher：服务端有ZNode，客户端关注ZNode发生变化，ZNode一旦变化，变更消息通过会话（Watcher：分布式回调）传回到客户端，客户端的消息处理函数得到调用（客户端有回调处理函数）

​　　　　　　　　

​　　　　4、Zookeeper核心API：

​　　　　　　　　create：在ZooKeeper命名空间的指定路径中创建一个ZNode

​　　　　　　　　delete：从ZooKeeper命名空间的指定路径中删除一个ZNode

​　　　　　　　　exists：检查路径中是否存在ZNode

​　　　　　　　　getChildren：获取ZNode的子节点列表

​　　　　　　　　getData：获取与ZNode相关的数据

​　　　　　　　　setData：将数据设置/写入ZNode的数据字段

​　　　　　　　　getACL：获取ZNode的访问控制列表（ACL）策略

​　　　　　　　　setACL：在ZNode中设置访问控制列表（ACL）策略

​　　　　　　　　sync：将客户端的ZNode视图与ZooKeeper同步

（三）Dubbo中Zookeeper注册中心实现过程

​　　　　1、交互流程：

​　　　　　　　　

​　　　　2、存储模型：

​　　　　　　使用文件系统类似的树状结构进行存储，一级结构是 /dubbo，二级结构是指定的service，三级结构是配置、服务提供者、服务消费者、监控等等

​　　　　　　　　

​　　　　3、Watcher：

​　　　　　　　　

​　　　　4、Zookeeper注册中心核心类：

​　　　　　　（1）ZookeeperRegistry：利用ZookeeperClient创建了对Zookeeper的连接，并且添加了自动回复连接的监听器

public ZookeeperRegistry(URL url, ZookeeperTransporter, zookeeperTransporter) {
    super(url);
    ......
    String group = url.getParameter(Constants.GROUP_KEY, DEFAULT_ROOT);
    if (!group.startsWith(Constants.PATH_SEPARATOR)) {
        group = Constants.PATH_SEPARATOR + group;
    }
    this.root = group;
  　　// Transporter 是通信组件的封装
    zkClient = zookeeperTransporter.connect(url);
  　　// 利用ZookeeperClient创建了对Zookeeper的连接，并且添加了自动回复连接的监听器
    zkClient.addStateListener(new StateListener() {
        public void stateChanged(int state) {
          　　// 如果是重连，则重新连接
            if (state == RECONNECTED) {
                try {
                    recover();
                } catch (Exception e) {
                    logger.error(e.getMessage(), e);
                }
            }
        }
    });
}

​　　　　　　（2）ZookeeperTransporter：定位上是一个底层通信组件，ZookeeperTransporter本身是一个接口，根据传入的URL通过创建与Zookeeper服务器的连接获取一个ZookeeperClient对象。

@SPI("zkclient")
public interface ZookeeperTransporter {
    @Adaptive({Constants.CLIENT_KEY, Constants.TRANSPORTER_KEY})
    ZookeeperClient connect(URL url);
}

​　　　　　　（3）ZookeeperClient：包含注册中心运行过程中的所有数据操作

public interface ZookeeperClient {
    void create(String path, boolean ephemeral);
    void delete(String path);
    List<String> getChildren(String path);
    List<String> addChildListener(String path, ChildListener listener);
    void removeChildListener(String path, ChildListener listener);
    void addStateListener(StateListener listener);
    void removeStateListener(StateListener listener);
    boolean isConnected();
    void close();
    URL getUrl();
}

​　　　　　　（4）核心类类图：

​　　　　　　　　对于Zookeeper不同的客户端，提供了不同的Transporter。

​　　　　　　　　

​　　　　5、Zookeeper注册中心核心方法：

​　　　　　　（1）注册：利用ZookeeperClient在服务器端创建一个URL的节点，该节点默认为临时节点，当客户端与服务端断开时会自动删除

//执行注册
protected void doRegister(URL url) {
    try {
        // 利用ZookeeperClient在服务器端创建一个URL的节点，该节点默认为临时节点，当客户端与服务端断开时会自动删除
        zkClient.create(toUrlPath(url), url.getParameter(Constants.DYNAMIC_KEY, true));
    } catch (Throwable e) {
        ...
    }
}

​　　　　　　（2）取消注册：取消注册的执行过程就是利用Zookeeper客户端删除URL节点

//取消注册
protected void doUnregister(URL url) {
    try {
        // 取消注册的执行过程就是利用Zookeeper客户端删除URL节点
        zkClient.delete(toUrlPath(url));
    } catch (Throwable e) {
        ...
    }
}

​　　　　　　（3）执行订阅：Dubbo会订阅父级目录, 而当有子节点发生变化时就会触发ChildListener中的回调函数，该回调函数会对该路径下的所有子节点执行subscribe操作

    //执行订阅
    ChildListener zkListener = listeners.get(listener);
    if(zkListener==null){
        listeners.putIfAbsent(listener,new ChildListener(){
            public void childChanged(String parentPath,List<String> currentChilds){
                for(String child:currentChilds){
                    child=URL.decode(child);
                    if(!anyServices.contains(child)){
                        anyServices.add(child);
                      　　// Dubbo会订阅父级目录, 而当有子节点发生变化时就会触发ChildListener中的回调函数，该回调函数会对该路径下的所有子节点执行subscribe操作
                        subscribe(url.setPath(child).addParameters(Constants.INTERFACE_KEY,child, Constants.CHECK_KEY,String.valueOf(false)),listener);
                    }
                }
            }
        });
        zkListener=listeners.get(listener);
    }

​　　　　　　（4）取消订阅：取消订阅URL的过程只是去掉URL上已经注册的监听器

//取消订阅
protected void doUnsubscribe(URL url, NotifyListener listener) {
    ConcurrentMap<NotifyListener, ChildListener> listeners = zkListeners.get(url);
    if (listeners != null) {
        ChildListener zkListener = listeners.get(listener);
        if (zkListener != null) {
        　　　　// 取消订阅URL的过程只是去掉URL上已经注册的监听器
            zkClient.removeChildListener(toUrlPath(url), zkListener);
        }
    }
}

​　　　　6、Zookeeper注册中心的容错性：

​　　　　　　　　FailbackRegistry构造函数中会创建一个定时任务，每隔一段时间执行该retry方法。

​　　　　　　　　从失败集合中获取URL，然后对每个URL执行doRegister操作从而实现重新注册。

​　　　　　　　　

五、使用Dubbo消费分布式服务

（一）Dubbo框架服务引用机制

​　　　　1、服务引用流程分析

​　　　　　　上面提到了Dubbo的服务发布流程，如下所示：　　　　　　　　

​　　　　　　　　

​　　　　　　而Dubbo服务的引用流程几乎与发布流程一一对应：

​　　　　　　　　首先由调用启动器获取服务引用列表和配置信息，然后调用动态代理将本地API调用转换为远程代理对象

​　　　　　　　　动态代理调用调用管理器创建服务导入类

​　　　　　　　　调用管理器从注册中心获取服务提供者地址信息，并更新本地缓存中的服务地址路由表

​　　　　　　　　然后动态代理根据服务调用者指定的协议类型创建协议客户端，发起连接请求

​　　　　　　　　　　　　　　　　　　

​　　　　　　在上述流程中，比较关键的就是如何将远程调用转换为本地接口调用：

​　　　　　　　　导入服务提供者接口API和服务信息

​　　　　　　　　生成远程服务的本地动态代理对象

​　　　　　　　　本地API调用转换成远程服务调用，返回调用结果

​　　　　Dubbo远程调用全流程：

​　　　　　　　　

​　　　　2、Dubbo服务调用核心技术：

​　　　　（1）回声测试（EchoService）

​　　　　　　回声测试是按照正常请求流程执行，能够测试整个调用是否通畅，可用于监控。

​　　　　　　所有服务（无论是业务服务或者系统提供的服务）自动实现EchoService接口，只需将任意服务引用强制转型为EchoService即可使用。

​　　　　　　首先就是回声测试接口（EchoService），内部提供了回声方法$echo，这种命名方式也是Dubbo的一种特点，框架内的接口都是以$开头。

public interface EchoService {
    //定义回声方法
    Object $echo(Object message);
}

​　　　　　　在使用时，首先获取到业务接口，然后强转为EchoService，在调用其$echo方法获取状态，就可以判断接口是否正常。

public static void main(String[] args) throws Exception {
    ClassPathXmlApplicationContext context = new
            ClassPathXmlApplicationContext("spring/dubbo-consumer.xml");
    context.start();
    UserService userService = context.getBean("userService", UserService.class);
    System.out.println("result: " + userService.getUserByUserName("*").toString());
    //使用回声测试
    EchoService echoService = (EchoService) userService;
    String status = (String) echoService.$echo("OK");
    System.out.println("status:" + status);
}

​　　　　　　回声测试一般在自动化脚本中会使用。　　

​　　　　（2）异步调用

​　　　　　　基于NIO的非阻塞实现并行调用，客户端不需要启动多线程即可完成并行调用多个远程服务，相对多线程开销较小所有异步编程接口开始以CompletableFuture为基础。

​　　　　　　首先定义接口，返回值是CompletableFuture

//定义异步业务服务
public interface AsyncUserService {
    CompletableFuture<User> getUserByUserNameAsync(String name);
}

​　　　　　　然后是接口的实现

public class AsyncUserServiceImpl implements AsyncUserService {
    @Override
    public CompletableFuture<User> getUserByUserNameAsync(String name) {
        CompletableFuture<User> future = CompletableFuture.supplyAsync(
                () -> {
                    return new User(...);
                }
        );
        return future;
    }
}

​　　　　　　接口调用

    AsyncUserService asyncUserService = context.getBean("asyncUserService", AsyncUserService.class);
    CompletableFuture<User> future = asyncUserService.getUserByUserNameAsync("*");

​　　　　（3）泛化调用（GenericService）

​　　　　　　 实现一个通用的服务测试框架，能够调用所有服务。

​　　　　　　实现泛化接口调用方式主要用于客户端没有API接口及模型类元的情况，参数及返回值中的所有POJO用Map表示。

​　　　　　　泛化调用违反了接口契约，慎用。

​　　　　　　与EchoService一样，所有的服务都实现了GenericService接口

​　　　　　　泛化接口定义：

public interface GenericService {
    Object $invoke(String method, String[] parameterTypes, Object[] args) throws GenericException;

    default CompletableFuture<Object> $invokeAsync(String method, String[] parameterTypes, Object[] args) throws GenericException {
        Object object = $invoke(method, parameterTypes, args);
        if (object instanceof CompletableFuture) {
            return (CompletableFuture<Object>) object;
        }
        return CompletableFuture.completedFuture(object);
    }
}

​　　　　　　泛化接口使用：与EchoService一样，强转为GenericService，然后调用其$invoke方法，入参是map，在map中可以输入任何参数。

    GenericService userService = (GenericService) context.getBean("paramsUserService");
    String[] parameterTypes = new String[]{"org.geekbang.projects.cs.UserParams"};
    Map<String, Object> param = new HashMap<String, Object>();
    param.put("class","org.geekbang.projects.cs.UserParams");
    param.put("userName","testUserName");
    System.out.println("result: "+userService.$invoke("getUserByParams",parameterTypes,new Object[]{param}));

（二）客服系统案例演进

​　　　　客服系统服务消费链路分析：

​　　　　　　customer-system 中有个定时任务，通过接口调用 customer-service获取数据，customer-service 调用对接系统intergation-service获取三方数据，intergation-service通过端点获取三方数据。

​　　　　以 distribution-customer-service 为例，需要调用 distribution-intergation-service 提供的接口。

​　　　　首先配置配置文件

dubbo:
  protocol:
    name: dubbo
    port: -1
  registry:
    address: zookeeper://127.0.0.1:2181
    file: D:/dubbo/customer-service/cache
  scan:
    base-packages: org.geekbang.projects.cs
customer:
  service:
    version: 1.0.0
#服务引用版本号
integration:
  service:
    version: 1.0.0

​　　　　然后进行接口调用

@DubboService(version = "${customer.service.version}")
public class CustomerStaffSyncServiceImpl implements CustomerStaffSyncService {

    @Autowired
    private ICustomerStaffService customerStaffService;

    @Override
    public void syncOutsourcingCustomerStaffsBySystemId(Long systemId) {
        customerStaffService.syncGetOutsourcingCustomerStaffBySystemId(systemId);
    }

}

六、Dubbo服务端与客户端通信原理解析

（一）Dubbo网络通信组件整体架构

​　　　　1、网络通信过程抽象：

​　　　　　　使用分层架构进行抽象，可以分为业务逻辑层、调用层、和网络传输层，其中：

​　　　　　　　　业务逻辑层是面向开发人员的

​　　　　　　　　调用层在客户端是调用请求层，在服务端时调用响应层，对于网络通讯，一般会抽离一层网络传输层，这样调用层就会很薄，这样调用层只处理请求响应，同时可以处理一些请求时效，请求效果等等的处理

​　　　　　　　　网络通讯层主要就是做网络通讯的，其实就是最底层的

​　　　　　　　　

​　　　　2、Dubbo中的网络通信组件（Remoting）

​　　　　　　在Dubbo中单独抽象了一个网络通信组件 Remoting，其是在业务逻辑层下面专门用来做网络通信的，在Remoting中，又分为Exchange、Transport、Serialize三层。

​　　　　　　　　Exchange层：信息交换层，用来封装请求-响应模式，对应上面的调用请求响应层。

​　　　　　　　　Transport层：网络传输层，抽象Netty等框架作为统一的接口，对应上面的网络传输层。

​　　　　　　　　Serialize层：序列化层，主要完成数据的序列化和反序列化过

​　　　　3、Dubbo网络通信核心类：

​　　　　　　在Dubbo代码中，业务逻辑层对应Protocol，即协议层，调用层对应Exchanger，网络传输层对应Transporter，网络传输需要Serialize序列化。

​　　　　　　　　

​　　　　　　Protocol：

​　　　　　　　　其提供了两个重要的方法：export 方法和 refer 方法，其中 export 方法对外暴露服务，refer方法对远程服务进行引用

​　　　　　　　　基于以上两个方法的设计，那么Protocol就成了一切调用的入口，对于Protocol最常见的实现是DubboProtocol。

@SPI("dubbo")
public interface Protocol {
    int getDefaultPort();

    // 对外暴露服务
    @Adaptive
    <T> Exporter<T> export(Invoker<T> invoker) throws RpcException;

    // 对远程服务进行引用
    @Adaptive
    <T> Invoker<T> refer(Class<T> type, URL url) throws RpcException;

    void destroy();
}

​　　　　　　Exchanger：

​　　　　　　　　exchanger封装了请求和响应的过程，其提供了bind和connect两个方法。

​　　　　　　　　其中bind方法是面向服务器端的，返回的是服务端组件ExchangeServer；

​　　　　　　　　connect方法是面向客户端的，返回值是客户端组件ExchangeClient

​　　　　　　　　通过这两个方法，就形成了网络通信的闭环

@SPI(HeaderExchanger.NAME)
public interface Exchanger {

    // 面向服务器端的bind方法
    @Adaptive({Constants.EXCHANGER_KEY})
    ExchangeServer bind(URL url, ExchangeHandler handler) throws RemotingException;

    // 面向客户端的connect方法
    @Adaptive({Constants.EXCHANGER_KEY})
    ExchangeClient connect(URL url, ExchangeHandler handler) throws RemotingException;
}

​　　　　　　Transporter：

​　　　　　　　　Exchanger只是做网络通信，但是没有网络调用，而网络调用是通过Transporter来做的。

​　　　　　　　　Transporter也是使用了bind和connect这两个方法来做网络调用，范式返回值却不一样，bind返回值是Server，connect返回值是Client，而Exchanger的返回值是ExchangeServer和ExchangeClient，可以看出一个偏底层，一个偏高级。

​　　　　　　　　通知通过@SPI 注解，可以看到底层通信的框架使用的是Netty。

@SPI("netty")
public interface Transporter {

    // 针对具体通信框架实现底层bind操作
    @Adaptive({Constants.SERVER_KEY, Constants.TRANSPORTER_KEY})
    Server bind(URL url, ChannelHandler handler) throws RemotingException;

    // 针对具体通信框架实现底层connect操作
    @Adaptive({Constants.CLIENT_KEY, Constants.TRANSPORTER_KEY})
    Client connect(URL url, ChannelHandler handler) throws RemotingException;
}

（二）Dubbo服务器端通信机制解析

​　　　　Dubbo中服务器端通信的目的就是集成并绑定Netty服务从而启动服务监听，典型的多层架构。

​　　　　如下图所示，Exchanger绑定了一个ExchangerServer，Transporter绑定了Server，当通过URL调用时，调用的是Exchanger，实际上访问的是ExchangerServer，然后再调用Transpoter，即调用绑定的Server。

​　　　　　　　　

​　　　　源码实现如下：　　　　

​　　　　1、DubboProtocol创建ExchangeServer

​　　　　　　在DubboProtocol中的openServer方法中，根据传入的服务请求URL来创建ExchangeServer，最终调用Exchangers.bind进行创建。

// 根据传入的服务请求URL来创建ExchangeServer
private void openServer(URL url) {
    String key = url.getAddress();
    boolean isServer = url.getParameter(Constants.IS_SERVER_KEY, true);
    if (isServer) {
        ExchangeServer server = serverMap.get(key);
        if (server == null) {
            serverMap.put(key, createServer(url));
        } else {
            server.reset(url);
        }
    }
}

// 通过Exchanger接口创建ExchangeServer
private ExchangeServer createServer(URL url) {
    ExchangeServer server;
    try {
        // 通过Exchanger创建Server
        server = Exchangers.bind(url, requestHandler);
    }
    return server;
}

​　　　　2、HeaderExchanger

​　　　　　　通过Transporter执行底层网络通信操作，在bind方法中，通过URL、ExchangeHandler来创建一个HeaderExchangeServer

public class HeaderExchanger implements Exchanger {
    public static final String NAME = "header";

    public ExchangeClient connect(URL url, ExchangeHandler handler) throws RemotingException {
        return new HeaderExchangeClient(Transporters.connect(url,
                new DecodeHandler(new HeaderExchangeHandler(handler))), true);
    }
    
    public ExchangeServer bind(URL url, ExchangeHandler handler) throws RemotingException {
        return new HeaderExchangeServer(Transporters.bind(url,
                new DecodeHandler(new HeaderExchangeHandler(handler))));
    }
}

​　　　　　　在HeaderExchanger中，会处理一些请求时效、请求效果等处理，例如下面的心跳检测，通过创建一个定时任务，来维护心跳。

//心跳检测功能
private void startHeatbeatTimer() {
    stopHeartbeatTimer();
    if (heartbeat > 0) {
        heatbeatTimer = scheduled.scheduleWithFixedDelay(
                // 定时心跳收发及心跳超时监测机制
                new HeartBeatTask(new HeartBeatTask.ChannelProvider() {
                    public Collection<Channel> getChannels() {
                        return Collections.unmodifiableCollection(
                                HeaderExchangeServer.this.getChannels());
                    }
                }, heartbeat, heartbeatTimeout),
                heartbeat, heartbeat, TimeUnit.MILLISECONDS);
    }
}

​　　　　3、NettyTransporter

​　　　　　　在Dubbo中Transporter有两个NettyTransporter、MinaTransporter、GrizzlyTransporter，默认使用Netty4对应的NettyTransporter，在该NettyTransporter种，提供了创建Netty服务端和客户端的方法。

public class NettyTransporter implements Transporter {
    public static final String NAME = "netty4";

    public Server bind(URL url, ChannelHandler listener) throws RemotingException {
        return new NettyServer(url, listener);
    }

    public Client connect(URL url, ChannelHandler listener) throws RemotingException {
        return new NettyClient(url, listener);
    }
}

​　　　　　　对对于创建Netty服务端的NettyServer方法来说，实际上就是通过Netty初始化服务器，并且通过Channel发送消息。

protected void doOpen() throws Throwable {
    ......
    bootstrap = new ServerBootstrap(channelFactory);
    final NettyHandler nettyHandler = new NettyHandler(getUrl(), this);
    channels = nettyHandler.getChannels();
    bootstrap.setPipelineFactory(new ChannelPipelineFactory() {
        public ChannelPipeline getPipeline() {
            NettyCodecAdapter adapter = new NettyCodecAdapter(getCodec(), getUrl(), NettyServer.this);
            ChannelPipeline pipeline = Channels.pipeline();
            pipeline.addLast("decoder", adapter.getDecoder());
            pipeline.addLast("encoder", adapter.getEncoder());
            pipeline.addLast("handler", nettyHandler);
            return pipeline;
        }
    });
    channel = bootstrap.bind(getBindAddress());
}

public void send(Object message, boolean sent) throws RemotingException {
    Collection<Channel> channels = getChannels();
    for (Channel channel : channels) {
        if (channel.isConnected()) {
            channel.send(message, sent);
        }
    }
}

​　　　　4、Dubbo服务器端网络通信全流程：

​　　　　　　下面是使用时序图来表示整个Dubbo服务端通信的流程：

​　　　　　　（1）首先通过DubboProtocol暴露一个服务，暴露服务时要打开一个服务

​　　　　　　（2）然后会打开一个server，打开服务前要创建服务

​　　　　　　（3）创建服务

​　　　　　　（4）创建完毕后要绑定服务，使用Exchanger进行绑定

​　　　　　　（5）实际底层使用的是Transporters进行绑定，而默认实现是Netty，最终创建的是NettyServer。

​　　　　　　　　

（三）Dubbo客户端通信机制解析

​　　　　Dubbo客户端的结构与服务端一一对应，网络通信核心类：

​　　　　　　　　

​　　　　下面重点介绍两个类的方法：

​　　　　1、NettyClient：通过Netty初始化客户端

@Override
protected void doOpen() throws Throwable {
    ......
    bootstrap = new ClientBootstrap(channelFactory);
    final NettyHandler nettyHandler = new NettyHandler(getUrl(), this);
    bootstrap.setPipelineFactory(new ChannelPipelineFactory() {
        public ChannelPipeline getPipeline() {
            NettyCodecAdapter adapter = new NettyCodecAdapter(getCodec(), getUrl(),
                    NettyClient.this);
            ChannelPipeline pipeline = Channels.pipeline();
            pipeline.addLast("decoder", adapter.getDecoder());
            pipeline.addLast("encoder", adapter.getEncoder());
            pipeline.addLast("handler", nettyHandler);
            return pipeline;
        }
    });
}

​　　　　2、DubboProtocol：获取ExchangeClient

private ExchangeClient initClient(URL url) {
    ExchangeClient client;
    try {
        if (url.getParameter(Constants.LAZY_CONNECT_KEY, false)) {
            client = new LazyConnectExchangeClient(url, requestHandler);
        } else {
            client = Exchangers.connect(url, requestHandler);
        }
    }
    return client;
}

七、实现分布式服务容错

（一）服务容错的基本概念

​　　　　服务访问失败的原因包括：大量请求导致的自身服务失败、依赖系统问题导致的失败等

​　　　　在分布式服务中，由于有失败重试策略，那么一个服务异常，会导致依赖服务更大的重试流量，从而导致依赖服务也异常，最终导致系统雪崩。

​　　　　服务失败的应对策略的基本思路包括超时和重试

​　　　　　　超时：指如果服务未能在这个时间内响应，将回复一个失败消息；

​　　　　　　重试：指为了降低网络瞬态异常所造成的的网络通信问题，可以使用重试机制，但是重试应该有次数限制，不能无限次重试。

​　　　　Dubbo中的解决方案：容错思想包括集群容错和服务降级

​　　　　　　集群容错：集群的建立已经满足冗余的条件，而围绕如何进行重试就产生了几种常见的集群容错略；

​　　　　　　服务降级：对服务进行分级管理，必要时关闭对不重要服务的访问入口，节省资源用于处理重要服务的请求

（二）Dubbo集群容错

​　　　　Dubbo负载均衡策略包括：Random(随机)、RoundRobin(轮询)、LeastActive(最少活跃调用数)、ConsistentHash(一致性 Hash)

​　　　　Dubbo集群容错策略包括：Failover、Failfast、Failsafe、Failback、Forking、Broadcast，其中Failover是最常见的集群容错机制

​　　　　Dubbo集群容错策略使用方法：

​　　　　　　cluster配置项：代表集群容错机制，可任选一种

​　　　　　　retries配置项：重试次数，当调用发生失败时重新发起请求的次数

​　　　　代码样例如下：

<dubbo:reference id="userService" check="false" interface="....UserService" loadbalance="roundrobin" cluster="failover" retries="2"/>

（三）Dubbo服务降级

​　　　　本地伪装 VS 本地存根：

​　　　　　　　　

​　　　　　　本地伪装是指当某服务提供者全部挂掉后，客户端不抛出异常，而是通过Mock数据返回失败，Mock类在服务消费者端配置

​　　　　　　本地存根是指服务的提供方也有在本地执行部分逻辑的场景(例如原先校验参数)，从而间接实现服务容错，Stub类在服务提供者端配置

​　　　　实现本地伪装：

​　　　　　　服务提供者模拟服务超时失败：

//服务提供者模拟服务超时失败
public class UserServiceImpl implements UserService {
    @Override
    public User getUserByUserName(String userName) {
        try {
            Thread.sleep(5000);//模拟服务端响应超时
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        return new User(...);
    }
}

​　　　　　　服务消费者实现和配置Mock类：

//服务消费者实现和配置Mock类
public class UserServiceMock implements UserService {
    @Override
    public User getUserByUserName(String userName) {
    //降级实现
        return new User(1L, "mock_username", "mock_password");
    }
}

​　　　　　　配置项：

<dubbo:reference id="userService" check="false" interface="...UserService" mock="....mock.UserServiceMock"/>

（四）客服系统案例演进

​　　　　在distribution-customer-service调用distribution-intergation-service时使用降级策略。

​　　　　首先在distribution-customer-service中编写降级类

@Component
public class CustomerStaffIntegrationServiceMock implements CustomerStaffIntegrationService {
    @Override
    public List<PlatformCustomerStaff> fetchCustomerStaffs(OutsourcingSystemDTO outsourcingSystemDTO) {
        return null;
    }
}

​　　　　然后在distribution-customer-service的调用中，配置mock

@DubboReference(version = "${integration.service.version}", timeout = 5000, loadbalance = "roundrobin", retries = 2, mock = "com.lcl.galaxy.customer.service.provider.intergation.CustomerStaffIntegrationServiceMock")
private CustomerStaffIntegrationService customerStaffIntegrationService;