探索Cassandra的去中心化分布式架构

Posted 2023-04-08 守护石技术研究

关系型模型之父Edgar F. Codd，在1970年Communications of ACM 上发表了《大型共享数据库数据的关系模型》，成为了永恒的经典，关系模型的语义设计易于理解，语法上嵌套、闭环、完整，因此在数据库领域，关系模型普及与流行了数年之久。

在此之后，IT世界涌现了很多非常著名的RDBMS（关系型数据库系统），包括了Oracle、mysql、SQLServer、DB2、PostgreSQL等。

1. 传统关系型数据库的分布式瓶颈

但是RDBMS的技术发展由于架构上的限制，遇到了很多问题，例如：关系模型的约束必须在设计前明确定义好属性，这就难以像很多NoSQL一样，具有灵活可变的模式，很难适应敏捷迭代的需要。

其实最难解决的一个问题，就是数据表的分布式化。

为什么会导致如此现象呢？

本质上，由于关系模型在前期设计上的强关联，导致表表之间的连接关系变得极为紧密。

例如：有一种比较普遍的业务场景中连接操作，通过A->B->C的关联查找，然而这种关联所形成的链，就将A、B、C紧密地捆绑在了一起。

那么这种紧密关系带来了什么问题呢？

那就是RDBMS在设计之初，很难去考虑到数据表在分布式网络环境中的通讯解耦设计，而只是单纯的数据表本地文件的IO扫描，而且在过去低带宽的网络环境中，模型关系的分布式化，更是难以想象。

如下图所示：

我们从上图可以看到，教师、学生和课程这三张表具有多对多的紧密关系（其中还有一些未展示的中间表），那么这种紧密的关系投射到具体的数据库物理文件上，就是图中多个物理上的表文件(Table Data)，当我们查询时，就是通过关系逻辑对这些表文件进行了频繁的IO扫描。

在这种模式下，我们会发现一个问题，这些表实际上很难跨数据库而分布式拆分，也就是说，RDBMS很难以分布式形式，把教师表放到服务器1的数据库1上，学生表放到服务器2的数据库2上，课程表放到服务器3的数据库3上。

而且更难做到的是：将1万名学生总共10万次课程活动所产生的学生上课数据分拆成10个1万条数据表，再将表分布在不同的数据库中。

如下图所示：

我们提出一个假设：如果能将学生课程活动表拆分到分布式网络中多个数据库实例当中，那么就极大地降低了单台数据库的负载。这对于访问量和数据量已经规模化的应用系统来说至关重要。

然而对于RDBMS来说，这种假设的目标实现是一件非常痛苦且困难的事情，例如：我们可以在网上搜索到大量关于MySQL分库分表的文章，这类文章的主题都是在对RDBMS进行分布式化的分区操作。

但是这种操作并非数据库天然所支持，必须组建专业的数据工程师团队，耗费大量的时间对数据库进行精密地调节，必须自己去解决分布式集群的诸多问题，例如：容错、复制、分区、一致性、分布式事务等等，其难度可想而知，所以这不是一般技术企业所能承担的巨大维护成本。

随着互联网时代的发展，互联网应用系统面向高并发、海量数据的规模化趋势愈演愈烈，RDBMS对于数据表进行分布式化的瓶颈也越来越明显，这也就促成了NoSQL在互联网等领域快速发展，接下来我们重点看看NoSQL的解决方案。

2. 中心化分布式架构的弊端

2.1 Hadoop分布式文件系统(HDFS)

谈到大数据领域的分布式数据库体系，必然绕不开Hadoop，Hadoop实际上是一个系统生态，基于Hadoop生态的各种分布式数据库都依赖于一个数据底座——HDFS，其实最早Google发明了GFS分布式文件系统之后，进行了论文发表，然后在开源界才产生了Hadoop分布式文件系统(HDFS)。

如下图所示：GFS/HDFS的特点表现在顺序的、成块的、无索引的向文件块中写入数据，并在集群环境中按块(block)均匀分布存储，需要使用时，再通过MapReduce、Spark这些批处理引擎发起并行任务，按块，批次地读取分析。这样就把写入和并行读取的性能发挥到了极致，具备了任何建立索引的数据库都无法比拟的读写速度。

HDFS在对多个数据节点(DataNode)协调写入数据的过程中，一定是由一个中心化的服务进行了全局调度，那就是NameNode节点。

也就是说NameNode节点会是一个单点风险，若出现了故障，整个HDFS分布式文件系统集群就会出现崩溃。

因此HDFS为了NameNode的高可用(HA)，实现了极为复杂的NameNode HA架构。

但是，在同一时刻，只可能有一个NameNode为所有数据的写入提供调度支撑，也就是说从并发负载的角度，NameNode始终会是一个瓶颈。

由于HDFS是整个Hadoop生态的数据底座，那么Hadoop的分布式架构就始终围绕在分布式中心化的路线上前进，然而中心化架构最大的问题就在于无论上层建筑如何变化，传导到数据底座后，HDFS作为中心管理者，一定会在高并发、大规模访问情况下成为瓶颈。

