资讯详情

系统架构设计——互联网金融架构设计

摘要

据第三方预测，自2016年至2019年以来，中国零售信贷规模保持了20%以上的高复合增长率，2017年中国零售信贷规模达到27万亿9年总规模超过37万亿。近年来互联网金融蓬勃发展，在借贷、保险、股权等领域涌现出一大批互联网与金融场景相结合的创新产品。同时，作为互联网金融的子领域，在国家消费升级战略下，各大平台推出了多项服务，如华北、借贷、小额贷款等。

互联网金融的结构不同于传统的金融体系。互联网金融产品主要包括三个主要方面：

  1. 互联网高并发软件平台
  2. 智能风险控制系统基于大数据场景
  3. 基于高弹性的云计算基础设施建设

在互联网浪潮的背景下，传统银行、金融行业也有着转型的诉求，并在股权、借贷、保险等方面都需要创新。有些是业务从线下转线上，有些是金融零售化转型。随着互联网金融业务的爆发增长，建设一个高并发、高可用、高弹性的互金平台是每个金融从业的IT技术人员面临的挑战。

1、高并发架构面临的挑战

在传统金融领域，结构的特点往往是保守的。除了相对陈旧的技术外，它还需要更高的稳定性、低风险和低维护。

面对互联网业务的快速发展，银行和金融机构往往陷入技术和基础设施建设的泥潭。一方面，在软件平台建设过程中，银行和金融传统系统的高可用性、低风险和低风险特性与互联网产品的高并发性、高性能、高扩展性/高弹性存在一定的冲突。另一方面，在基础设施建设方面，与互联网云计算平台相比，存在自然的先天性缺陷。因此，我们的结构设计需要结合两者的特点，综合考虑，既要考虑传统金融业的特点，又要承载互联网的高并发性和高弹性，这使我们面临巨大的挑战：

  1. 对于架构师来说，早期的技术架构设计和领域规划需要具备传统金融知识和互联网高并发架构的双重能力；
  2. 对于R&D、测试、运维人员来说，系统的复杂性成倍增加。微服务拆分后，系统R&D、测试、运维难度大大增加；
  3. 当出现在线问题时，调查问题和分析错误也变得复杂，需要依靠庞大的监控系统和log分析工具。

如何在构建高并发互联网架构的基础上，兼顾金融业的特点，让金融IT技术从业者面临着巨大的挑战。此外，金融业的高安全性和中国银行业和保险监督管理委员会的监管合规性要求也使高并发性的互联网架构在实施中步履蹒跚。

二、高并发场景下的安全设计

金融业的安全要求是架构设计中不可忽视的问题。一般包括以下四个方面：

1)数据安全:

  • 数据不丢失
  • 数据加密
  • 数据准确性

2)物理安全:

  • 物理机隔离规划
  • 重要的交易服务与普通服务网络隔离

3）网络安全

  • 网络加密
  • 防火墙施工等

4）业务安全

  • 反欺诈
  • 防恶意操作
  • 防篡改交易过程

在互联网金融的高并发场景中，涉及资本安全的问题尤为重要。在并发编程中，服务端通常需要考虑竞争条件。当多个并发线程同时访问相同的资源时，由于请求的处理不是原子，无法预测调度顺序，共享资源的运行可能会因时间顺序上的冲突而混乱。

2.2

通过高并发操作触及程序处理的临界区域，绕过程序的线性执行顺序，使原始逻辑限制失效。经典场景包括：

  1. 超额取款，提现
  2. 重复兑换积分
  3. 多次领取优惠券
  4. 使用相同的优惠券，多次下单等

  1. 在程序处理中使用时序队列
  2. 在更新数据库数据时使用数据库锁(乐观锁)
  3. 分布式锁针对数据库

三、互联网金融合规设计原则

在对互联网金融项目建设时，根据金融行业特性，必须在建设范围进行法律、法规的研讨和设计，确定要关注及合规部门银保监会的监控要求限制。

对于新的业务流程或不确定的业务规则，必须由银行合规和法律部门签字，以确保系统遵循合规条件。

参照法律法规的相关地址：

  1. 中国政府政策网页http://www.gov.cn/zhengce/zhengcewenjianku/index.htm
  2. 中华人民共和国公安部政策https://www.mps.gov.cn/n6557558/index.html
  3. 国家知识产权局法规http://www.sipo.gov.cn/zcfg/index.htm

  4. 中国银行保险监督管理委员会http://www.cbirc.gov.cn/cn/view/pages/index/index.html

四、高并发消费金融架构重点指标的核心设计理念

在构建一个高并发金融架构时，我们往往会考虑很多因素，从系统平台建设的角度来讲，会优先关注以下重点指标的建设：

  1. 高可用
  2. 高并发
  3. 高性能
  4. 高弹性

4.1 互联网金融高可用设计原则

