• 金融级IT架构:数字银行的云原生架构解密
  • 金融级IT架构:数字银行的云原生架构解密
  • 金融级IT架构:数字银行的云原生架构解密
  • 金融级IT架构:数字银行的云原生架构解密
  • 金融级IT架构:数字银行的云原生架构解密
21年品牌 40万+商家 超1.5亿件商品

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

新华书店全新正版书籍图书 保证_可开发票_极速发货支持7天无理由

52 4.8折 109 全新

库存3件

浙江嘉兴
认证卖家担保交易快速发货售后保障

作者网商银行技术编委会

出版社电子工业出版社

ISBN9787121414251

出版时间2021-07

装帧平装

开本16开

定价109元

货号31202866

上书时间2024-10-13

學源图书专营店

已实名 已认证 进店 收藏店铺

   商品详情   

品相描述:全新
商品描述
作者简介
本书的作者来自网商银行多个技术团队:__eol__ __eol__基础技术架构部:致力于通过分布式架构、云计算、大数据、AI等技术构建数字化银行技术底盘,从同城容灾到异地容灾,两地三中心到三地五中心,从单元化异地多活到混合云弹性架构再到云原生架构,从日常技术疑难杂症处理到容灾演练,应急响应,新数据中心建设,技术架构升级换代都能看见他们的身影,为全行业务发展构建高容量、高可靠、低成本、合规、高效、智能的基础技术底盘,探索前沿技术方向,与同行同业开展技术交流。__eol____eol__网商银行信息安全部:负责网商银行的信息安全,涵盖基础设施安全、应用安全、数据安全、威胁感知、红蓝演练、安全自动化/智能化等方向。团队成员均是各领域安全专家,在红蓝攻防、威胁情报、零信任、可信计算、隐私计算等领域有较多研究,致力于通过创新安全技术守护用户的数据与资金安全。未来愿景是让网商银行成为优选安全可信的银行,探索数字银行安全的很好实践,助力银行业数字化转型。__eol____eol__