另外从集群节点的伸缩扩展方面也有隐患，问题来自于元数据在NameNode内存中可能会出现溢出。

2.2 大规模结构化的分布式数据库(HBase)

然而HDFS是面向成块的大文件数据，无索引地追加读写，也就不具有数据随机查找能力，另外缺少结构化设计机制，像集合的数据项扫描、统计和分析就无法独立支撑，必须构建上层数据库系统合作来完成，因此就产生了鼎鼎大名的HBase。

如下图所示：我们可以从图中看到HBase的数据底座完全依赖HDFS，也就是说数据如何物理上分布是由HDFS所决定。

HBase实现了全局排序的K-V模型，满足海量数据的存放条件下通过行键定位结果，能达到毫秒级响应的数据库，或者通过主键排序扫描实现了统计分组。

尽管HBase对于大规模结构化数据的写入、排序扫描和聚合分析有着巨大的性能优势，但是HBase的查找设计目标并不是解决二次索引的大范围查找。

我们再看HBase完成数据切分的办法——Region切分，当Region（我们可以理解为数据表）追加数据超出阀值后，就要进行Region拆分，然后拆分出的新Region分布到别的RegionServer中。

这里有两个问题：

1）同一时刻向Region写入新数据的服务器必须是唯一的，那么这里就会出现RegionServer的高并发访问瓶颈。

2）由于分布式架构设计上的约束，使得HBase不具有二级索引，在随机查找过程中，只能根据全局的Region排序进行扫描，这就无法承载Web应用的数据随机查找的实时性。

因此HBase一般会作为大规模数据流形式导入的OLAP系统。

3. 去中心化分布式架构解析

那么到底有没有一种面向海量的结构化数据存储，可以实现大规模Web应用支撑的分布式数据库架构呢？

既能突破RDBMS的数据表在分布式过程中的瓶颈，又能解决Hadoop/HBase在高可用性问题上的隐患，同时还能满足高并发、大规模、大范围的随机查找要求。

答案是有的！

就是那篇改变互联网发展进程的论文《Dynamo: Amazon's Highly Available Key-value Store》，这篇论文源自于Amazon，对于自家数据库的架构设计的经验总结。

鼎鼎大名的分布式开源数据库Cassandra在分布式设计方面也完全继承了这篇论文的设计思想，只不过在数据模型方面又借鉴了Google BigTable的数据模型。

Cassandra分布式核心思想就是去中心化，形成了分布式系统世界的独特一面。

我们重点就是去解析这种去中心化的分布式架构的一些核心技术，到底有多么厉害，为什么可以解决我们前面所述的三个问题：

• 支撑大规模的结构化数据
• 解决数据表的分布式读写存放
• 满足高并发、大规模、大范围的随机查找。

3.1 什么是去中心化？

去中心化不同于中心化的核心特质在于任一服务实例在集群网络中都是以级别对等、点对点的形式存在，这就不存在服务节点在集群中的等级划分，也就是说，任何一个Cassandra服务节点，从维护者的角度都是一样的角色，那么这就极大降低了维护者运维的复杂性。

例如：我们对于Cassandra数据库的所有节点都可以称之为数据节点，集群中承担了相同的角色。

但是HBase/HDFS就不一样了，HDFS集群分为：NameNode、DataNode、JournalNode、ZKFC、Zookeeper等承担了集群的不同角色；HBase集群又分为：HMaster、HRegionServer、Zookeeper等承担了集群的不同角色。

从维护者的角度，肯定是集群角色统一的情况下更易于维护。

去中心化的另外一个特点就是高可用性非常好，伸缩性也很好，集群扩展几乎是无限制的。

对于没有一个中心节点进行调度的情况下，又能保证如此优异的高可用性、伸缩性，那么它是怎么做到的呢？

从原理上Cassandra主要表现为四个方面的特征：

• 利用一致性哈希环机制实现数据的分区分布和扩容缩容的数据迁移。
• 利用gossip协议在对等节点的网络传播下保持集群状态一致性。
• 利用anti-entropy(反熵)机制实现数据读取过程中节点之间的比对，保证数据一致性。
• 基于hinted handoff机制，按照最终一致性的模式，可以极大提升集群可用性。

以上这些特征都是集群中网络节点在对等条件下，基于共识机制，而非管理调度所形成的状态协同。

在这种机制之下，集群就具有的非常优异的高可用性以及伸缩性，也就是说，对于整个集群来讲，无论是扩容增加了很多网络节点，还是突然故障减少了很多网络节点，网络节点间的关系都是弱关联，也就难以对其它节点形成健康影响，对于用户几乎是无感知的。

从去中心化的特点，我们再对比一下HBase以及所依赖的Hadoop HDFS，这种基于中心化的集中式调度管理，HBase就存在HMaster的集群单点故障风险，因此一般HBase的HMaster可以有一个或多个HA热备，尽管引入HA后的HBase集群依然很健壮，只是必然引入更高的部署复杂度，底层依赖的HDFS NameNode HA在服务部署复杂性方面则更甚之。