对于互联网金融架构系统来说，涉及到以资金交易为核心的业务领域，最重要的指标是高可用。高可用HA（High Availability）是分布式架构设计中必须考虑的因素之一，它通常的是指，通过设计减少系统不能提供服务的时间。

我们通常会形容高可用如：

  • 不能“挂”
  • 可用性99.99%四个九
  • 一年故障时长0.876小时
  • 平均响应时间<10ms，95线<50ms
  • 全年数据故障不超过5次
  • 全年系统100%可用

保障系统的高可用，有两大架构设计的原则：

  • 多副本设计：

避免单点问题，对各个系统特别是涉及到交易、账务的核心系统进行多副本设计，对数据库进行多库备份和读写分离。如果有了多副本，在某个单点出问题时，副本可以发挥作用。架构设计以“集群化”的方式，保障架构的高可用。

  • 自动故障转移：

在有了多副本的建设的前提下，前面已经说到，互联网金融的架构体系相比传统系统复杂度高，所以在系统出问题时，我们必须引入故障自动转移机制，避免手工和人工的干预，能够高效率的自动化的切换至副本服务或数据库。

  互联网金融的网关的建设，有以下好处：

  1. 对金融安全性方面把关，涉及到数据的加解密工作和身份认证鉴权工作；
  2. 对流量进行管控和切换，保障核心系统始终处于可用状态，对异常节点进行剔除；
  3. 限流降级异常流量拦截，保护核心系统。

  在金融行业，数据的重要性不言而喻，为保障数据库的高可用，我们一般有：

  1. 读写分离设计；
  2. 主备库设计；
  3. 使用分布式数据库服务等。

提到数据库的多副本设计，如读写分离和主备库设计，这就涉及到数据同步的问题了。同步的方式有很多，现在很多云服务厂商也提供了很多配套工具，进过封装之后的服务，可以傻瓜式的上手。 对于自建的服务来说，我们常常会考虑通过MQ（如RocketMQ）进行异步同步，或者解析MYSQL的binlog等方式进行数据同步。

4.2 互联网金融高并发设计

互联网金融的场景下，在高可用的基础上，对于高并发的要求是必不可少的。为满足日益剧增的用户增长和交易量，往往需要在架构设计时，考虑高并发的特性。

我们通常会通过很多方式来衡量说明一个高并发系统的架构设计，如：

  1. 通过设计来保证系统能够同时处理很多的事情，比如亿级并发支付交易，百万级并发保单下单等
  2. 低响应时间：系统对请求作出的响应时间维持在一个较低的水平，通常不超过3秒。例如系统处理一个HTTP请求需要200ms，这个200ms就是系统响应时间。
  3. 高吞吐量：单位时间内处理的请求量。
  4. QPS：每秒响应请求数。在互联网领域，这个指标和吞吐量区分的没那么明显。
  5. TPS：每秒处理的事务数。
  6. 并发用户数：同时承载正常使用系统功能的用户数量。例如一个即时通讯系统，同时在线量一定程度上代表了系统的并发用户数。

垂直扩展的方式有两种：

增强单机硬件性能，例如：增加CPU的核数，由8核扩展到16核；升级更好的网卡，由千兆网卡升级到万兆网卡；升级更好的硬盘，如SSD；扩展硬盘的容量，如由500G升级到10T；扩展系统内存，如由16G升级到64G等。

提升单机的架构性能，例如：引入缓存机制Redis来减少IO次数；引入消息队列机制，来削峰填谷，用异步处理来增加单服务的吞吐量；用轻量级架构来减少服务的处理时间等。

系统单机的处理能力总是有极限的，我们可以通过增加服务器数量的方式，来线性扩充系统的性能。

4.3 互联网金融高性能设计

在互联网金融分布式架构中，高性能是一项涉及众多方面因素的系统工程，并不是单一高新技术和设备的简单应用或堆叠，应该进行合理的规划与优化设计，以适合用户在性能、成本等方面对系统建设的综合需求。

高性能的指标通常有：

  1. 通过合理的架构设计，实现互联网金融系统高吞吐、低延时（相对时间）
  2. 可用性指标计算：平均相应时间、95线的响应时间、99线的响应时间。

互联网金融系统，涉及到各方面的性能问题，如：系统软件平台服务的性能，网络和硬件的性能，数据库及存储的性能等。

将对庞大金融服务进行领域规划，将臃肿的系统进行拆分解耦，将每一个模块进行解耦，把每个服务都尽可能做成无状态化，每个独立模块均可以作为一个微服务，这样每个微服务的关联性都比较小，每一个微服务都可能做到最大化的性能。

互联网消费金融的产品，涉及到众多前端，使用CDN缓存技术，能大大提升用户的产品体验。CND加速将网站的内容缓存在网络边缘（离用户接入网络最近的地方），然后在用户访问网站内容的时候，通过调度系统将用户的请求路由或者引导到离用户接入网络最近或者访问效果最佳的缓存服务器上，由该缓存服务器为用户提供内容服务；相对于直接访问源站，这种方式缩短了用户和内容之间的网络距离，从而达到加速的效果。

