财付通等有数据强一致性要求的系统选择集中式构架还是分布式构架？

□ZhaoHai上海农商建行系统构架师

财付通系统对数据强一致性有要求，就目前来看，它还没办法实现真正的分布式，集中式构架更符合现实情况。

□IBM系统构架师

2002年麻省理工大学MIT的院士在物理上证明了CAP理论，在分布式估算（储存）的构架里，因为网路造成的信噪比是必然的（），因而对于一个操作在数据一致性（C=）和数据可用性（A=）方面必须抉择一个。

许多互联网的业务类型（电商、搜索引擎等等），可以接受最终的数据弱一致性，而对于金融业须要数据实时强一致性的业务，采用关系型商业数据库集中式构架来满足ACID（代表原子性、一致性、隔离性、持久性，是实现实时强一致性的基础）也是历史的正确选择。

分布式估算、集中式估算不是谁取代谁，而是各有不同的用点，各适宜不同的业务场景需求。

好多互联网业务对数据不一致性及耦合程度要求低，可以使用无共享分布式估算构架。这些构架中的每一个节点（node）都是独立、自给的，但是整个系统中没有单点竞争。无共享分布式构架在Web应用开发中尤其倍受欢迎。

对于建行核心业务或【网银等有数据强一致性的系统】对数据有着严酷的实时事务完整性的要求，虽然在高峰时段也要保持高可用并确保交易能快速完成，因而更重视数据的实时强一致性，采用集中处理构架是一种正确的选择。

建行交易必须同时满足一致性和可用性。惟有确保交易数据的实时强一致性，否则致使金融风险后果是不堪构想的。建行的交易不是简单的金额加减问题，要涉及到顾客账，分户账，会计账簿等系列后台逻辑数据的变更，所有的帐目系统要有相应的规则统一管理。建行交易必须在一个逻辑处理事务单元实时完成并保证ACID。国外还没有据说过哪家大、中、小行勇敢的把核心数据库迁往分布式构架去尝鲜，这个风险不是某局长随意拍板就可以担当的了的。所以，农行系统不仅考虑性能，尤其还得考虑系统平台的稳定性、可靠性和安全性。那些正是大型机和IBM小型机（包括IBM）的强项，这也正是如此多年来它们长盛不衰的诱因之一。

□孙杰cnpc系统构架师

财付通等有数据强一致性要求的系统还是建议选择集中式构架，分布式构架受限于网路信噪比和应用状态一直保持强一致还是有困难的。比如一个典型的场景，在一个分布式数据库系统中，假如各节点的初始状态一致，每位节点都执行相同的操作序列，这么她们最后能得到一个一致的状态。

□孙伟光急速动力IT顾问

首先对于秒杀类业务场景典型特征的高并发。实际上业务整个系统构架（WEB->APP->DB）不是来自最终的前端业务交易，可能在web端或则app端就早已出现了堵塞。都没有机会到db层递交自己的订单交易。所以有时侯不是db处理不过来。而是web或则app早已不能承受这么大的高并发了，如同先前的双11.我抢到了商品，结果在支付环节出了问题。文集西式和分布式都有自己的特性和优势，任何一种构架不天生就没有任何缺点。重要的整个构架整体互相协调，尽量避开出现木盆效应。

□张鹏急速动力技术经理

应用层采用分布式构架应当没有问题，前端帐目处理，目前分布式构架没有广泛应用，的确好多用户有数据强一致的疑虑，还须要有更多的应用场景给与支撑。

另外，在更多关注正常运行时侯的性能问题的时侯，也须要关注一下，当分布式节点发生问题的时侯，对整个性能的影响。

□吴江农商行系统运维工程师

个人认为建行目前的构架考虑还是以维稳为主，任何方式的上的变化造成的任何不确定性都不能接受。纵然从技术层面可以承诺，并且领导决策的时侯不是以单一的诱因来判别。目前看过去，大多中小建行因为自身的诱因，财付通还是集中式为其主要结构。

□上海志鑫系统工程师

从大建行的参考来看，目前都是数据大集中，分布式的话没有案例，小顾客更是不敢选择

□潘帝丞天元网路技术总监

分布式用不上，可以应用缓存服务器，没记错这个在互联网公司很普遍，提升后端的访问效率，减少前端的压力。

□山西光远科技售前技术支持