目录
目  录
第1章  金融级架构面临的挑战1
1.1  容灾2
1.1.1  数据容灾4
1.1.2  应用容灾5
1.1.3  业务容灾7
1.1.4  部署结构7
1.2  容量10
1.2.1  应用可伸缩11
1.2.2  数据可伸缩13
1.2.3  数据中心可伸缩16
1.3  成本16
1.4  安全架构挑战18
1.5  研发运维效能20
1.6  技术风险防控20
1.7  应对思路22
1.7.1  微服务24
1.7.2 “异地多活”单元化28
1.7.3  弹性架构29
1.7.4  云计算30
1.7.5  云原生32
1.7.6  安全架构36
1.7.7  技术风险防控36
第2章  云基础设施架构41
2.1  金融基础设施的机遇和挑战42
2.1.1  金融基础设施的窘境43
2.1.2  云计算助力数字金融45
2.2  云产品选型46
2.2.1  云服务器46
2.2.2  云存储51
2.2.3  总结57
2.3  云网络规划57
2.3.1  网络拓扑整体设计57
2.3.2  专有网络VPC59
2.3.3  IP地址规划60
2.3.4  总结61
2.4  云产品架构61
2.4.1  整体架构61
2.4.2  高可用架构63
2.4.3  SWIFT架构64
2.4.4  总结64
2.5  云资源规划65
2.5.1  建设阶段65
2.5.2  运营阶段65
2.5.3  总结67
第3章  存储架构68
3.1  数据库部署架构72
3.1.1  分布式数据库73
3.1.2 “异地多活”之“三地五中心”76
3.1.3  数据访问路由策略80
3.1.4  多集群部署83
3.1.5  容器化部署84
3.2  数据库逻辑架构86
3.2.1  分库分表87
3.2.2  数据源高可用90
3.2.3  历史库91
3.3  缓存架构98
3.4  存储链路分析101
3.5  架构演进103
3.6  数据安全108
3.6.1  备份恢复108
3.6.2  存储加密111
第4章  云单元架构115
4.1  为什么需要云单元115
4.1.1  从集中式架构到分布式架构116
4.1.2  分布式系统架构演进117
4.1.3  微服务架构下的容灾和容量问题122
4.1.4  云单元架构的诞生124
4.2  云单元架构总览124
4.3  架构目标125
4.3.1  跨地域弹性部署126
4.3.2  全业务“多地多活”127
4.3.3  一体化研发运维127
4.3.4  海量交易处理能力128
4.4  云单元架构的特征128
4.4.1  架构特征129
4.4.2  逻辑架构130
4.5  单元化改造主要思想131
4.5.1  分而治之131
4.5.2  D-I-D原则132
4.5.3  十三条原则134
4.6  单元化流量路由139
4.6.1  路由规则设计139
4.6.2  HTTP流量路由142
4.6.3  RPC流量路由144
4.6.4  消息流量路由146
4.6.5  调度流量路由153
4.6.6  数据流量路由154
4.7  应用与数据单元化157
4.7.1  分布式应用158
4.7.2  分布式数据159
4.8  分布式中间件160
4.8.1  基础开发框架161
4.8.2  微服务平台164
4.8.3  分布式数据访问代理175
4.8.4  分布式可靠事务服务179
4.8.5  分布式消息队列181
4.8.6  分布式全链路跟踪182
4.9  业务单元化实践案例183
4.9.1  灵活多变的路由决策机制实现183
4.9.2  如何优雅地过渡到单元化架构186
4.9.3  如何实现跨地域单元数据一致性188
4.10  总结与展望190
第5章  混合云弹性架构191
5.1  弹出193
5.1.1  无状态弹出196
5.1.2  有状态弹出201
5.2  弹回203
第6章  云原生架构206
6.1  架构概览210
6.2  容器技术212
6.2.1  不可变基础设施214
6.2.2  容器化实践过程216
6.2.3  集群混部应用220
6.3  服务网格222
6.3.1  MOSN223
6.3.2  DBMesh227
6.4  SERVERLESS229
6.4.1  Ark Serverless232
6.4.2  模块化开发236
6.4.3  任务托管241
6.5  云原生研发流程243
6.5.1  云原生DevOps243
6.5.2  关于配置化的研发效能244
6.6  可信云原生246
6.6.1  安全可信架构246
6.6.2  安全容器248
6.6.3  服务鉴权249
6.6.4  链路加密251
6.6.5  数据访问鉴权253
6.7  云原生运维255
6.7.1  容器集群运维255
6.7.2  Mesh运维264
6.7.3  Sidecar运维269
6.7.4  Mesh的技术风险防控273
6.7.5  发布和运维平台统一277
6.8  云原生实战场景278
6.8.1  混部技术应用278
6.8.2  应用镜像化发布284
6.8.3  服务网格技术应用288
6.8.4  Serverless技术应用296
6.8.5  安全可信技术应用301
第7章  技术风险防控架构304
7.1  多级业务分区发布305
7.2  全站自动化变更防控307
7.3  资金安全309
7.3.1  资金安全简介309
7.3.2  资金安全防线310
7.3.3  资金安全防线运营315
7.3.4  小结317
7.4  全链路压测317
7.4.1  压测链路与仿真319
7.4.2  容量规划321
7.4.3  压测风险识别323
7.4.4  压测风险管理324
7.4.5  压测实战325
7.4.6  自动化压测327
7.4.7  云原生全链路压测328
7.5  大促技术保障329
7.5.1  大促活动保障台330
7.5.2  自动化预案331
7.5.3  限流熔断332
第8章  业务架构333
8.1  数字化转型下的银行业务架构333
8.1.1  数字化银行设立初衷335
8.1.2  数字化银行顶层设计335
8.1.3  数字化银行落地过程337
8.1.4  数字化银行效果呈现339
8.2  中台战略340
8.2.1  中台战略概述340
8.2.2  业务中台343
8.2.3  数据中台347
8.3  大数据与人工智能352
8.3.1  数据化风控353
8.3.2  智能流动性管理357
8.3.3  智能化运营361
8.4  金融开放363
8.4.1  金融场景开放365
8.4.2  金融机构协作367
第9章  安全可信架构369
9.1  安全架构概述369
9.2  默认安全机制371
9.2.1  问题背景371
9.2.2  解决思路372
9.2.3  实践落地373
9.3  可信纵深防御386
9.3.1  问题背景386
9.3.2  解决思路387
9.3.3  实践落地389
9.4  威胁感知与响应390
9.5  实战演练检验393
9.5.1  目标设定393
9.5.2  红队攻击规划393
9.5.3  实施演练394
9.5.4  实战演练规范395
9.5.5  复盘395
9.6  数字化与智能化395
第10章  未来展望403

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