而增加分布式系统的复杂性只会带来更复杂和不确定的运维问题。

3.2 分区机制

Cassandra在实现去中心化架构的过程中，关键应用目标就是在结构化数据的大规模写入能力的基础之上，还能支撑大范围的海量数据的随机查找，这点就完全区别于HBase了，事实上HBase是对于OLAP业务场景的支撑上做到了一种分布式极致的表现。

但是Cassandra则完全进入到了另一种状态，那就是对于大规模的OLTP业务实现了强力支撑，可以在毫秒级、秒级、亚秒级的范围承诺读、写以及分布式事务的SLA(服务级别协议)。

一致性Hash环

如下图所示：Cassandra的分布是基于一致性哈希所形成的环状结构。

每个节点就好像分布在一个环形上。每个节点都是对等的，在读写过程中，每个节点面对客户端都是协调节点，并与其他所有节点直接形成单跳，这也是Amazon Dynamo论文中关键的分布式架构设计。

从上图中我们可以看到12个节点分布在Data Center1，Data Center2两个数据中心的四个机架（Rack）上，并通过DynamoDB集群的一致性哈希环联系在了一个分布式数据库中。

上图是数据写入过程的示例，首个副本定位在节点1（DC1，Rack1）上，然后第二个副本就会继续顺着环寻找，并定位在节点2（DC2，Rack1）上，最后第三个副本就需要在DC1中优先寻找到Rack2的节点位置，正好定位在节点3（DC1，Rack2）上。 通过环顺时针寻找定位，三个副本在DC1、DC2中分别存放，在DC1的Rack1、Rack2上交替存放。

通过使用这种跨数据中心（DC）的副本配置机制，使集群具有了更强的容灾能力，对大型应用平台的支撑也更具均衡负载和高可用优势；同一个DC的数据副本会在不同Rack节点上交替存放，以便巩固数据在集群分布的安全性。

那么进行了这种Hash分区之后，从均衡负载的角度将又带来哪些优势呢？我们接着看。

均衡负载案例

如下图所示：这是一个互联网医疗平台的应用场景。

我们应用了Cassandra，对表进行了复合主键设计，Group为Hash分区键，id为排序键。

由于我们在Cassandra中存储了很多家医院的大量医生与患者之间的诊疗数据，传统RDBMS诊疗表会存在单点写入，无法进行均衡负载的瓶颈。

但是Cassandra的这种Hash分区则不同，我们可以将诊疗数据分区到3台不同的数据节点上进行读写，其中设置访问量最大的1家三甲医院的Hash分区键为Group1，5家市级医院的访问量足以对标省级三甲医院，将此5家组成Hash分区键Group2，其他50家县级医院的访问量也形成了足够的访问量，组成Hash分区键Group3。

那么通过Hash分区形式，就可以对所有诊疗数据按照医院分组的形式进行了数据切分，均衡负载到了3台服务器的Cassandra数据节点当中。

其次我们使用诊疗号（id）作为排序键，只要是同一分区的诊疗数据，无论是扫描哪一家医院的诊疗数据，都可以根据id进行排序扫描，基于排序数据也更易于统计分析。

故障转移

如下图所示：在一致性哈希环中我们设置了4个节点，那么哈希范围就被定义为：Node1-Node2，Node2-Node3，Node3-Node4，Node4-Node1。

只要KV数据的主键Hash值落在某个范围内，就会顺时针找到范围尾部的节点落地。可是问题来了，节点2因为故障下线，通过备份机制我们可以将节点2的数据还原回来，但根据一致性哈希算法，只能转移到节点3上，那么节点3就承载了整个集群50%的数据量，这显然就出现数据分布的严重倾斜了。

因此Cassandra在一致性Hash的基础上又增加了虚拟节点，例如：Cassandra的默认分区策略就会创建1024个虚拟节点（Token），将-2^63～2^63-1的范围值进行平均切分，这1024个Token又被平均分配给这4个节点，这就形成了所有节点在一致性哈希环中交替且均匀出现的现象，这样如果再出现上述图中的故障，故障节点2上的副本数据就不会在恢复的时候，全压在节点3上，而是在节点1、3、4上平均地消化掉。

总之

Cassandra使用分区键进行Hash分区实现了数据在不同数据节点中的均衡负载，又通过改进型的一致性Hash算法与结构，使得数据节点无论是扩容还是缩容，都使得集群整体数据的变化迁移很小，而且还优雅地形成了多数据中心的异地容灾机制。

我们在看待Cassandra的核心优势上，就在于去中心化的这种对等节点所形成的大规模数据访问的均衡性，以及伸缩性的低成本维护特性，其实本质上，它们都是非常有利于云厂商形成无服务化的分布式数据库服务。

3.3 一致性

Amazon Dynamo论文的初衷是创建一个最终一致性的分布式数据库系统，但是同样也支持分布式的强一致性。

同样，对于Cassandra的应用，我不建议将强一致性作为主要应用考虑层面，因为强一致性对于网络带宽，客户端请求延时都有较大的资源消耗以及不可预估的问题。

