单体式与分布式的应用架构
产品架构在业务架构的基础上，按照解决的业务问题域，划分出不同的功能模块，再根据功能模块间的关系，组合成子系统。应用架构在产品架构的基础上考虑两个事情：第一、考虑的是子系统间的关系。第二、考虑将可复用的组件或模块进行下沉，沉淀到平台层，为业务组件提供统一的支撑。应用架构是要说明产品架构分哪些应用系统，应用系统间是如何集成的，这就是应用架构和应用集成架构。应用架构分为两种：一种是单体式应用架构、一种是分布式应用架构。
单体式应用架构就是系统只有一个应用，数据存储在一个 DB 等存储介质里面。
分布式应用架构是指存在多个系统，系统之间通过接口的形式进行调用，不同系统的数据存储在多个 DB 里面。
1.划分应用在做应用架构之前，我们已经完成了业务架构和产品架构这 2 步。在产品架构这个架构域，我们通过按照模块之间的聚合和分层，逐步形成产品内部子系统的边界。那么，按照子系统的边界进行切分，能得到整个产品的子系统组成。
还是以风控系统的产品为例，在产品架构这一环节，我们输出了下面的产品架构图。
https://static001.infoq.cn/resource/image/bd/fd/bdadc9f1763e69618ee63187f52081fd.png
图 1
应用架构的分解，通过对产品架构按照水平和垂直两个维度进行划分。
水平划分在产品架构的环节，按照同一产品范围的模块放在同一层级的原则，得到水平层面的应用系统划分。只要产品架构明确定义了系统间的边界，很容易确定整个产品的各个子系统。
https://static001.infoq.cn/resource/image/3c/56/3c8336832cf6720c786c1c3f589df256.png
图 2
垂直划分当应用内存在几个相对独立的模块，每个模块的业务逻辑差别比较大，且内部的组成较为复杂和庞大时，还需要进一步对应用内进行子系统的切分。这里的切分原则是，对应用内按业务进行切分，保证子应用是相互独立。
比如风控系统的案例中，在风控引擎这个应用中，存在实时、离线的校验场景。每种场景都是相对独立。这时候将这三个模块按照子系统进行切分成：实时风控引擎子系统、离线风控引擎子系统。
https://static001.infoq.cn/resource/image/80/ca/80243f35ce861a9b11f01175e7ea27ca.png
图 3
2.单体式应用单体式应用架构是比较传统的分为 4 层：数据层（Data Layer）、应用逻辑层（Business Layer）、表现层（Presentation Layer）和基础通用层（Common Layer）。
https://static001.infoq.cn/resource/image/91/4e/9117c01774b7cd04aa63304a943f584e.png
图 4
展现层展现层是整个应用面向用户的入口，用户通过展现层实现与系统的交互。展现层为用户提供系统功能的操作、系统数据的展现。展现层按照面向的用户类型提供不同的交互服务。
例如在业务场景中，用户有实操层用户、管理层用户、决策层用户。针对不同层级的用户，系统所提供的功能是不相同。
面向实操层用户，提供的是对系统的操作功能，满足业务日常运营。往往更多的是执行具体操作。
面向管理层用户，满足管理者的日常管理需求，通常提供经营数据、日常管理数据、团队业务数据等等。通过数据分析，改善日常运营的流程。
面向决策层用户，这一层的用户不需要太细的数据，为其提供企业的经营诊断数据和报告，辅助决策支持。
业务层业务层是应用为解决业务需求，按照产品架构中的功能模块进行细化。业务层是对将产品层从粗到细的分解过程。这个过程是对业务的细化过程，把项目要交付的模块细分到最基本的单元。最基本单元是实现日常业务操作的最细粒度的功能点。由此，我们能够得到实现业务逻辑的全功能结构。
数据层数据层按照应用的数据模型分别进行存储。这里的存储介质包含关系型数据库、NoSQL、分布式文件系统。
通用基础层通用基础层是为系统提供通用能力的中间件，比如流程引擎、消息中间件、缓存、搜索引擎等等。这些中间件和业务是无相关性的，提供的是通用的基础技术能力。
按照上述的方式，我们得到风控系统中的子系统：处置中心系统的单体应用架构。如下图：
https://static001.infoq.cn/resource/image/a3/b7/a398bbca35d015c706124310066554b7.png
图 5
3.分布式应用分布式应用架构图实质是产品内部所有应用在分布式环境下的调用关系图。各应用间通过服务的形式相互调用，这是典型的 SOA 架构。在应用架构图中，SOA 架构中的服务注册、服务治理、服务发现这些 RPC 框架的基础平台功能不用在应用架构中体现。
应用架构图的重点是体现应用之间的逻辑关系和通信关系，体现产品的内部关系和外部关系。内部关系是产品内各应用的调用关系；外部关系展现的是产品与外部系统间的调用关系。将应用的内外关系呈现在应用架构中，产品在整个业务中的定位和影响将变得清晰。
应用间调用关系在产品内部的各子系统之间，为了解决业务需求，通过应用之间的服务调用或者异步消息调用产生数据关系。通过产品架构图中得到的应用系统划分，按照系统间的调用关系，形成内部应用的集成架构图。在应用集成架构图中，需要标注调用链路中的业务含义，清楚的标注应用之间发生的业务关系。
https://static001.infoq.cn/resource/image/52/78/5259a852e5de5aca4d270358ed414478.png
图 6
外部系统调用关系数据输入做为产品的业务数据来源，很大部分是外部系统提供。在应用架构图中，按照业务属性、来源关系进行对外部系统进行归类，并将外部的来源系统纳入整个应用架构中。我们知道计算机系统中，数据输入和数据输出是作为一个整体。应用架构中除了输入系统，输出系统做为整个产品的一部分，需要纳入到应用架构图中。
https://static001.infoq.cn/resource/image/e4/d9/e4b153a05216c5f2b1fb5ecfcf3306d9.png
图 7
明确应用调用边界应用边界对于产品的定位、产品的设计有很重要的影响。在应用架构中需要通过不同颜色的标注，来确定产品与外部系统的边界。通过不同颜色标注外部来源系统、内部应用、应用依赖系统、输出系统。为后续的规划、发展提供基础。
https://static001.infoq.cn/resource/image/85/ff/852ef77a802c70c98f53246705cedcff.png
图 8
最终一种好的应用架构图，应该具备以下特点：
[*]清晰的应用边界。
[*]应用之间的调用关系明确。
[*]有入必有出，有输入系统、必有输出系统。
[*]清晰的呈现应用的全局关系。
作者简介
胡斌，菜鸟网络技术专家，目前负责菜鸟风控系统的建设。曾在淘宝技术部先后负责卖家平台、商家运营等领域。在大规模分布式应用、大数据、架构领域有多年的开发和管理经验。
页:
[1]