带宽性能：足够的带宽应该满足在网站峰值的情况还能足够快速的使用，所以网络带宽应该大于峰值流量=峰值QPS * 平均请求大小。只有在保证带宽的情况才能实现高性能服务。

服务器性能：服务器性能主要从CPU、内存和磁盘三个方面来考虑，CPU核心数量尽量多点，内存大小最好大一点，利用到磁盘存储的话SSD会优于机械磁盘。

硬件负载均衡设备对于有条件的团队可以采购硬件负载均衡设备，加强后台服务负载均衡的能力，比如F5。

在互联网金融的高并发场景，引入缓存能够大大提升系统性能，减少数据库IO请求，从而降低核心数据库的并发压力。一般来说，在系统横向扩展能力足够强的情况下，高并发的压力会打到数据库，所以分布式缓存的建设对于互联网消费金融产品架构设计来说非常重要。

缓存的本质是通过Key-Value形式的Hash表提升读写速度，一般情况是O（1）的读写速度。读量比较高，变化量不大的数据比较适合使用缓存。目前比较常用的分布式缓存技术有Redis，Memcache等。缓存这块的中间件建设，后面的章节会在细化讲解。

目前在大型的互联网消费金融系统架构设计中，普遍会考虑用消息队列来讲调用异步化，不仅可以提升系统的性能，还可以提升系统的扩展性。

对于大量的数据库写请求，数据库的压力很大，同时也会造成数据库的响应不及时。可以引入使用消息队列机制，数据库的写请求可以直接写入到消息队列，然后通过多线程或者多进程从消息队列读取数据慢慢写入到数据库。消息队列服务器的处理速度会远远快于数据库，所以用户在写入操作时会感觉到很快写入速度。

对于IO操作的请求可以采用基于状态机的异步化编程。如：多线程模型 多进程模型 多协作模型 事件驱动模型

处理算法的模型优化（时间复杂度和空间复杂度），对于数据结构的设计可以采用高效的数据结构，比如典型的key-value缓存系统就是基于hash的基本原理来实现的，hash表的查询效率是O（1），效率极快。

提供更高的存储硬件，更高的吞吐量和IPOS，读写性能。合理的数据连接池和缓存。

在互联网消费金融领域，涉及到很多账务数据的处理，引入分片技术能大大提升数据处理的性能。比如：借贷业务涉及到的借据数据、财务数据的夜间批量处理时，利用分片技术进行处理，提供了更高的扩展性，提升了整体的性能。

4.4 互联网消费金融高弹性架构设计

互联网消费金融行业的架构设计中，高弹性涉及到众多技术面。主要有：分布式高弹性架构 中间件平台高弹性支撑体系设计 分布式高弹性数据库建设 云计算基础设施架构

4.4.1

互联网消费金融架构设计时，考虑到的拆分涉及到两方面：

一是系统拆分，根据业务领域设计，把系统拆分解耦，让系统的颗粒度细化，模块化，微服务化。

二是数据拆分，对数据分而治之，减少单点数据故障的同时，又可以让每个数据模块具备高弹性能力。

4.4.2

在互联网金融行业，数据和服务的重要程度都非常高，通常会通过建设同城双活、异地多活的架构，来提升系统的容错和伸缩能力。

4.5 互联网消费金融高可测设计

4.5.1

互联网消费金融的软件架构的拆分与微服务建设，服务在我们的领域规划下变得有调理，服务越来越多，越来越细化，给测试也带来了巨大的挑战。进行高可测的架构设计时，我们对自动化测试的依赖越来越强，因为自动化测试能我们带来很大便利：

  1. 运用自动化环境，实现一次性部署测试环境，一键测试；
  2. 方便对程序的回归测试；
  3. 可以运行更多更繁琐的测试；
  4. 可以执行一些手工测试困难的测试；
  5. 测试具有一致性和可重复性；
  6. 增加软件信任度；
  7. 释放测试资源，提升测试人员能力等。

常用的自动化建设，一般分为前端页面的自动化测试，和接口的自动化测试。比较流行的工具有：appium，selenium，httprunner，loadrunner等。有能力的企业会自主研发自动化框架，加入更多定制化的功能，以满足实际的业务需要。

4.5.2

互联网消费金融业务复杂度高，面对性能测试往往会遇到诸多问题。

性能测试的场景多，业务复杂，比如支付功能可能涉及到从发起支服务的业务服务，到支付网关，在到银行内部系统等五六个服务。

解决方案：对关键业务路径进行性能回归，对单个服务接口进行压测和预估。

测试环境服务器和线上服务器的配置往往不一样，而且测试环境是单点的，而线上服务是集群的。