那么什么是分布式的一致性呢？

CAP定理

我们在研究和应用分布式架构的过程中，对于CAP理论是必须作为基础概念去强化理解的。

CAP：一致性(Consistency)，可用性(Availability)和分区容错性(Partition Tolerance)。

我可以这样去理解CAP：对于集群系统，网络分区无法访问的现象在将来是必然会发生的，当发生故障的时间里，正好要进行着一个分布式业务，例如多副本复制，就一定会出现不同节点的数据不一致。

那么我们为了保证分区容错性，我们只能有两种选择：

第一种情况就是等待故障的节点分区恢复，否则就不给客户端反馈，证明我们保证了强一致性。

第二种情况就是不等故障节点分区恢复了，先返回客户端当前已经写入完成的消息，等故障节点恢复后，再自行恢复数据，证明我们保证了高可用性。

因此当分区需要容错的情况下，我们只有CP或者AP两种选项。

对于高可用性系统，我们重点保证AP；对于强一致性系统，我们重点保证CP(HBase就是强一致性设计)。

一致性方法对比

我们前面说了，Cassandra主要满足最终一致性，也就是说当数据写完一个节点或复制不超过集群副本数量一半，写入成功的结果就可以反馈客户端，因此，复制未全部完成的期间，很可能其他节点或另一半的节点还在为另一个客户端的读取提供过期的数据。

其实Cassandra还有一种叫QUORUM级别的一致性，只有超过一半的节点写入成功后才反馈客户端成功，同样读取的时候也必须超过一半的节点一致才返回读取结果，那么读写一旦产生交集，客户端始终读取到的数据是写入成功的数据，其实这种模式是在最终一致性和强一致性之间最佳的一种平衡。

如下图所示：

上图第一种情况就是Cassandra的QUORUM级别，读取副本时，必须读取3个节点，如果3个节点是不一致的，它必须等待最后一个旧的节点被复制成功，3个节点才会一致，才能返回结果。

上图第二种情况就是典型的最终一致性了，这是个写入不到一半节点就返回成功的案例，当第一个客户端写入节点成功返回后，在没有复制到另一半节点的情况下，第二个客户端可能读取到数据依然是两外2个节点的过期数据。

总之

最终一致性必然带来了更少的网络资源消耗，也降低了网络分区出错的不可预估性，提升了集群的高可用性。但是可能会读取过期的数据。

那么什么样的应用场景会适合最终一致性呢？其实最常见的一个场景就是：购物车！

购物车可能在很小的几率情况下，读取到自己过期的数据，但是并不影响用户的最终使用体验，因为购物车并不是电商流程的终点，但一定是最频繁操作的业务之一，而最终只有订单确定了才算数。

同样像：社交网络、游戏、自媒体、物联网都是这种情况，这种规模化的联机数据业务，并不一定非得要保证读写的强一致性，一旦出现读写不一致，也许再访问一次，数据就是正确了，但是集群保证了在大规模访问场景下快速地响应客户，在这一点上，具有RDBMS无法比拟的天然优势。

4. 最后

分布式去中心化架构思想不仅应用于海量规模的结构化数据的分布式数据库系统，其实在其他领域也有应用。

例如：作为内存字典的Redis也具有Redis Cluster这种去中心化的分布式架构，Redis Cluster的主要价值也是为了更好的负载高并发的业务，例如：秒杀、抢单，完全可以先在Redis Cluster中完成，再同步到RDBMS当中。

但是无论是Redis Cluster，还是Cassandra，作为去中心化的分布式架构，都离不开为了维护集群节点对等的状态一致性，使用了类似病毒传播的Gossip协议，从一定程度，会给集群网络带来比较大的状态传播压力，另外基于共识的协议，如果集群网络节点出现步调不一致故障，对于运维人员的排查判断也会造成诸多不便。

作为云技术厂商对于去中心化的集群状态维护能力是远远大于普通企业团队或个人的，因此对于去中心化的集群架构，我更建议两种应用场景：

1）对于普通小团队的小型项目，进行小规模集群应用，可以考虑部署Cassandra集群，维护非常方便，也能快速支撑起一些海量数据查询业务，例如：很多政府类型与科研类型的项目。

2）对于具有一定数据规模量，且访问并发量较大的中大型的互联网项目，可以考虑直接上云，使用云厂商提供的Cassandra服务，因为集群中的节点数量较多的情况下，故障率会同步提升，但自主运维并不是一件容易的事情。

无论你会怎么选，作为分布式去中心化架构下的数据库，为我们在互联网应用业务的规模化发展支撑上，提供了一种很不错的选择。

---

本文原创，转载文章，务必联系作者！

 

 

 

分布式架构是数据中心的未来吗？

【摘要】本文分析了传统集中式数据中心和分布式架构数据中心的主要区别，探索了未来数据中心架构发展的趋势。

【作者】刘东，目前在东软集团股份有限公司担任首席技术顾问，主要负责数据中心IT系统架构设计，云计算中心IAAS层架构设计，容灾解决方案体系建设；具有10年以上技术支持和系统集成工作经验，对金融、医疗、能源和政府等行业的解决方案有独特的见解。

