3 什么是架构？
3.1 官方定义
“组成”论：程序或计算系统的软件架构是系统的一个或多个结构，它包括软件元素、这些元素的外部可见属性以及它们之间的关系。
“决策”论：软件架构是一系列重要决策的集合，这些决策与以下内容有关：软件系统的组织；选择组成系统的结构元素和它们之间的接口，以及当这些元素相互协作时所体现的行为；如何组合这些元素，使它们逐渐合成为更大的子系统；用于指导这个系统组织的架构风格。
综合两者：架构是一个系统在其组件层面的基本组织结构表现，包括系统内部组件之间的关系、组件与外部的关系以及决定其设计和演进的原则。
不知道大家第一眼看到这些官方定义会有什么感觉？反正作为一个非科班出身的程序员，我记得很清楚，这个架构定义是唯一一个我看了几年都还是觉得不明觉厉的定义。到现在不知不觉自己也做了十多年的架构，回头再看这个定义时，猛然才发现之前之所以一直不得要领，是因为我太过于执着于这个定义所包含的文字本身，而忽略了架构存在的根本原因和目的。为了帮助和我当初一样的小白同学快速地体会到架构的精髓，在此我把我对架构的理解和大家分享。
3.2 我的理解
架构存在的根本原因在于：目前的软件系统过于庞大复杂，参与方众多，投入巨大，因此如何在项目初期、在概要设计、详细设计之前便能协调各方关注，确保项目成功实施，以避免后续因项目实施失败而产生的巨大人力、物力、时间的浪费，就成为了一个必不可少的工作，而这个工作就是架构设计，而该工作产生的结果即为架构。
与面向具体业务模块实施的概要设计、详细设计不同，架构设计的目的更多的是通过架构控制项目整体的可实施性及其后续的运营风险。他在整个项目实施的初期就应成型，他面向的是整个系统，是比概要设计更高级别的设计，它不会也不应面面俱到，它关注的是系统的核心功能与核心特质，因此常常通过一些顶层结构及关键决策来表述。顶层结构自然而然地被描述为组件和组件之间的关系，以及组件与外界之间的交互；而关键决策往往来源于为了保证核心功能和核心特质权衡取舍后得到的定论。
综上所述，我对架构的理解如下：
架构就是确保系统核心功能，核心特质不受侵扰、自由生长的一系列顶层结构及关键决策。
近一步解释：
1、功能与特质指代系统的功能性需求与非功能性需求；
2、不受侵扰、自由生长指的是边界、职责清晰、可用、预测并响应变化，
3、一系列代表针对同一个系统、不同的关切会有不同的顶层结构（如业务架构、逻辑架构、数据架构、物理架构等等）及关键决策（分别针对安全、性能、高可用、可维护性等等）。
4、顶层结构即是组件和组件之间的关系，以及组件与外界之间的交互（如猿猿趴-物理架构）；
5、关键决策为了保证核心功能和核心特质，权衡取舍后得到的定论（如为了保证数据可信核心特质，猿猿趴允许适当降低用户的交互体验；为保证用户访问速度并控制网络带宽成本，猿猿趴前端实现动静分离，并引入OSS及CDN加速，但这其实增加了系统实施的工作量和复杂度）；
3.3 总结
官方的定义更多的是描述架构最终的表现形式，而隐藏了架构产生的前因后果，所以对于小白用户有些过于高深莫测，但如果从架构存在的根本原因和目的出发，自然而然的推导出架构落地时的表现形式，这样理解应该更容易把握架构的精髓。