解决方案： a. 机房单台服务器配置尽量与线上保持一致，集群问题通过等比缩放预估； b. 技术力量比较强的公司如阿里，直接在线上环境进行压测。

测试数据准确性和一致性问题 解决方案：对生产数据进行全量脱敏导下来，用于性能测试

接口的性能测试调用链太长，对外部系统依赖 解决方案：接口的调用链尽量优化简短，部分接口和外部依赖进行mock后再测试。

性能测试方案制定，怎样定位性能瓶颈？ 解决方案：需要对被压测的接口分析调用链，根据线上监控，进行分析可能存在的性能瓶颈。

根据接入的接口监控，比如cat监控，可以根据监控数据QPS/集群数，再乘以80%（因为测试服务器和线上服务器的性能可能有一些差距）。

接口理论上相应时间是100-800ms，最大不超过1s。这是基本要求，一些特殊重场景，需特殊处理。

根据测试环境压测结果（cpu<=50%）简单预估，测试QPS线上集群1.2 约等于线上QPS

五、互联网消金高并发架构八大中间件运用

互联网金融业务的快速发展，对架构设计在系统稳定性、交付能力、管理效率、技术栈规划方面提出了更高的要求。大规模线上化业务的挑战：

业务高速发展，流量和数据量大增； 在系统稳定性、可用性、扩展性、安全性和成本等面临挑战；

快速上线、快速交付能力（Time To Market），交付时间面临挑战； 管理结构BU化，千人研发人员并行开发，系统交付的质量面临挑战；

分布式的系统，复杂度高，调用链长，超出个人的处理能力，工具化势在必行； 多数据中心的部署，大量机器和应用服务面临治理的挑战；

编程语言： Java，NodeJs，Python，GO等 数据库：Oracle，MySQL，PostgreSQL，MongoDB等 中间件：Redis，RocketMQ，Apollo等

打造八大核心中间，支持未来在消费金融线上化交易业务未来10倍、100倍快速增长。

5.1

对于互联网消费金融架构来说，Dubbo适用于系统技术相对简单，业务调用链短，系统对并发量和吞吐量要求很高，对生态的要求不高，服务治理等外围系统不需要非常强大的业务场景。对迭代迅速、小短快，控制流程不需要很严格的互联网金融公司。

服务注册发现中心：Apache Zookeeper，Alibaba Nacos 服务调用方式： RPC：Netty、Mina、Grizzly、Hessian、RMI、Thrift等 REST：DubboX 服务调用序列化： FastJson、FST、Hessian2、Kryo、ProtoStuff、JDK 服务负载均衡： ConsistentHash、LeastActiveLoadBalance、RoundRobin、Random

5.2

对于中大型互联网消费金融公司来说，Spring Cloud是个不错的选择，但同时开发的预支也较大，适用于系统较为复杂，业务调用链较长，对生态的要求很高，微服务配套包括服务治理、监控、路由、网关、灰度发布等需要面面俱到的互联网金融公司。要求公司基础设施强大，架构团队、DevOps、运维等力量雄厚，自动化部署能力较强。同时具备，迭代周期较长，流程控制较为严格，较为正规化。

 

  • 服务注册发现中心：Netflix Eureka、HashiCorp Consul、Alibaba Nacos、CoreOS Etcd（孵化中）；
  • 服务负载均衡：Netflix Ribbon、支持异步WebFlux；
  • 服务调用方式：REST&RPC，FeignClient，RestTemplate；
  • 服务调用序列化：Json；
  • 服务API网关：Netflix Zuul（同步）、Spring Cloud Gateway（异步）；
  • 断路器：Hystrix、Alibaba Sentinel；
  • 分布式配置：Spring Cloud Config、Apollo；
  • 调用链：Sleuth、Zipkin、Pinpoint、Skywalking等；
  • 消息驱动：Spring Cloud Stream；
  • 消息总线：Spring Cloud Bus；
  • 容器化支持：Spring Cloud Kubernetes。

5.3 建设路由网关Gateway

对于互联网消费金融的架构来说，建设路由网关是一项很重要的工作。有了路由网关，能为我们的平台带来很多好处，除了常用的网关的路由功能外，我们还能在金融系统的升级、微服务线上化的过程中，根据需要把流量在新老系统之间切换，也为灰度发布、蓝绿发布、同城双活、异地多活的建设打下基础。

  1. 智能路由
  2. 业务隔离
  3. 熔断限流
  4. 动态更新
  5. 灰度发布
  6. 监控告警

互联网消费金融网关架构图：

OpenResty是一个基于 Nginx 与 Lua 的高性能 Web 平台，其内部集成了大量精良的 Lua 库、第三方模块以及大多数的依赖项。用于方便地搭建能够处理超高并发、扩展性极高的动态 Web 应用、Web 服务和动态网关。

