一个普通周二下班后，去打羽毛球的路上。。
二废：小废，听说，我们这边又要做系统架构调整了？
小废：是啊，你看看这几年我们都换了多少架构了，单说我们这一个系统，就经历了几轮的演变了，从单体到分布式，到现在的微服务。
大废：那你们有没有想过，为什么要这么去调整呢？
二废：向互联网大厂学习呗。
大废：其实也并不完全是为了向他们学习，实际上，也是为了适应银行业务的发展，适应年轻人喜欢网上购物、贷款的消费习惯。
二废：也是，只有不断适应客户的消费习惯，逐渐引导客户合理消费，才能留住客户，保住我们三的饭碗。大废，你还记得我们最开始的系统架构嘛？
大废：那当然，刚开始工作的时候，我们XX板块实时业务量也不多，所做业务也很单一，系统只要能保证运行稳定就好，基本上都是靠夜间批量来完成业务。
大废：当时审批系统架构还是单体垂直架构，系统部署机器大概是4核8G的配置，然后中间件是WebLogic，同时数据库是采用Oracle，数据库服务器配置是16核32G。
二废：那时候用户访问系统的实时请求也并不多，大概每秒最多在10笔左右，同时，用户对数据库访问基本上也是查询居多，一个请求同一时间，假设是三四次数据库访问，每秒也就40多次请求，多于单体架构及这样的配置，是完全够用的。
大废：对的，当时数据库操作主要集中在夜间的一些批量，然后能保证顺序执行，其实是没必要做架构调整的。但随着互联网金融的冲击，行里也逐渐接入互联网贷款，然后业务量也有了一些变化。
小废：对的，这点我是深有感触的，当时为了承接某贷业务，系统增加了负载均衡。当时，通过分析，发现系统瓶颈在应用层面，由于贷款审批业务过于耗时，单应用无法扛住大量的业务访问。数据库的配置相对而言要高一些，同时，oracle数据库完全可以扛住几百的访问。因此，最终是在用户访问流量和应用之间增加了Nginx做软负载，通过软负载对应用层面的流量进行了分流。
小废：那段时间，为了保持业务正常接入，不停的会横行扩展单体应用，通过不停部署单体应用、数据库分片*等，终于将业务承接了下来。
二废：但这样而言，压力就都集中在了数据库访问层面。之后，行里为了业务更好的发展，于是就开始系统的第一次大的架构调整。数据库如何扛住过大的业务压力，成了需要解决的燃眉之急。
大废：是呀，当时为了推动去IOE*，将数据库换成了MySQL，采用将业务键值做路由，把业务均衡分散到不同数据库中，避免了单个数据库的并发过高。
大废：对的，当时通过架构的调整，批量任务的耗时都得到了有效的缓解。
总结：
数据库分片：分片是把数据库横向扩展（Scale Out）到多个物理节点上的一种有效的方式，每一个分区包含数据库的某一部分，称为一个片(segment)。其主要目的是为突破单节点数据库服务器的 I/O 能力限制，解决数据库扩展性问题。
去IOE：其中IBM代表硬件以及整体解决方案服务商，Oracle代表数据库，EMC代表数据存储。
题外话：这节有点闲谈的意思，但其实更多的是为了将前面所讲的一些做一个总结和架构的整合。