一、什么是数据中心？

什么是数据中心？百度百科给出定义是：数据中心是全球协作的特定设备网络，用来在因特网络基础设施上传递、加速、展示、计算、存储数据信息。数据中心大部分电子元件都是由低直流电源驱动运行的。

数据中心的产生致使人们的认识从定量、结构的世界进入到不确定和非结构的世界中，它将和交通、网络通讯一样逐渐成为现代社会基础设施的一部分，进而对很多产业都产生了积极影响。不过数据中心的发展不能仅凭经验，还要真正的结合实践，促使数据中心发挥真正的价值作用，促使社会的快速变革。

二、为什么需要分布式数据中心？

说到发展，数据中心正随着各个行业的蓬勃发展而不断高速的建设着。云计算、大数据和物联网等新技术的大规模使用，让数据中心成为了医疗、政府、互联网和金融等行业建设的重点。特别是在银行 、保险等领域，数据中心由于承载核心业务，不允许任何数据中断、要求能够快速响应业务变化和具备一定的灵活性，已经成为了名副其实的“生产中心”。反观数据中心，传统的集中式架构已经无法满足新时代业务的需求。而基于分布式架构的数据中心是一个和集中式架构相对应的技术体系，包括了分布式业务部署、分布式计算、存储、网络安全等多种分布式技术的集合。在传统数据中心无法保证业务响应能力、连续性和灵活性，发展达到一定瓶颈的时候，分布式架构就自然成为了一种必然的选择。

在早期的数据中心建设中，大多数IT建设者们并不太关注采用何种技术架构，觉得没有那么重要。数据中心的建设重点就是让承载的业务系统稳定运行，为服务器、存储和网络设备提供一个良好的运行环境，让业务系统没那么容易“宕机”即可。所以早期大部分数据中心都是烟囱式的架构设计，每个业务系统都会配置一套独立硬件设备，数据完全是割裂的，导致设备利用率非常低，资源完全无法共享。典型的“标配”方案为两台高端小型机（或X86服务器）做数据库服务器双机，然后再加两台或以上应用服务器，后端连接两台FC交换机（或IPSAN交换机）和一台存储设备。直到现在，仍然可以看到许多招标文件中有类似的配置方案。当然，并不能说明这种配置方案不好或者不对，只能说在没有很好规划和合理利用的情况下，这样的配置会导致数据中心空间、能耗、制冷大规模增加，而且设备数量的随意增加还会严重影响运维和管理的效率。

为了应对信息化的快速发展，提高设备利用率和灵活性，云计算技术被大规模推广和采用。云计算可以提供可用的、便捷的、按需的资源提供，逐渐成为了主流的数据中心架构，目前大多数行业的数据中心都已经具备了云计算的能力。除了大规模数据库等少数业务场景以外，新业务应用基本都是使用云模式进行构建，同时还有大量现有的业务应用正不断向云计算环境进行迁移。将应用系统运行在虚拟化环境中似乎已经成为了一种常态。在云计算环境中，服务器虚拟化是基本的云计算技术之一。虚拟化软件厂商正在逐步将基于物理资源的数据中心向虚拟化资源的数据中心进行转变，有效的控制了数据中心内服务器数量和规模的增长，提高了服务器的利用效率。同时，虚拟化系统所具备的特性极大的提高了数据中心系统的可靠性。特别在主动运维、灾备建设和故障切换等方面对数据中心的业务连续性是一种质的飞跃。在这一阶段，虚拟化技术的大规模应用让传统数据中心在不改变集中式的架构条件下，获得了最大化的资源整合和共享，但是架构仍然没有太大的变化，更多的是一种服务模式的转变。

基于云计算架构的数据中心建设已经成为主流的建设模式，但是在架构上还有很多可以改进的地方。

1、基于云计算架构的数据中心只能解决单个数据中心内部的资源共享和使用等问题，无法解决资源的灵活扩展问题，资源的增加仍然是采用垂直架构。由于单个计算、存储或者网络设备都有性能上限，扩展到一定能力后必然要进行拆分，重新建设资源池，又会形成新的资源孤岛，并没有从根本上解决数据中心的发展问题。

2、随着各个行业的信息化发展，越来越多的企业需要建设多个不同地域的数据中心。比如银行业和保险业会按照银监会和保监会的要求建设灾备中心，集团企业会建设分公司分数据中心。这些数据中心如何进行统一的管理和应用，保证业务的连续性，解决业务协同问题，是对传统数据中心一个巨大的挑战。

基于云计算的数据中心提供更多的是一种服务。通常情况下，我们提到云计算，指的是一种计算、存储、软件等服务的交互和使用模式。而基于分布式架构的数据中心，更多的是指一种数据中心的计算模式，而不是一种服务形式，它是云计算数据中心的技术基础和扩充。

三、集中和分布式架构两种数据中心的区别

分布式架构数据中心在技术层次上，主要包括两个概念：单个数据中心内的分布式架构和多个数据中心的分布式架构。

