截教教主

分布式系统理论

说到分布式系统，不得不说集中式系统。传统集中式系统中整个项目所有的东西都在一个应用里面。
一个网站就是一个应用，当系统压力较大时，只能横向扩展，增加多个服务器或者多个容器去做负载均衡，避免单点故障而影响到整个系统。

集中式最明显的优点就是开发，测试，运维会比较方便，不用考虑复杂的分布式环境。

弊端也很明显，系统大而复杂、不易扩展、难于维护，每次更新都必须更新所有的应用。

                      集中式系统拓扑图

鉴于集中式系统的种种弊端，促成了分布式系统的形成，分布式系统背后是由一系列的计算机组成，但用户感知不到背后的逻辑，就像访问单个计算机一样，天然的避免了单机故障的问题。

应用可以按业务类型拆分成多个应用或服务，再按结构分成接口层、服务层。

我们也可以按访问入口分，如移动端、PC 端等定义不同的接口应用。数据库可以按业务类型拆分成多个实例，还可以对单表进行分库分表。同时增加分布式缓存、消息队列、非关系型数据库、搜索等中间件。

分布式系统虽好，但是增加了系统的复杂性，如分布式事务、分布式锁、分布式 Session、数据一致性等都是现在分布式系统中需要解决的难题。

分布式系统也增加了开发测试运维的成本，工作量增加，其管理不好反而会变成一种负担。

                           分布式系统拓扑图

分布式系统最为核心的要属分布式服务框架，有了分布式服务框架，我们只需关注各自的业务，而无需去关注那些复杂的服务之间调用的过程。

分布式服务框架

目前业界比较流行的分布式服务框架有：阿里的 Dubbo、Spring Cloud。

这里不对这些分布式服务框架做对比，简单的说说他们都做了些什么，能使我们用远程服务就像调用本地服务那么简单高效。

服务

服务是对使用用户有功能输出的模块，以技术框架作为基础，能实现用户的需求。

比如日志记录服务、权限管理服务、后台服务、配置服务、缓存服务、存储服务、消息服务等，这些服务可以灵活的组合在一起，也可以独立运行。

服务需要有接口，与系统进行对接。面向服务的开发，应该是把服务拆分开发，把服务组合运行。

更加直接的例子如：历史详情、留言板、评论、评级服务等。他们之间能独立运行，也要能组合在一起作为一个整体。

注册中心

注册中心对整个分布式系统起着最为核心的整合作用，支持对等集群，需要提供 CRUD 接口，支持订阅发布机制且可靠性要求非常之高，一般拿 Zookeeper 集群来做为注册中心。

分布式环境中服务提供方的服务会在多台服务器上部署，每台服务器会向注册中心提供服务方标识、服务列表、地址、对应端口、序列化协议等信息。

注册中心记录下服务和服务地址的映射关系，一般一个服务会对应多个地址，这个过程我们称之为服务发布或服务注册。

服务调用方会根据服务方标识、服务列表从注册中心获取所需服务的信息（地址端口信息、序列化协议等），这些信息会缓存至本地。

当服务需要调用其他服务时，直接在这里找到服务的地址，进行调用，这个过程我们称之为服务发现。

注册中心

下面是以 Zookeeper 作为注册中心的简单实现：

/**
     * 创建node节点
     * @param node
     * @param data
     */
    public boolean createNode(String node, String data) {
        try {
            byte[] bytes = data.getBytes();
            //同步创建临时顺序节点
            String path = zk.create(ZkConstant.ZK_RPC_DATA_PATH+"/"+node+"-", bytes, ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL_SEQUENTIAL);
            log.info("create zookeeper node ({} => {})", path, data);
        }catch (KeeperException e) {
            log.error("", e);
            return false;
        }catch (InterruptedException ex){
            log.error("", ex);
            return false;
        }
        return true;
    }

子节点 1

子节点 2

