中图网

>

操作系统/系统开发

>

其他

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

作者：网商银行技术编委会

出版社：电子工业出版社出版时间：2021-07-01

开本：其他页数： 432

本类榜单：计算机/网络销量榜

中图价:¥68.7(6.3折) 定价 ~~¥109.0~~ 登录后可看到会员价

加入购物车收藏

运费6元，满39元免运费

?新疆、西藏除外

本类五星书更多>

>
决战行测5000题(言语理解与表达)

决战行测5000题(言语理解与表达)

¥38.8¥88
>
软件性能测试.分析与调优实践之路

软件性能测试.分析与调优实践之路

¥49.3¥69
>
第一行代码Android

第一行代码Android

¥58.4¥99
>
深度学习

深度学习

¥92.4¥168
>
Unreal Engine 4蓝图完全学习教程

Unreal Engine 4蓝图完全学习教程

¥72.2¥168
>
深入理解计算机系统-原书第3版

深入理解计算机系统-原书第3版

¥104.3¥139
>
Word/Excel PPT 2013办公应用从入门到精通-(附赠1DVD.含语音视频教学+办公模板+PDF电子书)

Word/Excel PPT 2013办公应用从入门到精通-(附赠1DVD.含语音视频教学+办公模板+PDF电子书)

¥21¥49.9

买过本商品的人还买了

人工智能导论-面向非计算机专业
李德毅主编；于剑执行主编；中国人工智能学
¥15.7~~¥49.0~~

商品详情
商品评论(0条)

中图价:¥68.7 加入购物车

版权信息
本书特色
内容简介
目录
节选
作者简介

金融级IT架构:数字银行的云原生架构解密版权信息

ISBN：9787121414251
条形码：9787121414251 ; 978-7-121-41425-1
装帧：一般胶版纸
册数：暂无
重量：暂无
所属分类：
计算机/网络
>
操作系统/系统开发
>
其他

金融级IT架构:数字银行的云原生架构解密本书特色

适读人群：金融科技从业者、传统IT架构人员、开发人员1.本书可以称得上架构书中的“战斗机”了！契合当前银行业分布式架构转型趋势，内容是经过实践检验的领先技术，不但适合金融科技从业者阅读，也适合传统IT架构人员、开发人员阅读！上架不足半年，印刷4次，印量强势破万册！被技术人顶礼膜拜式地选择阅读！！！ 2. 金融行业*重要的就是信任，安全、稳定给客户带来的信任，是一种无形的产品，支撑着所有金融业务，这个产品的构建需要强大的技术实力。书中的内容囊括了网商银行IT底盘涉及的关键技术，对网商银行在异地多活单元化、弹性架构、云原生、分布式存储、资源混部、安全可信等技术上的探索和实践做了详细的讲解，向读者呈现了众多核心技术细节，为如何构建安全和稳定的金融级技术架构提供了参考样本。

金融级IT架构:数字银行的云原生架构解密内容简介

《金融级IT架构：数字银行的云原生架构解密》介绍了网商银行成立至今的IT技术架构演进路线，涵盖了分布式、单元化、弹性混合云、云原生多个基础架构领域，同时介绍了技术风险、安全可信、业务架构等多方面的技术实践经验，我们希望和读者分享网商银行在金融级IT技术上做的独特探索，跟大家探讨数字化时代金融级IT架构的发展方向。本书作者是网商银行核心架构师，深度参与了相关技术方案从前期设计到后期投产的完整过程，内容新且非常不错。本书以网商银行自身技术实践为主线展开，讲述的内容代表了靠前的技术方向，相关技术经过了真实的生产环境锤炼，包含了网商银行技术团队独到的实践经验，书中阐述的核心技术荣获中国人民银行颁发的2019年度"银行科技发展奖”二等奖。本书填补了市场空白，契合当前银行业分布式架构转型趋势，对打造金融级分布式架构具有借鉴意义，相关技术经过了大规模的生产环境验证，在分布式架构领域具有靠前水平，适合从事分布式、云原生架构建设，以及金融级高并发、高可靠、高容量系统打造的金融IT从业者，或对此有兴趣的读者。本书是一本不可或缺的技术指导书和技术决策参考用书。

金融级IT架构:数字银行的云原生架构解密目录