单个数据中心内的分布式架构，主要包括分布式计算、存储、安全网络等多种分布式技术的合集。多个数据中心的分布式架构主要是指将传统多个数据中心统一整合为一个数据中心。实现业务连续性灾备，多中心运营和管理等。例如：将多个不同地区，不同规模的数据中心使用统一的管理平台进行资源的统一管理，使用统一的运营平台实现统一运行。

3.1 分布式计算架构

按照分布式计算的定义是利用网络把成千上万台计算机连接起来，组成一台虚拟的超级计算机，完成单台计算机无法完成的超大规模的问题求解。

而数据中心的分布式计算更多的是指分布式软件架构。是以分布式计算技术为基础，用于解决大规模问题的软件架构。分布式软件架构具有较好的伸缩性，特别在处理大数据问题时，分布式架构能显著提高处理速度。常见的分布式软件架构有分布式操作系统、文件系统和数据库等等。

以数据库为例，传统数据中心是单个数据库为主，数据集中存储在一台服务器或存储上，数据的处理也集中在单个或多个集群节点（一般为2-8个）内完成。传统数据中心数据库以Oracle、Db2或者MySql为主，但是当单表数据量爆炸或者单个数据库无法承受高强度I/O时，集中式的架构是无法解决性能和数据处理瓶颈问题的。最早以前淘宝网就是使用的Oracle数据库，而且还组建了全球最大的Oracle数据库群集，可是随着淘宝网的用户和商品信息量增加，最后不得不走分布式数据库的路线。分布式架构的数据库具有灵活的体系结构 ，更适合分布式的管理与控制， 而且可扩展性好，也易于扩充。 当然，分布式数据库也有自身的一些缺点，例如数据一致性差，网络通信开销较大，数据的存取结构比较复杂。但是不可否认，在某些应用场景下，没有分布式架构的数据库，数据就很难进行管理和建设。

3.2 分布式存储架构

随着数据中心业务数据的不断增加，大数据的海量数据挖掘与日志分析正逐渐成为一个主要应用场景。在面对极具弹性的存储需求和性能要求下，传统数据中心单机或者独立的SAN存储设备基本无法满足大数据处理的需要。如同数据库系统一样，独立的存储设备在性能和数据存储容量等方面都面临着一定的瓶颈。

传统数据中心通常为集中式存储架构，单台SAN或IPSAN存储设备通常配置2-8个控制器，通过存储扩展柜进行容量扩展。如果增加性能，需要增加控制器和缓存，甚至需要更换存储设备型号为高端存储。按照集中式的存储架构，单台存储的性能和扩展能力是有限的，一般达不到线性扩展。随着存储容量的增加，存储的性能会先增加然后达到一定瓶颈后逐渐降低。因为一开始大量的磁盘增加会提升存储整体读写性能，但是当磁盘性能达到控制器的性能后会严重影响控制器对数据的处理和运行，性能会逐渐下降。

面对海量PB级数据，如果使用传统独立SAN存储设备，要么扩展能力达不到，要么扩展能力可以达到海量PB级别，但是容量和性能不会线性增长，而且以后存储扩容和运维成本也非常高。

面对数据中心越来越多的大数据业务增长需求，首先要能存得下大量数据。传统的存储系统容量是有限的，又无法跨越多个存储设备，即使利用虚拟化技术做存储资源整合，那么单位存储成本也会非常高，而且数据处理性能有限。

以Hadoop为例，这是一款比较成熟而且应用比较多的大数据处理的分布式开源软件。其最底部是HDFS分布式存储。HDFS的设计本质就是为了大量的数据能够分布式存储而存在的。HDFS可以将数据存放在很多不同的机器上。而用户不必关心具体的数据在哪，HDFS会管理这些数据。HDFS是一个高度容错的分布式存储系统。可以分布式部署，以流式访问模式访问应用程序的数据，可以大大提高整个系统的数据吞吐量，非常合适用于具有超大数据集的应用中，而且随着整个分布式存储系统的扩展，容量和性能会成正比进行线性增长，非常适合大数据类的业务处理和应用。

基于分布式架构的数据库和存储都是未来数据中心必不可少的发展方向之一，没有分布式架构，数据中心就没有能力管理大数据。

3.3 分布式安全网络

基于云计算技术数据中心为应用部署带来了灵活性和资源弹性配置，提高了硬件资源利用率，缩短了部署时间，但是同时也引入了新的安全问题。

传统数据中心网络安全是基于安全域、安全边界的防护机制，是一套纵向安全策略，只关注业务流量的访问控制，将流量安全控制作为唯一的规划考虑因素。

而虚拟化技术的大量使用使得网络边界模糊化，主要依赖横向安全策略，能够满足安全流量动态迁移到其它物理服务器。传统基于已经难以满足虚拟化环境下的应用模式，虚拟化的服务提供模式，使得对使用者身份、权限和行为的鉴别、控制与审计变得更加困难。这会导致许多基于传统数据中心的安全防护手段失效。

