下载掌阅APP，畅读海量书库
立即打开
架构作为系统的支撑骨架，相信没有人会怀疑优良的架构对系统的重要积极意义。那么，架构的重要意义具体体现在哪些方面呢？下面我们不妨就这个话题进行适当的延展以充分的阐述。
架构内涵2
架构优良的系统往往有着清晰的内部结构，具体表现为水平方面层次分明，各个层次职责单一，通过明确的编排和组装很容易构建出新的功能；其次，纵向来看，各个模块之间的界限也相对明朗，开发时团队可以很容易对功能归属的模块达成共识，避免模棱两可。这会带来几个好处。
首先，更低的开发成本。假设我们处于一个架构混乱的系统之中，既缺乏清晰的层次结构，模块界限也是模糊不清，每一位开发人员各凭己意进行开发。那么设想一下会出现怎样的境地呢？第一，反复的沟通和争执是少不了的。因为每个人理解不一样，要区分谁对谁错本就不容易，加上系统往往有时间的压力，有些开发人员即使做得不正确，如果让他重新调整，往往又会以时间紧迫后续再改为由进行推辞。如此一来，需要浪费很大的精力进行协调。第二，功能复用基本会沦为海市蜃楼。因为没有统一的架构，即使系统里边有许多基础的功能、重复的模块，经过简单的抽象和拆解，沉淀出一系列可供不同功能复用的基础能力，如此一来，既节约了重复开发的时间成本，也为以后统一修改提供了便利。但因为缺乏统一的架构设计，这样的美好愿景基本上无从落地。因此，设计优良的架构不仅仅是艺术品一般精美，而是具备实际的经济效益。
其次，更低的维护成本。按照软件工程的一般观点，一个系统的成本，三成是消耗在开发阶段，七成则是更为漫长的运维阶段，可见运维阶段的重要性。然而，在实际工作中却存在一个悖论。一般新项目开发阶段，很多工程师，尤其是初中级工程师往往只专注当前的开发阶段，对于更长远的维护期则几乎漠视，这样的短视行为往往会导致很多的技术方案缺乏生命力和韧性。同时，我们又经常听到另外一张声音，几乎是普遍且刺耳的，“这功能是谁开发的？”“这些的什么玩意儿”“这么乱怎么改？”……很多系统在维护阶段往往因为一个小功能导致大面积功能塌方，费时费力往往结果仍然是差强人意，以至于形成一个不成文的默契：开发新功能不要去动现有的东西开发新功能，不要去动现有的东西，重新做一套更稳妥。这样的场面几乎是时刻在上演，历历在目。因此，架构的重要性显得更加重要，因为他不仅可以让维护阶段变得友好而可靠，还可以延长系统的生命周期。
其次，更快速的迭代。理由跟上述基本一致，因为结构清晰，井然有序，开发过程中可以减少不必要的返工和消耗，还可以沉淀可复用的能力，自然可以加速迭代开发。此外，维护阶段少了大面积塌方，一个改动只需要改动一处而不用到处搜索，自然也更加确切。
其次，更可靠的质量。因为结构清晰，各层和各模块尽可能的职责单一各层和各模块尽可能地职责单一，通过组装和编排实现业务逻辑的串联。修改的时候，往往也只需要在一个地方统一处理，避免遗忘；同时，也不担心不相关的依赖导致预料之外的副作用产生。
最后，系统具备更长的生命周期。因为架构得当，系统维护起来比较友好，可以延缓进入“开发新功能，不要去动现有的东西，重新做一套更稳妥”这个阶段，一旦系统进入这个阶段，就意味着短时间内会滋生大量的重复实现，而且腐败速度会越发加速，最终导致系统架构混乱，无从下手，不得已另起炉灶，原系统也寿终正寝。
优良架构的另一个重要意义在于实现组织的“技术一体”宏伟蓝图。主要体现在以下几个方面。
首先，可以落实统一的技术规范。在企业中，往往存在着若干产研团队，分别承担不同产品的设计、开发和维护工作。因此，很容易出现不同产研团队在技术规范上各自为政，以至于政令不通的局面。因为规范不统一，可能导致对于基础设施、对于持续集成和持续交付有不同的要求，进一步导致成本升高。
其次，因为缺乏统一的架构，某些团队踩过的坑很可能其他团队也会再掉一次，难以达到统一规避的效果。
其次，如果缺乏统一的架构，各团队架构不一，可能导致团队间不经意彼此互设门槛。当某个团队接到新的紧急项目，亟需其他团队人力资源时，可能会因为架构不统一而增加不必要的熟悉成本。
最后，对于大型组织往往有着自己的中长期技术战略。而战略的落实离不开旗下各个产研团队的一致支持。设想一下，假设企业制定技术战略之一是“中台化”，这必然要求各个产研团队统一思想，在设计中打开格局，从全局着眼，沉淀和复用中台的能力。而要实现这样的战略目标，必然要求在统一架构，要么在研发过程中嵌入架构设计的环节，以及各个产研团队负责人组成的架构领导小组，共同实现在各个产品的架构管控，从而达成战略目标。否则，如果只是号召和宣导，缺乏统一的架构管控，那么要实现目标，无异于痴人说梦。
优良的架构设计，除了有利于开发和维护，从企业宏观角度来看，更具备至关重要的作用。从企业角度来看，各个业务单元应当遵循统一的规划。譬如哪些部门是前台业务部门，他们的业务需要哪些中后台部门来协同支持，流转的逻辑和资料是什么，同理，他们的应用系统需要具备哪些功能，哪些是他们自己开发的，哪些功能又是直接调用其他部门的能力；同样的，对于中台部门，他们提供的能力需要支撑哪些场景，需要为哪些前台部门提供支持；后台部门又该如何支持前台部门和中台部门……如果没有站在企业角度进行高屋建瓴，对于小公司运作尚且可以招架，一旦企业规模攀升，多条业务线并行，势必会引发越来越多的混乱、重复建设、协同困难。
有了优良的架构设计，从业务角度，可以清晰地定义各个业务线的职责边界、协同流程、分工矩阵，然后可以各司其职，实现全企业一盘棋，畅通无阻。
从系统角度来看，配合业务架构，应用架构也井然有序，层次分明，与过往的千头万绪乱麻一般的状态不同，设计后的应用架构，即使应用系统再多，也表现出整体的一致性和秩序美。
从数据架构来看，数据有了规划好的流向和结构，也有了主次，即哪一类数据以哪个业务单元为基准，解决过去同一类数据出自多个业务部门且彼此无法相认的情况。通过一致性的数据架构，数据有了集中的存储空间，也有了统一的编码，要实现跨系统的融合连通，也变得水到渠成了。更重要的，数据可以成为支持经营决策的重要资源，进一步推进数字化的进程。
架构设计的另外一个显而易见的作用，便是满足系统性能要求。回忆起工作上，很多次架构设计时我们纠结的是系统为了需要承载多少用户，日活跃用户数大概是多少，有没有发红包、秒杀等运营场景，峰值TPS/QPS大概是多少，响应时间需要控制在几秒之内，甚至一条记录大概多少字节，需要缓存的记录大概有多少条，缓存服务器的内存需要多大，数据库服务器的内存需要多大……
这些都是作为技术架构师最耳熟能详的日常工作内容。除此之外，作为一名称职的架构师，还需要对常见的中间件的基础参数有大概的了解。譬如机械硬盘的IOPS大概是多少？MySQL5.7部署在4核16G内存的Linux服务器上，TPS/QPS分别能去到多少？数据中心内网络延时是多少？跨数据中心的网络延时又是多少？有了这些基础数据，大家在做架构设计时心里自然大概有了轮廓。
除此之外，对于中间件的特性也是架构师们需要了然于胸的。譬如kafka消息队列的优缺点是什么，适用于哪些场景？诸如此类，都在指向一个结论，既要满足系统的性能要求，又离不开精心设计并严格落地的架构设计。这个时候的架构师，就好比是一位技术娴熟的能工巧匠，对于案头的各个工具和材料的禀赋了然于胸，并能够轻松驾驭。通过对目标的事前专业分析，得出基准数据，然后匠心独运，将案头的材料有机地组合起来，并实现互联互通，从而产出一件满足条件的制品。
我们很难想象，假设支撑双11活动的天猫系统，没有经过架构设计，而是一群开发工程师按照自己的理解，胡乱拼凑而成。我们同样难以想象，飞向九天的火箭控制系统，没有架构师的精心设计，而是开发工程师简单地按照需求实现功能即可，要知道要想遨游寰宇，所面临的不可控因素有多少。单说火箭上数以万计的零部件，哪一个坏了又该如何？如何保障火箭在飞行中不偏离轨道……我们再谈谈大家刚入行便开始学习的TCP协议吧。要支持联通全球各地的网络，何等巨大，这里交换机故障，那里网线老化，那里网络被攻击……真是一团乱麻。即使是在如此复杂且无法掌控的现实环境下，TCP协议仍然能够稳定地工作，并且保证结果的可靠性。如果没有精心的架构设计，你信吗？反正我是不信的。
同样的，与性能指标同样重要的还有安全指标。安全作为一门博大精深的学科，在数字时代的重要性越发彰显。一家企业即使业务如火如荼，但是安全上不及格，很可能万丈高楼被瞬间夷为平地。说轻一点，如果公司的业务和系统设计上，没有遵循法律法规的要求，轻一点被监管部门罚款并要求停业整改，重一点可能被起诉，客户逃离，企业负责人面临牢狱之灾。这些不是恐吓，而是真实发生的事情。鉴于安全如此之重，如果没有精心的架构设计和管控，全凭开发工程师的专业和认知觉悟，我想大部分企业负责人估计是无法安稳入睡的吧。