“书中自有黄金屋”,介绍一本和“钱”有关的书

本文涉及的产品
云原生大数据计算服务MaxCompute,500CU*H 100GB 3个月
云原生大数据计算服务 MaxCompute,5000CU*H 100GB 3个月
简介: 介绍这本和“钱”有关的《金融级IT架构》。

上周开始写了第一篇和“书”有关的文章,而今天就是四二三读书节,所以怕是最近一段时间的文章都会和“书”有关了,对于上次介绍的几本“阿里人写的书”,这次将聚焦其中的一本。

1.jpg

本着“Life is Random”的原则,这次还是按照片中书脊的从左到右顺序给大家介绍,第一本就是和“钱”有关的《金融级IT架构》。

2.jpg

《金融级IT架构—— 数字银行的云原生架构解密》

本书是网商银行技术编委会集体的集体创作。网商银行是由蚂蚁集团发起,银监会批准成立的中国首批民营银行之一,也是第一家将核心系统架构在金融云上的科技银行。

银行核心系统为什么要上云?开放式银行的建设需求可能是其中最大的推手,那么什么是开放式银行,按照书中引用《银行4.0》作者布莱特·金的观点:“银行服务无处不在,就是不在银行网点”。

开放式银行脱离了固定的银行网点,顾客使用银行服务的方式发生了改变,银行顾客将依托无处不在的移动互联网来使用金融服务,理论上,银行IT基础设施可能要同时承载整个移动互联网上用户的访问,再加上我国移动互联网的普及率和巨大的人口基数,这对银行的IT基础设施提出了全新的要求,为此网商银行基于金融云构建了“三地五中心”的IT基础架构,从而使得网商银行具备了“随时随地、按需扩容、随时切换”的全业务容灾能力。而“三地五中心”的落地有赖于如下技术:金融云架构、分布式数据库、单元化及精细化路由控制等。

在金融云架构的选型部分,本书介绍了为什么要选择DDH专有宿主机、云盘存储类型的选型、云网络的架构规划等内容。

DDH是指由一个租户独享物理资源的云主机。专有宿主机的使用者不需要与其他租户共享云主机的物理资源,可以获得这台物理服务器的物理属性信息,包括CPU数量(Socket数)、物理CPU核数、内存大小,可以根据宿主机规格创建指定规格族的ECS实例。

专有宿主机与普通云服务器的对比
3.jpg

(图片来自阿里云官网)

DDH专有宿主机相对于普通的云服务器来说提供了一种“单租户”环境,正好适用于金融行业的高安全、强监管需求。

在分布式数据库部分、介绍了三地五中心架构下的数据副本个数以及分布策略、流量调拨设计、分库分表设计、缓存架构等内容。

这里重点介绍一下三地五中心的数据分布,三地五中心共有五个数据副本,其中这“三地”中前“两地”具有两个数据中心,最后一地有一个数据中心。三地五中心架构最多允许存在两个异常节点。为了保证这一点,因此需要在进行数据写入时保证有三个节点完成数据写入,即在两个同城数据中心完成数据写入的同时完成跨城市的实时同步,具体耗时与城市间的距离相关, 假如在杭州和上海两地进行实时同步,则需要6~8毫秒。
最后一地有一个节点,无法满足同城的容灾要求,因此不部署应用服务,只提供日志副本存储,并协助进行一致性协议的投票。

介绍完了三地五中心,让我们再来看看单元化。
单元化架构是在多机房部署的前提下,对于业务处理能力进行逻辑上的单元划分,让业务流量按照一定的规则分配到各个单元中,并尽量确保用户流量始终收敛到一个单元内的架构。这里既要保证应用流量分配到确定的应用容器还要保证数据的访问分配到确定的数据库分库。

单元化和精细化路由机制让多个数据中心可以同时对外提供服务,从而实现了“多活”。为了实现“多活”,就是把数据水平拆分的思想升级到接入层,通过在前端基于一定的业务逻辑将客户的流量拆分到不同的“逻辑数据中心”进行处理,逻辑数据中心都有对应的“逻辑灾备中心”这些“逻辑数据中心和灾备中心”分布到不同的物理数据中心,从而实现了物理数据中心故障后的快速切换,在平时所有的物理数据中心都处于活跃状态,因此资源的浪费就被控制在最低限度。

为了单元化架构的高效运作,每一个逻辑数据中心都有如下四个重要特征:

  • 自包含、每一个业务单元都完整包含完成业务所需的计算和存储能力。
  • 松耦合、单元之间只允许通过服务进行调用访问,不允许直接访问其他单元中的数据库或存储。
  • 故障独立、一个单元的故障不会影响到其他单元。
  • 容灾、单元之间相互备份,每一个单元发生故障时都可以切换到其他单元继续对外提供服务。