在云计算数据中心，多台虚拟机都在一个服务器设备内运行，虚拟机之间通过虚拟化交换机进行连接，通信流量并没有通过外部交换设备，导致传统安全设备对这部分的流量失去监控。目前大多数虚拟化软件厂商没有在虚拟机通信的东西向流量提供高效的检测和隔离方式，如果某台虚拟机出现安全问题，可能会对相关连的资源池产生严重的安全威胁。另外，虚拟机会随时迁移到其他服务器设备上，造成安全域边界的动态化，传统数据中心固定边界的防护手段也会失效。当虚拟机迁移到新服务器设备上，如果新服务器设备没有对应的安全保护策略，就可能对迁移后的虚拟机造成安全威胁。

为解决云计算数据中心存在的安全问题，需要采用分布式的方式部署安全管理软件或系统。通常分布式网络安全产品由集中管理平台+分布式安全管理软件组成。集中管理平台负责安全策略的集中管理，并对安全策略的迁移功能提供支持。同时接收虚拟化安全设备的日志以及统计信息，并分析整个数据中心的安全态势。

安全软件是以分布式的形式部署虚拟机和虚拟化平台上，可以克服传统物理安全设备的局限，更贴近虚拟机的位置，利用引流或者重定向机制，获取所有虚拟机的流量，实现分布式的安全防护。

3.4 分布式云数据中心

传统数据中心为了做到业务高可用，保证业务连续数据，防止数据丢失，通过采用“同城主备/双活数据中心”或者“两地三中心”的架构。但是不管采用哪一种架构方案，都会产生一定的IT资源浪费问题。“主备数据中心”，解决了业务连续性问题，但是平时只启用一个数据中心资源，另外一个做备份。“双活数据中心”，解决了业务高可用问题，但是两个数据中心需要部署和运行同样业务，同样会浪费一个数据中心的资源。“两地三中心”，同时最大程度的兼顾业务和数据安全，但是IT资源浪费最严重。

在分布式云数据中心概念里，多个数据中心不再是主/备或者双活的关系，而是通过云计算技术、广域网二层网络互连（大二层）技术和数据复制技术，将多个数据中心组建成一个分布式的跨中心和地域的“虚拟资源池”。所有业务和数据都可以按需被分配到不同的数据中心，实现比“双活”或者“两地三中心”更优的业务部署方案。

基于分布式架构的云数据中心以往可能受技术限制，难以实现。但是随着各种技术的不断发展，难度已经大大降低，完全可以实现。主要考虑三个问题：业务访问网络，大二层网络和数据同步复制。业务访问网络可以通过全局负载均衡GLSB和智能DNS实现不同区域的本地访问，使用大二层互联网络技术可以解决虚拟机迁移问题。数据同步复制可使用微服务+容器+分布式存储复制技术解决。通过微服务解耦业务，无状态应用使用容器通过大二层网络进行迁移，有状态应用可以跟随虚拟机进行迁移，冷数据尽量集中存储，共享访问，避免过多的数据迁移。

目前已经有可以落地的方案帮助企业实现分布式架构的云数据中心。同时还可以实现数据中心资源利用率的最大化，降低运维和管理成本，更好的保证业务的连续性。

3.5 两种架构的主要区别

通过上述对集中式和分布式架构在资源处理能力、业务支撑能力、安全管理能力、可用性和一致性、运维和管理等多个方面的分析可以看出：

集中式架构在系统复杂度、数据一致性、安全措施实施方便性和运维管理复杂度等方面有一定优势。分布式架构在资源使用成本和扩展能力、业务部署的灵活和系统可用性等方面具有明显优势。而且集中式架构的复杂性可以通过加强管理和设计降低复杂度，安全措施则可以通过增加安全系统和手段加强控制，数据一致性则需要通过先进的分布式系统与大规模运维平台来支持，当然前提是需要牺牲一定的可用性，这也是分布式架构面临的一个挑战，下文我们会进行详细论述。

四、分布式架构建设的挑战

随着数据中心信息系统数量的增加和处理数据量越来越大，分布式架构的优势会越来越明显。但是越是先进的架构所面临的挑战也就越大，由于分布式架构采用多节点设计，这种架构最大的难点是会导致数据一致性和可用性上的挑战，所有的分布式架构设计都绕不开这两个挑战。

在分布式架构中，有一个非常著名的CAP理论（又被称作布鲁尔定理），定义如下：

对于任何一个分布式计算系统，不可能同时满足以下三点：一致性（Consistency)、可用性（Availability）和容忍网络分区（Partitiontolerance）。

一致性通常指数据一致性，即要求所有节点数据保持一致。可用性即要求每个节点在故障时都可以提供服务。容忍网络分区，通常指各个节点之间的网络通信性能。

根据CAP理论，分布式系统只能满足其中两项而不可能满足全部三项。

CP模型：不考虑A（可用性），多个节点之间数据具备强一致性。如果某个节点故障，那么就将这个故障节点丢弃（不考虑A），否则会导致各个节点之间数据同步被无限延长。为了保证数据的一致性，大多数金融行业的分布式关系型数据库采用这一模型，