主编推荐
"1.本书契合了当前银行业分布式架构转型趋势,内容是经过实践检验的靠前技术,不但适合金融科技从业者阅读,也适合传统IT架构人员、开发人员阅读!
2. 金融行业最重要的就是信任,安全、稳定给客户带来的信任,是一种无形的产品,支撑着所有金融业务,这个产品的构建需要强大的技术实力。书中的内容囊括了网商银行IT底盘涉及的关键技术,对网商银行在异地多活单元化、弹性架构、云原生、分布式存储、资源混部、安全可信等技术上的探索和实践做了详细的讲解,向读者呈现了众多核心技术细节,为如何构建安全和稳定的金融级技术架构提供了参考样本。"

精彩内容
4.8.1基础开发框架基础开发框架是一套用于分布式架构应用系统的快速、敏捷研发框架,拥有一整套全面的技术栈,能自动解决依赖下载、应用部署、健康检查、运维监控等研发效率相关问题。研发人员使用该基础开发框架,可将精力集中在业务代码编写上。基础开发框架还能实现对其他常用中间件的集成管理,通过独立可插拔的集成方式,对集成的中间件提供统一易用的编程接口,节约了开发时间,降低了后期维护成本。
开发框架在某种程度上也可以称为应用框架,或者一定程度上可以看作应用容器,当然这不一定完全正确。然而应用框架和应用容器总是成对出现的,比如早期的EJB(EnterpriseJavaBeans,企业JavaBeans)技术,EJB可以看作开发框架,但是需要运行在对应的EJB容器之上,例如Jboss、WebLogic、WebSphere等。由于EJB技术的臃肿,后面出现了像Spring、Guice这样的优秀的轻量级应用框架,配套的也不再是重量级的EJB容器,而是像Tomcat、Jetty这样的轻量级Servlet容器。
从EJB到Spring、Guice的演进带来的是业务研发效率的极大提升,然而随着互联网的快速发展,业务的复杂度与日俱增,原本单一的应用架构开始向分布式架构演进,分布式架构转型过程中业务系统无可避免地需要去集成众多的分布式中间件,以达到分布式架构改造的目的。然而中间件的接入是存在一定复杂度和理解成本的,这会对研发效率造成一定的负面影响,原本提供单一IOC(InversionofControl,控制反转)、AOP(AspectOrientedProgramming,面向切面编程)、MVC(ModelViewController,模型-视图-控制器)功能的Spring无法继续满足业务需求。面对挑战,Spring框架也在快速发展。近些年来产生的SpringBoot面对当前场景给出了不错的解决方案。与原先的Spring相比,SpringBoot省略了之前大量烦琐的XML配置,自动装配机制可以快速集成原本需要大量配置才可以支持的能力,而SpringBootStarter的出现进一步扩展了这种自动化装配能力,大量的第三方中间件组件、框架以Starter形式提供相关能力支持,业务如果需要引入每个中间件产品对应的能力,只需要依赖对应产品的Starter即可,再也不需要繁杂的配置以及理解成本,而且可以形成统一的接入规范,可以对公司技术体系的演进和发展起到很好的促进作用。
那么一个优秀的应用框架到底是什么样的呢?这里提出一个说法——“技术价值观”,可以理解为,一个企业是否采纳某种技术的评判标准,技术价值观一定程度上左右了这家公司的技术发展和演进方向。和其他价值观不同,大部分企业的技术价值观都是一致或相似的,或者说有一个大家公认的标准,这个标准其实可以理解为每种技术在业界的主流发展和演进方向,比如SpringBoot、Kubernetes,它们代表了应用框架和调度的主流技术价值观。网商银行内部的应用框架同样也遵从这个主流的技术价值观,而且在这之上还有着大量的技术实践和创新。内部大量使用的开发框架一共有两个,一个是构建在OSGi(OpenServiceGatewayInitiative,开放服务网关协议)容器之上的框架技术,内部称之为SOFA4,对应的运行容器内部称之为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为应用集成内部的中间件能力提供了极大的便利,通过制定一套标准的注解和XMLXSD规范,应用只需要使用标准的注解或者XML元素进行配置,即可集成相关产品能力,整个过程完全屏蔽了分布式和单元化架构的复杂度,让研发人员更加专注于业务逻辑,而不用关注底层框架的复杂性。所以说开发框架并不仅仅是应用框架和应用容器,也不仅仅是某一种技术,而是一整套用于提升业务研发效率的工具,是一个完整的研发生态圈。

—  没有更多了  —

以下为对购买帮助不大的评价

此功能需要访问孔网APP才能使用
暂时不用
打开孔网APP