写点什么

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

  • 2020-03-18
  • 本文字数:2103 字

    阅读完需:约 7 分钟

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

关于服务化

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



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


本文转载自成哥的世界公众号。


原文链接:https://mp.weixin.qq.com/s/b3enQL25LPtxja5oY2iqgg


2020-03-18 20:061522

评论 1 条评论

发布
暂无评论
发现更多内容

UCSXD-好的用户体验课程是怎样的?

科技热闻

故障定位系列:波动度故障

乘云数字DataBuff

智能运维 运维监控 故障复盘 故障排除

超实用!Dify快速接入本地MCP服务

王磊

零基础也能转型!MES系统助力中小企业数字化转型

万界星空科技

数字化转型 数字化 制造业 mes 万界星空科技mes

Spring AI 结合DeepSeek使用教程

知识浅谈

通义灵码 AI IDE 正式上线,智能体自动写代码,首创自动记忆,工程感知全面升级

阿里巴巴云原生

AI 通义灵码

恒普达:科技赋能公共安全,智领数字时代新未来

极客天地

《Nginx核心技术》第1章:安装Nginx

冰河

nginx 程序员 高可用 系统架构 架构师

客户为纲,万目皆张——中烟创新致烟草客户的一封信

中烟创新

七牛云存储基于时间戳防盗链的算法JAVA实现

Chris Zhang

Java 七牛云存储 安全 防盗链

艺术品NFT的开发框架

北京木奇移动技术有限公司

区块链技术 软件外包公司 音乐NFT

Studio 3T 2025.10 发布,社区版重磅回归

sysin

mongodb

低代码时代,让“双手”再解放一点

秃头小帅oi

存得快查得准,但就是算不动?试试时序数据库 TDengine × Spark 的组合拳

TDengine

数据库 tdengine 物联网 时序数据库

AI 不再是 PPT:它在帮企业做发电预测、运维预警和用电规划

TDengine

数据库 tdengine 物联网 时序数据库

Vinexpo Asia 2025于新加坡举行,在变局中为东盟酒饮贸易指明方向

极客天地

2025年5月文章一览

codists

Python

更强劲,更高效:智源研究院开源轻量级超长视频理解模型Video-XL-2

智源研究院

库存搞不好,利润掉一截!别让库存吃掉你的利润!

积木链小链

数字化转型 智能制造 库存管理

2025年测试人必看:AI+Playwright让自动化测试效率飙升200%?

测试人

人工智能 软件测试

HarmonyOS Next 弹窗系列教程(1)

万少

鸿蒙 HarmonyOS

艺术品NFT系统的运营

北京木奇移动技术有限公司

区块链技术 软件外包公司 音乐NFT

VMmark 4.0.3 - 虚拟化平台基准测试

sysin

VMmark

Next的Seo实践

溪抱鱼

next

今年行情回暖了

王中阳Go

Go 就业

烟草行业专卖人员画像与队伍考评系统(信创版)上线运行

中烟创新

基于 Amazon Q Developer CLI 和 Amazon Bedrock Knowledge Bases 实现智能问答系统

亚马逊云科技 (Amazon Web Services)

艺术品NFT系统的开发流程

北京木奇移动技术有限公司

软件外包公司 区块链NFT 艺术品NFT

鸿蒙仓颉语言开发实战教程:购物车页面

幽蓝计划

鸿蒙仓颉

LlamaFactory × 多模态RAG × Chat-BI,万字长文揭秘RAG进化迷踪,打造专业AI助手!

商汤万象开发者

AI 大模型 LLM

NITF 2025 聚焦核电数智化,时序数据库 TDengine 分享亿级数据处理方案

TDengine

tdengine 时序数据库 数据库·

如何打造一个以应用为核心的运维体系_语言 & 开发_成哥的世界_InfoQ精选文章