分布式还是集中式？核心数据管理怎么选？

分布式还是集中式？核心数据管理怎么选？

开篇正如《三国演义》开场诗中所云：天下大势，分久必合，合久必分。分布式还是集中式？自从有了计算机那天开始几乎一直是IT圈里割袍断义话题排行榜前五名。特别是随着近些年云计算技术的飞速发展。分布式架构这场大火更是借着云计算这场东风，乘风而起，大有千秋万代一统江湖的感觉。正所谓，世界上没有尽善尽美之物。IT架构也是一样，任何架构的诞生都有其时代的背景和适用的需求。分布式架构是否就是放之四海皆准的金科玉律呢？我看未必，至少在政府行业核心数据管理这个业务角度看是未必。以下就来让我们分析一下，分布式和集中式的各自优缺点，为小伙伴们的架构选型提供一些建议吧。

政府行业用户对核心数据管理的核心需求是改变了吗？随着我们政府行业从管理型向服务型转变的完成。通过信息化手段来完成的业务在不断增多和变化。经过近些年的发展，如下几大变化趋势越发的明显：

社会管理种类多元化随着时代的进步，业务客户的管理已经越来越精细化。20年前养狗不需要办证，现在可以在手机上办；20年前根本还没有校车的概念，现在对校车安全有着严格的电子化管理。无论是医保的跨地域异地结算，还是免检车辆可以在四S店电子化申请牌照，这些业务细分品类在过去十几年前都是无法想象的，而现在却都早已成为了现实。随着这些管理及服务领域的不断细分，随之带来的是更加立体的管理和更加碎片化的数据渠道。

业务数据立体化随着社会管理业务的增加及数据的整合，业务数据无论从品类方面还是从输入渠道方面都越来越多元，随着带来的是对每一个市民的数据描述越来越立体，越来越具体。但这些主要来自于数据质量的提升。但对于被管理的核心数据量来说并没有出现本质上的爆发式增长。通过上面的分析我们发现，随着业务需求的改变，政府行业用的业务模式已经在发生巨大的改变。业务模式上的巨大改变随之带来的也当然是IT架构方面的巨大改变。从应用架构角度出发，为了应对渠道快速碎片化，业务迭代周期加快等需求。采用微服务，分布式架构有其必然的技术必然性。但是在笔者认为在核心数据管理方面，应对上述业务挑战却并不适合采用传统意义的分布式架构。因为，无论政府用户业务如何如何快速变化与迭代，用户对核心数据管理的本质需求却从未改变。

追根溯源，用户对核心数据管理的本质需求有哪些？1. 黑箱，应用层与数据层的解耦我们想要的是什么？我们真的需要数据库吗？从本质上讲，我们想要的只是一个答案而已。至于计算机是如何进行存储的，以及如何计算出这个答案的，这个真的不是最终用户所关心的，存储和计算方法只是手段，是目前的最佳实践。把所有的数据放在一起管理也好，根据不同的应用或流程分开管理也罢，这些都是人为定义的。如果有一天一台如电影终结者中天网那样的超级电脑出现，那我们还用在这里讨论什么分布式集中式吗？直接所有应用都联他，盘他就好啦。在这方面，一个集中化的数据管理系统给业务架构带来的一个非常明显的好处在于，不管多少业务系统，多少业务渠道，只要本质上针对的是一套数据就可以将这个集中数据服务当做一个黑箱就可以了。哪里不会点哪里，从此妈妈再也不用担心我的学习。任何一个渠道对数据的改变，立刻可以反映到其他渠道上，实时一致性，不需要在后端数据进行同步，用户体验那是特别的好。

2. 容量与效率用户对核心数据管理的本质需求还在于对容量与效率的需求。这里的效率指的是通用的IT资源能够输出多少最终结果。其核心诉求就是管理1万人和管理100万人一个样。1个人操作1条数据和1万操作一条数据效率一个样。在上述方面，针对政府核心数据管理领域，集中式架构对比分布式架构的优势就更加的明显了。在同样计算资源的情况下，影响最终效率的因素主要有如下几个方面：I. 存储效率影响这一点在10年前的影响是非常巨大的，笔者看过太多核心系统因为I/O效率低导致整个IT系统龟速行走。但是随着今年SSD技术的成熟，这方面的影响已经大为改善了，未来随着傲腾技术的逐渐平民化，甚至大有硬盘性能内存话的趋势。甚至可能在未来10年以后内存这个从计算机诞生以来就有的部件也会从我们的视野中逐渐消失的可能。

