描述
开 本: 16开纸 张: 胶版纸包 装: 平装-胶订是否套装: 否国际标准书号ISBN: 9787111679363
架构师应该是软件开发的全才,需要掌握各个方面的知识,才能够针对业务场景选择出合适的技术解决方案,并解决开发实践中形形色色的问题。
那么,架构师如何获得这些技能,如何构建起自己的知识体系呢?本书从4个方面全面梳理了架构师在职业进阶的道路上必须牢固掌握的各种技术技能,帮助读者建立起自己的知识体系。
架构师的工作包罗万象,从开发基础框架到设计软件架构,从优化系统性能到修复重要Bug,从新技术选型到做出关键技术决策,从指导工程师开发到沟通、协调各种内外部关系。想要成为一个优秀的软件架构师,需要经过漫长的修炼,构建起自己的软件开发技术体系。但是一切看似纷繁复杂的技术技巧,均有其核心和基本的原理。
本书对架构师在职业进阶道路上必须牢固掌握的各项技术技能进行了梳理,涵盖基础知识、程序设计、系统架构、沟通管理4大方面。
本书包含38章,每一章都用一个软件开发中常见又经典的问题引出,深入浅出地剖析这个技术点背后的核心原理与外延扩展,进而帮助读者建立起自己的架构师知识体系。
第1部分是架构师的基础知识修炼。
软件的基础知识原理主要是操作系统、数据结构、数据库原理等,书中会从常见的问题入手,直达这些基础技术本质的原理,并覆盖这些基础技术的关键技术点,帮助读者理解这些基础技术原理和日常开发工作的关联关系,对这些基础技术有一个全新的认知。
第2部分是架构师的程序设计修炼。
讲述如何设计一个强大灵活、易复用、易维护的软件,在这个过程中,应该依赖哪些工具和方法,遵循哪些原则和思想,使用哪些模式和手段。
第3部分是架构师的架构方法修炼。
围绕目前主要的互联网分布式架构以及大数据、物联网架构分析这些架构背后的原理,详解它们都遵循了怎样的驱动力和设计思想,以及如何通过这些技术实现系统的高可用和高性能。
第4部分是架构师的思维修炼。
软件开发是一个实践性很强的活动,如果只是学习技术,那就是在纸上谈兵。只有将知识技能应用到工作实践中,才能真正体会到技术的关键点在哪里。如何在工作中处理好各种关系,得到充分的授权和信任,在工作中实践自己的技术思想,并为公司创造更多的价值,使自己的技术成长和职业发展进入互相促进的正向通道,也是架构师需要修炼与提升的。
【部分 架构师的基础知识修炼】
第1章 操作系统原理:程序是如何运行和崩溃的 2
1.1 程序是如何运行起来的 2
1.2 一台计算机如何同时处理数以百计的任务 4
1.3 系统为什么会变慢,为什么会崩溃 5
1.4 小结 7
第2章 数据结构原理:Hash表的时间复杂度为什么是O(1) 8
2.1 数组的结构 8
2.2 链表的结构 9
2.3 Hash表的结构 10
2.4 栈的结构 12
2.5 队列的结构 13
2.6 树的结构 14
2.7 小结 14
第3章 Java虚拟机原理:JVM为什么被称为机器 16
3.1 JVM的构造 17
3.2 JVM的垃圾回收 19
3.3 Web应用程序在JVM中的执行过程 22
3.4 小结 24
第4章 网络编程原理:一个字符的互联网之旅 25
4.1 DNS域名解析原理 26
4.2 CDN 27
4.3 HTTP的结构 28
4.4 TCP的结构 29
4.5 链路层负载均衡原理 32
4.6 小结 33
第5章 文件系统原理:用1分钟遍历一个100TB的文件 34
5.1 硬盘结构原理 35
5.2 文件系统原理 36
5.3 RAID硬盘阵列原理 37
5.4 分布式文件系统架构原理 39
5.5 小结 40
第6章 数据库原理:SQL为什么要预编译 42
6.1 数据库架构与SQL执行过程 43
6.2 使用PrepareStatement执行SQL的好处 45
6.3 数据库文件存储与索引工作原理 46
6.4 小结 48
第7章 编程语言原理:面向对象编程是编程的终极形态吗 49
7.1 软件编程的远古时代 49
7.2 机器与汇编语言时代 51
7.3 高级编程语言时代 51
7.4 面向对象编程时代 52
7.5 编程语言的未来 53
7.6 小结 54
【第二部分 架构师的程序设计修炼】
第8章 软件设计的方法论:软件为什么要建模 56
8.1 什么是软件建模 57
8.2 4 1视图模型 58
8.3 UML建模 59
8.4 小结 60
第9章 软件设计实践:使用UML完成一个设计文档 61
9.1 用类图设计对象模型 61
9.2 用序列图描述系统调用 62
9.3 用组件图进行模块设计 63
9.4 用部署图描述系统物理架构 64
9.5 使用用例图进行需求分析 65
9.6 用状态图描述对象状态变迁 66
9.7 用活动图描述调用流程 66
9.8 使用合适的UML模型构建一个软件设计文档 67
9.9 软件架构设计文档示例模板 68
9.10 小结 74
第10章 软件设计的目的:糟糕的程序差在哪里 75
10.1 糟糕的设计有多糟糕 76
10.2 一个设计“腐坏”的例子 77
10.3 解决之道 78
10.4 小结 80
第11章 软件设计的开闭原则:不修改代码却能实现需求变更 81
11.1 什么是开闭原则 81
11.2 一个违反开闭原则的例子 82
11.3 使用策略模式实现开闭原则 84
11.4 使用适配器模式实现开闭原则 85
11.5 使用观察者模式实现开闭原则 86
11.6 使用模板方法模式实现开闭原则 88
11.7 小结 89
第12章 软件设计的依赖倒置原则:不依赖代码却可以复用它的功能 91
12.1 依赖倒置原则 91
12.2 依赖倒置的关键是接口所有权的倒置 93
12.3 使用依赖倒置来实现高层模块复用 94
12.4 小结 96
第13章 软件设计的里氏替换原则:正方形可以继承长方形吗 97
13.1 里氏替换原则 98
13.2 一个违反里氏替换原则的例子 99
13.3 正方形可以继承长方形吗 100
13.4 子类不能比父类更严格 101
13.5 小结 102
第14章 软件设计的单一职责原则:一个类文件打开后好不要超过一屏 104
14.1 单一职责原则 107
14.2 一个违反单一职责原则的例子 107
14.3 从Web应用架构演进看单一职责原则 108
14.4 小结 110
第15章 软件设计的接口隔离原则:如何对类的调用者隐藏类的公有方法 112
15.1 接口隔离原则 113
15.2 一个使用接口隔离原则优化的例子 114
15.3 接口隔离原则在迭代器设计模式中的应用 117
15.4 小结 117
第16章 设计模式基础:不会灵活应用设计模式,就没有掌握面向对象编程 119
16.1 面向对象编程的本质是多态 119
16.2 设计模式的精髓是对多态的使用 121
16.3 小结 123
第17章 设计模式应用:编程框架中的设计模式 125
17.1 什么是框架 125
17.2 Web容器中的设计模式 127
17.3 JUnit中的设计模式 129
17.4 小结 132
第18章 反应式编程框架设计:如何使程序调用不阻塞等待,立即响应 133
18.1 反应式编程 135
18.2 反应式编程框架Flower的基本原理 135
18.3 反应式编程框架Flower的设计方法 138
18.4 反应式编程框架Flower的落地效果 140
18.5 小结 141
第19章 组件设计原则:组件的边界在哪里 143
19.1 组件内聚原则 144
19.2 组件耦合原则 145
19.3 小结 147
第20章 领域驱动设计:35岁的程序员应该写什么样的代码 148
20.1 领域模型模式 149
20.2 领域驱动设计 151
20.3 小结 154
【第三部分 架构师的架构方法修炼】
第21章 分布式架构:如何应对高并发的用户请求 156
21.1 垂直伸缩与水平伸缩 157
21.2 互联网分布式架构演化 157
21.3 小结 163
第22章 缓存架构:减少不必要的计算 165
22.1 通读缓存 166
22.2 旁路缓存 168
22.3 缓存注意事项 171
22.4 小结 173
第23章 异步架构:避免互相依赖的系统间耦合 174
23.1 使用消息队列实现异步架构 175
23.2 消息队列异步架构的好处 178
23.3 小结 180
第24章 负载均衡架构:用10行代码实现一个负载均衡服务 181
24.1 HTTP重定向负载均衡 181
24.2 DNS负载均衡 183
24.3 反向代理负载均衡 184
24.4 IP负载均衡 184
24.5 数据链路层负载均衡 186
24.6 小结 187
第25章 数据存储架构:改善系统的数据存储能力 188
25.1 数据库主从复制 188
25.2 数据库分片 190
25.3 关系数据库的混合部署 193
25.4 NoSQL数据库 196
25.5 小结 197
第26章 搜索引擎架构:瞬间完成海量数据检索 199
26.1 搜索引擎倒排索引 199
26.2 搜索引擎结果排序 202
26.3 小结 205
第27章 微服务架构:微服务究竟是“灵丹”还是“毒药” 206
27.1 单体架构的困难和挑战 206
27.2 微服务框架原理 208
27.3 微服务架构的落地实践 210
27.4 小结 211
第28章 高性能架构:除了代码,还可以在哪些地方优化性能 212
28.1 性能指标 212
28.2 性能测试 213
28.3 性能优化 215
28.4 小结 219
第29章 高可用架构:淘宝应用升级时,为什么没有停机 220
29.1 高可用的度量 221
29.2 高可用的架构 222
29.3 小结 225
第30章 安全性架构:为什么说用户密码泄露是程序员的问题 227
30.1 数据加密与解密 227
30.2 HTTP攻击与防护 230
30.3 小结 233
第31章 大数据架构:思想和原理 234
31.1 HDFS分布式文件存储架构 235
31.2 MapReduce大数据计算架构 236
31.3 Hive大数据仓库架构 238
31.4 Spark快速大数据计算架构 240
31.5 大数据流计算架构 242
31.6 小结 242
第32章 AI与物联网架构:从智能引擎到物联网平台 243
32.1 大数据平台架构 244
32.2 智能推荐算法 245
32.3 物联网大数据架构 249
32.4 小结 250
第33章 区块链技术架构:区块链到底能做什么 251
33.1 比特币与区块链原理 251
33.2 联盟链与区块链的企业级应用 255
33.3 小结 257
【第四部分 架构师的思维修炼】
第34章 技术修炼之道:同样工作十几年,为什么有的人成为资深架构师,有的人失业 260
34.1 德雷福斯模型 261
34.2 如何在工作中成长 263
34.3 小结 264
第35章 技术进阶之道:你和世界上的程序员差几个等级 265
35.1 软件技术的生态江湖与等级体系 265
35.2 技术进阶之捷径 267
35.3 小结 269
第36章 技术落地之道:你真的知道自己要解决的问题是什么吗 270
36.1 确定会议真正要解决的问题是什么 271
36.2 不需要去解决别人的问题,提醒他问题的存在即可 272
36.3 去解决那些被人们习以为常而忽略了的问题 273
36.4 小结 273
第37章 技术沟通之道:如何解决问题 275
37.1 让有能力解决问题的人感受到问题的存在 275
37.2 “直言有讳” 276
37.3 想解决一个大家都不关注的问题,可以等问题变得更糟 277
37.4 如果不填老师想要的答案,你就得不了分 278
37.5 小结 278
第38章 技术管理之道:真的要转管理吗 280
38.1 彼得定律 281
38.2 用目标驱动 282
38.3 小结 283
附录A 软件开发技术的性原理 284
附录B 我的架构师成长之路 287
附录C 无处不在的架构之美 293
附录D 软件架构师之道 298
【架构师拯救世界】
在我的职业生涯中,曾经见过一些差劲的系统,没有人知道这个系统是从什么时候开始变差的,参与其中的每个人都痛苦不堪,所有人都在同这个差劲的系统比赛,要么自己的工作进度足够快,在系统变得更差劲之前把自己的功能开发完成,发布上线;要么自己足够快,在系统变得更差之前“跑路走人”。
这样的系统通常都有一个共同特征:缺乏一个强有力的技术掌舵者,没有人为这个系统进行整体规划和设计,甚至没有人对系统整体负责,也就是说没有一个真正意义上的软件架构师。系统从一开始为实现某些功能堆砌了一堆代码,然后就是不断地往上继续堆砌代码,随着时间推移,系统变成了一团乱麻,每天的日常开发变成了一场冒险之旅,很容易就掉到坑里。
软件编程似乎没有门槛,任何接受过义务教育的人经过一些基本的编程培训就能够写一些可以执行的代码。但是想要设计一个架构良好、易于维护、富有弹性的系统,却是一件非常困难的事情。就我所见,很多项目团队根本没有系统架构设计这样一个软件开发阶段,也没有一个掌控整个系统技术架构的人,项目管理者主要关注内部和外部的各种沟通,以及人员、进度管理,而缺乏对系统架构的关注,导致系统架构在日复一日的开发过程中逐渐“腐烂”。
在实际工作中,很多软件工程师可能从来没有体会过良好架构设计带来的好处:系统模块的层次边界清晰,每个团队成员的工作都很少耦合;需求变更不需要在一大堆代码中改来改去,只要扩展几个类就能轻松实现;用户量快速增加时,只需要变更部署方案就可以应对,甚至不需要改动代码。而由此获益的其实是企业管理者,他不必为急剧膨胀的技术人员招聘预算而愁眉不展。
很多软件项目团队缺乏一个合格的软件架构师,甚至没有架构师。如果不能面对问题、解决问题,你跑得再快也于事无补,逃往的下一个地方也许有一个更不友好的系统在等着你。如果当前项目没有一个能够掌控技术架构的人,那么,好的办法就是你尽早站出来,为整个系统的技术架构承担责任,让自己成为软件架构师。整个过程你收获的不只是更好的工作体验,还有更广阔、更美好的未来。
优秀的软件架构师能够设计架构良好的系统,并让它在漫长的生命周期中持续演进、清晰合理。优秀的软件架构师既能够写漂亮的技术PPT,又能够写漂亮的代码,他开发的核心代码可支撑起系统的核心架构,架构方案可得到大多数人的拥护。优秀的软件架构师拥有宏观的技术视角,能够用更广阔的愿景来诠释当前项目的技术、架构和未来的演化趋势;优秀的软件架构师拥有某种技术影响力和领导力,无须施展权威就可以让其他工程师听信于他;优秀的软件架构师还会掌握一些特别的管理、谈判技能,让自己的技术构想易于被其他工程师、项目经理、企业管理者和用户接纳。
软件架构师也许不能拯救世界,但是他可以拯救自己,而自己即是世界。
【读者对象】
●希望成为架构师的软件开发工程师;
●需要掌握全面架构方法的技术经理;
●期望进行技术提升的架构师;
●计算机专业的在校大学生、研究生;
●计划转行进入软件开发领域的人员。
【你可以从本书收获什么】
软件架构师应该是软件开发方面的全才,需要掌握方方面面的知识,这样才能针对业务场景选择合适的技术解决方案,解决开发实践中形形色色的问题。
那么,架构师如何获得这些技能,如何构建自己的架构师知识体系呢?
本书总结了以下四个方面:
1)架构师的基础知识修炼:软件的基础知识主要包括操作系统、数据结构、数据库原理等。本书会从一个常见的问题入手,直达这些基础技术的原理,并覆盖这些基础技术的关键技术点,让你在理解这些基础技术原理和日常开发工作的关联基础上,对这些基础技术产生全新的认知。
2)架构师的程序设计修炼:如何设计一个强大、灵活、易复用、易维护的软件?在这个过程中,可以使用哪些工具和方法?遵循哪些原则和思想?使用哪些模式和手段?如果软件只是实现功能,那么,程序员就没有高下之分,软件也没有好坏之分,技术也就不会进步。好的软件究竟好在哪里?如何写出一个好的程序?本书会逐一解答这些问题。
3)架构师的架构方法修炼:围绕目前主要的互联网分布式架构以及大数据、物联网架构,分析这些架构背后的原理,看它们都遵循着什么样的设计思想,有哪些看似不同而原理相同的技术,以及如何通过这些技术实现系统的高可用和高性能。
4)架构师的思维修炼:软件开发是实践性很强的活动,只是学习技术无异于纸上谈兵。只有将知识技能应用到工作实践中,你才能真正体会到技术的关键点在哪里,才能分辨出哪些技术是真正有用的,哪些方法是“花拳绣腿”。但是公司不是你实践技术的实验室,怎样才能处理好工作中的各种关系,得到充分的授权和信任,在工作中实践自己的技术思想,并为公司创造更多的价值,得到更大的晋升和发挥空间,使自己的技术成长和职业发展进入正向通道?架构师也需要工作思维方面的修炼与提升。
应该说,这些内容涵盖了架构师技术技能的各个方面,但是在学习和实践的过程中,技术的全面与精通必然会有冲突,那该怎么办呢?对于架构师而言,应该优先建立全面的技术知识体系,然后针对知识短板和实践中遇到的问题,有针对性地提高和学习。本书的目的就在于此,即全面呈现架构师的知识结构体系与相关技术的本质和内涵,使读者构建架构知识之网,能从全局思考并面对自己的工作。
而构建知识体系的过程,是学习,也是修炼。
评论
还没有评论。