分布式系统改造需要考虑的 （二）分布式系统改造些什么

前一篇文章介绍了分布式系统和集中式系统的设计理念和优势分析，这篇文章我们来看一下分布式改造都要具体做些什么事情。

下图可以简单概括从集中式到分布式架构的演变过程：

1） 一个客户业务系统最简单的部署方式就是应用和数据库共同部署在一台设备上，这样的方式适用于小型业务，运维也方便。随着 数据库及文件的数据量越来越多，由于服务器的容量是有限的，原有系统架构已经不足以支撑，此时需要应用、数据库、文件存储服务拆分出来作为独立的服务，以此来避免存储瓶颈。

2） 随着数据库访问压力的增大，主数据库和只读数据库的读写分离成为了必然，应用服务器也从单台变为了多台集群，这样可以避免单机的瓶颈，同时可以做到更好的高可用，通过前端的负载均衡服务分发访问的请求到不同的应用服务器上。

3） 当请求并发量达到一定级别，而 Web 服务器不足以支撑应用的时候，此时我们会考虑引入缓存及集群，以改善系统的整体性能，把大量用户的读请求引导至缓存中，而写操作仍然直接写到数据库 DB 中。这点性能上的优化，可以将数据库的一部分数据或者系统经常需要访问的热点数据放入缓存中，减少数据库的访问压力，提高用户并发请求性能。

4） 引入分布式数据库和分布式文件系统，以满足超大容量数据的存储和高效访问需求。同时解决多副本数据保护的问题，线性容量扩展的问题，性能问题等单体数据存储难以解决的核心问题。

5） 有了硬件架构分布式改造，应用架构改造需要客户更大的决心和投入（如下图）。一方面在应用的微服务化逻辑下，对以前较重的业务进行微服务改造，微服务间用完善的通信和消息机制保障业务完整性。另一方面，数据的分库分表能够带来更高效的数据访问和更好的数据管理能力。

从近些年金融类客户的改造历程来看，有如下的趋势可供借鉴：

一、始于 2016 年前后，对于众多金融案例来看， IT 架构的分布式改造并不是摒弃集中式架构，而是在精简和优化集中式架构，将部分系统从集中式向分布式转变，构建多平台、多技术融合的架构。安全和发展是两个永恒的主题，在坚持和巩固中不断完善发展这两方面，形成传统技术与前沿金融科技融合的“双模”架构。

二、选取的分布式改造系统为对实效性不敏感且资源消耗较高的非金融服务，如互联网金融、反欺诈、普惠金融，风险管理，中间业务系统等。

三、双模架构，明确集中式核心和分布式核心处于平等地位，优势互补，并不是替代的关系。实施后在企业总线（ ESB ）上为分布式业务新开连接链路，并在很长的一段时间内，下移的应用具有同时路由到集中式核心和分布式核心的能力，分布式核心要定时向 ESB 汇报心跳状态，异常时能做到迅速切换。

四、在业务微服务的粒度划分上以及数据库分库分表上花了很大的精力和研讨，同时需要根据自有业务的应用逻辑开发数据访问引擎，以屏蔽数据布局的变化对上层应用的影响。