II. 网络效率影响集中式还是分布式？网络效率的影响无疑是最大的。也是目前分布式架构在并发访问处理集中小数据集方面无解的劣势存在。与业务分析类场景不同，核心应用场景是在有限的小数据集上进行大并发读写操作。经常会出现数个并发同时对一条数据进行操作的情况。在这种情况下，数据锁对运行效率的影响是必然会出现的。集中式架构的锁处理是在内存中完成的，效率肯定非常高。但是分布式架构，特别是随着节点的增多，锁的效率会成指数级下降。这也是为什么目前大节点数量条件下分布式数据库高并发处理小数据集性能瓶颈的核心原因。为了提升性能，分布式数据库架构所能做的只有是通过增加缓存，增加读写分离来解决锁冲突问题。结果为了达到同样的高并发性能指标，需要投入的资源数量增加数倍。而且越是定并发处理能力指标要求高的场景，这个放大效应就越明显。相反，集中式数据库场景在效率上与分布式数据库架构相比就要高上数倍了。可能超过了很多用户的通常认知，以笔者自己厂家的服务器为例，在集中式架构条件下，tpcc指标可以轻轻松松达到1000万以上。试问在这样的一个效率指标下，我们为什么还要劳民伤财地搞一大堆硬件来弄分布式呢？没理由呀？

3. 可靠性与可用性的平衡用户对核心数据管理的第三个本质诉求就是，数据服务不能三天两头总出故障。在这里我们要谈可靠性和可用性两个截然不同的概念。可靠性和可用性是衡量系统稳定性的两个重要指标。这两个指标就像是一个苹果的两面一样，分别从不同角度来衡量系统的稳定性。可靠性主要用于衡量系统出错的概率。主要衡量指标是故障率。这个值越低，表明系统可靠性越高，系统越稳定。可用性主要用于衡量系统正常工作的概率。主要衡量指标是年平均可用时间，或高可用率等等。对于单机系统来说，高可用率 = 1 - 故障率。然而对于一个多机集群来说，高可用率和故障率所描述的却是完全不同的两码事了。例如对于一个具有N台服务器的集群来说，如果每台服务器的故障率为n%。从系统可用率角度上讲，整个系统的高可用率 = 1 – nN。如果N=100（即集群规模有100台服务器），n=1%。及单个系统的可用性为99%。则整个系统的可用性为1- 1 x 10-100 从这个数值上来看，整个系统的可用性几乎可以达到万年可用的程度。但是从系统可靠性角度看的话，整个系统的可靠性 = 100 * 1% = 100%。及表示整个系统无时无刻都存在至少1台服务器宕机的实时。这也就意味着系统管理员需要无时无刻都在进行系统维修。这一点在大规模数据中心的运维中体现的是非常明显的。所以对于分布式架构存在一个可用性可靠性悖论的问题。及为了提高可用性，必须增加系统组件，而增加了系统组件却大大降低了系统的可靠性。当集群数量达到数十台的情况下(实时上，当一套分布式数据库系统包含了缓存服务器节点，生产数据库服务器节点，生产数据库备份服务器节点，生产存储服务器节点，生产存储服务器多副本节点的情况下，集群规模会很轻易的达到这个量级)，这个问题就会变得非常明显。

4. 总体成本最优化这个总体成本用户需要考虑的不仅仅是采购成本，还需要考虑机房占用成本、人员管理成本、空调及电费成本、技术故障造成的业务损失成本、以及运维服务成本，以及应用架构改造成本等多方面因素。通过上面的分析我们可以得出结论，在核心数据管理场景集中式架构总体上优于分布式架构。但是集中式架构有没有缺点呢？当然也是有的。主要的缺点有如下几点：价格比较贵：为了得到更好的纵向扩展能力，一般高端高性能服务器（无论是X86高端还是小型机系列），价格都会较贵。不过话又说回来，难道很多用户不也正是因为这个原因才考虑放弃集中式架构的吗？试问，如果高端纵向扩展设备价格和低端设备一样的话，又有多少用户会因为技术原因而选择分布式架构呢？不过随着服务器等设备国产化的逐步推进，高端设备的价格也正在逐步下降。相信在不久的将来一定会落到一个合理的区间。让用户买的放心，用的安心。处理混合负载能力相对不足：要说集中式架构技术上的缺陷，很重要的一点就是在处理混合负载方面。很多业务为了提升业务数据质量，需要通过多维数据分析为核心数据得到一些额外的数据描述。而一旦当分析负载和业务处理负载同时出现的时候，就会存在资源争用的情况。虽然效率低，但分布式架构毕竟处理资源更多。在同时处理混合负载的时候争用现象不明显。如何解？笔者认为，未来可能会出现集中式架构和分布式架构逐步融合的融合数据架构出现。及总体上是分布式的，但是核心业务处理通过纵向扩展的胖节点完成，分析业务处理通过存储的额外副本+瘦节点进行。或者真的到了那一天，量子计算机出来了，只需一台，所有需求全部搞定。到那时可能连应用的分布式架构也都没有了。又到了分久必合的年代。不过，这一天还真有可能就会到来。核心数据库架构，分布式还是集中式？元芳，你怎么看？

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。