软件架构分解 多维度软件架构分解步骤

什么是软件架构

如果期望有一个权威统一的标准定义，那答案是没有，目前存在多种软件架构的定义，可以说百花齐放，百家争鸣。其中 IEEE1471-2000 的定义是这样的：系统的架构是系统组件的基本组织形式，它们之间的关系以及和环境之间的关系，以及指导其设计和演化的原则。该定义中的系统组件可以理解为架构元素，根据涉及到的系统范围和层次，架构元素可以是子系统、模块、类等等。从架构设计的动态角度出发，我们可以这样来定义软件架构：通过一系列架构决策，将系统分解为一些架构元素，并定义这些元素之间的接口和交互关系、集成机制。架构决策就是在架构设计过程中做出的一系列全局的决定和权衡取舍，例如将系统拆分成几个子系统、子系统的职责是什么、子系统之间的接口是什么、采用什么通讯方式和集成机制、采用的开发语言和技术框架等。

架构形而上的本质

除了软件架构，众所周知，在建筑行业中也存在架构，而且建筑架构比软件架构历史要悠久得多；在公司中存在组织架构。这就引发了我们的思考，对这些不同的架构，它们的本质是什么？

从抽象的形而上的角度来看，架构是架构作用力的平衡，如图 1。

图 1 中左侧一个最初混沌的系统在架构作用力的相互作用下达到足够程度的平衡。右侧的椭圆蕴含的意思是架构应该是有弹性的，里面的多个小圆表示在力的作用下分解产生的架构元素。

图 1.形而上的架构

什么是架构作用力

对一个建筑工程项目，会涉及到多方涉众，如建设单位、勘察单位、设计单位、施工单位、工程监理单位、使用单位等等，他们对工程项目存在各种需求；同样在一个软件系统中也会有多种涉众，例如系统用户、投资人、需求分析师、架构师、开发人员、测试人员、客服人员、运维人员等等。这些涉众在架构层面有各自的架构需求，例如系统用户除了要求满足他们的功能需求外，还有对系统的易用性、性能、可用性等非功能性存在要求；开发设计人员希望系统架构清晰，便于理解，关注代码重用性、扩展性、可维护性。架构师更关注于系统可伸缩性、可用性、性能等非功能需求。这些需求必须在架构层面加以考虑，使这些涉众的需求在架构层面得到足够的满足。

从抽象的层次来看，涉众在架构层面的上述各种需求就是架构作用力，它们直接影响和驱动架构设计。大师 Grady Booch 在他的<<The architecture of Web applications>>一文中就已经关注软件中的作用力（Forces in software）。在架构中除了存在这些外力外，在架构中也存在内力，就是架构元素之间的相互作用力，这里不展开讨论。

一个架构要满足所有的需求通常是不可能的，因为不同的涉众，他们之间的需求可能是相互冲突的，也就是作用力的方向是相反的。作用力的大小主要体现在需求的优先级上。

架构设计过程中，架构师运用自己的经验，结合当前的技术，从全局考虑需求和约束，进行折中和取舍，平衡这些涉众的作用力。

在 IEEE1471-2000 规范中，将涉众在架构层面的各种需求称为关注点，从这个概念来说架构分解就是关注点分离。

架构分解

当我们看到一个复杂系统的架构视图时，可能会思考这些视图中的架构元素是怎么来的。如何从混沌的铁板一块的整体架构演变成一个可伸缩高性能的分布式系统？

分而治之是一种处理复杂问题的通用方法，在软件架构中，它也是一种很重要的手段，例如多层架构、OSI 七层模型都体现了分而治之思想。在架构设计过程中，通过将关注点分离对架构进行多层次分解，将系统层层分解为多个架构元素，进而识别架构元素。

可以说架构中的很多元素都是在架构分解的过程中识别产生的。

架构分解的作用

万事开头难，架构分解是架构设计过程中非常关键的一步。除了识别架构元素，对大规模的软件系统，分解还是解决非功能需求的重要手段。eBay 为了解决可伸缩性、可用性、可管理性等问题，在架构的多个层面进行了分解：

• 在应用层面，按照功能或 SOA 服务进行分解，将系统垂直拆分为多个应用池（应用池中的服务是无状态的）。每个应用池中有多个应用（水平拆分），可以独立灵活地进行伸缩。见图 2 所示。
• 在数据层面，对数据进行垂直拆分（分库）和水平拆分（数据分片 DB Sharding）；将分布式事务拆分成多个本地事务独自提交，避免分布式事务。见图 3 所示。

图 2.应用的垂直和水平拆分

<