为了进行精细化的路由控制,将逻辑数据中心分成三类:

  • 分区单元(RZone)、按照用户维度进行拆分的核心业务系统,保证不同用户的业务在不同的单元内处理。
  • 共享单元(CZone)、部署不可拆分的数据和服务,目的是解决跨城市通信延迟过高的问题,CZone内的数据或者服务会被RZone频繁的访问,每个城市至少都要部署一个Czone。
  • 全局单元(GZone)、部署未按用户维度进行拆分的服务,主要用于一些长尾应用或新用户注册。

在设计整个单元化架构时遵循了D-I-D原则:在设计阶(Design)段需要保证现有架构具备几十倍甚至无上限的可扩展性;在实施(Implement)阶段,可将需求缩小到数倍~几十倍的容量增长;在部署(Deploy)阶段,基于成本或现实考虑可以将系统部署规模控制在日常水平1.5倍即可,基于金融云和单元化架构来实现快速的弹性扩展。

而在将业务和应用完成改造实现单元化架构时有一个十三条原则:

  • 原则一、在单元化改造过度阶段,部分原则可不遵循。这一条保证了在业务和应用在过度到单元化架构时存在一定的“灰度”。
  • 原则二、单元化改造分阶段完成,优先确保部分流量路由正确。单元化改造过程中可分阶段进行“部分”流量的路由链路改造,不要求全部正确。
  • 原则三、服务要跟着数据走、无法拆分的数据需迁出分库集群。对于破坏单元化规则的数据需要迁出。
  • 原则四、异步化处理需要确保路由位不丢失。再重新“捞取”异步数据进行处理时需要保证路由的正确。
  • 原则五、任何方案都要确保链路延时、数据时延在可接收范围内。
  • 原则六、GZone不能直接范围Rzone的数据或缓存。因为GZone的流量无法按照用户进行分片,若GZone访问RZone数据库或缓存将导致部分流量进行跨单元甚至跨城市范围,导致业务耗时增加。
  • 原则七、GZone可以访问CZone的数据库、缓存或服务。CZone自己并不产生数据,而是通过其他单元进行数据写入或者复制。
  • 原则八、RZone只处理本单元数据。
  • 原则九、RZone不能直接访问GZone数据库或缓存。若RZone需要访问GZone单元的数据或缓存,则需要将这部分操作改成服务的形式。
  • 原则十、RZone尽量少依赖GZone服务。单元化的核心就是让业务处理能够在一个单元内独立完成。
  • 原则十一、RZone可以访问CZone的数据库、缓存及服务。对于不能够按照用户维度进行划分的数据,同时为了保证所有的操作能够在同城数据中心完成,可以将这部分数据放入CZone中。
  • 原则十二、CZone不创造新的数据、数据都来自GZone或者Rzone。可以通过分布式数据的同步功能、消息队列的复制等进行数据同步。
  • 原则十三、CZone依赖方需接受数据同步时延影响。对于跨城的数据同步,数据延时通常超过5毫秒。

在业务应用实现了单元化架构以后,当出现像双十一这样的业务高峰时就能够以业务单元的形式实现快速的弹性扩展,快速提升整体业务处理能力,当业务高峰期过后,又能够非常便捷的释放资源,这就是弹性架构。这里新增加的临时业务单元被称为弹性业务单元,弹性业务单元的主要特征包括:

  • 局部性、常规业务单元需要包含全量的应用和数据而弹性业务单元只需要包含部分高流量的应用和数据。
  • 临时性、弹性业务单元的生命周期通常是比较短暂的,业务高峰一过,弹性业务单元处理的这部分请求就会弹回到常规业务单元,之后临时申请的资源也将被释放以降低成本。
  • 跨云、弹性业务单元通常会跨多个云,当本地云资源无法满足业务高峰需求时,可以申请其他云平台上的资源进行弹性扩容。

创建弹性业务单元并将部分流量分配到弹性业务单元的动作被称为“弹出”,而弹出的流量分为入口流量和内部流量两大类,内部流量的弹出又可以分成有状态弹出和无状态弹出,这里的有无状态主要是根据业务特性进行区分。例如交易的创建动作就属于无状态操作,可以在弹性业务单元新增一套独立的数据库专门承载同类操作,而账户的余额增健就属于有状态的操作,需要在原先的常规业务单元完成数据操作。

有了“弹出”自然就会有“弹回”,当业务高峰过后,可以通过“弹回”操作将流量重新分配回原先的常规业务单元。

三地五中心、单元化架构、弹性架构这些可以归类为网商银行整体IT架构中的“技术架构”,技术架构要支撑和跟随业务架构,为了能够让读者更好的理解金融级IT架构为什么要如此设计和实现,本书还对网商银行的业务架构进行了介绍:网商银行的整体业务定位是为了服务更多小微企业、个人消费者和农村客户,践行普惠金融使命,网商银行从开业之初即自我定位为“轻资产、交易型、平台化的互联网银行。”

