02 打造互联网消金高并发架构八大中间件运用¶
大规模线上化的业务对互联网消费金融架构的要求¶
互联网金融业务的快速发展，对架构设计在系统稳定性、交付能力、管理效率、技术栈规划方面提出了更高的要求。
大规模线上化业务的挑战：
-
系统稳定性
业务高速发展，流量和数据量大增； 在系统稳定性、可用性、扩展性、安全性和成本等面临挑战；
-
交付能力
快速上线、快速交付能力（Time To Market），交付时间面临挑战； 管理结构 BU 化，千人研发人员并行开发，系统交付的质量面临挑战；
-
管理效率
分布式的系统，复杂度高，调用链长，超出个人的处理能力，工具化势在必行； 多数据中心的部署，大量机器和应用服务面临治理的挑战；
-
技术栈规划
- 编程语言：Java，NodeJs，Python，Go 等
- 数据库：Oracle，MySQL，PostgreSQL，MongoDB 等
- 中间件：Redis，RocketMQ，Apollo 等
打造互联网消费金融八大核心中间件¶
打造八大核心中间，支持未来在消费金融线上化交易业务未来 10 倍、100 倍快速增长。
- 服务框架：Dubbo，阿里开源的一个高性能的优秀服务框架；
- 服务框架：Spring Cloud，由美国 Pivotal 公司出品，由 Spring 官方背书，由 Netflix、Alibaba 等众多知名互联网企业技术输出；
- 路由网关 Gateway：分布式集群路由，负载均衡，协议适配，支撑峰值交易；
- 配置中心 Apollo：配置集中化，配置与代码分离，快速响应能力；
- 数据访问层 DAL：支持数据库横向扩展，分库分表，故障转移；
- 消息队列 MQ：业务解耦，组织解耦，流量削峰填谷；
- 缓存服务 Redis：高性能，高吞吐，秒杀利器；
- 作业调度 Job：定时作业，批量处理，支撑每日大规模作业。
打造互联网金融服务框架¶
服务框架的选型，目前主流的有两类，一是由阿里背书的 Dubbo 体系，二是由 Spring 背书的 Spring Cloud，下面就两类框架分别进行介绍。
服务框架 Dubbo 介绍¶
对于互联网消费金融架构来说，Dubbo 适用于系统技术相对简单，业务调用链短，系统对并发量和吞吐量要求很高，对生态的要求不高，服务治理等外围系统不需要非常强大的业务场景。对迭代迅速、小短快，控制流程不需要很严格的互联网金融公司。
服务框架 Dubbo 架构图¶
服务框架 Dubbo 简单介绍¶
- 背景：中国 Alibaba 公司出品，由 Alibaba 官方背书，捐献给了 Apache 开源组；
- 定位：本土化、高性能、轻量级、封闭式的开源 RPC 调用和 SOA 框架
- 技术：基于 Spring（低版本）/ Spring Boot（高版本），服务注册发现（依赖 zookeeper），负载均衡 RPC、REST（3.x 版本支持）调用；
- 协议：Apache License 2.0
服务框架 Dubbo 发展历程¶
- 诞生：2009 年初开源，推出 1.0 版，10 年多发展历史；
- 成熟：2012 年 10 月 23 日推出 2.5.3 版成熟稳定版后，停止维护和升级，当当网接手维护，推出 DubboX 版；
- 恢复：2017 年 9 月 7 日恢复维护，2018 年 1 月 8 日合并 DubboX，发布 2.6.0 版；
- 近况：阿里巴巴中间件部门计划推出 3.0 版
服务框架 Dubbo 的未来规划¶
- Streaming：支持 Streaming 为内核，取代同时兼容 RPC；
- Reactor：支持 "反应式编程”模式（Reactive Programming）"，去掉一切阻塞；
- Spring Cloud：支持 Dubbo 接入 Spring Cloud，使两者达到互通，Spring Cloud Alibaba 产品组已经着手支持；
- Service Mesh：支持 Service Mesh，由 Dubbo-Mesh 进行 IPC，路由、负载均衡和熔断机制将由
服务框架 Dubbo 组件体系¶
- 服务注册发现中心：Apache Zookeeper，Alibaba Nacos
- 服务调用方式：RPC：Netty、Mina、Grizzly、Hessian、RMI、Thrift 等
- REST：DubboX
- 服务调用序列化：FastJson、FST、Hessian2、Kryo、ProtoStuff、JDK
- 服务负载均衡：ConsistentHash、LeastActiveLoadBalance、RoundRobin、Random
服务框架 Spring Cloud 介绍¶
对于中大型互联网消费金融公司来说，Spring Cloud 是个不错的选择，但同时开发的预支也较大，适用于系统较为复杂，业务调用链较长，对生态的要求很高，微服务配套包括服务治理、监控、路由、网关、灰度发布等需要面面俱到的互联网金融公司。要求公司基础设施强大，架构团队、DevOps、运维等力量雄厚，自动化部署能力较强。同时具备，迭代周期较长，流程控制较为严格，较为正规化。
服务框架 Spring Cloud 架构图¶
服务框架 Spring Cloud 简单介绍¶
- 背景：由美国 Pivotal 公司出品，由 Spring 官方背书，由众多知名互联网企业技术输出，如：Netflix，Alibaba 等；
- 定位：国际化、全生态、全开放、全插件式的开源微服务架构解决方案和体系，拥抱全球知名云厂商；
- 技术：基于 Spring/Spring Boot，服务注册发现，负载均衡，熔断降级 RPC、REST 调用，API 网关等
- 协议：Apache License 2.0
服务框架 Spirng Cloud 发展历程¶
- 诞生：2015 年 7 月开源，推出 Angle 版，将近 4 年多发展历史，每年定期推出打迭代版本；
- 成熟：相继陆续推出了 Brixton 版、Camden 版等
- 飞跃：Finchley 版于 2018 年 6 月 19 日发布，属于划时代版本，支持 Spring Boot2.x，Spring5.x，WebFlux；
- 近况：社区活跃，各大互联网公司技术推出众多组件，如 Alibaba Nacos；
服务框架 Spirng Cloud 现状和未来¶
- WebFlux（已发布）：支持 Spring WebFlux 异步响应式框架，采用 Reactor 或 RxJava，未来将逐步取代 Spring WebMVC；
- Spring Cloud GW（已发布）：支持响应式的服务网关，使用 Spring WebFlux，网关吞吐量得到卓越提升；
- Kubernetes 支持（已发布）：支持 Kubernetes 的组件，Spring Cloud 官方推出直接集成 Kubernetes 的组件，朝着专业化 DevOps 踏出更坚实一步；
- Serverless 支持（已发布）：支持 Spring Cloud Function，面向函数式编程，支持跨 Serverless Providers 的统一编程模型，实现 Faas（函数即服务），进一步简化 Pass（平台即服务）；
- Spring Cloud LB（孵化中）：支持异步响应的负载均衡 Spring Cloud Loadbalancer，使用 Spring WebFlux，大幅度降低负载均衡时候的性能损耗；
- Service Mesh（规划中）：支持 Service Mesh，拭目以待。
服务框架 Spirng Cloud 技术组件体系¶
- 服务注册发现中心：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。
建设路由网关 Gateway¶
对于互联网消费金融的架构来说，建设路由网关是一项很重要的工作。有了路由网关，能为我们的平台带来很多好处，除了常用的网关的路由功能外，我们还能在金融系统的升级、微服务线上化的过程中，根据需要把流量在新老系统之间切换，也为灰度发布、蓝绿发布、同城双活、异地多活的建设打下基础。
路由网关 Gateway 的主要特性¶
- 智能路由
- 业务隔离
- 熔断限流
- 动态更新
- 灰度发布
- 监控告警
路由网关 Gateway 架构设计¶
互联网消费金融网关架构图：
基于 OpenResty 打造高性能网关¶
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 等都进行一致的高性能响应。
打造互联网消费金融配置中心 Apollo¶
Apollo 配置中心的主要特点¶
- 简单易用
- 多环境多集群配置
- 配置修改实时生效
- 版本发布管理
- 支持灰度发布
- 支持权限/审核/审计管理
- 开放 API 管理
消费金融 Apollo 配置中心实践¶
在互联网消费金融领域，打造分布式的配置中心，不但能够为服务架构 Dubbo 或 Spring Cloud 提供统一的配置化管理，而且在业务服务的架构上也能提供很多便利，它让我们可以将一些配置项存储于配置中心，减少主要业务数据库的压力的同时，又能动态更新配置项。下面我总结了一些在业务方面的配置化实践：
- 消费金融涉及众多业务功能，大量的开关功能是免不了的，我们可以业务开关放在 Apollo 进行统一管理。如：自动审批开关、新功能验证开关、风控规则启用开关等；
- 还有消费金融业务配置项管理：如利率范围根据国家政策经常变动，可以用 Apollo 配置管理起来；又如审批的节点管理，根据贷款类型，有抵押、无抵押，类型不一样，审批的节点也不一样，可以用 Apollo 管理；
- 同城双活、蓝绿发布的流量管理、Ip 路由管理等等。
打造互联网消费金融数据访问层 DAL¶
数据访问层 DAL 的主要特性¶
- 支持多数据源：Oracle、MySQL 等
- 统一的 API 封装 简单、安全
- 统一数据源
- 支持分库分表策略 Read/Write Mod N Range Hash
- 代码生成技术，比如统一加时间戳等等 统一的监控和统计
数据访问层 DAL 架构设计¶
互联网消费金融数据访问层 DAL 实践¶
在互联网消费金融领域，业务复杂，建设好 DAL 数据访问层，能为我们带来很多便利：
- 金融业务表众多，开发团队大，在 DAL 层为每张表统一封装好时间戳，这样做能为以后的大数据平台增量同步数据提供便利；
- 金融行业涉及到的账务数据，数据量大，对每日并行报批，查询服务都有不小挑战，建设统一的分库分表组件，应对未来数据量 10 倍 100 倍的增长；
- 对一些监控的需要，如关键表的 SQL 执行次数，用户行为留存，历史操作记录等，都可以在 DAL 层统一设计实现。
打造互联网消费金融消息队列 MQ¶
消息队列 MQ 的主要特性¶
-
消息特性
- 高吞吐
- 低延时
- 可靠
- 有序（统一分片内）
- 多生产者
- 多消费者
-
存储特性 支持 MySQL 等数据存储 Kafka 支持持久化
-
跨平台支持
- JAVA
- .NET
消息队列 MQ 架构设计¶
互联网消费金融消息队列 MQ 架构实践¶
-
服务之间的解耦：消费金融的业务链路特别长的场景，可以用 MQ 来解耦，比如一笔进件，经历贷前校验，到风控平台风险规则，风险探测，准入，核额，再到贷中审批流程，调用链比较长，业务环节也比较多，可以通过消息队列 MQ 进行系统&模块间的解耦；
-
异步的处理提升系统性能：在一些耗时环节，设计成异步的交互方式，通过 MQ 进行异步的结果通知，可以大大减少系统的同步响应处理，提升系统的吞吐量。例如：用户进行还款时，在进行跨行转账支付时可能会耗时比较长，而且要等待他行的返回结果，与支付服务的交互时，可以通过异步 MQ 的方式进交互，异步的返回交易的结果，成功或者失败。
互联网消费金融消息队列 MQ 技术选型¶
目前 MQ 中间件开源技术众多，比较流行的有 Kafka，RocketMQ，RabbitMQ，ActiveMQ。
-
Kafka 介绍
- 消息存储：内存、磁盘、数据库。支持大量堆积。
- 单节点吞吐量：十万级。
- 分布式集群架构：支持较好。天然的'Leader-Slave'无状态集群，每台服务器既是 Master 也是 Slave。
- 社区活跃度：高
- 适用场景：大数据日志采集
-
RocketMQ 介绍
- 消息存储：磁盘。支持大量堆积
- 单节点吞吐量：十万级。
- 分布式集群架构：支持较好。常用 多对'Master-Slave' 模式，开源版本需手动切换 Slave 变成 Master。
- 社区活跃度：高 适用场景：较大型公司使用，需要有专业人员研究源码，主要是有阿里背书，大公司用的比较广泛。
-
RabbitMQ 介绍
- 消息存储：内存、磁盘。支持少量堆积。
- 单节点吞吐量：万级。
- 分布式集群架构：支持不太好。支持简单集群，'复制'模式，对高级集群模式支持不好。
- 社区活跃度：高
- 适用场景：中小型公司，比较稳定成熟。
-
ActiveMQ 介绍
- 消息存储：内存、磁盘、数据库。支持少量堆积。
- 单节点吞吐量：万级。
- 分布式集群架构：支持不好。支持简单集群模式，比如'主-备'，对高级集群模式支持不好。
- 社区活跃度：低
- 适用场景：中小型公司，比较稳定成熟。
打造互联网消费金融缓存服务 Redis¶
缓存服务 Redis 的主要特性¶
- 高性能，高吞吐，读的速度是 110000 次/s,写的速度是 81000 次/s ；
- 丰富的数据类型： Redis 支持二进制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 数据类型操作；
- 原子性：Redis 的所有操作都是原子性的，同时 Redis 还支持对几个操作全并后的原子性执行；
缓存服务 Redis 的架构设计¶
我们在上一章举了一个贷款进度查询的例子，首先进行查询缓存，如缓存没有，再去查数据库，大大降低了数据库的压力。下面我将这个图扩展一下，重点示例 Redis 的集群结构：
Redis 哨兵的作用¶
Redis sentinel 是一个分布式系统中监控 redis 主从服务器，并在主服务器下线时自动进行故障转移。其中三个特性：
- 监控（Monitoring）：Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
- 提醒（Notification）：当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
- 自动故障迁移（Automatic failover）：当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作。
特点：
- 保证高可用
- 监控各个节点
- 自动故障迁移
互联网消费金融缓存服务 Redis 实践¶
在互联网消费金融业务领域里，Redis 有很多实践场景：
-
实现接口幂等性：在金融领域，很多业务行为对幂等性要求很高，比如支付，重复扣款，重复下单等。在调用接口之前先调用获取 token 的接口生成对应的令牌(token)，并存放在 redis 当中，在调用接口的时候，将第一步得到的 token 放入请求头中。解析请求头，如果能获取到该令牌，就放行，执行既定的业务逻辑，并从 redis 中删除该 token。如果获取不到该令牌，就返回错误信息;
-
热点数据缓存：比如常用的金融业务配置项，客户经理的状态等热点信息，可以存放在 redis，快速访问，减少数据库压力，增强系统性能；
-
分布式 Session 保存：消费金融领域涉及到的系统众多，特别是后台服务比如给业务经理用的系统可能就有审批系统、报表系统、查询信息系统等，可以将各个进行统一 Session 会话保存到 redis，减少每次系统重新登录，提升用户体验；
-
分布式锁：这是一个比较常用的场景，主要使用 setnx 命令功能来编写分布式的锁，跟幂等性的实现原理类似，比如用户在发起还款时，请求开始到结束会经过很多系统，还款金额校验、卡余额校验，还款发起服务等，需要对关键资源点进行加锁，防止并发场景带来故障；
-
对互联网消费金融门户网站/APP 首页排行榜信息进行缓存，比如商品信息贷款品种、贷款金额排行榜等。
打造互联网消费金融作业调度 Job¶
互联网消费金融作业调度 Job 的架构挑战¶
-
场景复杂：在互联网消费金融业务，涉及到很多跑批作业，而且作业间互相依赖，有分支，有汇总的场景特别多，比如：每日夜间批扣，财务分录，利率计算&减免等等；
-
数据量大：互联网消费金融业务的线上交易量的增长，无疑会大大增加作业 Job 的数据量。而且批量作业的数据跟交易量是 10 倍级别的增长，比如一笔贷款分 12 期还（一年 12 个月），这样就是 1：12 的关系。
-
监控的难度增加。
互联网消费金融作业调度 Job 的架构设计¶
作业调度 Job 分布式设计¶
支持集群部署，提升调度系统可用性，同时提升任务处理能力。构建作业注册中心，实现的全局作业注册控制中心。用于注册，控制和协调分布式作业执行。
作业调度 Job 分片设计 前面的章节也介绍过分片设计的好处，能够并行处理海量数据，支持动态横向扩展，提升系统的处理能力。将任务拆分为 n 个任务项后，各个服务器分别执行各自分配到的任务项。一旦有新的服务器加入集群，或现有服务器下线，将在保留本次任务执行不变的情况下，下次任务开始前触发任务重分片。
作业调度 Job 监控设计¶
互联网消费金融作业 Job 的监控，涉及到的方面：
- 作业的进度监控；
- 作业状态监控，是否正常或异常；
- 异常分类与报警；
- 消息通知。
互联网消费金融作业调度 Job 的架构选型¶
-
Quartz ：Java 事实上的定时任务标准。但 Quartz 关注点在于定时任务而非数据，并无一套根据数据处理而定制化的流程。虽然 Quartz 可以基于数据库实现作业的高可用，但缺少分布式并行调度的功能
-
TBSchedule ：阿里早期开源的分布式任务调度系统。代码略陈旧，使用 timer 而非线程池执行任务调度。众所周知，timer 在处理异常状况时是有缺陷的。而且 TBSchedule 作业类型较为单一，只能是获取/处理数据一种模式。还有就是文档缺失比较严重
-
elastic-job ：当当开发的弹性分布式任务调度系统，功能丰富强大，采用 zookeeper 实现分布式协调，实现任务高可用以及分片，目前是版本 2.15，并且可以支持云开发
-
Saturn ：是唯品会自主研发的分布式的定时任务的调度平台，基于当当的 elastic-job 版本 1 开发，并且可以很好的部署到 docker 容器上。
-
xxl-job : 是大众点评员工徐雪里于 2015 年发布的分布式任务调度平台，是一个轻量级分布式任务调度框架，其核心设计目标是开发迅速、学习简单、轻量级、易扩展