架构是什么？
老生常谈了。那就看看ChatGPT怎么说：
软件架构是软件工程师在设计一个软件系统时，定义系统架构结构的一种科学方法。它指的是软件系统在软件工程师关注功能、性能和安全等质量属性的条件下，组织系统的方式。换句话说，软件架构是一种把软件系统划分为模块，以实现特定功能的技术手段。
软件架构主要由三个要素组成，分别是：
1. 模块结构：模块结构是把软件系统划分为不同的模块的一种结构，以实现特定功能。
2. 框架结构：框架结构是把软件系统的各个模块按照一定的组织形式组织起来的一种结构，以实现特定功能。
3. 组件结构：组件结构是把软件系统由不同的组件组成的一种结构，以实现特定功能。
软件架构师与建筑师的类比隐喻
“Architecture”（架构）一词，在 google 的搜索结果页中第一条是维基百科的定义，在维基百科上是这样定义“Architecture”的:
Architecture is both the process and the product of planning, designing, and constructing buildings and other physical structures.
从这个解释看，架构是对建筑物和其他物理结构的规划、设计、和组织的过程和产品，看起来“架构”既是一个过程，又是一个结果。而且，“架构”原始的定义是面向建筑设计的，计算机在20世纪中叶才出现，软件业的蓬勃发展是在20世纪的80，90年代，相比于人类文明几千年的发展史，计算机、互联网的出现实在是太晚太晚，在此之前，“架构”一词还是主要应用于建筑领域，新事物的出现往往会借助旧事物的感念，“架构”一词就是这样来的，在软件行业还有很多这样次词，也是来源于建筑行业，比如“防火墙”（补充），“IT民工”。
一提到“架构”，在程序员或者系统架构师的脑子里就会出现各种规格的服务器，各种功能的软件，在建筑师的脑子里就会出现钢筋，水泥等各种建筑材料。
互联网和土木建筑虽然是不同的行业，但他们之间又有非常多的相似之处，都是通过将不同的组成模块有机联系在一起。
对一个建筑物，需要考虑，有空间，有多少平米，能容纳人居住或者办公；
对于系统如要考虑，能够支撑多大流量，这是所谓的容量规划。
对于一个建筑，需要考虑行防火防灾，要有一定的抗震性；
对于一个软件系统也要考虑容灾，不能因为一个单点的故障让整个系统崩溃。
一个大型系统的构建过程和一个建筑物的构建过程是非常类似的。
对于一个小平房，也许几个瓦匠几个木匠就建起来，这事每个人都兼具家中角色，比如既能当电工又能当钳工，就像一个网站或者APP的创业初期，经常是一两个开发人员搞起来的，就像最初facebook扎克伯克一个人开发的，google 是佩奇和谢布林两个人搞起来的，这时架构的作用还体现得不明显，随着业务规模的变大，面对的问题变多，分工越来越多样化，架构的意义就凸显出来了，比如新建一个机场（首都机场举例），面多如此多的工程，人员分工协作，很难想象可以按照一个小平房的方式去构建。
也很难想象，想BAT这样量级的公司，每天面对十几亿甚至几十亿的流量，整个系统的组织方式和一个企业官方宣传网站是一样的。
一辆玩具汽车有三十个零部件，一个真正的汽车有3万个零件，一架航天飞机有200万个零件，你能相信他们的构建方式的是一样的吗？越是庞大的系统，不仅需要高级额模块，还需要精密的组织，一堆砖头堆砌在还是在一堆砖头，并不能称为建筑，长期间都在哪里甚至可以叫做建筑垃圾，只有通过“架构”，将砖头砌成多长多高的墙，分割成几室几厅的空间，哪里留门，哪里流窗，总之通过一些列组织之后，才能形成产品，这个过程就是架构的过程。
架构师就像建筑行业的设计师，也许不是最优秀的电工、记忆最精湛的瓦工，但确实一个建筑工程中知识最丰富的人，懂得哪里用钢筋，哪里用木材，懂得如何利用建筑材料，而且能够将各种材料有机结合在一起。
架构师，就是通过抽象将整个系统进行清晰的划分，对整个产品负责，而不是仅仅是局部单一功能。
软件架构是一种结构化的方式，用于定义软件系统的模块、接口和关系，以及这些模块、接口和关系如何协同工作来实现软件系统的功能。它的目的是实现系统的可扩展性和可重用性。软件架构描述了软件系统的结构，但不涉及细节。
软件架构有多种形式，如架构图、架构视图和架构风格。架构图详细描述了系统中组件之间的关系，包括组件之间的接口和数据流。架构视图描述了系统的功能和结构，以及系统的构建和构建步骤。架构风格是一种抽象的设计模式，它指导系统如何被分解成一系列可重用的组件。
软件架构可以帮助软件开发者更好地理解系统的功能，以及如何更有效地开发软件。它还可以帮助软件开发者更好地构建软件，以满足软件质量要求，提高软件可维护性和可扩展性。
举个例子，假设我们要开发一个简单的电子商务系统，这个系统可以处理用户的订单、物流和支付。我们可以使用软件架构来构建这个系统。
首先，我们需要构建一个架构图，描述系统中不同模块之间的关系，以及它们之间的接口和数据流。然后，我们可以建立一个架构视图，描述系统的功能和结构，以及如何构建这个系统。最后，我们可以使用架构风格，指导系统如何被分解成可重用的组件。
软件架构生命周期
万事万物都不可能是永恒的，系统架构一样，也有一个生命周期，也有生老病死的问题。
互联网行业就是一个和时间赛跑的行业，快人一步可能意味着永远的领先，这个行业流行一个有个有意思的规律，叫做7:2:1法则，市场份额是中的70%被行业第一的公司占据，第二名占据20%的份额，其余的10%再被剩下的其他公司瓜分。市场永远在变化，第一的公司如何保持领先地位，如何才能不被第二第三的公司超越，“快”就是其中的重要因素，可谓“天下武功唯快不破”，“快”就是壁垒，就是优势。所以，当一个新机会出现时，业务会等你先设计一个完美的架构在上线吗？当然不可能，所以任何架构都是为了解决眼下和未来一段时间的问题，核心价值在于满足的业务的需要，同时考虑业务未来一段时间的增长。所以，任何架构设计都不可能一开始就完美，除非业务的规模不再增长，只能通过不断的迭代升级，才能变得越来越强大。
技术架构一遍经过三个阶段，创建期、瓶颈期和退化期。
架构在创建器满足业务需求，在创建期迅速开发，迅速迭代，快速满足业务需要，当达到一定服务能力之后进入缓慢迭代的成熟期（瓶颈期），当为某个时间点遇见到现有的系统架构已经无法满足未来的业务需要时，就要准备研发新的架构，再替换老的系统架构，此时老的系统架构进入衰退期，新的架构进入创建期，直到完全被新的系统架构替代。比如，电商平台，初期使用单机架构模式，等到业务规模不断扩大，访问量、数据规模逐渐变大时，老的单机架构在未来已经无法满足业务需求了，就是从单机架构过渡到分布式架构。
当然，引起架构衰退的原因不仅仅是服务能力的不足（还包括现有架构满足不了业务功能），还可能是编码问题，文档问题，导致后来的人员对既有系统难以维护，开发升级效率越来越低，这种情况在实际工作中很常见。
架构的演进
一个架构的演进，从简单到复杂，需要关注的要点有一下几个因素：
功能预见性（功能性）：这是架构设计的第一要务，任何架构设计不能脱离需求凭空存在，所以架构从满足需求最大程度功能上的要求。其余要点都是以满足功能为前提的，为了设计漂亮复杂的架构，而忽略功能性的要求是不可取的。而且还要考虑系统架构是能支撑多久。
系统可用性：这一点对一个被高频使用的产品只管重要，可以想象一下，像百度搜索、淘宝、微信这样的产品，或者是双十一这种大促活动，一天就有过千亿的交易和，哪怕是一分钟的不可用都会给企业带来数以千万的损失，而且还会对公司声誉造成影响，让用户失去对你的产品失去信心。所以，对于一个大型系统，对核心系统的出错几乎是 0 容忍的，对技术架构也是一个基本要求。在分布式系统的架构的设计中，要仔细考虑每个组件或者子系统的可靠性，必要时可以丢车保帅，确保核心系统不出故障。从可用性触发还可以延伸出可靠性和容错性：
容错性：另外，系统还要具备一定额容错能力，随着业务规模的扩大，系统架构也会越来越复杂，整个系统由很多组成部分构成，那么整个系统不能因为单点的故障就引起整个系统的崩溃，所以系统设计中要有容错机制。
可靠性：在容错性基础之上还要保证用户的输入出去的正确性，不能因为部分系统的错误就造成数据、操作的混乱。
性能够快：产品的性能对用户的体验有着至关重要的影响，如果产品和SEO相关，还会影响搜索引擎的排名，进而影响流量和收入。曾经有报道称，Google的页面访问速度每增加500毫秒，搜索量就会下降25%，访问亚马逊每增加100毫秒，就会损失%1的订单；Facebook 每增加500毫秒，会损失 %3 的访问量。可见性能对于产品的影响之大，创建一个高性能的系统架构对于产品而言非常重要。
可伸缩：对于大型分布式的架构，必须具有一定的伸缩性，能够面对负载的变化进行调整。比如很多电商网站网站定期举办的大促活动，比如每年的京东618，天猫双十一等，往往在这种活动期间，系统的负载要比平时翻几番。所以对应的系统架构，要具备一定的伸缩性，能够以非常容易的方式进行扩展，比如可以很容易水平增加计算资源和存储资源等就可以应对更高的流量负载。
可维护性：越复杂的系统就依赖于高度的自动化。一个大型的架构系统的维护工作一定是趋于简单，具备高可维护性。越复杂的系统越脆弱，越需要自动化的运维工具，而不是完全依赖于人力，是要尽量少的依赖人力，靠批量操作。除非必要，没有必要增加额外的依赖。
安全性：网络世界也是一个江湖，有好人也有坏人。所以架构设计中一定要考虑安全的因素，俗话说“害人之心不可有，防人之心不可无”，作为架构是要假设这个世界是不安全的，要面对种种不不完全的攻击，包括病毒、服务器的攻击，以及数据安全。
成本：在大企业工作时，往往会忽略成本的因素，因为有充足的资源让架构师可以尽情发挥。但这确实是架构设计中要考虑去的重要因素，包括软件、硬件成为，以及需要投入的人力成本，包括开发、运维、测试等等。还有就是使用新技术带来的风险和学习成本。
可度量性：架构设计的质量可以通过可量化的指标进行衡量。比如响应速度，敏捷性，批量上线的周期等等。而且每一个单独的模块可以进行测试。
当然“罗马不是一天建成的”，一个系统从简单到复杂是经过不断迭代演进而成的，不会一蹴而就，而且这些要素之间有时也是互相冲突的，作为架构师就要做的就是在以上几点之间做权衡，要考虑哪些因素对你是更重要的。
在架构的演技过程中，容易掉进如下几个问题的大坑里：
“重复造轮子”：这句话相比有过几年工作经验的程序员不会陌生，但这种问题在架构设计中也非常常见。很多时候，尤其是新人，由于经验、视野问题，找不到可用的轮子，遍从头创建一个轮子。就算只有10%的差异，却要重写90%的代码，相比于成熟的开源软件，一两个人维护的产品很难持续。所以实际架构设计中尽量使用成熟、开源的解决方案，及时少量不满足的功能，多数情况也可以通过变通的方法解决掉，或者进行少量的二次开发以满足需求，而不是因为一点满足都要从头开始，再不考虑功能的情况下，这里的时间成本，人力成本，可维护性都是个严重的问题。
脱离实际业务需求：需求决定价值，技术的价值在于满足了业务的需求，在架构设计中为了技术而技术，不考虑业务是否真实需要是没有任何价值的。一味求新求变，尤其是使用很多小众软件，而不考虑是否真正为业务带来价值，是不可取的，有事反而会增加系统架构的脆弱性，维护的难度，反而让架构更加不可靠。再一点就是一位追求大公司的解决方案，互联网行业有很好的分享氛围，网上能找到很多可以借鉴的资料，尤其是大公司公开出来的，所以很多人就变成了伸手党，一味抄袭大公司的解决方案，而不加任何分析，不考虑是否真正能为业务带来好处，一句“Amazon”就是这么做的，“Facebook”就是这么架构的，就成了最终的决策依据。但要记住，你不是Amazon，你也可能不是Facebook，你不一定有那么大的规模，也可能是面临不同的业务问题，所以不要盲目追求别人的方案，可以有选择地借鉴，但不要完全抄袭。
避免无意义的重构：“铁打的营盘流水的兵”，随时时间的推移，架构还是那个架构，维护架构的人的人已经不是之前的那批人了，互联网行业发展这么快，人员流量也很正常，有事一个业务一两年甚至几个月就会换一拨人。对于系统架构，或者程序架构，后来的程序员面对前任留下来的东西旺旺是脸上波澜不惊，心中翻云覆雨，虽然谁技术是相通的，但不同的程序员、不同的架构师面对同样的问题是，态度可能不一样，也许系统中用的某些软件不是他擅长的，或者某些代码风格不是他习惯的，所以很容易就会滑向重构的坑，为了自己运维使用的舒服而把架构中大量的组件重构，而不考虑是否会业务带来价值，如果这种问题不解决，下一波人进来还会重复这种问题，就会不断进入重构再重构的恶性循环。所以为什么我推荐在架构设计中尽量使用成熟的方案，使用敏捷的方式，简单可依赖，才能避免不断滑入毫无价值的重构的坑。
功能完成是完事了：很多时候，很多人认为只要功能完成了，满足业务需求了就是完事大吉了，但还要考虑后期维护，升级的问题。如果没有清晰的文档，教程、后来的人搞不懂架构的细节，面对业务升级，就会不算地打补丁解决临时问题，补丁摞补丁，整个架构逐渐腐化掉，最后积重难返很容易把原来的方案推翻重来，就像前文提到的，就会滑向毫无意义的重构的大坑里。
技术解决一切：双十一秒杀为例，通过验证码，问题方式解决，就可以轻松缓解瞬时压力。
【更多阅读】
【企业架构设计实战】0 企业数字化转型和升级：架构设计方法与实践
【成为架构师课程系列】系统架构设计：非功能性目标的设计
【编程实践】Linux Shell 编程：使用 循环和递归 实现斐波那契数列代码
【编程实践】Linux / UNIX Shell编程极简教程
【编程语言】Scala 函数式编程
【编程实践】SQLite 极简教程
【编程实践】Google Guava 极简教程
【编程语言】AWK 极简教程
Bito AI：免费使用 ChatGPT 编写代码/修复错误/创建测试用例Use ChatGPT to 10x dev work
写代码犹如写文章: “大师级程序员把系统当故事来讲，而不是当做程序来写” | 如何架构设计复杂业务系统? 如何写复杂业务代码？
【工作10年+的大厂资深架构师万字长文总结 精华收藏！】怎样设计高可用、高性能系统？关于高可用高性能系统架构和设计理论和经验总结
【企业架构设计实战】0 企业数字化转型和升级：架构设计方法与实践
【企业架构设计实战】1 企业架构方法论
【企业架构设计实战】2 业务架构设计
【企业架构设计实战】3 怎样进行系统逻辑架构？
【企业架构设计实战】4 应用架构设计
【企业架构设计实战】5 大数据架构设计
【企业架构设计实战】6 数据架构
企业数字化转型和升级：架构设计方法与实践
【成为架构师课程系列】怎样进行系统逻辑架构？
【成为架构师课程系列】怎样进行系统详细架构设计？
【企业架构设计实战】企业架构方法论
【企业架构设计实战】业务架构设计【企业架构设计实战】应用架构设计【企业架构设计实战】大数据架构设计【软件架构思想系列】分层架构【软件架构思想系列】模块化与抽象软件架构设计的核心：抽象与模型、“战略编程”企业级大数据架构设计最佳实践编程语言：类型系统的本质程序员架构修炼之道：软件架构设计的37个一般性原则程序员架构修炼之道：如何设计“易理解”的系统架构？“封号斗罗” 程序员修炼之道：通向务实的最高境界程序员架构修炼之道：架构设计中的人文主义哲学
Gartner 2023 年顶级战略技术趋势【软件架构思想系列】从伟人《矛盾论》中悟到的软件架构思想真谛：“对象”即事物，“函数”即运动变化【模型↔关系思考法】如何在一个全新的、陌生的领域快速成为专家？模仿 + 一万小时定律 + 创新
Redis 作者 Antirez 讲如何实现分布式锁？Redis 实现分布式锁天然的缺陷分析&Redis分布式锁的正确使用姿势！
红黑树、B树、B+树各自适用的场景
你真的懂树吗？二叉树、AVL平衡二叉树、伸展树、B-树和B+树原理和实现代码详解
【动态图文详解-史上最易懂的红黑树讲解】手写红黑树（Red Black Tree）
我的年度用户体验趋势报告——由 ChatGPT AI 撰写
我面试了 ChatGPT 的 PM （产品经理）岗位，它几乎得到了这份工作！！！
大数据存储引擎 NoSQL极简教程 An Introduction to Big Data: NoSQL《人月神话》（The Mythical Man-Month）看清问题的本质：如果我们想解决问题，就必须试图先去理解它【架构师必知必会】常见的NoSQL数据库种类以及使用场景新时期我国信息技术产业的发展【技术论文，纪念长者，2008】B-树（B-Tree）与二叉搜索树（BST）：讲讲数据库和文件系统背后的原理（读写比较大块数据的存储系统数据结构与算法原理）HBase 架构详解及数据读写流程【架构师必知必会系列】系统架构设计需要知道的5大精要（5 System Design fundamentals）《人月神话》8 胸有成竹（Chaptor 8.Calling the Shot -The Mythical Man-Month）《人月神话》7（The Mythical Man-Month）为什么巴比伦塔会失败？《人月神话》（The Mythical Man-Month）6贯彻执行（Passing the Word）《人月神话》（The Mythical Man-Month）5画蛇添足（The Second-System Effect）《人月神话》（The Mythical Man-Month）4概念一致性：专制、民主和系统设计(System Design）《人月神话》（The Mythical Man-Month）3 外科手术队伍（The Surgical Team）《人月神话》（The Mythical Man-Month）2人和月可以互换吗？人月神话存在吗？在平时的工作中如何体现你的技术深度？Redis 作者 Antirez 讲如何实现分布式锁？Redis 实现分布式锁天然的缺陷分析&Redis分布式锁的正确使用姿势！程序员职业生涯系列：关于技术能力的思考与总结十年技术进阶路:让我明白了三件要事。关于如何做好技术 Team Leader？如何提升管理业务技术水平?（10000字长文）当你工作几年就会明白，以下几个任何一个都可以超过90%程序员编程语言：类型系统的本质软件架构设计的核心：抽象与模型、“战略编程”【图文详解】深入理解 Hbase 架构 Deep Into HBase ArchitectureHBase 架构详解及读写流程原理剖析HDFS 底层交互原理，看这篇就够了！MySQL 体系架构简介一文看懂MySQL的异步复制、全同步复制与半同步复制【史上最全】MySQL各种锁详解：一文搞懂MySQL的各种锁腾讯/阿里/字节/快手/美团/百度/京东/网易互联网大厂面试题库Redis 面试题 50 问，史上最全。一道有难度的经典大厂面试题：如何快速判断某 URL 是否在 20 亿的网址 URL 集合中？【BAT 面试题宝库附详尽答案解析】图解分布式一致性协议 Paxos 算法Java并发多线程高频面试题编程实践系列: 字节跳动面试题腾讯/阿里/字节/快手/美团/百度/京东/网易互联网大厂面试题库
[精华集锦] 20+ 互联网大厂Java面试题全面整理总结
【BAT 面试题宝库附详尽答案解析】分布式事务实现原理……