OpenResty 通过汇聚各种设计精良的 Nginx 模块（主要由 OpenResty 团队自主开发），从而将 Nginx 有效地变成一个强大的通用 Web 应用平台。这样，Web 开发人员和系统工程师可以使用 Lua 脚本语言调动 Nginx 支持的各种 C 以及 Lua 模块，快速构造出足以胜任 10K 乃至 1000K 以上单机并发连接的高性能 Web 应用系统。

OpenResty 的目标是让你的Web服务直接跑在 Nginx 服务内部，充分利用 Nginx 的非阻塞 I/O 模型，不仅仅对 HTTP 客户端请求,甚至于对远程后端诸如 MySQL、PostgreSQL、Memcached 以及 Redis 等都进行一致的高性能响应。

5.4 互联网消费金融配置中心Apollo

简单易用 多环境多集群配置 配置修改实时生效 版本发布管理 支持灰度发布 支持权限/审核/审计管理 开放API管理

在互联网消费金融领域，打造分布式的配置中心，不但能够为服务架构Dubbo或Spring Cloud提供统一的配置化管理，而且在业务服务的架构上也能提供很多便利，它让我们可以将一些配置项存储于配置中心，减少主要业务数据库的压力的同时，又能动态更新配置项。下面我总结了一些在业务方面的配置化实践：

  1. 消费金融涉及众多业务功能，大量的开关功能是免不了的，我们可以业务开关放在Apollo进行统一管理。如：自动审批开关、新功能验证开关、风控规则启用开关等；
  2. 还有消费金融业务配置项管理：如利率范围根据国家政策经常变动，可以用Apollo配置管理起来；又如审批的节点管理，根据贷款类型，有抵押、无抵押，类型不一样，审批的节点也不一样，可以用Apollo管理；
  3. 同城双活、蓝绿发布的流量管理、Ip路由管理等等。

5.5 互联网消费金融数据访问层DAL

支持多数据源：Oracle、MySQL等 统一的API封装 简单、安全 统一数据源 支持分库分表策略 Read/Write Mod N Range Hash 代码生成技术，比如统一加时间戳等等 统一的监控和统计

 

在互联网消费金融领域，业务复杂，建设好DAL数据访问层，能为我们带来很多便利：

  1. 金融业务表众多，开发团队大，在DAL层为每张表统一封装好时间戳，这样做能为以后的大数据平台增量同步数据提供便利；
  2. 金融行业涉及到的账务数据，数据量大，对每日并行报批，查询服务都有不小挑战，建设统一的分库分表组件，应对未来数据量10倍100倍的增长；
  3. 对一些监控的需要，如关键表的SQL执行次数，用户行为留存，历史操作记录等，都可以在DAL层统一设计实现。

5.6 互联网消费金融消息队列MQ

  1. 消息特性：高吞吐 低延时 可靠 有序（统一分片内） 多生产者 多消费者
  2. 存储特性：支持MySQL等数据存储 Kafka支持持久化
  3. 跨平台支持：JAVA .NET

1）服务之间的解耦：消费金融的业务链路特别长的场景，可以用MQ来解耦，比如一笔进件，经历贷前校验，到风控平台风险规则，风险探测，准入，核额，再到贷中审批流程，调用链比较长，业务环节也比较多，可以通过消息队列MQ进行系统&模块间的解耦；

2）异步的处理提升系统性能：在一些耗时环节，设计成异步的交互方式，通过MQ进行异步的结果通知，可以大大减少系统的同步响应处理，提升系统的吞吐量。例如：用户进行还款时，在进行跨行转账支付时可能会耗时比较长，而且要等待他行的返回结果，与支付服务的交互时，可以通过异步MQ的方式进交互，异步的返回交易的结果，成功或者失败。

目前MQ中间件开源技术众多，比较流行的有Kafka，RocketMQ，RabbitMQ，ActiveMQ。

5.7 互联网消费金融缓存服务Redis

高性能，高吞吐，读的速度是110000次/s,写的速度是81000次/s ； 丰富的数据类型： Redis支持二进制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 数据类型操作； 原子性：Redis的所有操作都是原子性的，同时Redis还支持对几个操作全并后的原子性执行；

举了一个贷款进度查询的例子，首先进行查询缓存，如缓存没有，再去查数据库，大大降低了数据库的压力。下面我将这个图扩展一下，重点示例Redis的集群结构：

 Redis哨兵的作用：Redis sentinel 是一个分布式系统中监控 redis 主从服务器，并在主服务器下线时自动进行故障转移。其中三个特性：监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。 提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。 自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作。

特点： 1、保证高可用 2、监控各个节点 3、自动故障迁移

