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

在前面《有了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怎么来把握,或者团队有统一的架构师来定义标准。

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

原文发布于微信公众号 - Forrest随想录(forrest_thinking)

原文发表时间:2017-07-24

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏互联网数据官iCDO

【转载】搜索引擎来路关键词的挖掘:百度统计的高级分析报告导出获取来源关键词

简单的说就是买百度统计的高级分析,然后用关键词维度组合其他访问属性导出报告。 n年没有接触SEO了,最近发现现在的搜索引擎优化已经和以前完全不一样了。 自从各大...

3625
来自专栏SDNLAB

适合初学者的软件定义数据中心(SDDC)架构

软件定义数据中心是一种数据管理方式,它通过虚拟化来抽象计算、存储和网络资源,并将其作为服务提供。为了促进这一过程,SDDC包括智能软件以集中管理虚拟化资源,并自...

3858
来自专栏BestSDK

智能化API为企业提供高效服务同时,也将节省大量人力物力

企业一直在寻找新的方法来提高效率,降低成本的同时保持其产品和服务的质量。云计算的重要组成部分API被IT部门和服务供应商越来越看好(应用程序编程接口),其使工作...

2905
来自专栏WeTest质量开放平台团队的专栏

腾讯手游如何提早揭露游戏外挂风险?

随着大量外挂、辅助、工作室等非法盈利团队借由移动游戏产业迅猛发展的东风趁虚而入,对游戏开发商和玩家来说都造成了不小的伤害,安全问题成为手游发展不容忽视的前提。本...

1061
来自专栏哲学驱动设计

微服务(Microservices)——Martin Flower【翻译】

原文是 Martin Flower 于 2014 年 3 月 25 日写的《Microservices》。 本文内容 微服务 微服务风格的特性 组...

2298
来自专栏云计算D1net

将数据迁移到云端的最佳实践

就当前而言,移动PB级的数据对企业来说仍然是一件难事,可以按照以下步骤来操作,尽量减少风险和成本,并最大程度地提高灵活性。 接受云部署的企业需要具有成本效益和...

3489
来自专栏腾讯大讲堂的专栏

王者荣耀、NBA突发支撑

2927
来自专栏DevOps时代的专栏

手把手教您构建自己的 DevOps 流水线

持续交付是一组能够帮助软件开发团队极大的提高其软件交付的速度和质量的模式和最佳实践组成。

2161
来自专栏互联网数据官iCDO

【转载】搜索引擎来路关键词的挖掘:百度统计的高级分析报告导出获取来源关键词

简单的说就是买百度统计的高级分析,然后用关键词维度组合其他访问属性导出报告。 n年没有接触SEO了,最近发现现在的搜索引擎优化已经和以前完全不一样了。 自从各大...

2994
来自专栏大数据

适合初学者的软件定义数据中心架构

软件定义数据中心是一种数据管理方式,它通过虚拟化来抽象计算、存储和网络资源,并将其作为服务提供。为了促进这一过程,SDDC包括智能软件以集中管理虚拟化资源,并自...

2327

扫码关注云+社区

领取腾讯云代金券