websphere 分布式计算和架构是怎么实现的

Posted 2023-05-01

参考技术A 介绍
分布式计算简单来说，是把一个大计算任务拆分成多个小计算任务分布到若干台机器上去计算，然后再进行结果汇总。 目的在于分析计算海量的数据，从雷达监测的海量历史信号中分析异常信号(外星文明)，淘宝双十一实时计算各地区的消费习惯等。
海量计算最开始的方案是提高单机计算性能，如大型机，后来由于数据的爆发式增长、单机性能却跟不上，才有分布式计算这种妥协方案。 因为计算一旦拆分，问题会变得非常复杂，像一致性、数据完整、通信、容灾、任务调度等问题也都来了。
举个例子，产品要求从数据库中100G的用户购买数据，分析出各地域的消费习惯金额等。 如果没什么时间要求，程序员小明就写个对应的业务处理服务程序，部署到服务器上，让它慢慢跑就是了，小明预计10个小时能处理完。 后面产品嫌太慢，让小明想办法加快到3个小时。
平常开发中类似的需求也很多，总结出来就是，数据量大、单机计算慢。 如果上Hadoop、storm之类成本较高、而且有点大才小用。 当然让老板买更好的服务器配置也是一种办法。
利用分片算法
小明作为一个有追求有理想的程序员，决定用介于单机计算和成熟计算框架的过度解决方案，这样成本和需求都能满足了。 分布式计算的核心在于计算任务拆分，如果数据能以水平拆分的方式，分布到5台机器上，每台机器只计算自身的1/5数据，这样即能在3小时内完成产品需求了。
如上所述，小明需要把这些数据按照一定维度进行划分。 按需求来看以用户ID划分最好，由于用户之间没有状态上的关联，所以也不需要事务性及二次迭代计算。 小明用简单的hash取模对id进行划分。
f(memberid) % 5 = ServerN

这样程序可以分别部署到5台机器上，然后程序按照配置只取对应余数的用户id，计算出结果并入库。 这种方式多机之间毫无关联，不需要进行通信，可以避免很多问题。 机器上的程序本身也不具备分布式的特性，它和单机一样，只计算自身获取到的数据即可，所以如果某台机器上程序崩溃的话，处理方式和单机一样，比如记录下处理进度，下次从当前进度继续进行后续计算。
利用消息队列
使用分片方式相对比较简单，但有如下不足之处。
它不具有负载均衡的能力，如果某台机器配置稍好点，它可能最先计算完，然后空闲等待着。也有可能是某些用户行为数据比较少，导致计算比较快完成。
还有一个弊端就是每台机器上需要手动更改对应的配置， 这样的话多台机器上的程序不是完全一样的，这样可以用远程配置动态修改的办法来解决。
小明这种方式引入了个第三方，消息队列。 小明先用一个单独的程序把用户信息推送到消息队列里去，然后各台机器分别取消费这个队列。 于是就有了3个角色：
推送消息的，简称Master。
消息队列，这里以Rabbitmq为例。
各个处理程序，简称Worker或Slave都行。
虽然仅仅引入了个第三方，但它已经具备了分布式计算的很多特性。
计算任务分发。 Master把需要计算的用户数据，不断的推送消息队列。
程序一致性。 Worker订阅相同的消息队列即可，无需更改程序代码。
任意扩容。 由于程序完全一样，意味着如果想要加快速度，重复部署一份程序到新机器即可。 当然这是理论上的，实际当中会受限于消息队列、数据库存储等。
容灾性。 如果5台中某一台程序挂了也不影响，利用Rabbitmq的消息确认机制，机器崩溃时正在计算的那一条数据会在超时，在其他节点上进行消费处理。
Hadoop简介
Hadoop介绍已经相当多了，这里简述下比如:”Hadoop是一套海量数据计算存储的基础平台架构”，分析下这句话。
其中计算指的是MapReduce，这是做分布式计算用的。
存储指的是HDFS，基于此上层的有HBase、Hive，用来做数据存储用的。
平台，指可以给多个用户使用，比如小明有一计算需求，他只需要按照对应的接口编写业务逻辑即可，然后把程序以包的形式发布到平台上，平台进行分配调度计算等。 而上面小明的分布式计算设计只能给自己使用，如果另外有小华要使用就需要重新写一份，然后单独部署，申请机器等。Hadoop最大的优势之一就在于提供了一套这样的完整解决方案。
下面找了介绍Hadoop的概览图，跟小明的设计做对比下:
图中“大数据计算任务” 对应小明的100G用户数据的计算任务。
”任务划分“ 对应Master和消息队列。
“子任务” 对应Worker的业务逻辑。
”结果合并“ 对应把每个worker的计算结果入库。
“计算结果” 对应入库的用户消费习惯数据。

