微服务时代，为什么要以“应用”为核心？

todo

一、应用的起源

微服务架构一般都是从单体架构或分层架构演化过来的。软件架构微服务化的过程，就是一个根据业务模型不断进行细化的过程，在这个过程中切分出一个个具备不同职责的业务逻辑模块（即微服务模块），然后每个微服务模块都会提供相应业务逻辑的服务化接口。

简单来说，微服务化的核心就是一个字：拆。从一个单体工程，拆分出N个独立的模块。这些模块都可以独立部署和运行，并提供对应的业务能力。拆分后的模块数量与业务体量和复杂度相关，少则几个、十几个，多则几十、几百个，所以为了统一概念，我们通常称这些模块为应用。

为了确保每个应用的唯一性，我们会给每个应用定义一个唯一的标识符，比如app1、app2等，而这个唯一的标识符，就是我们常说的应用名。

二、应用的模型

需要知道的是，我们在上面定义出来的一个个应用，都是从业务角度入手进行细化拆分出来的一个个业务逻辑单元。这些应用虽然可以独立部署和运行，但是每个应用都只具备相对单一的业务功能。如果要完成整体的业务流程和目标，就需要和周边其它的微服务化应用交互。此外，它们还会依赖各种与业务无直接关系、相对独立的基础设施和组件，比如机器资源、域名、缓存、消息队列、DB等。

所以，在一个实际的运维场景中，除了应用这个实体之外，还会存在其他各类基础组件实体。应用在运行过程中，会不断地与它们产生和建立各种各样复杂的关联关系。而正是因为有了这种复杂的关联关系，才提高了我们的运维复杂度。也正因为如此，理清运维场景中的关联关系就变得尤为重要。

接下来，我们先来看一看可以从哪些角度来梳理这种关联关系。

2.1、应用的业务模型

应用的业务模型，就是每个应用对外提供的业务服务能力，通常会以API的方式暴露给外部。

该模型一般由业务架构师在进行业务需求分析和拆解时进行设计，更多的聚焦在业务逻辑上。

2.2、应用的管理模型

应用的管理模型，就是应用自身的各种属性，比如应用名、应用功能信息、责任人、Git地址、部署结构（代码路径、日志路径以及各类配置文件路径等）、启停方式、健康检测方式等等。其中，应用名是应用的唯一标识，我们一般用AppName来表示。

2.3、应用的依赖模型

应用的依赖模型，就是应用运行时所需要的基础设施和基础组。其中：

基础设施：主要是指应用运行所必需的资源载体，比如物理机、虚拟机或容器等。而如果应用会对外提供HTTP服务，就需要虚IP和DNS域名；
基础组件：主要是指我们常说的中间件体系，比如数据库、缓存、消息队列、文件存储等。

在这里我们需要知道的是，这些基础设施和基础组件都是为了业务应用而存在的。正是因为业务应用的需要，才开启了它们各自的生命周期。如果脱离了这些业务应用，它们就失去了存在的意义。

三、应用关系建模

在理解了应用的模型后，我们再去梳理应用的关联关系就会顺畅很多，这个梳理过程可以分为两步走：

第一步，建立各个基础设施和基础组件的数据模型，同时识别出它们的唯一标识符。这一步与应用的管理模型梳理过程类似。以缓存为例，每当我们申请一个缓存空间时，通常会以NameSpace来表示唯一标识符，同时这个缓存空间会有容量大小和Partition分区等属性信息。
第二步，识别出基础设施和基础组件可以与应用名AppName建立关联关系的属性，或者在基础组件的数据模型中增加所属应用这样的字段。还是以缓存为例，当应用申请缓存空间时，可以直接将NameSpace字段的值设置为AppName，也可以在增加一个所属应用这样的字段，通过外键关联模式建立起应用于缓存空间的关联关系。