根据定位,网商银行的数字化银行总体建设规划要点如下:

  • 云计算基础设施、将核心系统架构在云上,具备处理高并发金融交易、海量大数据和弹性扩容能力。建立“异地多活”跨地域金融级容灾体系,保障业务连续性。建设金融级云原生分布式架构和安全可信架构,为业务发展提供安全、稳定、高效和敏捷的基础设施。
  • 大数据风控体系、应用大数据风控技术实现“3-1-0”的信贷放款模式,即:3分钟审贷、1秒钟放款、全程0人工介入,大幅降低信贷成本,控制信用风险,提高服务效率。
  • 多端多渠道服务体系、通过小程序、SDK、API等多种形态,将银行服务植入电商、物流、供应链、支付等外部商业平台,实现对客户的全渠道、全场景触达,实现金融服务的全方位渗透,实现“无微不至,无所不在”的金融服务。
  • 智能运营营销体系、通过引入大数据分析,全面解读客户的行为、关系网络,生成客户画像,再根据产品特性、服务内容、客户习惯等进行深度挖掘,在不同的商业场景中,向不同的客户推荐不同的产品和服务,实现千人千面的个性化智能服务和精准触达。
  • 智能资产管理、应用大数据、人工智能技术,预测和防控流动性风险,优化金融市场、资产证券化等业务的交易成本和效率,优化总体资金成本,保障融资、支付、理财等业务健康、可持续运营。
  • 开放银行、应用开发平台、区块链、共享智能技术,联合商业生态系统、金融同业、政府等,实现金融能力开放、金融业务开放、数据安全融合与共同利用,建立开放、共赢的普惠金融合作生态,服务更多小微客户。

好了,这本《金融IT架构》就介绍到这里了,希望能够对您选择这本书有所帮助。

目录
相关文章
|
7月前
人生没有捷径,专注做好一件事就是捷径——《元智慧》读后
人生没有捷径,专注做好一件事就是捷径——《元智慧》读后
54 0
|
前端开发 JavaScript
如何书写一份好的互联网校招简历|牛气冲天新年征文
如何书写一份好的互联网校招简历|牛气冲天新年征文
|
架构师 程序员 CDN
|
Web App开发 编解码 缓存
云话题 | 第3期 你女朋友在买买买时,程序员小哥在干嘛?
年货节来了,你女朋友下单了吗?观看直播已经成为人们日常上网的习惯之一,直播购物作为其中的重要项目,销售额屡创新高。最近,天猫年货节刚刚开幕,淘宝直播中就涌入了不少的用户前来抢购,毕竟足不出户就可以买到全国甚至全球的年货,对热衷买买买的消费者们来说实在太方便了。那么,直播抢购背后到底蕴藏着哪些技术?平台在开发网络直播系统时为什么如此看重CDN?在高并发直播的当下,CDN的技术人员都需要关注什么?阿里云Edge Plus的第3期云话题,边缘酱将为你讲讲关于直播抢购与CDN的那些事。
4574 0
云话题 | 第3期 你女朋友在买买买时,程序员小哥在干嘛?
|
算法 架构师 Android开发
iOS开发者如何做到升职加薪到25k?6年开发 架构师笔记送给你!
对于我们绝大多数人来说,工作最基本的意义是我们可以通过自己的劳动换取酬劳来养活自己,尤其是对于刚毕业的学生,拥有一份全日制的工作意味着自己走出校园,踏上社会,自己真正开始独立起来。
iOS开发者如何做到升职加薪到25k?6年开发 架构师笔记送给你!
|
机器学习/深度学习 运维 JavaScript
【最受程序员欢迎的图书推荐】学习知识,什么时候都不晚,写书评,就有机会获得这些书
加班 -> 没空学习-> 总是写同等水平代码 ->无法提升代码质量 ->总是出Bug -> 总是需要修改-> 加班 -> ....如果这是你的日常,那么恭喜你,你距离被淘汰就不远了。
38367 0
|
数据可视化 算法
从新人到技术主管,他只用了2年
加入阿里云MVP,与行业大咖切磋
1155 0
|
供应链 小程序 安全
社区团购讲堂之敲黑板、划重点!社区团购哪些是考点?
任何一个行业要想持续发展,就要不断的汲取新事物的营养,跟上趋势的节奏,才能在激烈的市场竞争中脱颖而出,屹立不倒!社区团购之所以被资本市场青睐,其根本原因在于,社区团购符合了当下消费者的“潜在核心需求”。
|
C++
c++基础(上) 听课流水账
1、pass by value /   pass  by  pointer  /   pass  by  reference   pass by value:实参和形参不是同一个值,因此交换的是形参的值,当函数swap结束后,a和b的值并没有发生交换 pass  by pointer  and  pass by reference :实参和形参是相同的。
1273 0
|
Java 程序员
做为一名IT新人,必了解程序员与产品经理的恩怨情仇
近日《产品经理和程序员打起来了》的消息被疯传。通过这事件,我们需要了解与反思,产品经理与软件开发程序员到底应该如何配合,如何有效的合作,才达到共赢的状态?
1826 0