在互联网消费金融业务领域里，Redis有很多实践场景：

  1. 实现接口幂等性：在金融领域，很多业务行为对幂等性要求很高，比如支付，重复扣款，重复下单等。在调用接口之前先调用获取token的接口生成对应的令牌(token)，并存放在redis当中，在调用接口的时候，将第一步得到的token放入请求头中。解析请求头，如果能获取到该令牌，就放行，执行既定的业务逻辑，并从redis中删除该token。如果获取不到该令牌，就返回错误信息;
  2. 热点数据缓存：比如常用的金融业务配置项，客户经理的状态等热点信息，可以存放在redis，快速访问，减少数据库压力，增强系统性能；
  3. 分布式Session保存：消费金融领域涉及到的系统众多，特别是后台服务比如给业务经理用的系统可能就有审批系统、报表系统、查询信息系统等，可以将各个进行统一Session会话保存到redis，减少每次系统重新登录，提升用户体验；
  4. 分布式锁：这是一个比较常用的场景，主要使用setnx命令功能来编写分布式的锁，跟幂等性的实现原理类似，比如用户在发起还款时，请求开始到结束会经过很多系统，还款金额校验、卡余额校验，还款发起服务等，需要对关键资源点进行加锁，防止并发场景带来故障；
  5. 对互联网消费金融门户网站/APP首页排行榜信息进行缓存，比如商品信息贷款品种、贷款金额排行榜等。

5.8 互联网消费金融作业调度Job

场景复杂：在互联网消费金融业务，涉及到很多跑批作业，而且作业间互相依赖，有分支，有汇总的场景特别多，比如：每日夜间批扣，财务分录，利率计算&减免等等；

数据量大：互联网消费金融业务的线上交易量的增长，无疑会大大增加作业Job的数据量。而且批量作业的数据跟交易量是10倍级别的增长，比如一笔贷款分12期还（一年12个月），这样就是1：12的关系。

监控的难度增加。

支持集群部署，提升调度系统可用性，同时提升任务处理能力。构建作业注册中心，实现的全局作业注册控制中心。用于注册，控制和协调分布式作业执行。

前面的章节也介绍过分片设计的好处，能够并行处理海量数据，支持动态横向扩展，提升系统的处理能力。将任务拆分为n个任务项后，各个服务器分别执行各自分配到的任务项。一旦有新的服务器加入集群，或现有服务器下线，将在保留本次任务执行不变的情况下，下次任务开始前触发任务重分片。

互联网消费金融作业Job的监控，涉及到的方面：

  1. 作业的进度监控；
  2. 作业状态监控，是否正常或异常；
  3. 异常分类与报警；
  4. 消息通知。

  • ：Java事实上的定时任务标准。但Quartz关注点在于定时任务而非数据，并无一套根据数据处理而定制化的流程。虽然Quartz可以基于数据库实现作业的高可用，但缺少分布式并行调度的功能
  • ：阿里早期开源的分布式任务调度系统。代码略陈旧，使用timer而非线程池执行任务调度。众所周知，timer在处理异常状况时是有缺陷的。而且TBSchedule作业类型较为单一，只能是获取/处理数据一种模式。还有就是文档缺失比较严重
  • ：当当开发的弹性分布式任务调度系统，功能丰富强大，采用zookeeper实现分布式协调，实现任务高可用以及分片，目前是版本2.15，并且可以支持云开发
  • ：是唯品会自主研发的分布式的定时任务的调度平台，基于当当的elastic-job 版本1开发，并且可以很好的部署到docker容器上。
  • : 是大众点评员工徐雪里于2015年发布的分布式任务调度平台，是一个轻量级分布式任务调度框架，其核心设计目标是开发迅速、学习简单、轻量级、易扩展。

六、互联网金融高并发架构微服务治理方案实践

传统金融行业，在业务线下转线上、零售化互联网转型的过程中，面临诸多技术和架构的挑战。一方面，系统架构需具备金融高可用、高标准、低风险的技术基础，另一方面，需求必须兼具互联网规模化的服务能力、具备互联网架构高并发、高性能、高扩展的能力。对于传统金融系统，未经历大规模互联网线上化的考验，往往一次洪峰、一次线上促销活动就把系统压垮了。

特别是面向C端的消费金融的架构体系，面对这种情况我们需要进行微服务的改造和建设，引入服务治理框架（在上一章节介绍过Dubbo与Spring Cloud），随着微服务的拆分，服务集群的数量指数级的增加，架构的复杂也相继增加，那么怎样对微服务架构进行有效的治理成为了互联网金融服务治理面临的主要架构问题。

6.1 互联网金融架构服务治理面临的常见问题

1）金融系统耦间合度高

  • 金融业务涉及面广，但系统模块划分简单，并且模块职责不明确；
  • 所有模块共用一个数据库，主数据库的表已经超过一千张；

2）金融系统服务间调用链混乱

  • 服务间的调用随意，没有进行合理的服务调用链规划；
  • 存在循环调用，调用链过长等问题；

