应用的起源
软件架构服务化就是根据业务模型进行细化的过程，在这个过程当中切分出一个个具有不一样职责的业务逻辑模块，而后每一个微服务模块都会提供相对应业务逻辑的服务化接口。数据库
简单来讲就是把一个单体工程，拆分出 N 个独立模块。缓存
拆分后的模块，咱们称为应用，而且为每个应用定义一个惟一标识符，如上图中的APP-一、APP-2,也就叫应用。架构
应用模型及关系模型的创建
上面定义出来的应用须要和周边的其余应用交互，完成总体的业务流程，还须要依赖各类与业务无关的组件，好比机器、缓存、消息队列等等。运维
下来就是具体的梳理过程，梳理清楚，才能为咱们后面一系列的运维自动化、持续交付以及稳定性保障打下一个良好的基础。微服务
1. 应用业务模型spa
应用业务模型，也就是每一个应用对外提供的业务服务能力，并以 API 的方式暴露给外部，以下图商品的应用业务模型示例：设计
业务模型一般都是业务架构师在进行业务需求分析和拆解时进行设计，更多的是聚焦在业务逻辑上，因此从运维的角度，咱们通常不会关注太多。日志
接下来是运维关注的重点中间件
2. 应用管理模型blog
应用管理模型，也就是应用自身的各类属性，如应用名、应用功能信息、责任人、Git 地址、部署结构（代码路径、日志路径以及各种配置文件路径等）、启停方式、健康检测方式等等。这其中，应用名是应用的惟一标识，咱们用 AppName 来表示。
这里咱们能够把应用想象成一我的，一般一我的会具有身份证号码、姓名、性别、家庭住址、联系方式等等属性，这里身份证号码，就是一我的的惟一标识。
3. 应用运行时所依赖的基础设施和组件
- 资源层面：物理机、虚拟机或容器，对我提供http服务，公网IP 和 DNS 域名服务；
- 基础组件：这一部分其实就是咱们所说的中间件体系，好比应用运行过程当中必然要存储和访问数据，这就须要有数据库和数据库中间件；想要更快地访问数据，同时减轻 DB 的访问压力，就须要缓存；应用之间若是须要数据交互或同步，就须要消息队列；若是进行文件存储和访问，就须要存储系统等等。
这些基础设施和组件都是为上层的一个个业务应用所服务的，因此才开启它们各自的生命周期。反之它们就没有存在的必要。
具体操做
第一步，创建各个基础设施和组件的数据模型（资源和组件的关系）以典型的缓存为例，每申请一个缓冲空间，一般会以 NameSpace 来标识惟一命名，同时这个缓存空间会有空间容量和 Partition 分区等信息。
第二部，也是最关键的一步，就是识别出基础设施及组件能够与应用名 AppName 创建关联关系的属性，或者在基础组件的数据模型中增长所属应用这样的字段。
以上面的缓存为例，既然是应用申请的缓存空间，而且是一对一的关联关系，既能够直接将 NameSpace 字段取值设置为 AppName，也能够再增长一个所属应用这样的字段，经过外键关联模式创建起应用与缓存空间的关联关系。
相应地，对于消息队列、DB、存储空间等，均可以参考上面这个思路去作。
通过梳理，能够创建以应用为核心的应用模型和关联关系模型，应用将成为整个运维信息管理及流转的纽带。
真实的状况是怎么样的？
大部分公司在这块的统筹规划是不够的，或者说是不成熟的。也就是软件架构上引入了微服务，可是后续的一系列运维措施和管理手段没跟上，主要仍是思路没有转变过来。虽说要作 DevOps，但实际的执行仍是把开发和运维分裂了去对待。
- 场景一
是关于线上的缓存和消息队列的。
开发使用的时候就去申请一下，一开始还能记住本身使用了哪些，可是时间一长，或者申请得多了，就记不住了。长此以往，线上就存在一堆无用的 NameSpace 和 Topic，可是集群的维护者又不敢随意清理，由于早就搞不清楚是谁用的，甚至申请人已经离职，之后会不会再用也已经没人讲得清楚了，越日后就越难维护。
根本缘由，就是前面咱们讲到的，太片面地对待基础组件，没有与应用的访问创建起关联关系，没有任何的生命周期管理措施。
- 场景二
场景就体现了应用名不统一的问题。
按说应用名应该在架构拆分出一个个独立应用的时候就明确下来，并贯穿整个应用生命周期才对。
大多数状况下，咱们的业务架构师或开发在早期只考虑应用开发，不注重应用名的统一
运维这里，也只从软件维护的角度，为了便于资源和应用配置的管理，会独立定义一套应用名体系出来，方便本身的管理。
会出现不统一。
微服务架构模式下的运维思路必定要转变，必定要将视角转换到应用这个维度，从一开始就要统一规划，从一开始就要将架构、开发和运维的工做拉通了去看，这一点是与传统运维的思路彻底不一样的。
固然，这里面也有一个经验的问题。虽然微服务在国内被大量应用，可是咱们绝大多数技术团队的经验还集中在开发设计层面。微服务架构下的运维经验，确实还须要一个总结积累的过程。我本身也是痛苦地经历了上面这些反模式，才总结积累下这些经验教训。
总结
微服务架构下，运维管理体系必需要以应用为核心。
以应用为核心，把相关的基础实施及组件都关系梳理和创建起来，才能为后面一系列的运维自动化、持续交付以及稳定性保障打下一个良好的基础。
技术团队不只仅关注开发设计，还要关注微服务运维。