AP模型：不考虑C（一致性），多个节点之间要求高可用。如果某个节点故障，并与其他节点失去联系，为了保证节点的可用性，会放弃全局数据一致性（不考虑C）。节点访问并使用本地节点数据，各个节点数据会导致不一致。大多数非关系型的数据库采用这一模型，因为不需要高度的数据一致性。

CA模型：不考虑P（容忍网络分区），两个或多个节点之间要求必须具备可用性的同时又要求数据一致。如果某个节点故障，为了同时保证可用性和数据一致性，那么只能对分布式网络进行强制分区，划分成多个不同的分区来保证C和A，会导致分区被割裂。

由以上几个模式可以看出，在分布式计算环境下，P是必须要现实的，否则分布式网络节点通讯就会出现问题，所以只能在C和A之间做出选择，即选择CP模型或者AP模型，实际的选择需要根据自身的业务场景来根据各个不同的模型特点进行取舍。

对于一些离线的应用或者对可用性要求不高的业务，可以采用CP模型。这一类模型相对简单，但是应用场景也有限。例如日志数据分析系统，大部分数据都在本地，我们只需要在分布式架构中配置一定的冗余节点和恢复机制即可。如果某个节点出现故障，分析系统会自动等待其他备用节点恢复后再继续运行，因为短时间停止不会对系统产生太多影响，但是各个节点分析的数据要求必须保持一致性。

在数据中心，核心系统和重要业务系统占比较大，如果采用分布式架构，可能即需要高用性也要求数据一致性，这是分布式架构设计最大的一个挑战。

以金融行业为例，保证业务的连续性和高可用性是非常重要的一个需求，可以采用AP模型进行设计。但是数据一致性也是要尽量保证的，因为金融系统如果数据不一致，会产生严重的数据问题。关于数据一致性，在分布式架构中可以按程度分为强一致性、弱一致性和最终一致性。为了保证金融系统的高可用和业务连续性，数据强一致性很难达到，弱一致性又无法满足要求，做为取舍，可以实现数据的最终一致性。在分布式系统中，数据会被存储在多个节点，各个节点的数据被应用修改后，最终一致性不要求各个节点同时更新数据，只要求尽快将各个节点更新后的数据分布到整个系统中，这样在保证系统可用性的同时会实现数据的最终一致性，保证金融行业对数据要求。当然，并不是所有的金融业务都可以采用最终一致性的方案，例如核心实时交易系统，必要要求实时处理数据并保持强一致性，这也是目前大多数金融机构核心交易系统还在使用集中式架构的原因。

分布式云数据中心在建设过程中同样也面临一些挑战，主要包括网络、存储和计算三个方面：

在网络方面，多个分布式云数据中心之间的通信是个问题。需要考虑多个不同区域的网络访问接入、负载均衡问题。还要满足分散在多个云数据中心之间的业务通信和切换的需要。目前主流的技术方案是以大二层网络技术为主，打通多个数据之间的网络，形成一个统一的逻辑网络。但是目前各个网络设备厂商之间的大二层网络和协议不统一，设备兼容性有一定的问题，这也是分布式云数据中心改造所需要解决的一个问题。

在存储方面，数据实时同步，实现统一的存储资源共享并建立高可靠性的数据保护机制，是一个比较严峻的挑战。多个数据中心可能分散在不同地域，各个数据中心之间的网络带宽有限，可能无法做到数据实时同步，只能采用异步传输。那么数据一致性和完整性可能就等不到保证。上文提到的应用解耦+微服务架构可以解决一部分问题。但是对于传统的无法进行微服务改造的应用仍然是个难题。在数据一致性和可用性上可能需要一些取舍。

在计算方面，目前技术相对成熟。将资源云化以后，利用云计算技术可以实现对计算资源在多个云数据中心的统一调度和管理。还可以设定权限，进行精细化管理。在计算方面的一些挑战，通常指对计算资源的管理。例如在某一个应用出现故障时，是将这个资源在本地进行重建还是在其他云数据中心进行迁移和重启，因为这会影响到各个节点的其他业务访问，需要提前进行统一的规划和安排。

五、结束语

相对于传统数据中心，构建分布式架构的云数据中心是非常有必要的，它影响着数据中心建设的方方面面。在未来，没有分布式架构的数据中心一定不会是一个优秀的数据中心。通过云计算技术的不断发展与实践，我相信分布式架构一定会成为数据中心的未来发展方向。即使未来数据中心的架构不是完全分布式的，但是分布式架构也绝对不会缺席，一定会有分布式架构的一席之地。

点击文末阅读原文，可到社区原文下提问交流

觉得本文有用，请转发或点击“在看”，让更多同行看到

 资料/文章推荐：

• 数字化浪潮下的架构融合浅谈—分布式与集中式、微服务与巨石，对峙是偏狭，融合是趋势！

  http://www.talkwithtrend.com/Article/240709

欢迎关注社区 “分布式架构”技术主题 ，将会不断更新优质资料、文章，您也可以前往提出疑难问题，与同行切磋交流。

下载 twt 社区客户端 APP