架构是如何运作并影响人们的日常生活的,在软件行业中架构是如何运作的?架构又是如何指导代码编写的,如何把架构应用在软件工程实践上?带着这些疑问,本书通过大量的实例一步一步揭示出架构背后的原理,以及架构在软件行业的发展,并通过企业实例来展示软件架构的实际应用。本书没有高深的词汇,不仅适合IT从业人员阅读,也适合其他行业的人士阅读。尤其对于想从事架构工作的人而言,是一本不可多得的参考材料。
“聊聊架构”是知名IT技术垂直社区网站新推出的一个栏目,内容为软件与网站架构,由一线架构师执笔。本书作者王概凯,网名Kevin,是一位资深的软件架构师,也是这个栏目开山之作的作者,赢得数百万访问量。
第一部分 认识架构
第 1 章 生命周期
1.1 生命周期的识别
1.2 核心与非核心生命周期
1.3 生命周期与分工
第 2 章 时间
第 3 章 为什么会产生架构
3.1 分工
3.2 分工和生命周期
第 4 章 什么是架构
4.1 架构产生的条件
4.2 什么是架构
4.3 架构的生命周期
第 5 章 架构和树
5.1 树与增长
5.2 架构和树
第 6 章 概念
6.1 何为名相
6.2 究竟什么才是相
6.3 概念是沟通的基础
6.4 把握概念的力量
聊聊架构
第 7 章 什么是抽象
7.1 个性与共性
7.2 个性是基础
第 8 章 识别问题
8.1 面对问题有哪些困难
8.2 如何识别问题
8.3 寻找问题主体
第 9 章 切分的原则
9.1 切分就是利益的调整
9.2 为什么需要切分
9.3 切分的原则
9.4 树和分层
9.5 切分与建模
9.6 切分的输出和组织架构
第 10 章 架构与流程
10.1 什么是流程
10.2 流程和架构拆分的关系
第 11 章 什么是架构师
11.1 架构师做什么
11.2 架构师也是人
11.3 人人都是架构师
11.4 架构师和权利
第二部分 软件架构
第 12 章 什么是软件
12.1 以模拟人为目标的冯诺依曼结构和图灵机
12.2 成本为王
12.3 天空才是极限
12.4 软件的作用
目录
IX
第 13 章 软件的生命周期
13.1 软件的开发生命周期
13.2 软件开发的增长
13.3 软件开发的迭代
13.4 软件的运行生命周期
第 14 章 什么是软件架构
14.1 要解决什么问题
14.2 分别是谁的问题呢
14.3 分别有什么问题
14.4 分析问题
14.5 会生成哪些架构
14.6 什么是软件架构
第 15 章 什么是软件架构师
15.1 软件架构师的区别
15.2 软件架构师的困境
15.3 生命周期的思考
15.4 软件架构师的权力
15.5 软件架构师和技术人员对技术的态度区别
15.6 架构师是技术的使用者
15.7 如何保障架构落地
第 16 章 业务、架构和技术三者的关系
16.1 什么是技术
16.2 业务和架构及技术之间的关系
16.3 技术人员和业务人员的关系
16.4 重新发明轮子
16.5 开源技术
第 17 章 软件研发
17.1 软件工程师的兴起和使命
17.2 分工的困境
17.3 软件的迭代
17.4 软件开发的分工
聊聊架构
X
17.5 软件开发模式和架构
17.6 软件工程师的支持者
第 18 章 软件的架构拆分
18.1 软件拆分的原动力
18.2 软件开发团队的拆分
18.3 软件的拆分
18.4 软件开发的基础技术
18.5 软件拆分的第二动力
18.6 架构一步到位
第 19 章 如何写好代码
19.1 什么叫业务逻辑
19.2 业务逻辑分散的危害
19.3 业务逻辑内聚的好处
19.4 代码架构实例
19.5 代码误解
19.6 软件的拆分
第 20 章 单元测试
20.1 什么是单元测试
20.2 单元测试的困境
20.3 单元测试测什么
20.4 如何改造代码
20.5 为什么要做单元测试
20.6 如何做单元测试
第 21 章 软件架构和面向对象
21.1 什么是面向过程
21.2 什么是面向对象
21.3 生命周期和面向对象及面向过程
21.4 架构和面向对象及面向过程
21.5 面向对象的误区
21.6 对象和生命
目录
XI
第 22 章 软件架构与设计模式
22.1 模式以及模式的意义
22.2 什么是设计模式
22.3 软件设计模式
22.4 设计模式和架构
22.5 设计模式的误区
第 23 章 软件架构和软件框架
23.1 访问类框架
23.2 业务类框架
23.3 什么是框架
23.4 框架的特点
第 24 章 软件运维
24.1 软件运行生命周期
24.2 什么是软件运维
24.3 运维的业务模型
24.4 控制变化
24.5 监控变更
24.6 预警变更
24.7 主导变更
24.8 提升变更质量
24.9 运维的架构拆分
第 25 章 软件访问生命周期
25.1 软件访问的业务模型
25.2 软件访问路径的架构拆分
25.3 大规模软件访问的架构拆分
25.4 集群
25.5 数据中心
第 26 章 软件架构和大数据
26.1 什么是大数据
26.2 如何做好大数据
26.3 软件大数据
聊聊架构
XII
第 27 章 软件架构和建筑架构
27.1 软件架构和建筑架构的目标之异同
27.2 软件和建筑的架构扩展之异同
第三部分 软件架构的应用
第 28 章 交易
28.1 什么是交易
28.2 货币的出现
28.3 企业的实质
28.4 软件对交易的影响
28.5 软件的交易
28.6 企业的核心
第 29 章 产品
29.1 什么是产品
29.2 什么是商品
29.3 识别产品
29.4 产品系统
29.5 产品列表
29.6 产品详情
29.7 商品的规则
第 30 章 用户
30.1 什么是用户
30.2 为什么需要用户
30.3 客户的出现
30.4 用户的生命周期
30.5 用户的识别
第 31 章 订单
31.1 什么是订单
31.2 订单的生命周期架构拆分
31.3 订单支付
31.4 订单生命周期
第 32 章 交易系统
32.1 企业的架构拆分
32.2 软件系统的建模
32.3 访问业务模型
32.4 交易软件系统的架构拆分
32.5 服务的产生和粒度
32.6 用户系统的拆分
第 33 章 事务
33.1 什么是事务
33.2 软件中的事务
33.3 数据库事务的滥用
33.4 数据库的正确使用方式
33.5 服务调用
序
在软件行业,架构师和软件工程师是非常辛苦的职业。一方面新技术层出不穷,另一方面业务需求也层出不穷,让人疲于应付。导致的后果就是常常加班,生活质量低下。只有曾经身在其中的人,才能够体会其中的酸甜苦辣。
在软件行业经历过这么多年,也看到了软件行业普遍存在的一些问题,总觉得自己应该为这个行业贡献一点点力量。不期望能够改变这个行业,能够引起一点点思考也是好的,如果能够帮助提升一些软件从业者的工作和生活质量,就超出期望值了。
把自己的想法写出来的过程是痛苦的,从来没有写文字的习惯,也没打算过写书,因此愈发艰难。年初时基于以上同样的想法,在 InfoQ 投稿写了《架构漫谈》专栏,和大家分享一下自己对软件架构的思考,以为算是交差了。不料 InfoQ 的郭蕾多次和我约稿,希望我能够把架构漫谈扩展成一本书。拒绝了很多次,但是脸皮实在是薄,禁不住郭蕾三番五次的游说,狠狠心答应了下来。
把文字写下来传播出去,是要承担很大的责任的,一旦说得不对,伤害的是一大片人。不愿写东西的原因大部分在此。但是想想人非圣贤,总有犯错的时候,把自己的错误暴露出来给大家,也是帮助大家学习。话虽如此,还是郑重声明,本书的内容都是个人的思考和个人的观点,并非学术的结论,请各位读者不要当作结论全盘接受。反而读者应该质疑书中的各种观点,尽量自行思考,如此才会有所收获。本书的目的也仅仅是为了引发大家的思考。
思及自身水平有限,文字功底也差,难免伤人慧命,深感惭愧和惶恐!望各位读者,鉴其愚诚,不吝慈悲指正!
——王概凯 Kevin
前言
现代的软件从业者,都受过良好的计算机和软件方面的教育。但是现代的计算机和软件方面的教育,基本上都是从科学研究领域脱胎出来的,教育的目的也理所当然的主要是为科学研究领域服务。而随着社会的发展,软件不断地渗透到不同的业务领域,涉及到普通人生活的方方面面。以科学研究为目的的软件教育,和日益深入人们生活的软件应用,产生了很大的隔阂。以致于很多计算机和软件专业毕业的学生,进入企业工作后,总是感叹学校所学习的知识派不上用场,必须得重新学起,才能够达到企业的要求。
而这些重新学习的内容,又往往是以技术为主的。技术的更新换代太快,往往也导致想跟上新技术的我们力不从心。技术和业务的关系是如何的?业务又是怎么运作的?很少有人去问这些问题。即使有人问了,也很难有人可以提供建议。
软件技术学习到一定的地步,又会发现软件架构是一个门槛。一直以来,在软件行业,对于什么是架构有很多的争论,每个人都有自己的理解。甚至于很多架构师一说架构,就开始谈论应用架构、硬件架构、数据架构等。而事实上,架构在软件发明时的很多年以前就已经存在了。众说纷纭,莫衷一是,这也给大家带来了很多困扰。
业务和架构,是压在软件从业人员身上的两座大山。而软件从业人员手上却只有一个武器:技术。可是这个武器还时灵时不灵,就好像金庸小说《天龙八部》中段誉的六脉神剑,并不总是能够解决问题,有时还会带来麻烦。
软件并不是虚无缥缈的东西,它和现实生活是紧密相关的。业务和架构都是处理人的问题。而技术人员最讨厌处理的就是人的问题,心里面厌恶,但却又无法逃避。因为这个排斥的心理,工作中始终想避开和人有关系的地方。因此在技术之前,还需要做一些准备工作,用来连接现实生活,联系上人,让大家知道处理人的问题并不可怕。建立了这个相关性,每个人就都可以自行思考了。
不仅人类受限于自身的生命周期,凡事都有其生命周期。理解了生命周期,就可以看到很多隐藏在背后的规律,以及这些规律之间的联系。因此,本书试图从生命周期入手,描绘出一张整体的画卷,帮助包括技术人员在内的大家定位自己处于什么地方,自己在起什么作用,别人又在什么地方,他们又在起什么作用。
明白了自己的位置和别人的位置,自然也就清楚自己有什么,缺什么,要往哪个地方走,从哪些地方入手了。所谓“知己知彼,百战百胜”,知道这些后中,面对人打交道时也就有了自己的思考方式,能够进行独立思考,对业务也不再厌恶以致于逃避,而是为能帮助业务人员分析及解决问题而自豪。
本书虽然不是技术书籍,不谈技术,但却是以帮助技术人员为出发点。本书的内容可以作为连接技术人员和现实世界的桥梁,用来使技术人员不再悬在空中使不出力。对于非技术人员而言,本书可以帮助其理解软件开发的特殊性,拉近与技术人员的距离,能够更有针对性地与技术人员合作。
当然,读完本书不会使读者突然学会神功,打通任督二脉。因为每个人的成长,最终还是要靠自己的思考和实践。本书的思考也不能够代替读者自己的思考,在解决某个业务问题时也无法从书中直接找到答案。本书可以提供给大家的是一个思考的出发点,一个思考的方向,一个思考的角度,使得大家不再惧怕或排斥业务,并可以像业务人员一样思考,和架构师一样思考,不再受困于业务和架构,甚至是技术本身。如果本书能够帮助大家跨过这个门槛,并从这里开始展开思考,那么目的就达到了。
在阅读《聊聊“架构”》之前,我对“架构”这个词,总是停留在“高大上”、“复杂”、“难懂”的刻板印象中。但这本书,就像一位技艺高超的魔术师,用最朴素的道具,变出了最令人惊叹的戏法,让我对这个曾经遥不可及的领域,产生了浓厚的兴趣。 我非常喜欢书中对于“抽象”的阐述。作者没有直接讲“接口”或者“模块化”,而是用了一个非常贴切的比喻:就像我们描述一个“交通工具”,我们只需要知道它能“载人”、“能行进”,而不需要知道它是如何实现这些功能的。这种“隐藏细节,暴露功能”的思想,让我瞬间明白了抽象的核心价值。 书中关于“容错性”的讨论,也让我大开眼界。它没有枯燥地罗列各种错误处理的模式,而是通过一个“应急预案”的故事,让我看到了在系统设计中,提前考虑到各种“意外”的重要性。当发生不可预料的故障时,一个有良好容错性的系统,能够将损失降到最低,甚至无缝切换,继续为用户提供服务。 让我感到惊喜的是,这本书的语言风格非常流畅且富有趣味。作者仿佛就是一个经验丰富的工程师,在跟你分享他的心得体会,而不是在进行一场冰冷的技术宣讲。他会用一些生动的词语,描绘出那些抽象的技术概念,让它们变得鲜活起来。 总体而言,《聊聊“架构”》这本书,为我打开了一扇通往“架构”世界的大门。它不仅让我理解了“是什么”,更重要的是,让我开始思考“为什么”。读完之后,我发现自己看待很多技术产品的方式都发生了改变,开始能够透过表面的功能,去窥探其背后的设计哲学和架构智慧。
评分《聊聊“架构”》这本书,给我的感觉就像是在品尝一杯精心调制的咖啡,初尝时可能觉得只是普通的味道,但细细品味,便能体会到其中层次分明的香醇和回甘。我一直对那些看不见的“骨架”和“脉络”很感兴趣,但以往接触到的资料,要么太过抽象,要么太过碎片化,总难以形成一个完整的认知。 作者在书中对于“可扩展性”的阐述,是我之前从未有过的理解。他没有直接谈论什么“横向扩展”或“纵向扩展”,而是用了一个非常生动的比喻,讲述了一座城市如何从一个小村庄逐渐发展壮大,并需要不断地增加新的道路、桥梁和建筑。这个过程中的每一个“新增加”的部分,都需要与现有的结构良好地融合,并且不能因为增加而导致原有的功能受损。 更让我感到共鸣的是,书中对“可用性”的探讨。它不仅仅是停留在“服务器不宕机”这样的层面,而是深入到用户在何种情况下会觉得“不好用”,以及这些“不好用”是如何源于底层的架构设计。比如,当一个网站在高峰期加载速度变得异常缓慢时,作者会引导你去思考,这背后可能隐藏着什么样的性能瓶颈。 让我惊喜的是,这本书在讲解复杂概念时,总是能找到最贴切的比喻。我尤其喜欢关于“依赖性”的讨论,作者用了一个家庭装修的例子,说明如果水电改造和墙体粉刷的顺序安排不当,就会导致返工,耗费大量时间和资源。这让我深刻理解了,在软件开发中,各个模块之间的依赖关系如果处理不好,会产生多么严重的后果。 总而言之,《聊聊“架构”》这本书,以一种非常平易近人的方式,揭示了那些支撑着我们日常使用的各种系统背后的逻辑。它不是一本硬核的技术手册,更像是一位经验丰富的引路人,带着你一步步探索,让你在潜移默化中,对“架构”这个概念有了更深入、更全面的理解。
评分这本《聊聊“架构”》真是有趣极了!我一直以为架构这东西离我们很遥远,都是那些头发花白、穿着格子衬衫的“大神”们在讨论的“高大上”的议题。但这本书的出现,就像一把钥匙,轻轻一拧,就打开了我对这个领域的好奇心。我最喜欢的地方在于,它并没有一开始就丢给我一堆晦涩的概念和枯燥的定义,而是用一种非常贴近生活,甚至有点像是朋友之间闲聊的方式,一点点地渗透进来。 我尤其记得书中讲到“瓶颈”那里,作者没有直接给我看图表或者数据,而是用一个大家都能理解的例子——就像一家餐厅,如果点餐的服务员太慢,即使后厨做的再快,整体效率也会受到影响。这个比喻一下子就让我恍然大悟,原来架构中的“瓶颈”就是这么回事!它让我开始反思自己日常生活中遇到的各种“效率低下”的场景,是不是也存在着类似的“架构”问题。 更让我惊喜的是,这本书并没有止步于理论的讲解,而是巧妙地穿插了一些小故事和案例,这些故事让原本可能显得冰冷的技术概念变得有温度、有血有肉。比如,书中提到一个开发团队如何通过调整系统的“接口”,让原本互相掣肘的两个部门能够顺畅协作,这让我看到了架构的实际应用价值,不再是空中楼阁。 我一直觉得,好的技术书籍应该能够激发读者的思考,而不是单方面地灌输知识。而《聊聊“架构”》在这方面做得非常出色。它经常抛出一些问题,引导我去思考,去尝试理解为什么某个设计是这样,而不是那样。这种互动性的阅读体验,让我感觉自己不再是一个被动的接受者,而是一个主动的探索者。 总而言之,如果你也曾经对“架构”这个词感到陌生,或者觉得它遥不可及,那么我强烈推荐你翻开这本《聊聊“架构”》。它会用一种你意想不到的方式,让你发现其中的乐趣,并且打开一扇新的视野。我敢说,读完这本书,你可能会和我一样,开始用一种全新的眼光去看待周遭的世界,去发现隐藏在各种系统背后的“架构智慧”。
评分翻阅《聊聊“架构”》的过程,就像走进了某个古老图书馆的深处,每一页都散发着知识的微光,但又不至于让人觉得窒息。我一直对那些宏大的系统运作原理心生敬畏,总觉得那是少数人的专属领域。然而,这本书却以一种极其温和而循序渐进的方式,引领我窥探了其中一角。 作者的笔触,在描述那些看似复杂的概念时,总能找到一个恰当的切入点。我记得其中一段关于“解耦”的论述,并没有直接抛出“降低耦合度”这样的术语,而是先讲了一个小村庄里,大家各司其职,但又相互关联的故事。当他们开始各自独立发展,又不至于影响整体运作时,作者才引申出“解耦”的概念。这种叙事方式,让我能自然而然地理解其深层含义。 让我印象深刻的还有书中对“权衡”的解读。它没有给出任何“最优解”的答案,而是反复强调,架构的本质是不断地在各种相互制约的因素之间做出选择。书中举的例子,比如为了提高响应速度而牺牲一部分数据一致性的场景,让我认识到,每一个架构决策都伴随着取舍,并没有完美无缺的设计。 这本书的魅力还在于它鼓励读者去质疑和思考。它不会告诉你“必须怎样”,而是“可以怎样”,并且会分析不同“怎样”可能带来的结果。这种开放式的探讨,让我感到非常舒服,也激发了我自己去想象不同的可能性,去思考在现实场景中,该如何进行权衡和选择。 读完这本书,我并没有觉得自己瞬间变成了架构专家,但我的思维方式却发生了 subtle 的改变。我开始能够理解,为什么有些产品用户体验顺畅,而另一些却总是磕磕绊绊;我开始能够识别出一些系统设计中的潜在问题,并尝试去分析其根源。这无疑是一次非常充实且富有启发性的阅读体验。
评分这本书的出现,就像在我的技术认知领域投下了一颗小石子,激起了层层涟漪。我一直对那些看似“简单”的操作背后,所蕴含的复杂系统感到好奇。而《聊聊“架构”》恰好满足了我的这份好奇,并且用一种我从未预料到的方式。 我尤其欣赏书中在解释“状态管理”时所采用的方法。它没有直接使用“状态机”这样的术语,而是通过一个非常形象的故事,描绘了一个游戏角色在不同场景下的行为变化。比如,角色在“战斗中”和在“休息时”,其行为逻辑是截然不同的,而这种“状态”的切换和管理,正是支撑着整个游戏流畅运行的关键。 书中对“并发”的描述,也让我印象深刻。我之前总是把并发想象成很多东西“同时发生”,但作者通过一个厨房切菜的比喻,让我理解了,即使是看似“同时”发生的动作,也可能存在着资源争夺和等待的问题。当多个厨师同时使用一个切菜板时,谁先使用、谁后等待,就需要一套精妙的“调度”机制,这不就是并发场景下的核心挑战吗? 让我感到眼前一亮的是,书中经常会从“用户体验”的角度出发,去反推架构设计。它不会上来就告诉你“你应该这样做”,而是先让你去感受“不这样做”会带来什么不好的体验,然后再去探究背后的架构原因。这种“由果溯因”的方式,让我更容易理解架构决策的合理性。 总的来说,《聊聊“架构”》这本书,为我提供了一个全新的视角来审视和理解技术世界。它让我明白,那些我们习以为常的便捷功能,背后都凝聚着设计师们的智慧和权衡。这是一本值得反复阅读,并且能够不断带来新感悟的书籍。
评分此用户未填写评价内容
评分rcgu我说的都非常分发给多幸福
评分一次买了很多书,都没来得及看
评分向着架构师进击
评分向着架构师进击
评分粗粗翻了一下,描述层面毕竟高,不是实战经验介绍,描述流程性的东西太多,有些枯燥。有点借鉴意义
评分书不错,便宜了买的
评分此用户未填写评价内容
评分此用户未填写评价内容
本站所有内容均为互联网搜索引擎提供的公开搜索信息,本站不存储任何数据与内容,任何内容与数据均与本站无关,如有需要请联系相关搜索引擎包括但不限于百度,google,bing,sogou 等
© 2025 book.teaonline.club All Rights Reserved. 图书大百科 版权所有