互联网业务快速发展，银行系统架构师如何应对网银等数据强一致性系统的性能问题？

1. 网银等有数据强一致性要求的系统还是建议选择集中式架构，分布式架构受限于网络时延和应用状态始终保持强一致还是有困难的。例如一个典型的场景，在一个分布式数据库系统中，如果各节点的初始状态一致，每个节点都执行相同的操作序列，那么他们最后能得到一个一致的状态。

2. 怎么解决互联网业务系统数据库层面的扩展能力问题？

数据库的扩展性，很多传统数据库都有很大提升。比如ORACLE 12C就很更好的解决扩展性问题。而MYSQL在5.5之后的版本，扩展性也有很大的提升。

3. 互联网业务架构如何选择合适的服务器？

这个完全看需求，2路 、4路、8路都可以，很多厂商的服务器也都可以定制，依据跑应用还是跑数据库等做不同的定制化会很好，国产的服务器也可很好的满足这方面需求。

应用层采用分布式架构应该没有问题，

后端账务处理，目前分布式架构没有广泛应用，的确很多用户有数据强一致的顾虑，还需要有更多的应用场景给予支撑。

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

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

    分布式架构强调的是并发处理能力，也是针对需要高计算资源的应用需求，例如图形化软件在 对图像进行编辑制作的时候需要高计算资源来运算，此时需要采用分布式架构来分布处理和并发提供计算资源来处理

    而现有的应用系统的性能瓶颈往往都不会是在服务器端（现在的CPU和内存可以增加很多），大部分都是后端的存储资源也就是IO的瓶颈；

    由于分布式架构需要借助网络和节点之间的协议协商等，同样受限于网络延时和节点之间的协商等问题，可以通过副本方式满足提供一种冗余的方式提供数据和处理服务，但是对于数据的一致性高的应用不太适合

    在服务器选型上，我觉得X86服务器架构是趋势，尽管像楼主所说，原有的小型机、大型机等在稳定性、性能等方面可能优于目前的X86架构，但是X86架构也在不断完善和发展，而且现在好多新技术也都是基于X86架构的，同时加之虚拟化、软件定义等新鲜技术血液，都是基于X86架构的，以后随着软件定义和虚拟化的大量部署和应用，X86是基础，相对于封闭的小型机和昂贵的维护和维修成本，X86都有很多的优势

1. 网银等有数据强一致性要求的系统选择集中式架构还是分布式架构？

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

2. 怎么解决互联网业务系统数据库层面的扩展能力问题？

还是建议从业务着手，scale out的扩展能力总会遇到天花板，scale up 已经是互联网的主流，而且也逐步走向成熟。不过一般都是通过MYSQL实现，传统的DB2，ORACLE还是比较困难，除非自己写一个DB路由分发中间层。

3. 互联网业务架构如何选择合适的服务器？

DMZ的前置服务器主要承载交易入口，CPU不用太高，但网络带宽一定要大，网卡需要好一点

后端APP和DB如果采用分布式的，目前主流的2路PC服务器性能足够好了，DB可以考虑加载SSD盘。

1. 网银等有数据强一致性要求的系统选择集中式架构还是分布式架构？

是否采用集中或分布式架构建议根据实际的网络环境，企业地区分布，业务管理需求。

2. 怎么解决互联网业务系统数据库层面的扩展能力问题？

数据库本身可以建集群，如需要数据分析也可以引入大数据分析和展现。

3. 互联网业务架构如何选择合适的服务器？

服务器建议按需选择就可以，推荐用闪存卡，闪盘阵列。

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

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

  通过增加集群中的节点来满足扩展