限时领|《AI 百问百答》专栏课+实体书(包邮)! 了解详情
写点什么

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

  • 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:061543

评论 1 条评论

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

国内外开源数据可视化工具对比:DataEase 与 MetaBase 对比

搞大屏的小北

DataEase Metabase 开源数据可视化

MySQL进阶:Innodb的RR到底有没有解决幻读?

程序员小毕

MySQL 数据库 程序员 后端 java面试

论文复现丨基于ModelArts实现Text2SQL

华为云开发者联盟

人工智能 华为云 12 月 PK 榜

选择大数据培训学习技术之前有哪些准备

小谷哥

破解加密的LastPass数据库

神锁离线版

数据安全 密码 密码管理器 Lastpass 密码安全

分布式系统关键路径延迟分析实践

百度Geek说

12 月 PK 榜 延时分析 关键路径 大型分布式系统延时优化

中美顶级AI首次对话 送给人类的忠告引发关注

硬科技星球

java培训学习后找不到工作的原因有哪些

小谷哥

线上GC故障:CMSGC太频繁,你知道这是什么鬼?

Java永远的神

程序员 性能优化 JVM java面试 GC

MySQL 慢查询日志分析(Filebeat+Elasticsearch+DataEase)

搞大屏的小北

MySQL慢查询 MySQL日志分析 MySQL日志可视化

YonBuilder开发之后端函数

YonBuilder低代码开发平台

后端 数据 开发 扩展 软件研发

华为应用市场公布2022年度榜单 原子化服务、车载应用首次上榜

最新动态

【大屏设计】数据大屏间距那点事-距离产生美

搞大屏的小北

大屏布局 报表布局 看板布局排版

跨越速运运单分析系统入选2022中国数据智能最佳实践案例

StarRocks

数据分析 物流

大数据培训机构怎么选择

小谷哥

隐私集合求交(PSI)协议研究综述

京东科技开发者

安全 密码学 安全多方计算 隐私集合求交 不经意传输

玩转OpenHarmony智能家居:如何实现树莓派“碰一碰”设备控制

OpenHarmony开发者

OpenHarmony

火山引擎工具技术分享:用AI完成数据挖掘,零门槛完成SQL撰写

字节跳动数据平台

大数据 BI BI 分析工具 12 月 PK 榜

美团餐饮SaaS基于StarRocks构建商家数据中台的探索

StarRocks

数据分析 零售

海量请求下的接口并发解决方案

Java全栈架构师

Java 数据库 面试 后端 架构师

葡萄酒越贵越好?贾斯特里尼&布鲁克斯刷新你的认知

联营汇聚

自学数据分析——数据分析方法和模型

搞大屏的小北

数据分析方法 自学数据分析

端到端流程打通企业经脉

元年技术洞察

数字化转型 流程 趋势研究 PaaS平台 方舟平台

InfoQ 写作社区 2022 年度优质企业号评选正式开启!

InfoQ写作社区官方

热门活动

【年度评选】让我们为即将过去的 2022 划上圆满的句号

InfoQ写作社区官方

热门活动

微信开放小程序运行SDK,自己的app也能运行小程序

Onegun

微信小程序 小程序容器

自学数据分析——重新认识数据分析

搞大屏的小北

数据分析 数据分析可视化

AI技术实践 | 人脸核身在未成年人保护领域的实践应用

牵着蜗牛去散步

人工智能 腾讯云 腾讯 人脸识别 未成年保护

实践GoF的23种设计模式:命令模式

华为云开发者联盟

Go 开发 华为云 12 月 PK 榜

自学web前端开发能找到好工作吗?

小谷哥

web前端培训班怎么学习?

小谷哥

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