第1章金融级架构面临的挑战

1.1 容灾

1.1.1 数据容灾

1.1.2 应用容灾

1.1.3 业务容灾

1.1.4 部署结构

1.2 容量

1.2.1 应用可伸缩

1.2.2 数据可伸缩

1.2.3 数据中心可伸缩

1.3 成本

1.4 安全架构挑战

1.5 研发运维效率

1.6 技术风险防控

1.7 应对思路

1.7.1 微服务

1.7.2 “异地多活”单元化

1.7.3 弹性架构

1.7.4 云计算

1.7.5 云原生

1.7.6 安全架构

1.7.7 技术风险防控

第2章云基础设施架构

2.1 金融基础设施的机遇和挑战

2.1.1 金融基础设施的窘境

2.1.2 云计算助力数字金融

2.2 云产品选型

2.2.1 云服务器

2.2.2 云存储

2.2.3 总结

2.3 云网络规划

2.3.1 网络拓扑整体设计

2.3.2 专有网络VPC

2.3.3 IP地址规划

2.3.4 总结

2.4 云产品架构

2.4.1 整体架构

2.4.2 高可用架构

2.4.3 SWIFT架构

2.4.4 总结

2.5 云资源规划

2.5.1 建设阶段

2.5.2 运营阶段

2.5.3 总结

第3章存储架构

3.1 数据库部署架构

3.1.1 分布式数据库

3.1.2 “异地多活”之“三地五中心”

3.1.3 数据访问路由策略

3.1.4 多集群部署

3.1.5 容器化部署

3.2 数据库逻辑架构

3.2.1 分库分表

3.2.2 数据源高可用

3.2.3 历史库

3.3 缓存架构

3.4 存储链路分析

3.5 架构演进

3.6 数据安全

3.6.1 备份恢复

3.6.2 存储加密

第4章云单元架构

4.1 为什么需要云单元

4.1.1 从集中式架构到分布式架构

4.1.2 分布式系统架构演进

4.1.3 微服务架构下的容灾和容量问题

4.1.4 云单元架构的诞生

4.2 云单元架构总览

4.3 架构目标

4.3.1 跨地域弹性部署

4.3.2 全业务“多地多活”

4.3.3 一体化研发运维

4.3.4 海量交易处理能力

4.4 云单元架构的特征

4.4.1 架构特征

4.4.2 逻辑架构

4.5 单元化改造主要思想

4.5.1 分而治之

4.5.2 D-I-D原则

4.5.3 十三条原则

4.6 单元化流量路由

4.6.1 路由规则设计

4.6.2 HTTP流量路由

4.6.3 RPC流量路由

4.6.4 消息流量路由

4.6.5 调度流量路由

4.6.6 数据流量路由

4.7 应用与数据单元化

4.7.1 分布式应用

4.7.2 分布式数据

4.8 分布式中间件

4.8.1 基础开发框架

4.8.2 微服务平台

4.8.3 分布式数据访问代理

4.8.4 分布式可靠事务服务

4.8.5 分布式消息队列

4.8.6 分布式全链路跟踪

4.9 业务单元化实践案例

4.9.1 灵活多变的路由决策机制实现

4.9.2 如何优雅地过渡到单元化架构

4.9.3 如何实现跨地域单元数据一致性

4.10 总结与展望

第5章混合云弹性架构

5.1 弹出

5.1.1 无状态弹出

5.1.2 有状态弹出

5.2 弹回

第6章云原生架构

6.1 架构概览

6.2 容器技术

6.2.1 不可变基础设施

6.2.2 容器化实践过程

6.2.3 集群混部应用

6.3 服务网格

6.3.1 MOSN

6.3.2 DBMesh

6.4 Serverless

6.4.1 Ark Serverless

6.4.2 模块化开发

6.4.3 任务托管

6.5 云原生研发流程

6.5.1 云原生DevOps

6.5.2 关于配置化的研发效率

6.6 可信云原生

6.6.1 安全可信架构

6.6.2 安全容器

6.6.3 服务鉴权

6.6.4 链路加密

6.6.5 数据访问鉴权

6.7 云原生运维

6.7.1 容器集群运维

6.7.2 Mesh运维

6.7.3 Sidecar运维