3）金融系统性能差

  • 系统臃肿导致系统容易出现大规模单点故障，牵一发而动全身；
  • 单点的jvm和容器的性能瓶颈容易成为性能瓶颈；

4）缺乏有效的降级、熔断手段

  • 老系统往往缺乏熔断、限流、降级，超时控制，蓄洪等服务治理的能力；

5）快速交付的挑战

  • 互联网金融平台的系统，在面对高并发服务的要求，往往需要快速交付、快速上线，如果服务臃肿庞大，就难以做到快速灵活的发布；
  • 需要进行微服务化设计，将庞大臃肿的系统化整为零，每个服务集群能够独立发布和部署，快速应对性能需求和业务需求。

6.2 互联网消费金融的服务化架构方案

在介绍互联网消费金融的服务化架构设计之前，我们先介绍一下，服务化主要有如下特点：

  • 应用按业务模块，拆分成独立服务；
  • 各个服务均可独立发布和部署，独立运维；
  • 每个服务可被多个应用共享；
  • 服务之间可以通过HTTP、RPC、Soap等协议进行通信。

  • 企业级SOA架构方案
  • 互联网服务化架构方案
  • 微服务架构方案

6.2.1 消费金融企业级SOA架构方案设计

  • 主要解决的问题是已有系统的整合(互联互通)问题
  • 手工治理比重大、自动化程度不足
  • 技术实现及流程繁琐复杂、治理成本高
  • 覆盖面广、涵盖企业IT各方面，和IT治理重叠度高
  • 传统IT大厂(IBM、Oracle)把持标准

6.2.2 消费金融互联网服务化架构方案设计

 

  • 伴随消费金融业务规划拆分应运而生
  • 主要解决业务的快速响应及系统复杂性扩散问题
  • 技术实现形式五花八门，有标杆、但没有统一标准
  • 聚焦线上服务的生命周期治理
  • 强调自动化

6.2.3 消费金融微服务架构方案设计

  • 大中型金融企业推荐建设微服务架构，搭建微服务治理平台、标准化微服务设计；
  • 微服务集群的运维和容器技术紧密结合
    • 量变导致质变，不仅仅是服务化架构的延伸 组织架构、管理策略、研发模式、测试、运维等领域 都要做出相应的调整，以为微服务架构的落地创造合 适的“土壤”。
  • 线上化全生命周期的服务治理
  • 测试自动化、运维智能化

6.3 互联网消费金融线上化微服务治理建设实践

6.3.1 建设服务注册发现中心

互联网消费金融服务治理领域最重要的问题之一就是服务发现与注册中心的建设。在服务治理框架中，如Dubbo和Spring Cloud中均引入了一个服务注册发现中心的概念，服务的注册与发现、服务的上线与下线主要就依赖这个服务中心。

 

  1. 服务提供者启动，向注册中心注册自己提供的服务；
  2. 消费者启动，向注册中心订阅自己需要的服务；
  3. 注册中心返回服务提供者的列表给消费者；
  4. 消费者从服务提供者列表中，按照软负载均衡算法，选择一台发起请求；

注册中心职责简单，只负责注册查找，不负责请求转发，压力小； 消费者本地缓存服务地址列表，注册中心宕机影响不影响服务调用； 注册中心可搭建集群，宕掉一台自动切换到另外一台； 服务提供者无状态，可动态部署，注册中心负责推送； 消费者调用服务者，自动软负载均衡；

6.3.2  

社区活跃度：中 CAP模型：CP 控制台管理：不支持 适用规模（建议）：十万级 健康检查：Keep Alive 易用性：易用性比较差，Zookeeper的客户端使用比较复杂，没有针对服务发现的模型设计以及相应的API封装，需要依赖方自己处理。对多语言的支持也不太好，同时没有比较好用的控制台进行运维管理。 综合建议：更新较慢，功能匮乏，使用部署较复杂，不易上手，维护成本较高。

社区活跃度：低，已停止开源维护 CAP模型：AP 控制台管理：支持 适用规模（建议）：十万级 健康检查：Client Beat 易用性：较好，基于SpringCloud体系的starter，帮助用户以非常低的成本无感知的做到服务注册与发现。提供官方的控制台来查询服务注册情况。 综合建议：eureka当前停止开源不建议企业级使用

社区活跃度：高 CAP模型：CP 控制台管理：支持 适用规模（建议）：百万级 健康检查：TCP/HTTP/gRPC/Cmd 易用性：较好，能够帮助用户以非常低的成本无感知的做到服务注册与发现。提供官方的控制台来查询服务注册情况。 综合建议：集成简单，不依赖其他工具，推荐大中型企业使用。

社区活跃度：高 CAP模型：CP+AP 控制台管理：支持 适用规模（建议）：百万级 健康检查：TCP/HTTP/MYSQL/Client Beat 易用性：较好，能够帮助用户以非常低的成本无感知的做到服务注册与发现。提供官方的控制台来查询服务注册情况。 综合建议：阿里巴巴背书，更新速度快，文档完善，社区活跃度高，推荐大中型企业使用。

