在软件的开发演进过程中，都会涉及软件的架构，那软件架构究竟是指什么？在软件的整个生命周期中又都包含什么样形式的软件架构？它们的作用又是什么？什么样的角色和团队要为这些架构负责？带着这些问题我们一起聊聊软件架构这些事。
什么是架构
架构的本意是指结构以及结构之间的关系，而作为动词的架构就是指根据需求、目标、问题场景等所做出的一些列符合要求的设计决策，换句话说架构就是做设计决策，但是软件开发本身就是一个不断设计的过程，所以才有开发一个软件其实就是在做 software design 的说法，那是不是就可以说软件设计就是软件架构？这样的说法并不正确。
要解决一个问题，可能会设计出101种解决方案，但并不是设计所有这些解决方案时都可以称之为架构，因为最终你会根据多种因素比如时间、金钱、团队技术水平等只选择其中的一种方案，而你做出这种潜在选择的设计决策就是架构。
不难理解，所有的架构的都是设计，但是并非所有的设计都是架构，架构反映的是让一个系统成型的重要设计决策，决策的重要性是通过改变的成本来衡量的。架构的这种定义决定了架构几乎存在于软件开发的方方方面面，比如网络架构、数据架构、解决方案架构、安全架构等等。
架构的种类
架构和决策有关，因而架构的种类划分会根据决策的问题场景不同而不同，按照软件开发的生命周期可以分为：业务需求架构、产品功能架构、应用系统架构、应用程序架构。
业务需求架构
业务需求架构发生在业务需求提出的阶段，这个阶段的处于软件开发的最早期，此时开发者对于要解决的问题可能根本还不了解，甚至提出需求的人也未必真的能把问题讲清楚，说明白。因此这一阶段最重要的就是梳理业务需求和业务流程，为产品提供明确可被解决一个个业务问题。
业务需求架构就是在软件开发的初期，罗列业务需求，提取业务问题，梳理业务流程，明确业务价值以做出合理的业务规划。
产品功能架构
明确了业务需求，就需要设计解决业务问题的产品，产品有什么的样的功能，各个功能之间的关系是什么，业务流程是如何通过产品提供的的功能完成的，这些都是产品功能架构要解决的问题。
产品功能架构就是设计产品所具有的所有功能模块以及各个模块之间的关系，将它们按照合理的层级、关系进行梳理组织，形成具有完整性的产品结构。
应用系统架构
一般来说，应用系统架构是更大规模的应用程序的集成与架构，系统架构会横跨多个应用程序，并且应用程序之间有明显的边界和职责划分，甚至还包括硬件，系统架构关注的是应用程序之间如何集成、关联、调用，在系统架构中，不会特别关注单个应用程序的技术细节，除非这些技术细节影响了系统之间的集成。系统架构中经常会涉及非功能性需求，比如审计要求、系统的构建和发布形式、系统的可伸缩性、可用性要求、安全性要求等等。
应用系统架构就是具有不同能力和职责的应用程序之间的结构、层次、关系的划分和集成，系统架构要求在更高层次上描绘应用程序之间的关系，并且需要考虑很多非功能性需求。
应用程序架构
应用程序架构是大多开发者所熟知的设计应用程序所涉及到的技术架构，因为其本身就是关于编程语言选择、代码模块划分、API 设计、框架选择、命名规范、函数设计、错误处理、设计模式、单元测试等一系列技术细节的选择、约束、规范。
应用程序架构就是应用程序的技术架构，这将是软件开发和软件生命周期中最细粒度的架构，应用程序的架构好坏直接决定了软件代码的质量、可维护性和可扩展性，应用程序架构几乎涉及到的技术开发的所有细节。
谁该为架构负责
现在，我们知道了架构就是设计决策，软件开发又包含：业务需求架构、产品功能架构、应用系统架构、应用程序架构，那谁该为这些架构做出正确的设计决策？可能大多数读者的第一反应是该架构师上场了，是的，此时需要架构师来干活了。但是什么样的角色适合做这些架构，技术、产品、提出需求的人还是项目经理 ？
绝大多数业务需求架构设计都免不了会受到技术成本、市场因素等客观条件的约束，要能设计出满足诉求人合理业务需求的架构，需要决策者对能对各种综合性因素做出考量，包括但不限于技术、市场、金钱、团队构成等，这就要求决策者必须是能理解需求、了解市场、熟悉技术、知道团队构成，这就是业务需求架构的人选要求。
有了业务需求架构的输入，设计产品功能架构可以说软件开始进入落地阶段了，以笔者的理解，这就是大多数产品经理角色的能力范围。
应用系统架构和应用程序架构很显然是属于技术的范畴了，这也是我们通常意义上所说的架构师所负责的领域范围，负责技术架构的人一般被称之为软件架构师。
架构师的角色应该如何扮演
很明确的说，架构师是一种角色而不是一个职位或是某个人，因为担当角色的可能不只是某个人，也可能是一个团队，这个角色需要扮演以下职责才能发挥他的作用。
理解需求，明确目标
这个角色首先需要理解需求，理解最终产品是什么，以及产品所要达成的目标是什么，除此之外，对于软件所要满足的非功能性需求，比如性能、伸缩性、可靠性、安全性等也要保持关注。
设计软件
软件是设计出来的，软件的设计过程包含很多的技术细节，技术选型如何做？如何选择合适的框架和数据库？是否应该包含 ORM 框架？编码规则是什么？如何测试软件的正确性？代码质量如何保证？这些都是软件设计要关注的，但远远不止这些。
预估风险
设计成功的软件可能很难，但是想要它失败却很容易。软件的设计开发过程中隐含着种种风险，尤其是在交付日期逼近，很少有人会真正关注软件是否真的会以设想的方式工作，架构师这个角色必须要承担这种风险管理职责，确保软件的交付是正确的。
在做技术决策时需要审慎评估和选择，例如如果你的业务非常复杂，对灵活性要求很高，这个时候选择一个大而全的ORM框架就要三思，越大越全，也意味着灵活性的缺失，最终会导致架构的僵化，难以扩展和变动。笔者曾亲见过，有团队把引入 Django 的 ORM作为团队的主要 ORM 框架，从而最终导致公司在上市审计时候做出变动非常困难，如果系统对稳定性要求很高，引入一个未经考验的组件可能就是个风险点，笔者所在的团队就曾经历过采用 Istio 这个网关新星而失败。
架构演化
没有一成不变的软件，软件生命周期的绝大部分时间都在维护和改动，同理也不应该有一劳永逸的架构，没有架构会在设计之初一下子就把将来所有的可能性都覆盖，软件架构是在软件开发的维护过程中随着需求的变化而不断演化的，问题需求决定了架构的设计，反过来架构设计又决定了软件的开发效率和质量，架构发生演化的另一个因素就是开发团队的反馈，架构师因而要根据软件需求的变化和团队的反馈应时调整，应时的含义是说不应该过早也不应该过晚进行调整。
参与开发
笔者见过很多架构师从来不写代码，这和厨师从来不吃自己做的饭没有任何区别，架构师不参与开发就不能亲身检验自己的设计是否合理，完全交由开发团队很难保证最终的架构设计可以被成功塑造，架构师有义务通过主动参与开发来引导开发团队落地架构实践。
既可以参与实际编码，又能够做出重要的设计决策，要求架构师能够做到在底层技术细节和架构大局之间灵活切换，做架构师真的好难，既要又要，因而不是人人都能成为架构师。
质量保证
好的架构不一定会让软件最终成功交付，但是差的软件质量一定会让软件交付失败，因此架构师保证软件的质量至关重要。质量保证不仅仅是代码评审，架构师需要在架构实践中引入合适的设计原则、编码标准、测试基线等来保证架构的质量。
如何成为一个合格的架构师
知道了架构师应该扮演的角色，那该如何成为可以成功扮演这些角色的架构师。毕竟有种说法是“人人都是架构师”，其背后的含义好像是说不成为一个架构师都不能称之为人了，因而成为架构师对“作为一个人真”的是至关重要。
平衡技术深度和广度
毋庸置疑，架构师需要掌握很多的技术知识，且需横跨多个领域，这是对架构师技术能力的硬性要求。广则不深，专则难以广，架构师需要在广度和深度之间适度权衡，有的放矢，听上上是正确的废话，但是真的很管用。没有广度，很难预知架构面临的风险，风险可能来自任何地方；没有深度，无法保证在架构演化过程中可以及时做出影响全局的重要技术决策，细节往往决定成败。
学习领导力，建立影响力
领导力和影响力是架构师需要必须要具备的重要品质，而影响力的建立是一个非常长期的结果，这通常和架构师自身的技术能力过硬有关，更和架构师善于倾听他人的想法，并做出合理回应有关。架构师不仅仅是要善于处理一堆技术问题，更是一个团队的润滑剂和教练，他需要为团队创建一个共同的目标，并且积极带领团队为之付出努力。软件架构不仅关乎技术，还关乎人，有团队的地方就有情绪、政治、利益，架构师就是需要在满足大多数人利益的情况下，还能让团队成员保持着积极面对问题的热情，这就是领导力。
学会控制和放权
架构需要约束，约束就是需要控制，控制什么，什么时候控制，都是架构师要掌握的，可能架构师没有人事豁免的权力，但是技术决策上应该有决定权。控制总会让人不爽，控制是为了保证架构正确落地和质量，但是控制一定程度上也会导致开发效率降低。如果控制的范围过大，控制的数量过多，常常会适得其反，让开发团队产生抵触情绪，控制的范围太小，可能起不到促进架构演化的作用。如何决定？保留架构师的技术裁决权，适当放权给团队，划定可一定时间内执行落地的范围，和团队达成一致，比如约束命名规范，和团队协商对命名约束达并成一致，借助 IDE 工具快速让命名规则在已有代码库中保持统一，并保证可以持续在后续的编码中落地。快速让已经存在的命名保持统不仅践行了架构实践，也让团队认识到这种约束的真正意义，协商一致可以你让团队成员都遵守共同的承诺。
技术的裁决权为什么重要？在很多关键时刻，独裁可能才是解决问题的最佳形式，并不是所有人都有勇气打破常规做出一些正确但是当时团队又无法理解的技术决策。
做好抽象，关注细节
架构师需要知道在什么时候关注抽象，什么时候关注细节，过度的抽象可会导致细节藏的太深，架构无法揭示软件实际的面貌，细节太多也会让软件缺乏架构的指导，让架构失去作用。关注抽象需要有大局观，关注细节需认识抽象的局限。更多的抽象的，意为更多的理解成本，更多的细节意味着又会导致难以扩展和维护。架构师需要在二者之间做出平衡。
成为架构师的途径看似有点虚无缥缈，还充斥着正确无比的大道理，就好像听了很多道理依然过不好生活一样，实践才是检验大道理的唯一标准，你需要在团队中做一次架构来开始架构师之路。
