我对分布式计算框架的理解与设计

谢谢大家来看这篇文章，我想花点时间分享一下我对分布式计算的理解。
分布式服务有很多，比如hbase, hadoop, spark等，我所要讲述的重点不是这些服务的原理，而是用更浅显的话讲述更深刻的设计。
如何把多个的机器组合起来完成一件简单的计算任务，所以这方面的架构设计更多的关注服务器间的关系。
下面我们来设计一个框架，以进行简单的分布式计算。
我们假设计算目标有三类：
1.分布计算能力，简单多节点计算， 计算1万以内的质数。
2.map-reduce，以wordcount为例。
3.资源查询，分布式查询数据库

模块设计

在架构上， 可以将服务中的服务器分三个模块：

模块	含义
config	配置服务
service	对外接口服务
server	工作服务（worker)

我想让service接受请求，server进行计算， 流程会是怎样的呢。

流程设计

一条简单的请求过来，可能经过的处理过程：

实际的处理比这个要复杂，比如请求过期处理等。

抽象设计

在框架内通个上，service与server都会向config注册，通信以及获取节点情况等，因此会有很多
相似的逻辑实现，所以很自然地，我把节点的关系重新定义为 config-node

为了简单处理，抽象了一个node，service与server共同继承node, 由node负责与config通信。

功能设计

config在框架里起到分配资源与注册服务的功能。

node功能

整体功能

下面我将对系统设计的协议进行设计。

协议设计

为了简单方便，我将模块间的通信采用protobuf。
（实际上在通用对外服务是不能用protobuf的，请大家思考为什么。）

config:

message ConfigRequest{
    optional ConfigAuthReq auth= 1;
    optional ConfigGetNodesReq get_nodes= 2;
}
message ConfigResponse{
    optional ConfigAuthRsp auth = 1;
    optional ConfigGetNodesRsp  get_nodes= 2;
    optional ConfigNotifyNodes  notify_nodes= 3;
}

server

message ServerRequest{
    required ServerDiag               diags = 1;
    required ServerDiagNodeType       diag_type = 2;

    optional ServerAuthReq            auth = 3;

    optional PrimeQueryReq            prime = 4;
    optional ServerWordCountReq       wc = 5;
    optional ServerQueryReq           query = 6;
    optional ServerBGReq              bg = 7;

}

message ServerResponse{
    optional ServerAuthRsp               auth = 1;
    optional PrimeQueryRsp               prime = 2;
    optional ServerWordCountRsp          wc = 3;
    optional ServerQueryRsp              query = 4;
    optional ServerBGResponse            bg = 5;
}

下面来定义我们的代码结构

代码架构

下面的代码架构主要争对config-node而设计。
config请求处理：

class Config{
  public:
     void OnRequest(const TcpConnPtr& con, ConfigRequest& request);
}

相应的node接口

  class Node{
  protected:
      virtual void onConfigResponse(const TcpConnPtr& con,ConfigResponse& response);

  protected:
      void sendToConfig(const TcpConnPtr& con,ConfigResponse& response);
};

service与server继承node后实现onConfigResponse即可。

对外接口设计

为了接口方便，对外接口均设为http接口，并支持网页。

prime：

[get] http://dist.alibaba-inc.com/calc/prime

参数	含义
start	起始值
end	结束值

例：http://dist.alibaba-inc.com/calc/prime?start=1&end=10000

wordcount

[post] http://dist.alibaba-inc.com/calc/wordcount

参数	含义
data	待计算的文件
tokenize	分隔符

分布式查询
[post] http://dist.alibaba-inc.com/calc/query

参数	含义
app	应用名
db	库
collection	连接
data	查询条件

service与server程序架构

流程监控设计

为了方便了解每次请求的全链路情况，我在原架构中添加了日志与监控模块

功能显示设计

prime

wordcount

query

chart

业务流程图

prime

wordcount

对于map reduce运算，实际处理过程是这样的

query

这里的query在设计上是简化处理了的，生产上可能需要注意结果缓存，主从同步等。

从上面的设计上，我们可以发现，分布式处理的基础需要有一个config（配置服务器），及内部通信协议。
另外，节点的备份机制也很重要， 比如 config崩溃或者server崩溃的结果要做到不受影响。

崩溃恢复机制

config

对于config的功能，由于其核心功能是当前节点分布，是动态数据，因此数据安全可以采用的方法有很多，比如redis，mysql, mongo等。

其自身的功能崩溃恢复可以采用一种简单有效的方法。每个config节点都存有所有config的信息并且同步到各个node(service/server)。
每当新起一个config或者关掉一个，信息更新一次，node与config失联后再主动选择一个连接。

node

config提供node相互关注的能力， 即node A可以关注node B, 当node B断开后，config会通知像A一样所有关注它的node。