6.7.4 Mesh的技术风险防控

6.7.5 发布和运维平台统一

6.8 云原生实战场景

6.8.1 混部技术应用

6.8.2 应用镜像化发布

6.8.3 服务网格技术应用

6.8.4 Serverless技术应用

6.8.5 安全可信技术应用

第7章技术风险防控架构

7.1 多级业务分区发布

7.2 全站自动化变更防控

7.3 资金安全

7.3.1 资金安全简介

7.3.2 资金安全防线

7.3.3 资金安全防线运营

7.3.4 小结

7.4 全链路压测

7.4.1 压测链路与仿真

7.4.2 容量规划

7.4.3 压测风险识别

7.4.4 压测风险管理

7.4.5 压测实战

7.4.6 自动化压测

7.4.7 云原生全链路压测

7.5 大促技术保障

7.5.1 大促活动保障台

7.5.2 自动化预案

7.5.3 限流熔断

第8章业务架构

8.1 数字化转型下的银行业务架构

8.1.1 数字化银行设立初衷

8.1.2 数字化银行顶层设计

8.1.3 数字化银行落地过程

8.1.4 数字化银行效果呈现

8.2 中台战略

8.2.1 中台战略概述

8.2.2 业务中台

8.2.3 数据中台

8.3 大数据与人工智能

8.3.1 数据化风控

8.3.2 智能流动性管理

8.3.3 智能化运营

8.4 金融开放

8.4.1 金融场景开放

8.4.2 金融机构协作

第9章安全可信架构 P369

9.1 安全架构概述

9.2 默认安全机制

9.2.1 问题背景

9.2.2 解决思路

9.2.3 实践落地

9.3 可信纵深防御

9.3.1 问题背景

9.3.2 解决思路

9.3.3 实践落地

9.4 威胁感知与响应

9.5 实战演练检验

9.5.1 目标设定

9.5.2 红队攻击规划

9.5.3 实施演练

9.5.4 实战演练规范

9.5.5 复盘

9.6 数字化与智能化

第10章未来展望 P403

附录A 本书插图索引 P406

展开全部

金融级IT架构:数字银行的云原生架构解密节选

