专家观点 | 郭涛：银行分布式架构的发展与实践

Posted 2021-04-14 金融IT圈

作者 | 神州信息分布式架构专家 郭涛

来自神州信息FinTech高峰论坛

分布式如何应对互联网所带来的挑战

第一， 面对大并发。

在分布式架构之下，通过服务层的分布式，将业务系统拆分为多个子系统，每个子系统又可以按需部署多份实例，从而实现压力分解。

 

第二， 面对大数据量。

在互联网接入以后，所面临的业务模式不明确，未来数据的增长量也不清楚，必须有一种策略应对数据增长，以及如何去构建系统。分布式架构在这方面解决了大数据的存储问题，即通过数据层的分布式，将数据分布到多个物理节点上，可从容地应对大数据量带来的压力。

 

第三， 面对浪涌现象。

瞬时流量已经超过系统稳定峰值，会给系统带来冲击。这时应该采取什么样的方式来避免这种浪涌现象所带来的系统异常宕机或者故障？综合考虑，采用缓存、流量控制、缓冲队列、延时入账等手段，来应对互联网中的红包或者秒杀业务场景。

 

第四，敏捷灵活方面。

在分布式体系之下，所有系统构建的服务单元尽可能单一独立，采用高内聚、低耦合的设计原则，将一类业务功能聚合在一个业务系统中提供服务。系统的服务规划得非常清晰、合理之后，在应对互联网的需求变化快速迭代的过程中，才能更加灵活，更加敏捷。

分布式带来的贡献

高扩展性

在分布式架构中，只需增加运行节点就可以提升系统的处理能力。可以在应用层横向扩展，也可以在数据层借助数据分片的能力进行伸缩。

 

高性能、高处理能力

借助分布式技术更充分地利用物理资源，提升系统的处理能力，性能也可以线性增长。

 

低成本

在分布式体系之下，以X86 PC Server组集群的方式，即保证系统处理能力又能降低系统建设成本。

 

高可用

在分布式架构下，每个应用都可以部署多份，在整个集群中不存在单点故障。一旦出故障只会影响一个应用。

 

高灵活性

分布式体系下业务的粒度更细，便于灵活的组合及调整。

 

自主可控

分布式架构不会对IOE相关的厂商产品有强烈依赖，也不会绑定某个数据库，对操作系统来说也没有要求。实施策略上能完全满足自主可控的需要。

 

分布式架构的发展过程

先看下第一个架构。从点切入。

 

分布式架构之一（以点切入）

（☝ 点击放大后查看）

首先，在集中式系统架构中，所有业务模块都部署在一个业务系统里，我们需要通过ESB向外注册服务，消费者通过ESB进行服务访问，后台应用通过负载均衡设备保证流量到达多个节点上，这种架构属于分布式系统吗？严格来讲，它是集群部署模式，还不算真正的分布式系统。

 

其次，业务系统和数据库之间，在业务系统增加一个分布式服务框架，例如DUBBO。借助它来实现应用层的横向伸缩能力，算分布式吗？算，它解决的是应用层的横向伸缩。

 

再者，我们在应用和数据库之间增加了一个数据代理，实现了数据分区的能力解决了数据库横向伸缩的问题，这个也算分布式系统架构。以上两种均以点切入的模式，即只在应用某个点，为了解决系统痛点，应用了分布式技术。

 

再看第二个架构，即从点到面的架构，借助分布式技术在多个层面上去解决系统瓶颈或痛点。

共分为四个层面。

第一是服务层分布式，多个应用实例共同承担系统的功能和流量，按需调整实例数量，故障自动隔离/恢复。

第二是数据层分布式，将超大数据量的表水平切分到多个物理库中进行存储，提升其处理能力。

第三是缓存分布式，多个缓存服务器共同承担系统的所有缓存数据，缩短服务的响应时间。

还有一个是日终处理，一般系统在批量作业的时候，数据量特别大，没办法将作业分到多个物理的计算节点上去运行，时间不可控。在分布式架构体系下，可以把大量的数据作业进行切分，然后把切分后的作业分到多个应用计算节点上，让所有的计算节点并行处理来完成日终作业，把日终处理时间控制在一个有效的范围内。

 

如上可以看到分布式思想，已经由某一个点的切入变成了全面的切入。但是，在这个阶段，应用系统与分布式技术组件还是仅仅耦合在一起，是为了解决实际问题而引入分布式技术，所以这是由点到面的发展过程。

 