如下面 Zookeeper 中写入的临时顺序节点信息：
com.black.blackrpc.test.HelloWord：发布服务时对外的名称。
00000000010，00000000011：ZK 顺序节点 ID。
127.0.0.1:8888，127.0.0.1:8889：服务地址端口。
Protostuff：序列化方式。
1.0：权值，负载均衡策略使用。

这里使用的是 Zookeeper 的临时顺序节点，为什么使用临时顺序节点，主要是考虑以下两点：
当服务提供者异常下线时，与 Zookeeper 的连接会中断，Zookeeper 服务器会主动删除临时节点，同步给服务消费者。
这样就能避免服务消费者去请求异常的服务器。校稿注：一般消费方也会在实际发起请求前，对当前获取到的服务提供方节点进行心跳，避免请求连接有问题的节点。
Zookeeper 下面是不允许创建 2 个名称相同的 ZK 子节点的，通过顺序节点就能避免创建相同的名称。
当然也可以不用顺序节点的方式，直接以 com.black.blackrpc.test.HelloWord 创建节点，在该节点下创建数据节点。

下面是 ZK 的数据同步过程：

/**
     * 同步节点 （通知模式）
     * syncNodes会通过级联方式，在每次watcher被触发后，就会再挂上新的watcher。完成了类似链式触发的功能
     */
    public boolean syncNodes() {
        try {
            List nodeList = zk.getChildren(ZkConstant.ZK_RPC_DATA_PATH, new Watcher() {
                @Override
                public void process(WatchedEvent event) {
                    if (event.getType() == Event.EventType.NodeChildrenChanged) {
                        syncNodes();
                    }
                }
            });
            Map> map =new HashMap>();
            for (String node : nodeList) {
                byte[] bytes = zk.getData(ZkConstant.ZK_RPC_DATA_PATH + "/" + node, false, null);
                String key =node.substring(0, node.lastIndexOf(ZkConstant.DELIMITED_MARKER));
                String value=new String(bytes);
                Object object =map.get(key);
                if(object!=null){
                    ((List)object).add(value);
                }else {
                    List dataList = new ArrayList();
                    dataList.add(value);
                    map.put(key,dataList);
                }
                log.info("node: [{}] data: [{}]",node,new String(bytes));
            }
            /**修改连接的地址缓存*/
            if(MapUtil.isNotEmpty(map)){
                log.debug("invoking service cache updateing....");
                InvokingServiceCache.updataInvokingServiceMap(map);
            }
            return true;
        } catch (KeeperException | InterruptedException e) {
            log.error(e.toString());
            return false;
        }
    }

当数据同步到本地时，一般会写入到本地文件中，防止因 Zookeeper 集群异常下线而无法获取服务提供者信息。

通讯与协议

服务消费者无论是与注册中心还是与服务提供者，都需要存在网络连接传输数据，而这就涉及到通讯。

笔者之前也做过这方面的工作，当时使用的是 java BIO 简单的写了一个通讯包，使用场景没有多大的并发，阻塞式的 BIO 也未暴露太多问题。

java BIO 因其建立连接之后会阻塞线程等待数据，这种方式必须以一连接一线程的方式，即客户端有连接请求时服务器端就需要启动一个线程进行处理。当连接数过大时，会建立相当多的线程，性能直线下降。

Java NIO：同步非阻塞，服务器实现模式为一个请求一个线程，即客户端发送的连接请求都会注册到多路复用器上，多路复用器轮询到连接有 I/O 请求时才启动一个线程进行处理。

Java AIO：异步非阻塞，服务器实现模式为一个有效请求一个线程，客户端的 I/O 请求都是由 OS 先完成了再通知服务器应用去启动线程进行处理。

BIO、NIO、AIO 适用场景分析:
BIO：用于连接数目比较小且固定的架构，这种方式对服务器资源要求比较高，并发局限于应用中，但程序直观简单易理解。
NIO：适用于连接数目多且连接比较短（轻操作）的架构，比如聊天服务器，并发局限于应用中，编程比较复杂。
目前主流的通讯框架 Netty、Apache Mina、Grizzl、NIO Framework 都是基于其实现的。
AIO：用于连接数目多且连接比较长（重操作）的架构，比如图片服务器，文件传输等，充分调用 OS 参与并发操作，编程比较复杂。

