谈谈云计算的部署方式——关于分布化实现

前言：

         我们在以前的文章（对云计算中几种基础设施（Dynamo,Bigtable,Map/Reduce等）的朴素看法）中对云计算的概念和基础组织已作了较为详细的解释和分析，这次我们将继续云计算的话题——进一步谈谈云计算在实际应用环境中的部署方法。

         我个人理解，云的主要精髓之一（除此以外，资源虚拟化动态分配和安全访问是另外两个核心，我们后面找机会讨论它们）在于数据存储和计算的分布化，因而需要在云部署上充分考虑如何满足分布性，以及如何方便的集中管理云——自动化部署，启动，停止等。

         下文的主要内容将以我们的实际开发实践为基础展开，重在说明部署方法和管理方法，而不详细谈代码实现——另外，可能的实现方法多会是种多样，但目的殊途同归。

 

 

云的分布性：

 

     我这里所说的云其实就是我们自己的具体应用程序，之所以叫它云是因为我们的应用——无论是存储或者是计算——都是分布实现的。这是因为我们所需要处理的数据量在单机上无论是存储或者是计算都无法完成，因此必须将数据处理任务分散开来，化整为零交给多台机器共同完成。我们的每个应用部署起来都是分布化的，我这里姑且叫它们为云好了——这里先别去管所谓的云服务，重点关注它的分布性，或者并行性。

    下面的内容我们重点说说这种分布性的实现方法。

 

派发服务

     首先看满足分布化所要求做的工作——云中的和云之间的存储和运算点都是部署需要支持跨机器访问（可能还要跨IDC喽)——我们因此需要一个消息派发服务，即负责管理消息的分布通讯。

     在谈派发服务前，我们简要说一下云应用如何被访问。云应用程序和单机应用程序从功能层面看应该是没有区别的，唯一的区别在于访问方式上有一点点差别。访问云应用时需要访问者给出云应用的名称（或者说是namespace)外，还需要给出派发KEY，用来觉得该任务应该下发给云中那个点负责。也许你要说dynamo或者google的bigtable就没有见要指定派发KEY呀，其实不然，他们的派发KEY虽然没有被显示出现，但却被隐含在访问数据中了，比如dyname中的访问键就是派发KEY。

    有了这个派发KEY的概念，我们就接着谈派发服务了。

 

派发服务的责任

     具体的讲该服务需要负责：

1. 根据派发规则和云的路由信息找到派发目标点——所谓路由信息，其实就是云中各点的位置信息，比如 ip地址和port。
2. 建立和管理链接；
3. 发送和接受数据——采用异步IO处理模型应该更高效率。

      除此基本功能以外，最好还能做到一些附加功能：

1. 动态更新路由——实时感知网络拓扑结构或者计算点和存储点的位置信息变化，以便能在不停服务的情况下，调整派发路线；
2. 统计各种通讯计数（包数，流量等），以便能分析云运行数据流的状态；

3. 对流量进行控制，以防止过载；

4. 上报错误（对于链接等异常，需要上报）

 派发服务算法基础和派发规则

       派发服务的主要算法是DHT（分布hash)，数学描述忽略，我们找最简单的例子举例说明这个算法的含义。

     首先我们所选定的派发KEY的是由一个字符串做MD5后获得的，它会是一个128为数值——做MD5的目的是使得数据均匀分布和避免冲突——。然后我们在逻辑上将128位的数值空间均分成N份，然后让每个机器负责其中1/N的任务，从而让任务分布派发到不同机器上。很简单是吧，虽然有很多变种算法，但万变不离其宗。我们的分布基础多数就是依赖于该算法。

        分布系统的消息必定有其派发规则。这种规则随应用不同而相应变化，不过我们通常还是可以抽象出一些标准的派发规则。下面谈谈能抽象出来的派发规则。