6.4 互联网消费金融微服务流量治理实践

金融系统平时平稳，但遇到大促的时候，机器的load会爆发式增长，这时候对系统的负载保护就显得非常重要，以防止雪崩。流量控制提供了对应的保护机制，让系统的入口流量和系统的负载达到一个平衡，保证系统在能力范围之内处理最多的请求。通常，在消费金融系统我们进行流量治理时，架构设计会重点考虑以下场景和因素：

流量的控制从入口开始，对流量负载按权重进行调度调配，同时根据底层的压力进行动态调整。这里的流量分配主要涉及到两方面：

  • 一是多系统在改造过程中的新旧系统的流量分配；
  • 二是建设有多集群副本的情况下的流量控制，如蓝绿、灰度发布，同城双活，异地多活等；

事先制定好保护预案

  • 通过压测预知系统所能承载的压力和并发量；
  • 降级的降级策略与业务紧密结合，比如某个接口在降级的情况下应该返回默认值还是给用户错误提示等；
  • 系统在超出承受能力触发熔断时，我们应该做哪些处理，如紧急扩容服务、简化部分业务的流程等；

  • 漏桶算法：漏桶算法(Leaky Bucket)是网络世界中流量整形（Traffic Shaping）或速率限制（Rate Limiting）时经常使用的一种算法，它的主要目的是控制数据注入到网络的速率，平滑网络上的突发流量。漏桶算法提供了一种机制，通过它，突发流量可以被整形以便为网络提供一个稳定的流量。
  • 令牌桶算法：在一个桶内按照一定的速率放入一些 token，然后，处理程序要处理请求时，需要拿到 token，才能处理；如果拿不到，则不处理。
  • 队列算法。入队速率波动，消费可以相对匀速处理，队列满则丢弃。具体可以分为普通队列、优先级队列、权重队列等，来应对不同的场景。

  1. 限流前置
  2. 集群限流

Spring Cloud官方默认的熔断组件Hystrix（已停止维护）； 较轻量的熔断降级库resilience4j（轻量级）； Google开源工具包Guava提供了限流工具类RateLimiter（功能较单一）； 阿里巴巴的开源框架Sentinel（推荐）

  • 轻量级，核心库无多余依赖，性能损耗小。
  • 方便接入，开源生态广泛。Sentinel 对 Dubbo、Spring Cloud、Web Servlet、gRPC 等常用框架提供适配模块，只需引入相应依赖并简单配置即可快速接入；同时针对自定义的场景 Sentinel 还提供低侵入性的注解资源定义方式，方便自定义接入。
  • 丰富的流量控制场景。Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景，流控维度包括流控指标、流控效果（塑形）、调用关系、热点、集群等各种维度，针对系统维度也提供自适应的保护机制。
  • 易用的控制台，提供实时监控、机器发现、规则管理等能力。 完善的扩展性设计，提供多样化的 SPI 接口，方便用户根据需求给 Sentinel 添加自定义的逻辑。

6.5 互联网消费金融微服务架构治理实践

 互联网消费金融业务复杂度高，对调用链的设计时应遵循以下设计原则：

  1. 模块间的调用应遵循ADP（The Acyclic Dependencies Principle，无环依赖原则）。当 A 模块依赖于 B 模块，B 模块依赖于 C 模块，C 依赖于 A 模块，此时将出现循环依赖。在设计中应该避免这个问题，可通过引入“中介者模式”解决该问题。
  2. 对调用链尽量简化，减少长链，去除多余的业务逻辑链路；
  3. 利用消息MQ机制进行异步通信，对模块&服务间进行解耦，减少同步调用，降低系统间的强依赖；
  4. 对异常链路进行容错处理；
  5. 建立完善的调用链监控平台；

6.5.1  

Failover失败转移策略:当发生调用异常时，重新选路，查找下一个可用的服务提供者。通常可以配置失败切换的最大次数和间隔周期，以防止E2E服务调用时延过大。

Failback失效自动恢复策略：Fail-over之后的自动恢复，在集群架构系统（有两台或多台服务器互联的网络）中，由于要某台服务器进行维修，需要网络资源和服务暂时重定向到备用系统。在此之后将网络资源和服务器恢复为由原始主机提供的过程，称为自动恢复

:Failcache策略是失败自动恢复的一种，在实际项目中它的应用场景如下：

服务有状态路由，必须定点发送到指定的服务提供者。当发生链路中断、流控等服务暂时不可用时，服务框架将消息临

标签： 简易式压力变送器堆叠式卡连接器33x压力变送器荔波智能电容器fstcp100变送器

锐单商城拥有海量元器件数据手册、 IC替代型号，打造 电子元器件IC百科大全！

锐单商城 - 一站式电子元器件采购平台