作为基石的通讯，其实要考虑很多东西。如：丢包粘包的情况，心跳机制，断连重连，消息缓存重发，资源的优雅释放，长连接还是短连接等。

下面是 Netty 建立服务端，客户端的简单实现：

import io.netty.bootstrap.ServerBootstrap;
import io.netty.channel.ChannelInitializer;
import io.netty.channel.ChannelPipeline;
import io.netty.channel.EventLoopGroup;
import io.netty.channel.nio.NioEventLoopGroup;
import io.netty.channel.socket.SocketChannel;
import io.netty.channel.socket.nio.NioServerSocketChannel;
import io.netty.handler.codec.LengthFieldBasedFrameDecoder;
import io.netty.handler.codec.LengthFieldPrepender;
import io.netty.handler.codec.bytes.ByteArrayDecoder;
import io.netty.handler.codec.bytes.ByteArrayEncoder;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
/***
 * netty tcp 服务端
 * @author cds
 *
 */
public class NettyTcpService {
    private static final Logger log = LoggerFactory.getLogger(NettyTcpService.class);
    private String host;
    private int port;

    public NettyTcpService(String address) throws Exception{
        String str[] = address.split(":");
        this.host=str[0];
        this.port=Integer.valueOf(str[1]);
    }

    public NettyTcpService(String host,int port) throws Exception{
        this.host=host;
        this.port=port;
    }
    /**用于分配处理业务线程的线程组个数 */  
    private static final int BIZGROUPSIZE = Runtime.getRuntime().availableProcessors()*2; //默认  
    /** 业务出现线程大小*/  
    private static final int BIZTHREADSIZE = 4;  
    /* 
     * NioEventLoopGroup实际上就是个线程,
     * NioEventLoopGroup在后台启动了n个NioEventLoop来处理Channel事件, 
     * 每一个NioEventLoop负责处理m个Channel, 
     * NioEventLoopGroup从NioEventLoop数组里挨个取出NioEventLoop来处理Channel
     */  
    private static final EventLoopGroup bossGroup = new NioEventLoopGroup(BIZGROUPSIZE);  
    private static final EventLoopGroup workerGroup = new NioEventLoopGroup(BIZTHREADSIZE);  

    public void start() throws Exception {
        log.info("Netty Tcp Service Run...");
        ServerBootstrap b = new ServerBootstrap();  
        b.group(bossGroup, workerGroup);  
        b.channel(NioServerSocketChannel.class);  
        b.childHandler(new ChannelInitializer() {  
            @Override  
            public void initChannel(SocketChannel ch) throws Exception {  
                ChannelPipeline pipeline = ch.pipeline();  
                pipeline.addLast("frameDecoder", new LengthFieldBasedFrameDecoder(Integer.MAX_VALUE, 0, 4, 0, 4));  
                pipeline.addLast("frameEncoder", new LengthFieldPrepender(4));  
                pipeline.addLast("decoder", new ByteArrayDecoder());  
                pipeline.addLast("encoder", new ByteArrayEncoder());  
              //  pipeline.addLast(new Encoder());
              //  pipeline.addLast(new Decoder());
                pipeline.addLast(new TcpServerHandler());
            }  
        });  
        b.bind(host, port).sync();  
        log.info("Netty Tcp Service Success!");
    }  
    /**
     * 停止服务并释放资源
     */
    public void shutdown() {  
        workerGroup.shutdownGracefully();  
        bossGroup.shutdownGracefully();  
    }
}

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import io.netty.channel.ChannelHandlerContext;
import io.netty.channel.SimpleChannelInboundHandler;
/**
 * 服务端处理器
 */
public class TcpServerHandler extends SimpleChannelInboundHandler