4.8.1 基础开发框架基础开发框架是一套用于分布式架构应用系统的快速、敏捷研发框架，拥有一整套全面的技术栈，能自动解决依赖下载、应用部署、健康检查、运维监控等研发效率相关问题。研发人员使用该基础开发框架，可将精力集中在业务代码编写上。基础开发框架还能实现对其他常用中间件的集成管理，通过独立可插拔的集成方式，对集成的中间件提供统一易用的编程接口，节约了开发时间，降低了后期维护成本。开发框架在某种程度上也可以称为应用框架，或者一定程度上可以看作应用容器，当然这不一定完全正确。然而应用框架和应用容器总是成对出现的，比如早期的EJB（Enterprise Java Beans，企业Java Beans）技术，EJB可以看作开发框架，但是需要运行在对应的EJB容器之上，例如Jboss、WebLogic、WebSphere等。由于EJB技术的臃肿，后面出现了像Spring、Guice这样的优秀的轻量级应用框架，配套的也不再是重量级的EJB容器，而是像Tomcat、Jetty这样的轻量级Servlet容器。从EJB到Spring、Guice的演进带来的是业务研发效率的极大提升，然而随着互联网的快速发展，业务的复杂度与日俱增，原本单一的应用架构开始向分布式架构演进，分布式架构转型过程中业务系统无可避免地需要去集成众多的分布式中间件，以达到分布式架构改造的目的。然而中间件的接入是存在一定复杂度和理解成本的，这会对研发效率造成一定的负面影响，原本提供单一IOC（Inversion of Control，控制反转）、AOP（Aspect Oriented Programming，面向切面编程）、MVC（Model View Controller，模型-视图-控制器）功能的Spring无法继续满足业务需求。面对挑战，Spring框架也在快速发展。近些年来产生的SpringBoot面对当前场景给出了不错的解决方案。与原先的Spring相比，SpringBoot省略了之前大量烦琐的XML配置，自动装配机制可以快速集成原本需要大量配置才可以支持的能力，而SpringBoot Starter的出现进一步扩展了这种自动化装配能力，大量的第三方中间件组件、框架以Starter形式提供相关能力支持，业务如果需要引入每个中间件产品对应的能力，只需要依赖对应产品的Starter即可，再也不需要繁杂的配置以及理解成本，而且可以形成统一的接入规范，可以对公司技术体系的演进和发展起到很好的促进作用。那么一个优秀的应用框架到底是什么样的呢？这里提出一个说法——“技术价值观”，可以理解为，一个企业是否采纳某种技术的评判标准，技术价值观一定程度上左右了这家公司的技术发展和演进方向。和其他价值观不同，大部分企业的技术价值观都是一致或相似的，或者说有一个大家公认的标准，这个标准其实可以理解为每种技术在业界的主流发展和演进方向，比如SpringBoot、Kubernetes，它们代表了应用框架和调度的主流技术价值观。网商银行内部的应用框架同样也遵从这个主流的技术价值观，而且在这之上还有着大量的技术实践和创新。内部大量使用的开发框架一共有两个，一个是构建在OSGi（Open Service Gateway Initiative，开放服务网关协议）容器之上的框架技术，内部称之为SOFA 4，对应的运行容器内部称之为CloudEngine，另外一个开发框架称为SOFABoot，SOFABoot构建在SpringBoot之上，是对SpringBoot的有效扩展和优化，同时也是内部特定需求下的产物。这里重点介绍一下SOFABoot，因为流行的SpringBoot框架更为大家所熟知。就像前面提到的，SpringBoot的自动装配机制和Starter扩展机制已经给研发效率带来了极大的提升，那为什么还要创造一个SOFABoot框架？它又有哪些优势？其实这里并没有从头创造一个全新的框架，本质上SOFABoot就是SpringBoot，但是进行了相关功能的丰富和扩展，这主要涉及以下几方面。 1. 类隔离的支持类冲突无疑是Java开发者“*大的痛”，有过几年经验的Java开发人员应该都有较为丰富的类冲突解决经验，规范的第二方、第三方依赖可以通过releaseNote进行版本升级，而某些管理不善的依赖只能靠版本试错，或者逐个反编译精确查找版本。更有某些场景中的间接依赖和直接依赖产生了版本冲突，解决这种冲突往往需要耗费大量时间，甚至在某些场景中不得不去推动相关依赖方进行升级才能解决，严重阻碍了业务的迭代效率。而SOFABoot自身集成了强大的、轻量级的类隔离框架可以完美解决这类问题，通过简单的配置即可完成对冲突类的隔离，让你可以专注于业务代码的开发。 2. 多模块隔离大型项目的开发需要有良好的模块划分方案，然而传统的模块划分均是以人为规约的形式进行的，而这在实际运行时是很难有约束力的。事实说明，在一个项目迭代的过程中很难长期遵守开发规约，因为一个长久的项目往往会经历多个研发人员，每个人对研发规约的理解又是存在差异的，久而久之，逻辑的模块划分将无法起到很好的作用。说到模块隔离，大家可能会想到OSGi，但是OSGi本身比较复杂，并不能为大部分互联网公司所接受，而SOFABoot提供了一种轻量级的模块隔离方案，每个模块都是单独的Spring上下文，每个模块可以暴露哪些服务能按照规范进行配置，未暴露的服务其他模块是无法进行调用的，而且独立的Spring上下文设计给后续服务拆分提供了极大的便利，当前的一个模块只需要少量的调整就可以作为一个单独的项目进行开发部署。想一想如果是以逻辑模块的方式进行划分，项目拆分会多么困难和复杂，因为内部服务也可能被多个其他模块所依赖，光拆分前的梳理和改造就要花费大量的时间，成本无法估计。 3. 部分功能扩展这里主要说两点，一是SOFABoot提供了Readiness检查能力，SpringBoot提供的HealthCheck只能反映当前系统是否被监控，但是无法反映是否已经做好了可以接受请求的准备。这一点其实是很重要的，比如应用的平滑上下线就比较依赖这个功能，如果在应用还没达到可以接收请求的状态之前就把请求发过去，就会引起应用请求的报错，而对于一个拥有大量容器的应用而言，为了提升发布速度，单个发布批次会包含较多的容器，如果这里处理不好，就会引起服务调用方的抖动，甚至对业务造成影响。二是支持了日志空间隔离，依赖日志空间隔离可以方便有效地对日志进行隔离管理，比如网商银行内部的中间件系统通过接入日志隔离把每个产品的日志都单独输出到指定的目录，有效防止了日志的相互污染，对问题排查和监控指标的接入都提供了极大的便利。除了上面提到的两方面，SOFABoot为了支持内部的某些特殊场景，还增加了很多不错的功能，这里不再一一赘述。除了SOFABoot这样优秀的应用框架，开发框架还包含了很多高效的支持工具。比如拥有完善的IDEA研发插件，利用该插件可以快速生成各类型项目代码，安全快速地进行相关组件的升级，快速进行应用代码部署和自动化测试等。统一的技术栈维护了应用的基础软件依赖，让我们可以方便快捷地进行统一的版本升级和安全问题修复。 *后再回到SOFABoot框架本身，SOFABoot为应用集成内部的中间件能力提供了极大的便利，通过制定一套标准的注解和XML XSD规范，应用只需要使用标准的注解或者XML元素进行配置，即可集成相关产品能力，整个过程完全屏蔽了分布式和单元化架构的复杂度，让研发人员更加专注于业务逻辑，而不用关注底层框架的复杂性。所以说开发框架并不仅仅是应用框架和应用容器，也不仅仅是某一种技术，而是一整套用于提升业务研发效率的工具，是一个完整的研发生态圈。