PS：为了方便描述，把小明设计的分布式计算，叫做小和尚。
MapReduce
由于MapReduce计算输入和输出都是基于HDFS文件，所以大多数公司的做法是把mysql或sqlserver的数据导入到HDFS，计算完后再导出到常规的数据库中，这是MapReduce不够灵活的地方之一。 MapReduce优势在于提供了比较简单的分布式计算编程模型，使开发此类程序变得非常简单，像之前的MPI编程就相当复杂。
狭隘的来讲，MapReduce是把计算任务给规范化了，它可以等同于小和尚中Worker的业务逻辑部分。 MapReduce把业务逻辑给拆分成2个大部分，Map和Reduce，可以先在Map部分把任务计算一半后，扔给Reduce部分继续后面的计算。 当然在Map部分把计算任务全做完也是可以的。 关于Mapreduce实现细节部分不多解释，有兴趣的同学可以查相关资料或看下楼主之前的C#模拟实现的博客【探索C#之微型MapReduce】。
如果把小明产品经理的需求放到Hadoop来做，其处理流程大致如下：
把100G数据导入到HDFS
按照Mapreduce的接口编写处理逻辑，分Map、Reduce两部分。
把程序包提交到Mapreduce平台上，存储在HDFS里。
平台中有个叫Jobtracker进程的角色进行分发任务。 这个类似小和尚的Master负载调度管理。
如果有5台机器进行计算的话，就会提前运行5个叫TaskTracker的slave进程。 这类似小和尚worker的分离版，平台把程序和业务逻辑进行分离了， 简单来说就是在机器上运行个独立进程，它能动态加载、执行jar或dll的业务逻辑代码。
Jobtracker把任务分发到TaskTracker后，TaskTracker把开始动态加载jar包，创建个独立进程执行Map部分，然后把结果写入到HDFS上。
如果有Reduce部分，TaskTracker会创建个独立进程把Map输出的HDFS文件，通过RPC方式远程拉取到本地，拉取成功后，Reduce开始计算后续任务。
Reduce再把结果写入到HDFS中
从HDFS中把结果导出。
这样一看好像是把简单的计算任务给复杂化了，其实如果只有几台计算任务的话，使用Mapreduce确实是杀鸡用牛刀了。 如果有TB、PB级别的数据、跑在成百上千台计算节点上，Mapreduce的优势才会体现出来。 其计算框架图架构如下：

离线计算
通常称Mapreduce及小和尚这种计算为离线计算，因为它对已经持久化的文件数据进行计算，不能实时响应。 还有个原因就是它的处理速度比较慢，它的输入和输出源都是基于HDFS设计，如果数据不是一开始就写入到HDFS上，就会涉及到数据导入导出，这部分相对耗费时间。 而且它的数据流动是基于文件系统的，Map部分输出的数据不是直接传送到Reduce部分，而是先写入HDFS再进行传送。
处理速度慢也是Mapreduce的不足之处，促使了后面实时计算的诞生。
另外个缺点是Mapreduce的计算任务流比较单一，它只有Map、Reduce两部分。 简单的可以只写一部分逻辑来解决，如果想拆分成多个部分，如逻辑A、逻辑B、逻辑C等， 而且一部分计算逻辑依赖上一次计算结果的话，MapReduce处理起来就比较困难了。 像storm框架解决此类问题的方案，也称为流式计算，下一章继续补充。本回答被提问者采纳

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

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

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

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

社会管理/服务渠道碎片化
随着近些年的IT发展，在政府行业，我们明显可以感觉到的一个变化就是。政府用户的信息化系统数量出现了爆发式增长。这一增长一方面是由业务细分带来的。而还有一个重要的方面就是社会管理和社会服务渠道的碎片化所带来的。
什么是渠道碎片化？举个栗子，以前我们想查询一下车辆的违章记录，需要到当地的交警大队排号查询。后来出现了短信订阅查询，后来出现了互联网上的12123网站，现在是通过移动端的手机app就可以实现从违章查询到违章处理申请再到移动端违章罚款缴费支付的全过程。业务还是那个业务，但处理渠道却从原来的一个变成了四个。
社保业务也非常明显，从前的社保缴费记录及社保余额只能在社保大厅查询，现在可以通过微信公众号，手机app等多渠道进行查询。
随着未来5G业务的铺开，可以预见自动驾驶和可穿戴设备必将大行其道。所以围绕着智能汽车和可穿戴设备的业务渠道也必将继续爆发式增长。
另外，之所以将这个管理和服务渠道的爆炸式增长称作碎片化的原因在于，不断这个管理或服务渠道如何增长，其实对应于最终的业务总量的变化其实是很小的。例如，增加了手机app端的药店买药功能并不能带来全社会买药人数和笔数的增加。这也是将这种渠道数量的增长成为碎片化的原因。

业务数据立体化
随着社会管理业务的增加及数据的整合，业务数据无论从品类方面还是从输入渠道方面都越来越多元，随着带来的是对每一个市民的数据描述越来越立体，越来越具体。但这些主要来自于数据质量的提升。但对于被管理的核心数据量来说并没有出现本质上的爆发式增长。
通过上面的分析我们发现，随着业务需求的改变，政府行业用的业务模式已经在发生巨大的改变。业务模式上的巨大改变随之带来的也当然是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高端还是小型机系列），价格都会较贵。不过话又说回来，难道很多用户不也正是因为这个原因才考虑放弃集中式架构的吗？试问，如果高端纵向扩展设备价格和低端设备一样的话，又有多少用户会因为技术原因而选择分布式架构呢？不过随着服务器等设备国产化的逐步推进，高端设备的价格也正在逐步下降。相信在不久的将来一定会落到一个合理的区间。让用户买的放心，用的安心。
处理混合负载能力相对不足：
要说集中式架构技术上的缺陷，很重要的一点就是在处理混合负载方面。很多业务为了提升业务数据质量，需要通过多维数据分析为核心数据得到一些额外的数据描述。而一旦当分析负载和业务处理负载同时出现的时候，就会存在资源争用的情况。虽然效率低，但分布式架构毕竟处理资源更多。在同时处理混合负载的时候争用现象不明显。
如何解？笔者认为，未来可能会出现集中式架构和分布式架构逐步融合的融合数据架构出现。及总体上是分布式的，但是核心业务处理通过纵向扩展的胖节点完成，分析业务处理通过存储的额外副本+瘦节点进行。
或者真的到了那一天，量子计算机出来了，只需一台，所有需求全部搞定。到那时可能连应用的分布式架构也都没有了。又到了分久必合的年代。
不过，这一天还真有可能就会到来。
核心数据库架构，分布式还是集中式？元芳，你怎么看？