第三是独立平台。

为了让整个业务系统，都能够全部应用上分布式的特性，需要把相关的技术组件整合到一起抽象为一个平台，以此提供具备分布式特性的功能平台级应用框架，在这个平台之上可以构建多个业务系统。

这些业务系统完全具备了分布式的处理机制和访问能力。与此同时，还有一部分集中式架构的系统存在。那么分布式系统和传统系统之间是如何互相访问呢？可引入了网关的概念，通过它来完成协议层的转换，使得两种异构系统完全可以互相访问。

 

再之后，可以把平台里面的这些分布式组件与平台解耦，解耦的目的是把这些具备分布式处理能力的独立组件，以独立平台的方式进行技术服务输出。这个阶段称为“组件平台化”，就是把组件完全向平台化发展。

分布式架构之四（组件平台化）

（☝ 点击放大后查看）

组件平台化有如下特点：组件以独立平台体现，业务系统可以灵活选择，跟业务系统完全解耦，具备可分可合的部署模式。在这个阶段将组件完全平台化是分布式架构为了进入下一个阶段做准备，那就是架构云化。

 

云化架构

现在经常被提及的技术热点多是云、大数据、AI、区块链。关于云，我们重点看一下PaaS层，它可以细分为APaaS和IPaaS。APaas指的是应用部署和运行平台，我们常提到的PaaS多指APaaS。

平台部署到APaaS后，借助云的能力，业务系统只需要知道应该用APaaS层的哪个平台解决分布式数据访问，使用哪个平台进行数据一致性的保证即可。所以在云的体系下，业务系统其实就是在云上部署SaaS服务系统，与PaaS结合形成了云化分布式部署架构。

 

您已充电70%

继续....

神州信息的产品现状

神州信息Sm@rtGalaxy平台涵概了分布式数、分布式计算四个维度的分布式解决方案。据访问、分布式缓存访问、分布式服务运行。如图：

（☝ 点击放大后查看）

 

平台提供了两种事务一致性的保障方式，一种是DTP，基于服务两阶段的最终一致性分布式事务保证机制；另一种是SCP，在服务层基于服务补偿方式的事务保证机制。平台支持金融行业所有典型业务场景，例如联机业务处理；日间批量业务处理；日终批量业务处理等等。微服务机制借助去中心化的微服务体系来完成的。另外，平台还配备了两个辅助性的平台，一个是开发平台，一个是运维平台。从服务的开发到测试、部署、服务治理、系统监控，全生命周期的服务都可以在这两个平台中进行。

 

神州信息的产品实践

首先，在银行核心系统中的实践。

 

基于Sm@artGalaxy构建的分布式核心系统，采用微服务理念，包含客户中心、业务核心、会计核心、参数工厂等多个微服务系统，这些系统可以独立部署，也可以分开部署。

 

对于客户中心和业务核心，支持以客户号维度进行数据切分，一个客户下的所有账号，都切分到一个物理库里面。通过客户号将数据散列到多个数据分区中。对于会计核心和尾箱流水，通过流水号维度进行数据切分。

 

日终作业处理通过分布式调度将作业分发多个节点并行处理。

 

其次，在互联网领域的实践。

 

在互联网金融方面，我们提供用户中心和账户中心完整的体系，以客户纬度进行数据切分。日终处理也是借助了批处理调度的组件进行批处理。

 

再有，在支付领域的实践。

 

支付系统数据量最大的是支付流水，支付流水在存储的支持按支付流水号维度进行数据切分。三方支付、聚合支付、统一支付、支付网关也是以微服务的方式服务解耦，支持独立部署和集中式部署。

 

最后，独立平台性质的实践。可分有两种方式：一种采用纯平台的方式，还有一种是已经引入了分布式体系之下的业务系统，也可以在分布式平台之上建设一些其他的业务系统。

 

神州信息的产品后续发展

主要体现在两个方面：

 

一是平台需要深度整合微服务体系，完成现在行业里大家都比较关注的微服务框架与平台的整合并做好向下兼容，而且还要借助DevOps形成一个高效的开发体系。

 

二是分布式平台往组件平台化发展，将分布式相关组件与平台解耦，以独立平台的方式提供技术支撑，为后续平台云化奠定基础。

想要原版演讲ppt？

留言处，留下邮箱

下周发你！

---