架构学习之旅-架构的由来

架构的入门知识可以先看看之前写的浅谈单体向微服务架构的演进
里面描述了 系统和子系统、架构与框架、模块与组件的大致区别，在此便不多赘述。

一、什么是 4R 架构

4R 架构的组成

• Rand(顶层结构）
  • 软件架构是分层，对应“系统”和“子系统”的分层关系。自顶向下，逐步细化。
  • 一般情况下，我们只需要关注某一层的架构，最多展示相邻两层的架构

架构在不同的分析方式下通常有着不同的表现形式，从流量的方向来看，可以区分用户层、网关层、应用层、基础设施层、存储层。从物理架构的角度进行分析，又可以区分开网关层、服务器层、存储层。新手容易犯的一个架构设计错误就是把不同角度的架构表现都融合在了一起，这样形成的架构图，边界往往不清晰，更加容易变成四不像。便表现的不是很“专业”

由于架构存在分层情况，因此，层次过多会导致架构复杂性增加，因此架构师在实现架构图设计的时候，可以侧重某一层的架构（比如应用层、或者存储层），再把相邻两层的架构一并表现。

顶层架构是在更高的视角去分析架构，此时，通常不会关注其某一层的具体细节，只标柱各层之间的关联性和重要介质。

• Role（组成角色）
  • 指软件系统包含哪些角色，每个角色都会负责系统的一部分功能，比如将整体复杂的业务系统按照业务领域的方式，拆分为多个微服务，每个微服务就是系统的一个角色

角色在不同的架构表现形式中所呈现的粒度也是不同，在微服务架构中，角色通常是指各个微服务，在公司级别的架构中，角色也可以区分为核心业务角色、通信交互角色、数据存储角色、质量保障角色、部署运维角色等

• Relation(角色关系）

  • 指软件系统的角色之间的关系，对应到架构图中就是连接线，包括连接方式、数据协议以及具体的接口等

• Rule（运作规则）

  • 指软件系统角色之间如何协作来完成系统功能

Rank、Role、Relation是通过系统架构图来展示的

Rule是通过系统序列图来展示的

二、架构设计的历史背景

• 机器语言时代（1940年之前）

  • 二进制语言（0101011110）
  • 特点：难写、难读、难改

• 汇编语言（20世纪40年代）

  • 又称汇编语言
  • 机器语言（100010101110111），汇编语言（mov,ax,bx)
  • 面向机器，需要精确了解计算机底层的知识
  • 不同CPU的汇编指令和结构是不同的

• 高级语言（20世纪50年代）
  分类：

  • Fortran：1955 年，名称取自”FORmula TRANslator”，即公式翻译器，由约翰·巴科斯（John Backus）等人发明。
  • LISP：1958 年，名称取自”LISt Processor”，即枚举处理器，由约翰·麦卡锡（John McCarthy）等人发明。
  • Cobol：1959 年，名称取自”Common Business Oriented Language”，即通用商业导向语言，由葛丽丝·霍普（Grace Hopper）发明。

高级语言可以被编译为适合不同 CPU 指令的机器语言。程序员只要写一次程序，就可以在多个不同的机器上编译运行，无须根据不同的机器指令重写整个程序。

• 第一次软件危机与结构化程序设计（20 世纪 60 年代~20 世纪 70 年代）

  • 软件危机：20 世纪 60 年代中期开始爆发了第一次软件危机，典型表现有软件质量低下、项目无法如期完成、项目严重超支等，因为软件而导致的重大事故时有发生
  • 结构化程序设计 ：结构化程序设计的主要特点是抛弃 goto 语句，采取“自顶向下、逐步细化、模块化”的指导思想。结构化程序设计本质上还是一种面向过程的设计思想，但通过“自顶向下、逐步细化、模块化”的方法，将软件的复杂度控制在一定范围内，从而从整体上降低了软件开发的复杂度。结构化程序方法成为了 20 世纪 70 年代软件开发的潮流

• 第二次软件危机与面向对象（20 世纪 80 年代）

  • 结构化程序设计虽然能够解决（也许用“缓解”更合适）软件逻辑的复杂性，但是对于业务变化带来的软件扩展却无能为力，软件领域迫切希望找到新的银弹来解决软件危机，在这种背景下，面向对象的思想开始流行起来
  • 面向对象真正开始流行是在 20 世纪 80 年代，主要得益于 C++ 的功劳，后来的 Java、C# 把面向对象推向了新的高峰。到现在为止，面向对象已经成为了主流的开发思想。

软件架构的整体历史背景：

• 随着软件系统规模的增加，计算相关的算法和数据结构不再构成主要的设计问题；当系统由许多部分组成时，整个系统的组织，也就是所说的“软件架构”，导致了一系列新的设计问题。
• 相关问题
  • 系统规模庞大，内部耦合严重，开发效率低
  • 系统耦合严重，牵一发动全身，后续修改和扩展困难
  • 系统逻辑复杂，容易出问题，出问题后很难排查和修复

我们可以发现，整个架构的演化路线都是为了解决当时某一些无法的解决问题。 高级语言的出现，是为了解决机器语言和汇编语言难读难写难维护、平台拓展性的问题。结构化设计和面向对象则是为了解决代码复杂度过高的问题。

三、为什么要做架构设计

常见的误区是：

• 架构很重要，所以要做架构设计
• 不是每个系统都要做架构设计吗
• 公司流程要求系统开发过程中必须有架构设计
• 为了高性能、高可用、可拓展，所以要做架构设计

做架构设计的真正原因是：解决软件系统复杂度带来的问题

并不是所有的系统都是需要做架构设计的，如果是特别简单的系统，完全不需要进行设计。就如哲学大师黑格尔说的存在则合理，任何事物的存在必然是有意义的。如果特别简单的系统非要为了设计而设计，很容易造成“过度设计”，或者简单问题被复杂化。

正常来说，架构设计可以是个模块功能的、子系统的、或者是一个大系统的，其重点是描述系统中存在哪些角色，彼此的关系是什么，达到让人可以在你的系统设计中了解基本的全貌的效果，有助于指导开发进行代码的实现。