新書推薦：
《
小学生C++趣味编程从入门到精通 青少年软件编程等级考试（C语言）学习用书
》
售價：HK$
102.4
《
新知文库精选·一念之差：关于风险的故事与数字
》
售價：HK$
78.2
《
道德自我的伦理根基——教化论视野下的现代性道德哲学批判
》
售價：HK$
101.2
《
投诉是礼物：从投诉中学习经验并恢复客户忠诚度的101个活动、练习及工具（实践版）
》
售價：HK$
67.9
《
白酒风云录 中国白酒企业史（1949-2024）：清香风起
》
售價：HK$
101.2
《
宋代社会经济史论集（增订版）（上下册）
》
售價：HK$
331.2
《
博弈论与社会契约（第1卷）：公平博弈
》
售價：HK$
124.2
《
海外中国研究·政治仪式与近代中国国民身份建构（1911—1929）
》
售價：HK$
101.2
|
| 編輯推薦： |
★涵盖应用上云所有的必会知识点，全面、细致、丰富、前沿。
★全书提供多个实操级案例，源自真实场景，具有可复用性。
★通过应用上云的全流程设计，揭示架构师成长的三个阶段。
|
| 內容簡介： |
十年前的云计算是以资源为中心的，而现在（2024 年），云计算是以应用为中心的。
本书分为 8 章，重点讲解云上应用的功能性设计、高可用设计、高并发设计、安全设计及可运维设计，介绍如何通过应用设计充分释放云平台的技术红利，快速实现业务构建。希望本书能为云计算领域的从业者提供一个清晰的方向，通过分享经验与方法帮助他们更好地探索、设计并优化应用，以更高效地应对不断变化的市场需求和技术挑战。
|
| 關於作者： |
贺阮
攻读博士期间的主要研究方向是云计算安全。曾先后任OpenStack基金会董事、ISO/IEC JTC1/SC38和ISO/IEC JTC1/SC27标样委员会委员、联合国国际电信联盟（ITU）云计算安全组副报告人，以及多个云计算学术会议、期刊编辑等职位，从各个维度见证了云计算行业的发展。
史冰迪
2015年毕业于中央财经大学计算机科学与技术专业，现任职于中国信息通信研究院，从事政务信息化项目管理工作，从另一个方向继续在政务信息化方向发力，不断努力将电子政务、数字政府等工作与各类新技术结合。
陆佳亮
上海交通大学巴黎卓越工程师学院副院长，上海市科学技术委员会入库评审专家，承担国家自然科学基金、上海市“创新行动”科研项目等重大项目。主要研究方向是人工智能赋能、云计算、大数据系统。
|
| 目錄：
|
目 录
第1章 应用上云简介 1
1.1 上云价值 2
1.1.1 业务价值 2
1.1.2 技术价值 3
1.2 上云路线 4
1.2.1 私有云 4
1.2.2 混合云 5
1.2.3 多云 5
1.3 上云策略 6
1.3.1 直接迁移 6
1.3.2 重新规划 7
1.3.3 不合适上云的应用 7
1.4 注意事项 8
第2章 应用的空间维度和时间维度 10
2.1 应用架构 11
2.1.1 架构概述 11
2.1.2 主流架构 13
2.1.3 本书定义 24
2.2 业务架构 25
2.2.1 业务场景 25
2.2.2 业务用例 26
2.2.3 业务实体 26
2.2.4 业务流程 26
2.3 数据架构 27
2.3.1 数据模型 27
2.3.2 数据实现 28
2.4 功能架构 30
2.4.1 系统用例图 30
2.4.2 业务功能架构 30
2.4.3 应用功能架构 33
2.4.4 面向数据与面向领域 38
2.5 实现架构 39
2.6 部署架构 40
2.6.1 物理架构 40
2.6.2 运行架构 41
2.7 应用生命周期 41
2.8 明确愿景 42
2.8.1 识别目标对象 42
2.8.2 度量价值 43
2.8.3 详细描述 43
2.8.4 上下文图 44
2.9 业务建模 45
2.9.1 业务建模概述 45
2.9.2 组织架构 46
2.9.3 业务领域 46
2.9.4 业务场景 51
2.9.5 业务建模小结 53
2.10 需求分析 54
2.10.1 需求分析概述 54
2.10.2 涉及角色 56
2.10.3 业务实体 56
2.10.4 业务流程 58
2.11 架构设计 60
2.11.1 架构设计概述 60
2.11.2 业务功能架构 61
2.12 领域驱动设计及架构设计 63
2.12.1 领域驱动设计概述 63
2.12.2 DDD中的基本概念 66
2.12.3 实施步骤 72
2.12.4 DDD与微服务 76
2.12.5 DDD与架构设计 76
2.13 技术实现 77
2.13.1 技术选型 77
2.13.2 代码开发 77
2.14 部署发布 77
2.15 线上运维 78
第3章 应用的功能性设计 80
3.1 应用功能架构 81
3.1.1 客户端 82
3.1.2 网络接入层 82
3.1.3 应用接入层 84
3.1.4 逻辑层 85
3.1.5 中间件层 88
3.1.6 数据库层 89
3.1.7 存储层 90
3.2 云上实现架构 90
3.2.1 网络接入层 91
3.2.2 应用接入层 94
3.2.3 逻辑层 97
3.2.4 中间件层 98
3.2.5 数据库层 99
3.2.6 存储层 100
3.3 云上应用实战案例：某大型实时对战游戏上云设计 100
3.3.1 业务概述 100
3.3.2 业务架构 101
3.3.3 功能架构 102
3.3.4 实现架构 105
3.3.5 部署架构 106
第4章 应用的高可用设计 108
4.1 高可用简介 109
4.1.1 应用故障及其原因分析 109
4.1.2 高可用的定义 110
4.1.3 高可用的实现方式 112
4.1.4 高可用的衡量指标 114
4.2 避免错误 117
4.2.1 代码 117
4.2.2 配置 128
4.3 控制影响 131
4.3.1 前置措施 131
4.3.2 资源冗余 133
4.3.3 故障资源隔离 139
4.3.4 数据库层 144
4.3.5 存储层 145
4.4 快速恢复（应用容灾） 146
4.4.1 应用容灾的设计思路 147
4.4.2 同城冷备 153
4.4.3 同城热备 155
4.4.4 异地冷备 156
4.4.5 两地三中心 157
4.4.6 同城双活/多活 158
4.4.7 异地多活（单元化） 164
4.4.8 发展阶段 168
4.4.9 案例：即时通信App的容灾设计 169
4.5 标准流程及演练 173
4.5.1 应急处理和响应流程 173
4.5.2 容灾演练 175
4.6 案例：日交易超10亿元的支付平台容灾方案 193
4.6.1 业务架构 194
4.6.2 业务功能架构 194
4.6.3 容灾方案演进 195
第5章 应用的高并发设计 199
5.1 高并发设计概述 200
5.1.1 高并发带来的问题 200
5.1.2 高并发问题产生的原因 201
5.1.3 高并发系统性能的衡量指标 202
5.1.4 高并发系统的设计原则 204
5.1.5 高并发与高可用 214
5.2 提高吞吐量 214
5.2.1 客户端 215
5.2.2 网络接入层 218
5.2.3 应用接入层 219
5.2.4 逻辑层 221
5.2.5 数据库层 242
5.2.6 存储层 250
5.3 缩短响应时间 251
5.3.1 网络接入层 251
5.3.2 应用接入层 253
5.3.3 逻辑层 257
5.3.4 调用保护 262
5.3.5 数据层 268
5.3.6 案例：K8s中Informer的缩短响应时间设计 272
5.4 过载保护 275
5.4.1 网络接入层 276
5.4.2 应用接入层 276
5.4.3 逻辑层 279
5.4.4 数据库层 281
5.4.5 存储层 285
5.5 案例一：某休闲闯关小程序游戏的高并发设计 287
5.5.1 优化前 287
5.5.2 优化后 288
5.6 案例二：某即时通信App上云设计 289
5.6.1 功能架构 290
5.6.2 业务架构 290
5.6.3 实现架构 291
5.6.4 部署架构 293
5.7 案例三：某支付平台百万QPS消费券 294
5.7.1 业务架构 294
5.7.2 实现架构 295
5.7.3 部署架构 299
5.7.4 活动效果 301
第6章 应用的安全设计 302
6.1 简介 303
6.1.1 责任分工 303
6.1.2 防护原则 304
6.1.3 云内租户安全 305
6.2 网络安全 306
6.2.1 网络接入层 306
6.2.2 应用接入层 310
6.2.3 案例：某手游后台服务的多层防护设计 312
6.3 系统安全 314
6.3.1 应用接入层 315
6.3.2 逻辑层 319
6.4 数据安全 322
6.4.1 数据安全建模 323
6.4.2 数据库层安全管理 324
6.4.3 存储层安全管理 326
6.5 预案及审计 326
6.5.1 安全预案 326
6.5.2 安全审计 327
第7章 应用的可运维设计 330
7.1 可运维性概述 331
7.1.1 目标 331
7.1.2 发展阶段 331
7.1.3 云上应用的可运维性 337
7.2 可观测性 338
7.2.1 可观测性概述 338
7.2.2 指标/监控/告警 342
7.2.3 日志 353
7.2.4 链路追踪 356
7.2.5 案例：健康码可观测性体系设计 359
7.3 日常操作 364
7.3.1 云上资源供给 365
7.3.2 应用部署/发布 368
7.3.3 日常维护 376
7.4 故障排查 380
7.4.1 故障告警 380
7.4.2 问题定位 382
7.4.3 故障恢复 385
7.4.4 根因分析 388
7.4.5 案例：某电商平台存储集群变更故障 389
第8章 应用上云总结与展望 392
8.1 云上/云下对比 393
8.1.1 IaaS供给和配置更为实时便利 393
8.1.2 PaaS管理和运维更为自动化 393
8.1.3 应用运行时管理全托管 394
8.2 上云的挑战 395
8.3 未来趋势 396
8.3.1 多云部署 396
8.3.2 云上应用的精细化运营 399
|
| 內容試閱：
|
大部分人更关心如何在股市投资上成功，查理·芒格最关心的却是为什么在股市投资上大部分人都失败了。这是《穷查理宝典》中关于芒格思维的大致刻画。
在芒格漫长的一生中，他持续不断地收集并研究各种各样的失败案例，并把失败的原因总结成做出正确决策前的检查清单，这使他在人生、事业的决策上几乎从不犯重大错误。我们对云上应用的设计也应如此，需要通过对各类故障进行分析，获得架构设计最佳实践——这里的“最佳”指的是犯最少的错误。
笔者还记得自己刚刚接手“上云迁移”业务时，有一个重要客户的线上商城应用上线仅仅 5 秒，就因为大量用户的争相访问及“黄牛”抢票软件的疯狂刷票而变得不可用。笔者当时就在想，要是有一本书，可以体系化地介绍在应用上云过程中需要考虑的方方面面，并且能结合实际案例把这些说清楚，就太好了！于是，笔者萌生了撰写本书的想法。
在后续的工作中，随着帮助越来越多的客户将原先的传统应用迁移上云，笔者逐步积累了云上应用知识体系，并且慢慢接触到了应用上云的各种案例——固然有许多通过应用上云改造支撑海量用户的正面案例，但更多的是反面案例——因为在应用上云的设计或流程上没有做到位。通过对各种反面案例进行分析，我们能够更好地设计和优化云上应用，使其满足高可用、高并发、安全和可运维的要求。
有了ChatGPT后，还有没有必要读书
在撰写本书期间，以ChatGPT为首的大语言模型逐步兴起，它们对“世界知识”的概括和抽象使人们逐渐产生一个疑问：有了ChatGPT后，还有没有必要读书？人们可以便捷地通过“提问”从大语言模型中获取任何需要的知识，那读书还有什么意义？
笔者在实际使用大语言模型的过程中发现，大语言模型的确可以快速、准确地给出我们需要的知识点，但对于“应用上云改造”这样的领域，大家真正需要的不是一个个知识点，而是一套完整的知识体系，这样的知识体系是ChatGPT远远无法给出的。读者在工作中遇到相关问题时，可以通过查询知识体系在诸多方案中选择最合适的解决方案，从全局的视角给出最优解。而大语言模型更多地基于“关键词提问”得出局部最合适的答案。
总结出完整的上云知识体系也是笔者撰写本书的一大初衷。结合这套知识体系和大语言模型的知识抽象能力、检索能力，笔者希望可以快速帮助读者在今后的应用上云工作中解决实际的问题。有了 ChatGPT后，我们其实更需要去阅读那些体系化的图书，为自己构建领域知识体系，方便后续更好地使用ChatGPT。希望大家明确——结构比内容更重要。
如何理解应用架构设计
对应用架构设计的讲解往往是一大难点。如果单纯地讲解理论知识，则会显得非常枯燥乏味，读者也很难将其与实际工作相结合。同时，读者往往觉得架构是过于抽象甚至有些“缥缈”的概念，听着好像懂了，但遇到实际问题时还是手足无措。
其实，应用架构设计有点儿像老子所说的“道可道，非常道”。笔者无法直接把观点灌输给读者，而需要读者通过实际的场景自行理解、领悟。这也是为什么笔者花费了大量的精力为本书搜集和整理了众多实际案例。笔者希望通过实际案例带领读者进入当时的场景，通过对实际案例的分析更进一步地巩固那些体系化的知识点。当然，为了避免纠纷，本书对实际案例做了脱敏处理。
架构师在日常工作中的真正价值是什么
其实本书所写的是云上应用的“理想国”，在现实中，它的实现难度非常大，而且需要各方面资源的配合——很多真正需要这种先进架构的应用都面临着各种历史遗留问题，还有大量的应用并不需要先进、全面的架构，而只需要做好某些基础设计即可。基于此，为架构设计做最适合的选择，正是架构师真正价值的体现。
笔者觉得架构师的成长分为三个阶段。
（1）刚开始的第一阶段，积累了某些技术的理论知识和实操经验，并且可以就这些技术点及案例进行分享，也就是所谓的“见而识之”。
（2）随着工作中的逐步积累，架构师逐步进入第二阶段，形成了体系化的技术框架。如果拿医生做比喻，那么这个阶段的架构师仿佛拥有了自己的“医书”。但架构师实际需要解决的“病患问题”千差万别，“医书”只能指明最终目标。
（3）处于第三阶段的优秀架构师会因为其更了解业务且更有经验，而能够厘清从现状到最终目标的最佳路径。一个经历过实际项目锤炼的架构师，还有能力将路径分拆为多个里程碑，并且为每个里程碑设定具体的验收指标，量化控制进程。
大部分技术人员经常会听到某些架构师说“应用应该这样、应该那样”，听的时候觉得他们说的都对，但有些东西又说不上哪里别扭。其实这就是典型的处于第二阶段的架构师给人的感觉，他们累积了一定的技术体系，形成了自己的“医书”，但由于缺乏实际的操作经验，所以不知道通往理想架构的路径是什么样的，也就是我们常说的“不接地气”。优秀的架构师有点儿像经验丰富的“主治医生”，他们能弥合现实与理想的缝隙，找到通往成功的最佳路径，平衡效能和成本。
请读者们始终记住：最适合的架构才是最好的架构，好的“医生”比好的“医书”更重要。
|
|
購物車/收銀台(
0
) | 在線留言板
| 付款方式
| 運費計算
| 聯絡我們
| 幫助中心 |
加入書簽
HOME
新書上架
