内容简介
架构是如何运作并影响人们的日常生活的,在软件行业中架构是如何运作的?架构又是如何指导代码编写的,如何把架构应用在软件工程实践上?带着这些疑问,《聊聊“架构”》通过大量的实例一步一步揭示出架构背后的原理,以及架构在软件行业的发展,并通过企业实例来展示软件架构的实际应用。《聊聊“架构”》没有高深的词汇,不仅适合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
前言
现代的软件从业者,都受过良好的计算机和软件方面的教育。但是现代的计算机和软件方面的教育,基本上都是从科学研究领域脱胎出来的,教育的目的也理所当然的主要是为科学研究领域服务。而随着社会的发展,软件不断地渗透到不同的业务领域,涉及到普通人生活的方方面面。以科学研究为目的的软件教育,和日益深入人们生活的软件应用,产生了很大的隔阂。以致于很多计算机和软件专业毕业的学生,进入企业工作后,总是感叹学校所学习的知识派不上用场,必须得重新学起,才能够达到企业的要求。
而这些重新学习的内容,又往往是以技术为主的。技术的更新换代太快,往往也导致想跟上新技术的我们力不从心。技术和业务的关系是如何的?业务又是怎么运作的?很少有人去问这些问题。即使有人问了,也很难有人可以提供建议。
软件技术学习到一定的地步,又会发现软件架构是一个门槛。一直以来,在软件行业,对于什么是架构有很多的争论,每个人都有自己的理解。甚至于很多架构师一说架构,就开始谈论应用架构、硬件架构、数据架构等。而事实上,架构在软件发明时的很多年以前就已经存在了。众说纷纭,莫衷一是,这也给大家带来了很多困扰。
业务和架构,是压在软件从业人员身上的两座大山。而软件从业人员手上却只有一个武器:技术。可是这个武器还时灵时不灵,就好像金庸小说《天龙八部》中段誉的六脉神剑,并不总是能够解决问题,有时还会带来麻烦。
软件并不是虚无缥缈的东西,它和现实生活是紧密相关的。业务和架构都是处理人的问题。而技术人员最讨厌处理的就是人的问题,心里面厌恶,但却又无法逃避。因为这个排斥的心理,工作中始终想避开和人有关系的地方。因此在技术之前,还需要做一些准备工作,用来连接现实生活,联系上人,让大家知道处理人的问题并不可怕。建立了这个相关性,每个人就都可以自行思考了。
不仅人类受限于自身的生命周期,凡事都有其生命周期。理解了生命周期,就可以看到很多隐藏在背后的规律,以及这些规律之间的联系。因此,《聊聊“架构”》试图从生命周期入手,描绘出一张整体的画卷,帮助包括技术人员在内的大家定位自己处于什么地方,自己在起什么作用,别人又在什么地方,他们又在起什么作用。
明白了自己的位置和别人的位置,自然也就清楚自己有什么,缺什么,要往哪个地方走,从哪些地方入手了。所谓“知己知彼,百战百胜”,知道这些后中,面对人打交道时也就有了自己的思考方式,能够进行独立思考,对业务也不再厌恶以致于逃避,而是为能帮助业务人员分析及解决问题而自豪。
《聊聊“架构”》虽然不是技术书籍,不谈技术,但却是以帮助技术人员为出发点。《聊聊“架构”》的内容可以作为连接技术人员和现实世界的桥梁,用来使技术人员不再悬在空中使不出力。对于非技术人员而言,《聊聊“架构”》可以帮助其理解软件开发的特殊性,拉近与技术人员的距离,能够更有针对性地与技术人员合作。
当然,读完《聊聊“架构”》不会使读者突然学会神功,打通任督二脉。因为每个人的成长,最终还是要靠自己的思考和实践。《聊聊“架构”》的思考也不能够代替读者自己的思考,在解决某个业务问题时也无法从书中直接找到答案。《聊聊“架构”》可以提供给大家的是一个思考的出发点,一个思考的方向,一个思考的角度,使得大家不再惧怕或排斥业务,并可以像业务人员一样思考,和架构师一样思考,不再受困于业务和架构,甚至是技术本身。如果《聊聊“架构”》能够帮助大家跨过这个门槛,并从这里开始展开思考,那么目的就达到了。