金融级IT架构:数字银行的云原生架构解密作者简介

基础技术架构部致力于通过分布式架构、云计算、大数据、AI等技术构建数字化银行技术底盘，从同城容灾到异地容灾，从“两地三中心”到“三地五中心”，从“单元化异地多活”到混合云弹性架构再到云原生架构，从日常技术疑难杂症处理到容灾演练、应急响应、新数据中心建设、技术架构升级换代都能看见他们的身影，为全行业务发展构建大容量、高可靠、低成本、合规、高效、智能的基础技术底盘，探索前沿技术方向，与同行开展技术交流。信息安全部负责网商银行的信息安全，涵盖基础设施安全、应用安全、数据安全、威胁感知、红蓝演练、安全自动化/智能化等方向。团队成员均是各领域安全专家，在红蓝攻防、威胁情报、零信任、可信计算、隐私计算等领域有较多研究，致力于通过创新安全技术守护用户的数据与资金安全。未来愿景是让网商银行成为更安全可信的银行，探索数字银行安全的最佳实践，助力银行业数字化转型。业务架构部负责网商银行所有金融产品和商业模式在企业级架构层面的顶层设计，同时也是网商银行中后台系统的核心建设者。团队成员负责全行信息标准制定、企业级架构治理，同时带领技术团队负责产品中台、财务计量工具、财务核算、管理会计、金融同业、智能资产负债管理等多领域多平台的研发落地。团队成员拥有传统大行、互联网金融企业等的从业经历，具备丰富的金融领域业务经验和深度解决方案的设计能力，擅长以创新型技术、平台化理念和智能化思想站在企业级视角，解决全局性的业务与技术难题。未来整个团队期望在普惠金融、数字化银行、交易银行等创新业务场景下再创佳绩。 SRE团队主要负责网商银行的运维及高可用、资金安全能力建设，围绕变更风险防控，线上故障的快速发现、定位、自愈，日常风险发现等平台能力，期望打造一套基于分布式架构的高可用、资金安全的技术风险防控平台，并通过持续运营，提升网商银行的可持续服务能力，助力网商业务发展。质量与技术风险部负责建立和持续完善网商银行的产品研发运维体系，构建可靠、安全的生产机制，建立从产品立项到产品需求、系统设计、系统编码、系统测试、系统发布，再到产品试运行及推广、持续监督运营与优化，最后到产品下线的全生命周期的规范、科学的产品研发流程。致力于革新传统测试手段，沉淀风险技术能力，通过数据化积累和智能化实践提效降本。未来愿景是打造网商银行金融级安全底盘，保持持续稳定和安全，并建立一支业务精湛、技术一流、使命必达的质量与技术风险团队。

商品评论(0条)

写书评赚书币

暂无评论……

书友推荐