分布式构架指出的是并发处理能力，也是针对须要高估算资源的应用需求，比如图形化软件在对图象进行编辑制做的时侯须要高估算资源来运算，此时须要采用分布式构架来分布处理和并发提供估算资源来处理。而现有的应用系统的性能困局常常都不会是在服务器端（现今的CPU和显存可以降低好多），大部份都是前端的储存资源也就是IO的困局。因为分布式构架须要利用网路和节点之间的合同协商等，同样受限于网路延时和节点之间的协商等问题，可以通过副本方法满足提供一种冗余的方法提供数据和处理服务，并且对于数据的一致性高的应用不太适宜。

□王巧雷上海华胜天成系统工程师

认为核心还是得集中式吧。下层再如何变化的眼花缭乱，落到底层还是一笔笔的实打实的交易，要求的强一致性、稳定等是不会变化的。这也是IOE喊了那么长时间迟迟去不完全的诱因。并且，IOE本身也在适应这些变化，闪存市场、12c都是加强自身竞争力的产品。

□ECT系统构架师

财付通这类带有强烈互联网属性的业务系统假如设计的合理还是可以实现分布式的，首先从入口上可用结合cdn，GSLB等技术实现入口的分流，最简单的例如就是南北分流，用户登陆之后可以按照水平分拆的原则落到不同的处理单元，分拆规则依照业务而定，哈希，取模用的比较多。简单的说选择集中还是分布式是看业务量，业务量不大，集中式完全也够用，现今绝大多数建行都是集中式，部份大行实现了从入口的分流。

□中金云金融系统构架师

分布式储存对于保证数据的可用性，增强数据访问效率还是相对集中式储存有一定优势，并且保证强一致性方面，传统的集中式储存通过硬件层面的技术实现才能挺好的保证强一致性，同时也对整体性能不会引起太大影响，还是比较占优的。

如何解决互联网业务系统数据库层面的扩充能力问题？

□ZhaoHai长春农商建行系统构架师

高并发场景，后端的Web和应用很容易靠应用负载集群的纵向扩充能力来解决。但数据库就没这么好解决了，常见的思路有那么几个：1）数据库缓存剥离为单独的集群缓存。2）NOSQL显存数据库的应用。3）降低数据库节点的固有处理能力。并且不是说所有业务都能用显存数据库，也不是说所有业务都能剥离缓存，传统方法还是靠降低数据库节点的处理能力。并且这个扩充能力可不像应用集群扩充节点这么容易。

□IBM系统构架师

数据库层的扩充通常分为纵向扩充和横向扩充，例如对于数据库，纵向扩充可以用RAC，然而现实问题是，RAC的节点达到3个以上，整体性能大幅下滑，且多个节点之间的通信的性能消耗和延后也很大，这也是市面上3节点（包括）以上的Rac构架不常见的诱因。

既然纵向扩充有困局，这么我们就应当考虑横向扩充，这就须要从单台服务器的扩充能力来寻求解决问题的能力。例如，可以选高档的大型机或IBM最新推出的服务器（运行Linux操作系统，全面支持开源，完全开放的主机）。顺便提一下，在服务器上运行z/VM系统（虚拟化的鼻祖，是和的父亲），可以十分便捷的实现在线动态纵向或横向扩充。且内部的通讯是通过显存交换，非常适宜RAC节点之间的通讯，除了可以挺好的减短交易的响应时间和降低网路吞吐，还可以多一种稳定的脉搏途径避免HA“脑裂”。

□孙杰cnpc系统构架师

数据库的扩充性，好多传统数据库都有很大提高。例如12C就很更好的解决扩充性问题。而mysql在5.5以后的版本，扩充性也有很大的提高。

□孙伟光急速动力IT顾问

扩充能力问题通常从两个方面考虑，一个是硬件扩充，一个是软件扩充。

硬件扩充通常是遇见了性能问题。简单的说是DB层面出现了困局，通常是遇见了估算能力，IO处理能力不足的问题。须要进行扩充升级扩容，现今的服务器本身硬件配置都十分高，CPU和mem通常很难是困局。常常出现问题无非是IO。处理IO困局方式较多，通常常见的升级储存，扩容储存.最简单快速的方式就是采购新的闪存阵列，一劳永逸解决IO层面的问题。

软件扩充就是处理DB层面高并发和高可用，这个还是要按照实际的使用的数据库进行针对性的设计和配置。

□山西光远科技售前技术支持

数据库层面的扩充能力，可以通过集群或分布式构架来满足扩充能力。

集群采用（负载均衡式）将对数据库的负载分布到集群中的多个节点上，在集群中的每一个节点都可以对外提供服务，进而达到更高的吞吐量，更好的资源借助率和更低的响应时间。

