我理解的分布式系统，你需要了解的我都有

前言

说到分布式系统，不得不说集中式系统。传统集中式系统中整个项目所有的东西都在一个应用里面。一个网站就是一个应用，当系统压力较大时，只能横向扩展，增加多个服务器或者多个容器去做负载均衡，避免单点故障而影响到整个系统。集中式最明显的优点就是开发，测试，运维会比较方便，不用考虑复杂的分布式环境。弊端也很明显，系统大而复杂、不易扩展、难于维护，每次更新都必须更新所有的应用。

介于集中式系统的种种弊端，促成了分布式系统的形成，分布式系统背后是由一系列的计算机组成，但用户感知不到背后的逻辑，就像访问单个计算机一样。天然的避免了单机故障的问题。应用可以按业务类型拆分成多个应用或服务，再按结构分成接口层、服务层。我们也可以按访问入口分，如移动端、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;
    }

如下面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服务器会主动删除临时节点，同步给服务消费者。这样就能避免服务消费者去请求异常的服务器。

校稿注： 一般消费方也会在实际发起请求前，对当前获取到的服务提供方节点进行心跳，避免请求连接有问题的节点

二、 zk下面是不允许创建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参与并发操作，编程比较复杂。
(有兴趣可以看看这篇文章：BIO与NIO、AIO的区别 )
作为基石的通讯，其实要考虑很多东西。如：丢包粘包的情况，心跳机制，断连重连，消息缓存重发，资源的优雅释放，长连接还是短连接等。
下面是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 v_wangshiyu
 *
 */
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