如何打造一个以应用为核心的运维体系

在前面《有了CMDB，为什么还要应用配置管理》一文中，描述了CMDB和应用配置管理的关系，这里面提到了非常核心的一个概念：应用，。但是，上篇中更多的是从运维的角度看待这两个概念，不过从根源本质上，这个应该是分布式架构中的核心概念才对，只不过是我们在运维过程中整天要面对它，管理它，所以貌似感觉好像这个概念只跟运维相关一样，其实不然，本文详细描述下。

关于服务化

在讲发布系统《XXOps实践：持续发布和部署》的时候提及过，随着业务体量和业务复杂度的上升，单体工程因为紧耦合的原因，会慢慢地无法满足快速迭代的要求，特别是开发人员增加到一定规模的时候，代码的开发和维护变得非常头疼，这个时候必然要对单体工程进行拆分，也就是我们常说的服务化拆分的过程。

以Java为例，我们根据业务模型拆分出不同职责的模块或工程（可独立运行的一套代码），叫做一个应用，在应用里我们会设计很多类出来，其中对外提供业务功能逻辑的类，我们通常定义为服务，也就是我们常见到的xxxxService，这个Service里面我们又可以提供很多的具体调用方法出来，我们叫做API或者Method。大致的逻辑可以用下图表示：

比如电商里面的商品Item，最典型的就会有SKU、Detail、Snapshot、Tag等等的服务，以SKU为例，我们定义为SKUService，做过服务设计和开发的同学肯定都很清楚，接下来我们就要为SKUService提供各种get、list、query、update等方法，有时候为了提供统一的查询或写服务，可能还会专门设计出SKUReadSevice提供统一的各种的query方法。

以应用为核心的运维体系建设

这里面Item就是一个应用的定义，所以我们可以从这里看到，从源头上讲，应用这个标示是在引入服务化，进行架构拆分的时候就应该定义下来的。

但从我个人实际观察到的情况看，大部分的公司在这块的统筹设计上是不够的，我经常看到的场景是，RPC的服务注册或配置中心上，有自己的一套应用名标示，开发要独立去填写；做发布系统的时候，又单独搞出一套应用标示，开发又要填一遍；同理，做监控的时候，监控自己也整一套，到了运维这里，为了维护资源的分配，为了应用跟资源的对应关系，搞不好也会有一套。有时候为了保持各个系统能够很好的协作，又得搞出一个映射关系来，比如运维的应用标示跟监控的应用标示做个对应，或者跟服务化的应用标示做个对应，但是这样做就很难形成统一的体系。所以，我看到的很多平台就都会变成一个个的孤岛，无法成为体系。

所以，在这块的建设上，必须在服务化阶段就得明确应用标示的统一，后续的资源分配、发布、监控、稳定性体系等等，都以此标示为准。这块我们CMDB的文章中已经提到了基于应用为核心，如何去建立CMDB和应用配置的模型，下面直接上图，说明从运维的角度如何去建立应用服务和稳定性体系的模型。

对于服务化的应用：

1、首先是应用，这个要根据产品业务场景去设计。然后拆分出对应的服务，也就是Service这一层，服务里面再设计出对外暴露的方法。这个过程，主要是业务技术架构师和开发Owner要去做。但是应用的标准，要么架构师一开始就能够全局确认下来，否则，运维就必须参与进去跟开发一起明确指定下来。

所以这里的路径就是，应用—服务Service—方法Method

2、基于应用，有了CMDB、应用配置，以及服务的管理，就可以去完成类似于持续集成和发布、自动化扩缩容这些动作了，具体可以结合《XXOps实践：持续发布和部署》

3、有了应用服务管理，接下来可以做的另外一件事情，就是稳定性体系的建设，比如全链路跟踪、容量评估、开关、限流、降级等等。这块后面专门整几篇文章出来。这里特别要说明的一点，所有上面提到的这些技术手段，准确的讲，都应该要加几个定语，就是基于应用的xxxx，或者基于服务的xxx。比如，降级策略，就以Cache故障，自动降级到DB为例，最终这降级策略是要通过配置的方式，下发到应用或服务层面来执行的，具体可以看下上述图示。

最后，有了这样一套基于应用的模型之后，就可以通过应用把这些管理环节给集成起来，放在统一的门户里提供出来，至此，应用为核心的运维体系雏形就有了。简单的示例：

关于微服务和服务化，多说两句： 前两天跟公司一个开发Leader还在探讨是否有必要拆分微服务的问题，这里也分享一下，服务化和微服务的的争议主要是个粒度问题，我们在设计时到底是把应用拆分成粗粒度的一组服务形成一个应用，比如上面提到的Item商品，形成一个单独应用，还是将更细粒度的Service独立成一个个的应用，比如上面提到的Item里面的SKUService这个服务，还是再微服务化一点，甚至可以SKU这个服务里面的读写服务，SKUReadSevrvice和SKUWriteService分别独立出来分别独立出来作为一个应用。 这个说实话没有什么严格标准，横着切也好，竖着切也罢，粒度大也好，粒度小也好，关键还是看这个应用和服务的Owner怎么来把握，或者团队有统一的架构师来定义标准。

不过，个人观点，对于微服务还是持一点保守态度，不要做过细粒度的拆分，也并不是越细越好，这里面有个度的问题。粒度过细就会有大量的应用独立出来，应用之间又会有相互调用，应用的管理和调用链管理就变的异常的复杂，最终意味着管理成本就会非常高。这个时候是需要有非常完善的运维体系来保障的，比如持续集成和发布、全链路保障、容量和性能评估手段等等，而这些保障体系说实话有一定的技术门槛，也需要一定的技术和人才积累，需要有一个迭代的周期来完善，这必然是一个逐步演进的过程，所以这些配套手段跟不上的情况下，过度的微服务化是没有意义的。