【供应链架构day4】途牛进销存架构的演进之路 - 从诞生到发展

写在前面

正交软件架构是一种很常见的架构模式，往往由分层架构演化而来。俗话说“不识庐山真面目，只缘身在此山中”。虽然我们整天吐槽着正交架构的各种问题，却没有能够对其有一个完整的认识。本文将结合业界实践，从架构演化的视角剖析这一架构模式，探索正交架构的前世今生，全面介绍这一架构的结构和优势，分析实践中的缺陷并探讨解决方案。

关于架构的基本认识

软件系统架构（简称架构）关注软件系统的结构和全生命周期内的演化。软件系统的结构是指构成软件系统的基本元素和元素间的相互关系；演化过程包括软件系统为何创建、为何下线、如何适应外界环境的变化、以及约束软件行为和表现的一系列原则。任何一个软件系统都有其架构，不存在没有架构的软件系统，只有不能把架构说明白的架构师。

架构图是架构师为了向系统特定的利益相关者展示系统架构设计而绘制的系统某一方面的结构关系图。常见的架构图有：管道架构模式中常用的数据流图、面向对象架构模式中常用的类图、企业应用开发中常用的实体关系图、描述系统如何部署的部署图等等。架构图不等同于架构。在实践中，受限于时间和资源约束，我们不能也没必要将系统架构的方方面面都完整而全面地描述清楚；我们更多地是在描述利益者关注的部分和对系统架构决策有重大影响的部分。我们无法也没必要通过一张架构图呈现出系统全部的架构细节。因为，我们没有无穷无尽的时间去描述特定系统的架构细节；将多个架构图合并会造成信息过载，架构图的阅读者难以理解、吸收和消化。

复杂系统往往是多种架构模式组合使用，我们在系统的某一视角上选用一种架构模式时，并不意味着对其他架构模式的弃用。例如：目前主导系统间交互的架构模式主要有面向服务的架构、微服务、Service Mesh，当我们选择他们的时候并不意味着我们单个系统不能选用面向对象的架构模式；当我们选用面向对象的架构模式时，也不意味着系统的网络部署不能选择层次架构模式。我们在讨论某一种架构模式时，往往是指系统的某一方面采用了这种架构模式。

企业信息系统是为支持企业运作而开发的具有数据输入、传输、处理和输出等基本功能的计算机系统。企业信息系统往往由多个部分组成，我们可以按照管理对象的不同将这些子系统分为三类：管理计算机资源的系统、管理数据的系统、对其他系统进行集成的系统；其中管理数据的系统又可以细分为管理事务的系统和分析数据的系统。“管理计算机资源的系统”就是我们俗称的能力系统，典型的能力系统包括系统软件如数据库软件、中间件软件如ESB。“管理事务的系统”就是我们俗称的对象系统，系统中的主要、关键、核心数据就是我们俗称的“对象”。“ 对其他系统进行集成的系统”就是我们俗称的应用系统，他们并不直接管理、存储业务数据，而是通过调用其他系统的服务进行整合集成。也可以从软件的核心价值进行分类：以“数据”为核心价值的就是对象系统，如管理供应链中交互信息的订单、产品、库存系统；以“系统集成”为核心价值的就是应用系统，如各种大前端应用系统；以“软件”为核心价值的就是能力系统，如数据库软件系统、中间件软件系统。如图1所示，企业信息系统在一种视角下呈现出层次架构模式。现实中的系统既有专门负责单一职责的独立系统，如云平台管理系统；也有同时承担多种职责的系统，如订单系统即管理订单数据和处理订单的事务，也会对其他系统进行集成。这几种类型的系统中，管理计算机资源的系统”是最稳定的，受业务变动影响最小；“ 对其他系统进行集成的系统”是变化最频繁的，受业务变动影响最大；“管理事务的系统”中，数据逻辑是比较稳定的也就是数据架构部分稳定性较高，事务逻辑的变化则比较频繁也就是应用架构部分的变化比较频繁。

图1

“管理事务的系统”往往伴随企业业务变化而演化，本文将围绕“管理事务的系统”应用架构演化过程进行讨论。