• RR派发规则：就是随机的给目标云中的一组点上任意一个下发数据。这种规则的应用场景应该是数据之间没有逻辑关系，数据给哪个节点处理都一样——也就是说节点处理过程没有session. RR规则的派发KEY可以随机选取。
• SESSION 派发规则：和RR派发不同之处就是节点处理有Session——后面的任务需要在前面的基础上进行，因此数据不能任意下发，而是要保证给定的数据集合发给同一个点。SESSION规则的派发KEY需要发送方给定。
• 查表派发规则：有些派发无法用给定的规则做partation——因为需要某些预先给定的数据落到预先给定的点上处理 ，而不向SESSION派发那样仅仅要求给定任务集合落到同一个点就行。那么可能需要具体的查预先定义的映射表，才能决定派发路径。查表派发规则的派发KEY需要发送方给定。
• Dynamo 式派发规则：这种派发遵循dynamo系统采用的N,W,R规则进行派发，具体看看dynamo论文吧，对于冗余存储采用这种方式。

 

       除了上述派发规则外，很多应用会有自己特殊的派发规则。不过上述的规则最普遍，多数情况下都够用 

 派发服务的部署

    派发服务部署可采用多种方式：如做成一个lib供应用程序（这里说的应用程序就是云的存储或者计算点）自己去调用；或者做成一个单独的服务进程独立于应用程序。这两种方式各有各的好处，我们下面具体谈谈这两种方式的区别。

    首先说说作为单独服务程序部署——我们可认为它是一个负责派发逻辑的独立的消息中间件。这种作为部署方式有一些好处：1 系统的数据逻辑层次解耦合——应用的计算逻辑和IO逻辑分离——提高了程序的可维护性；2 跨机器间的数据都由消息中间件走减少了系统中的连接数目——不需要云中计算点和点之间都建立点到点的连接了，而只需要机器到机器建立端到端的连接即可（因为一个机器只需要部署一个消息中间件就可）。

    鉴于以上好处，我们一般对于小数据都建议使用该方式传输。但是这样必然增加了进程见通讯负载，对于大数据传输这种消耗可能无法忍受，因此在这种情况下，可以将消息中间件“退化”成一个lib供计算点内部调用。

 

 派发服务的路由组织

      派发服务必须知道云中个点的位置信息才能正确完成消息派发。这些位置信息记录在“路由表”中，路由表信息中需要包含派发规则（可以交给一个动态库完成）；云中个点的ID和其位置信息（即，个点的location信息：如ip,port等）；以及其他诸如超时（timeout)等信息。

 

      比如Dynamo 式派发规则的路由表信息需要如下部分：

• 云的命名 —— 作为一个云唯一的标示，用于数据发送时的制定目的地
• N （副本数）, W（每次写需成功写入副本数） ,R（每次读需要读取的副本数） 参数值
• 分段数目——即MD5值域被均匀切分总段数目，一般给成2的次幂。
• 具体的运算点或计算点位置信息{ID ,LOCATION} —— 我们记载全云路由信息，因此每个点的信息都需要记录。
• 派发规则算法——可以是以一个provider,用于解析路由信息和实现派发逻辑

• 其他辅助属性——如连接超时等参数  

派发服务的路由查询

       云的路由信息作为元数据管理一般的设计方式是交给一个服务点做集中式管理，当发送方发送前访问该路由查询服务获取路由信息。这种传统方式的好处在于路由数据只有一点管理便于管理，尤其是更新。坏处是需要跨机器的额外查询，增加了交互，影响了性能——当然可以做一定优化，让访问方在本地缓存以减少访问次数；另外一个坏处是系统存在单点，影响了系统可靠性。

       我们的方法是将路由信息（路由信息生成下一次将介绍）下放到路由服务机器上，让路由服务自己加载，这种本地管理避免了远程查询过程，带来了性能优化。可是也造成了路由更新实现的复杂性，要知道在分布系统更新路由并不能保证个点都同步和成功。因此需要解决个点路由不一致期间的数据的正确性。具体方法有很多，比如增加路由版本，更新保证分布事务等，这里不展开了。

      就我们的应用运行环境和应用要求（机房私有，环境稳定安全；云规模适中；要求高性能）而言，我们采用了第二种方法。—— GOOGL的GFS采用的是第一种方式，具体那种需要看实际应用而言了。

小结：

      关于分布化的实现就谈这么多了，虽然学院派会有更多的理论和方法，但我们认为企业应用不易复杂——简单就是美。 下次我们继续谈谈关于云部署的其他服务组件以及管理方法了。