下载掌阅APP，畅读海量书库
立即打开
以笔者的软件学习与从业经历来划分，本书内容跨越了四个时期，这四个时期的时间是连续的。
第一个时期，1998—2004年。这是我的求学时代，与其对应的是第1章的内容，其技术关键字是编程语言、设计模式，另外，还包括那个时期对技术管理与决策的一些思考。
第二个时期，从第一个时期结束一直到大约2016年。其关键字是开源、平台化、虚拟化、企业架构。这是我的前半段职业生涯，历时十余年。对这一时期技术的提炼、浓缩，内容见第2章。
第三个时期，从第二个时期结束一直到目前。其代表特征是大前端技术、大数据技术、人工智能、云计算，以及微服务理念和分布式架构登上舞台，成为软件行业当之无愧的主角。这段时间历时7～8年，于我而言，这是软件架构、技术决策的知识与技能最为新鲜、浓烈的时代。作为本书的内容主体，我将沉淀的架构理论和相关知识体系进行整理，编写进第3～6章，这是对读者现实工作指导意义最大的部分。
第四个时期，既是当下，也是面向未来。在第7、8章，我对混沌工程、大模型、隐私计算、量子安全等领域做出了一些技术观点的分享与展望。
说一下阅读提示，“时期”二字，是连接本书各章内容的重要线索。本书正文中多次出现的“时期”，如无特殊指代，都默认是上面所定义的时期含义。
四个时期跨越了逾25年，这正是软件业如火如荼发展的年代。作为一名普通从业者，能够偶遇这样的契机，实乃职业生涯之福分。因此，一定有什么东西是可以深刻反思、好好总结的。那么，以书为载体来承载这份情怀，一定是不二之选。如果用几小段话概况全书内容体现的技术发展趋势，那么可以是以下几点。
第一，伴随着硬件资源及算力的大幅提升，以开源化、平台化为代表，软件行业的生产关系快速进化，软件生产力从各方面、以各种形式飞跃式增长。随着原始积累
的完成，以及软件行业生态日趋健全，桥接、复用已成为软件系统建设的重要组成方式。工具化全面替代手工已经到来，软件生产已呈现流水线制造之态势。
第二，软件系统架构领域的两条发展主线：一是从垂直（或纵向）方向看，不论设计理念层面还是技术实现层面，都在不断强化系统间的协调、协同能力，持续提升服务治理水平；二是从水平（或横向）方向看，通过虚拟化技术对系统分层，推进系统控制与业务应用的分离。这两个线索，20余年来从未动摇。同时，分而治之和关注耦合点
，永远是不变的架构思想核心。无论是编程原则，还是架构设计的原理和方法，其中的多数思想在几十年间贯穿始终、不曾改变。
软件系统由功能化向服务化演变。软件架构的使命，先是为基本设计服务，然后是聚焦于实现质量属性目标，发展至今，更深层意义在于对抗复杂系统的熵增。
第三，伴随着软件系统的日趋复杂，架构设计工作呈现立体化发展，上至复杂系统群的架构蓝图，中到各相异系统的不同架构风格、单一系统内的各类设计模式，下到面向对象的继承、封装、多态，以及编程语言层面的设计技巧和特征利用。
与此同时，架构设计的内涵更加丰富。微观层面，架构量子
的边界不断延伸，从面向过程语言（以头文件和声明为边界）的程序文件、面向对象的类，发展到结构化封装的组件（或模块），再提升至一个个独立部署、运行的系统进程；宏观层面，架构关注点不断变化，从单体系统内部的分层，发展到多系统之间的逻辑关系和通信机制，再提升到分布式架构下的公共抽象、服务协作和一体化管控。
第四，传统意义上的软件架构
已经进入成熟稳定期，褪去光环、不再是高大上领域。分布式应用架构臻于完美，已无太多的“真空区”待填充，云+容器对运行架构的追求，也已经发挥得淋漓尽致。近几年来软件架构领域缺少新的热点，有些后继乏力，这与呈“日薄西山”之态的传统项目管理相比，两者可谓异曲同工。这并非是对项目管理出言不逊，继敏捷和DevOps之后，项目管理领域确实是缺少再发展、演变的活力。
判断一个行业领域的潜力，最直观的方式是观测岗位饱和程度。相对于庞大的人才供给量而言，软件架构、项目管理这些传统领域的岗位需求量，可以用杯水车薪来形容。
不难预测，代表新质生产力的前沿科技，将成为软件行业的中流砥柱。软件行业未来的前进方向（或者说是趋势），必然是新兴领域的各自突破。
●大数据服务与数据要素流通，以及安全技术与场景应用，会成为行业赛道上的领跑者，代表性领域包括量子安全、区块链、隐私计算。
●人工智能领域发展方兴未艾，以机器学习的人工智能和以大模型为代表的通用智能，已成为市场的宠儿。与此同时，算力经济的前途不可估量。
●软件制造以及技术服务（由国外向国内）的转换与流动趋势，其本质是能力替代（或称为置换），最具代表的是5G通信、虚拟现实等领域的技术创新，以及核心软件国产化大潮下的信创产业机会。
通过第8章的内容，读者可以对这些前沿科技进行快速概览。读者不难发现，决定新技术生命力的首要因素是算法能力。展望未来，软件从业能力的竞争，将更多表现为算法领域的能力比拼。算法的学科基础是泛数学
，从本质上看，算法具有较强的科学属性；软件架构的本质是软件技术与方法的运用，更多体现出的是工程属性。
当然，算法也有架构的概念，算法团队里面也有（负责选型和设计的）架构师角色，但这与传统软件架构师显然不属于一个领域。
那么，软件架构还重要么？笔者给出的答案是，不论算法重要性如何提升，必须要承认的是，软件架构的重要性从未降低。
软件质量属性、软件设计视图、软件架构风格与设计模式……依然牢牢控制着软件设计与开发过程的方方面面，决定着软件系统建设的成败。新技术的诞生，无不根植于经典的架构体系。软件架构不仅没有止步不前，而且已然大步流星进入新的时代——智能原生时代，不断地与前沿科技相互结合、融会贯通，释放更加巨大的生产力。架构的多面性本质
，赋予其多方面的价值和意义。软件架构领域的发展，将与时俱进、源远流长。
软件行业所辖领域如此之多，软件技术栈及框架的品类、数量浩如烟海，如何能够独辟蹊径，写出一本好的架构书？在落笔时，笔者做了两方面的定位。
第一，尽量把握影响技术的趋势，揭示各类技术发展背后的共性思想，聚焦核心理念、主流的方法论，帮助大家建立更鲜活、深厚的思考力，善于把控架构理论与技术实践之间的对立与协同。
第二，与一般科技类书籍的明显不同之处在于，本书内容涉及很多领域，但是一本书不可能做到包罗万象，因此读起来可能会有品尝大杂烩之感。之所以这样去构思本书，目的是为读者提供更丰富的情境、更多的交互点，增大与软件世界的接触面，能更宽泛、理性、包容、灵活地去看待软件架构，感知自我与技术之间的相互作用。正如混沌工程理念所强调：在一个“技术社会”系统中，人和技术结合在一起，这如同硬币的两面，如果对两面有任何的厚此薄彼，就无法完全理解这个系统。
有关软件系统的理论、规律、规则、特征，第3章有更为体系的描述，在本章中，首先开门见山地浅谈软件架构到底是什么，应该如何去理解它。从正统的概念说起，软件架构可以有如下多种定义。
（1）架构是一组软件结构，它有组件，有连接器。也可以将架构理解为“对系统的抽象理解，并形成的一种表达方式”，通常体现为软件元素及关系。这是大家最为熟知的架构的含义。
（2）对于架构的另外一种形象说法是，它是系统的骨架，是系统中不能更换的部分，或者说是一旦形成、再难改变的部分。如果用汽车来打比喻：汽车的底盘是架构，汽车的座椅就不是架构，座椅可以更换，底盘则无法更换，换底盘无异于换掉整部车。
（3）对于架构还有一种理解方式，即为了满足质量属性所做的事。没有质量属性就没有架构，质量属性是架构整个工作自始而终的轴心。
（4）架构还是对系统施加的约束，这也强调了约束的重要性。约束系统不能做什么的过程，就是在进行软件设计，就是一种架构的形成。
（5）对于架构的词性，多数理解认为架构是名词，其实架构也有动词的词性。我们可以把架构理解成设计动作，它是对软件的组织编排，就本质活动而言，它是一系列的技术决策，以及构建动作。尽管架构设计与技术设计两者间的边界越来越模糊，但从本质上讲，一切架构设计都是技术设计，反之则不然。
（6）第3章会反复提及软件系统的复杂性，那么架构则是处理复杂问题的方式，降低系统复杂性的一个过程。架构是降低风险的一个过程，没有技术风险，当然也就不需要做架构了。
（7）架构一词，还可以从更广义的范畴上被泛化理解为一种结构性关系，一种系统化思维，是多维度认识、迅速剖析一个软件系统的自然而然的方法论。因此，完全可以说架构是一种思维认知和意识。
毫不夸张地说，笔者可以给软件架构列出几十种定义。对架构一词，《演进式架构》一书给出了更有趣的定义：“架构就是一切重要的东西。”这是我所见过的若干定义之中最为推荐的一个，这源于它的高度抽象性和概括性。无独有偶，《分布式系统架构：架构策略与难题求解》一书对架构的含义也给出了类似的说辞。
使用如此多的定义方式去看架构的含义，确实可以帮助我们从多个切面去理解架构。除了上面的定义和理解方式，架构还可以是一种技术角色。这并不难理解，与项目管理、程序员这些角色是同理的，不同角色负责不同工作而已。在日常实际工作中，建议将架构当作技能，而不要站在角色角度去理解它，否则会将注意力集中于架构师与开发者之间的区别上。实际上，现代企业中架构师、项目管理者、核心开发人员的工作职责是互相融合和渗透的，从发展趋势来看，这些岗位之间的边界可能越来越模糊。正是因为这样的特性，在岗位设置上，可以看到很多企业倾向于压缩架构师团队和项目管理团队的规模。
架构学的出现只有几十年的时间，严格来说它更像是一门手艺，难以被称为学科。其中道理，在笔者的第一本著作
中已做过描写：从事软件架构设计工作，不需要持证上岗，主要门槛是个人实力，难以将软件架构进行绝对化、学科式的考量，更不乏自学成才者，在此方面，难以将其与律师、医生、会计师等行业相提并论。
架构具有主观性、艺术性、平衡性、难以度量性这些特征。架构并没有好坏，只有适不适合。架构设计越来越广义化，越来越泛化，它与技术设计逐渐融为一体。架构管理与技术管理也是同理，两者之间的界限也是很模糊的，不同的企业、不同的人员配置，都可以有灵活的、自定义的工作分工方式。
软件架构，因服务于软件设计而生，以达到质量属性为目标。但是，不论是架构还是软件工程，都未给软件带来严格意义上的标准化。
相比于食品的成分表，用户购买的软件不会制式标明其内部构成。相比于汽车的尺寸、极限功率和速度，用户其实并不知道所使用软件的真实承压能力，即使软件采购合同中标明了最大并发数、无故障运行时间等方面的参数，也仅能当作参考所用，实际值取决于客户提供的运行环境和维护方式等其他因素。行业中关于质量属性的文档不计其数，但是具体软件中从未标识其出厂达到的各项质量属性标准值，除了有监管要求的能耗值外，可伸缩性、弹性、安全性等任何重要质量属性都不会提供清单可查。质保、退货，这些在任何商品采购领域的共识性服务，对于软件来说都不太适用，即使有约定，也常有名无实。
相比于相对严苛的工业软件，上述这些问题在互联网软件、消费类软件中更为严重。即使是银行核心交易系统也是如此，客户遇到Pos机交易失败时，除了投诉别无他法可言，没见过银行对社会发布刷卡失败的标准化赔付条款。这并非抨击银行，笔者知道这样的标准确实难以事先界定，根据具体影响情况进行事后处置更符合常规。但是就标准性话题而言，软件领域存在这样的问题，确实是客观现实。
对于软件架构，很多情况下是处在“无法度量、只能体验”的世界中。这与0.1节中提到的“软件架构已经相对成熟”的观点貌似南辕北辙，但仔细分析，现实的确如此。或许，这就是软件架构的魅力所在。
在架构知识、方法之上，本书更深远的立意在于，提升实战中的技术判断与决策力。
下面讲一下决策力的含义，相比于架构思维，决策力一词在本书中的含义更为广阔，不仅指建设软件系统的架构决策、技术工作以及管理决策，还包含关于软件从业者如何学习、如何自我定位，以及如何竞争的思考分析，这是有关于个体职业发展方面的决策。
决策比架构的动态变化更强，我有时很喜欢说“架构是架构、决策是决策，这是两回事”。这句话听起来武断，实则不然。当存在有价值的权衡时，我们也可以违反架构原则，例如，有意牺牲系统之间的低耦合度来提高通信性能，或是降低安全加密强度来加快软件的上市时间。此时，起决定作用的因素，是决策而非技术。
技术决策确实有正确与否的绝对答案吗？对于这个问题，笔者观点是十分明确的。决策是平衡与取舍的艺术，是一种审时度势、左右逢源的折中艺术，是一种虽无答案但仍能够超越分歧继续前进的力量。总而言之，决策没有绝对意义上的正确或错误。如果能从心理学角度看待决策问题，则更容易理解决策的本质，决策是在人的智力、经验、偏好、心态等数个维度的主观能力综合作用下做出的决定。决策是一种意识形态的体现，因此永远无法逃脱“被主观性所驾驭”的枷锁。
如果决策过于频繁，可能是工作根基出现了问题，如果决策发生困难，可能是向前无路，需要暂时回避，延时决策。总之，工作中无时无刻不在决策，说句感触颇深的话：我的工作，不是在“正在决策”之中，就是在“去往决策”的路上。
既然没有绝对答案，那么对于软件设计、架构管理、技术决策工作而言，我更喜欢使用最佳实践一词。无论如何，这个词听起来永远是无懈可击的。
正是因为主观性、泛化性等特点，相对于某个领域的具体技术而言，写好一本架构方面的书籍难度更大。如果本书能“上得厅堂、下得厨房”，适用于各类读者，让读者能看得懂，并能收获到知识和趣味，做到雅俗共赏，那么就算成功了。