一套分布式系统的开发总结（草稿）

一套分布式系统的开发总结 （草稿）

一、“分布式系统”的定义：
分布式系统到底如何定义，我不了解；
我这里的“分布式系统”，指的是具有如下特点的系统：

1、 有多种业务逻辑组成
2、 业务之间需要通信
3、 业务有分布式的需求。

二、 分布式系统的需求：
1、 分布式
1）、 业务逻辑可部署在多台物理机器上
2）、 可扩展性： 当性能等遇到瓶颈后，可通过扩展来解决
3）、 可重新部署

2、 业务逻辑的控制：
1）、 启动、停止
2）、 重启

3、 业务状态监控：
1）、 运行状态
2）、 资源占用情况

4、 业务逻辑更新
1）、 程序升级
2）、 配置修改
3）、 模块升级

5、 节点机器监控

6、 节点机器维护

我把这样一台系统，叫做“分布式系统”，而Matrix 系统，就是为了能用一种集中、简便的方式，来满足这种系统的需求；
它既是一套运维平台，也是一套运行平台。

三、 Matrix 系统如何满足如上需求：
为了能满足如上需求，Matrix 进行了如下抽象：

1、 用“云”来描述业务逻辑
任何业务逻辑，都是一种云
云有唯一的 namespace
云之间可进行通信




2、 “云”由一组虚节点组成
虚节点具有相同的逻辑
虚节点可部署到不同的物理机器上
通过扩展虚节点数量，并将之部署到不同的物理机器上，从而满足“分布式”、“冗余”、“扩展”等需求。
虚节点最终落实为物理机器上的一个进程。




3、 将运行虚节点所需要的素材抽象为“资源”
要运行一个虚节点，通常需要准备如下素材：
1）、 容器的可执行程序
2）、 应用逻辑的动态库、脚本、配置文件
3）、 应用逻辑所需要的模块
4）、 依赖的其它库、可执行程序、脚本

把这些素材抽象为资源，并分成不同类别。
资源对应着“资源文件”
在描述一个虚节点的时候，需要指定它用到哪些资源
要运行一个虚节点，首先要获取所需要的资源文件
当资源文件更新后，可能需要重新启动虚节点。

这样，一个虚节点需要多种资源，
在运行虚节点之前，所需要的资源文件应该就绪。
如果某种资源更新后，应及时获取，并根据需要重启虚节点。


4、 通过 Agent 进程来实现分布式管理。
资源的获取、虚节点的管理，等等，都需要在屋里机器上进行。
因此，在每台物理机器上，必须部署一个 Agent 进程，作为中央控制服务的在物理机器上代言人。
Agent 进程接受中央控制服务的指令，并执行之，这些指令包括：
1）、 资源获取
2）、 虚节点控制
3）、 虚节点监控
4）、 其它

5、 让虚节点跑在相同的容器中
虚节点，最终变现为跑在某台物理机器上的服务进程
为了能对这些进程进行统一管理，我们让虚节点，跑在相同的容器中，而具体业务逻辑通过动态库来提供。
容器，提供了管理和通信等接口，可接收外部的控制，并可与其它虚节点通信。
而业务逻辑，则由动态库来提供
业务逻辑课用不同的语言开发，例如 C, C++, Java, Python


有了“中央控制服务”、"Agent进程”、“物理机器”、“云”、“虚节点”、“资源”、“统一的虚节点容器”等概念，一个分布式管理平台就具备了雏形。

1、 Agent 进程运行在“物理机器”上，接收“中央控制服务”的指令
2、 用“云”来描述业务逻辑
3、 “云”由相同逻辑的“虚节点”组成
4、 “虚节点”需要不同的“资源”
5、 “虚节点”部署到“物理机器”上，表现为一个进程
6、 “虚节点”由“统一的虚节点容器” 加上“具体的业务逻辑”等资源组成
7、 "Agent 进程”接受“中央控制服务”的质量，获取资源文件，控制“虚节点”的运行。


四、 逻辑云和物理云
分布式系统，要求业务之间需要通信，

1、 将云分为“逻辑云”和“物理云”两个层次
2、 逻辑云在系统中具有唯一的名称，且不能改变
3、 通过名称来访问“逻辑云”，由于名称不变，
4、 “物理云”描述云的虚节点的组成，“物理云”属于某个逻辑云，但名称可变化
5、 “逻辑云”与“物理云”之间需要建立“绑定关系”。

五、 云之间的通信
1、 通过“路由表”来描述一个物理云中的虚节点的分布
2、 当需要访问某个云的时候，首先获取路由表，然后根据访问策略，选择虚节点，建立连接，并进行通信。
3、 当“物理云”发生变化后，路由表需要及时更新
4、 采用亚马逊 paper 中的 DHT 环