架构设计实践五部曲（四）：单体式与分布式的应用架构.docxVIP

架构设计实践五部曲（四）：单体式与分布式的应用架构 在做应用架构之前，我们已经完成了业务架构和产品架构这 2 步。在产品架构这个架构域，我们通过依据模块之间的聚合和分层，逐渐构成产品内部子系统的边界。那么，依据子系统的边界进行切分，能得到整个产品的子系统组成。 还是以风控系统的产品为例，在产品架构这一环节，我们输出了下面的产品架构图。 图 1 应用架构的分解，通过对产品架构依据水平和垂直两个维度进行划分。 水平划分 在产品架构的环节，依据同一产品范围的模块放在同一层级的准绳，得到水平层面的应用系统划分。只需产品架构明确定义了系统间的边界，很简约确定整个产品的各个子系统。 图 2 垂直划分 当应用内存在几个相对独立的模块，每个模块的业务规律差别比较大，且内部的组成较为简单和浩大时，还需要进一步对应用内进行子系统的切分。这里的切分准绳是，对应用内按业务进行切分，保证子应用是相互独立。 比如风控系统的案例中，在风控引擎这个应用中，存在实时、离线的校验场景。每种场景都是相对独立。这时候将这三个模块依据子系统进行切分成：实时风控引擎子系统、离线风控引擎子系统。 图 3 2. 单体式应用 单体式应用架构是比较传统的分为 4 层：数据层（Data Layer）、应用规律层（Business Layer）、表现层（Presentation Layer）和基础通用层（Common Layer）。 图 4 呈现层 呈现层是整个应用面对用户的入口，用户通过呈现层实现与系统的交互。呈现层为用户供应系统功能的操作、系统数据的呈现。呈现层依据面对的用户类型供应不同的交互服务。 例如在业务场景中，用户有实操层用户、管理层用户、决策层用户。针对不同层级的用户，系统所供应的功能是不相同。 面对实操层用户，供应的是对系统的操作功能，满足业务日常运营。往往更多的是执行具体操作。 面对管理层用户，满足管理者的日常管理需求，通常供应运营数据、日常管理数据、团队业务数据等等。通过数据分析，改善日常运营的流程。 面对决策层用户，这一层的用户不需要太细的数据，为其供应企业的运营诊断数据和报告，协助决策支持。 业务层 业务层是应用为处理业务需求，依据产品架构中的功能模块进行细化。业务层是对将产品层从粗到细的分解过程。这个过程是对业务的细化过程，把项目要交付的模块细分到最基本的单元。最基本单元是实现日常业务操作的最细粒度的功能点。由此，我们能够得到实现业务规律的全功能结构。 数据层 数据层依据应用的数据模型分别进行存储。这里的存储介质包含关系型数据库、NoSQL、分布式文件系统。 通用基础层 通用基础层是为系统供应通用力量的两头件，比如流程引擎、消息两头件、缓存、搜索引擎等等。这些两头件和业务是无相关性的，供应的是通用的基础技术力量。 依据上述的方式，我们得到风控系统中的子系统：处置中心系统的单体应用架构。如下图： 图 5 3. 分布式应用 分布式应用架构图实质是产品内部全部应用在分布式环境下的调用关系图。各应用间通过服务的方式相互调用，这是典型的 SOA 架构。在应用架构图中，SOA 架构中的服务注册、服务管理、服务发觉这些 RPC 框架的基础平台功能不用在应用架构中体现。 应用架构图的重点是体现应用之间的规律关系和通信关系，体现产品的内部关系和外部关系。内部关系是产品内各应用的调用关系；外部关系呈现的是产品与外部系统间的调用关系。将应用的内外关系呈现在应用架构中，产品在整个业务中的定位和影响将变得清楚。 应用间调用关系 在产品内部的各子系统之间，为了处理业务需求，通过应用之间的服务调用或者异步消息调用产生数据关系。通过产品架构图中得到的应用系统划分，依据系统间的调用关系，构成内部应用的集成架构图。在应用集成架构图中，需要标注调用链路中的业务含义，清楚的标注应用之间发生的业务关系。 图 6 外部系统调用关系 数据输入做为产品的业务数据来源，很大部分是外部系统供应。在应用架构图中，依据业务属性、来源关系进行对外部系统进行归类，并将外部的来源系统纳入整个应用架构中。我们晓得计算机系统中，数据输入和数据输出是作为一个全体。应用架构中除了输入系统，输出系统做为整个产品的一部分，需要纳入到应用架构图中。 图 7 明确应用调用边界 应用边界对于产品的定位、产品的设计有很重要的影响。在应用架构中需要通过不同颜色的标注，来确定产品与外部系统的边界。通过不同颜色标注外部来源系统、内部应用、应用依靠系统、输出系统。为后续的规划、进展供应基础。 图 8 最终一种好的应用架构图，应当具备以下特点： 清楚的应用边界。 应用之间的调用关系明确。 有入必有出，有输入系统、必有输出系统。 清楚的呈现应用的全局关系。 相关阅读： 架构设计实践五部曲（一）：架构与架构图 架构设计实践五部曲（二）：业