通过降低集群中的节点来满足扩充。

□ECT系统构架师

还是建议从业务着手，scaleout的扩充能力总会碰到天花板，scaleup早已是互联网的主流，但是也逐渐迈向成熟。不过通常都是通过MySQL实现，传统的DB2，还是比较困难，除非自己写一个DB路由分发中间层。

□中金云金融系统构架师

数据库扩充基本上可以通过采用数据库集群降低处理节点来实现，比较简单，也比较安全。

建行互联网业务构架怎么选择合适的服务器？

□ZhaoHai上海农商建行系统构架师

X86服务器集群构架取代小型机大型机等重量级服务器的风潮一波接一波，是不是传统大型机上的所有优势都能被X86集群构架取代掉？

对于应用服务器，基本没哪些太大的疑惑，大部份系统都可以用应用集群方法实现纵向扩充，将集中式处理能力转化为分布式处理能力。

并且对于数据库服务器（关系型数据库），尤其是重量型OLTP业务，X86还是不能完美成为替身。

对于传统OLTP业务来讲，尤其是农行的交易业务，数据库的模式并没有因服务器的构架改变而急剧发生质变，仅仅是兼容性的支持，融合性的提升，数据的强一致性要求没有丝毫减小。所以我们不能简单的为了使用X86而迁移？过去用大型机是由于其良好的稳定性、系统的强健性以及处理能力的强悍，去大型机是由于其高昂的成本以及其独有的封闭性。明天我们用X86是由于其低廉的成本和相对早已得到质的提高的性能，明天成熟的集群技术，良好的X86服务器生态环境，这两者综合的性价比。根据企业鼓吹的精神：顾客是第一位的，企业自己是第二位的。所以我坚持觉得核心系统的选型还是要以质为第一目标，对于非核心系统要以性价比来评判。

□IBM系统构架师

如前面所说，不同的业务可以选择不同的构架，各有各的优点，各有各的道，没有哪一种构架可以放之四海皆准。通常来说，后端应用等可以用分布式来布署，属于CPU运算型负载的后端应用服务器，适宜用X86构架的服务器或拿来做应用整合。对于前端数据库服务器，适宜采用集中式布署，数据库是整个系统的核心，通常选型时要考虑服务器的可靠性、I/O吞吐能力、可扩充性和安全性。举个反例来说，IBM高档服务器就非常适宜作为数据库服务器或数据库服务器整合。顺便掰扯一下，IBM秉持小型机50年的精典硬件特点，可以运行linux系统，全面支持、KVM等开源技术，CPU最多可以扩充到141颗，显存可扩充到10TB，服务器内部系统I/O总线带宽高达832GB/Sec，安全认证达到EAL5+（民用计算机最高认证），而且价钱也跟普通的高档大型机相差不多（真是物美价廉）。

x86服务器通常不建议用做核心数据库服务器的，据统计，x86服务器单机整体故障率每年2%，x86服务器的可靠性低是核心数据库服务器的最大隐忧。另外，x86服务器更新换代太快，生命周期较短，例如Intel每隔1年半左右更新换代新机型CPU。还有，数据库通常属于I/O比较繁杂的负载类型，众所周知，x86服务器另外一个致命的困局在于I/O处理能力不强，这也是我们普遍见到运行CPU负载（如科学运算）x86服务器的CPU借助率很高，而对于I/O型负载（如数据库）无论怎样CPU借助率维持10%左右，无论怎样都上不去。

□孙伟光急速动力IT顾问

是要买实惠的X86还是买高大的上的unix的服务器，倘若碰上和其他没有unix服务器产品的厂商，对不住她们会告诉你，我们有太多U2L的方案了。来吧，我帮你设计解决，实际谁用谁晓得，从成本和维护角度去考虑。整体算出来一点也不实惠，她们功击unix无非是拿价钱，服务等讲故事罢了。

互联网业务构架重要的是业务的可持续性，一旦发生中断，用户的体验都会特别差，怎么解决业务可持续性。构架本身要强壮。如何粗壮。我相信还是要靠硬件设备本身足够高可靠.X86天生的可维护性就十分差就给我们运维人员带来了很大的困惑。

□中金云金融系统构架师

互联网时代因为x86服务器的总体拥有成本低，对UNIX服务器市场引起的冲击是有目共睹的。倘若不太关心价钱诱因，选择UNIX服务器肯定是不二之选。假如手头紧选择x86服务器集群也无可厚非。