• 自动秒收录
  • 软件:1973
  • 资讯:56863|
  • 收录网站:209068|

IT精英团

微博资源网格服务的探索与实践

微博资源网格服务的探索与实践

浏览次数:
评论次数:
编辑: 乐咏
信息来源: ITPUB
更新日期: 2022-06-21 21:17:31
摘要

本文由极客时间整理自微博研发中心基础架构部资深系统架构开发工程师臣勇在QCon+案例研习社的演讲《微博KV服务探索与实践》。作者|臣勇编辑|支小亚你好,我是来自新浪微博的臣勇,我目前负责KV

  • 正文开始
  • 相关阅读
  • 推荐作品

本文由极客时间整理自微博研发中心基础架构部资深系统架构开发工程师臣勇在 QCon+ 案例研习社的演讲 《微博 KV 服务探索与实践》 。

作者|陈勇编辑|智大家好,我是新浪微博的陈勇。我目前负责KV缓存和存储的相关工作。今天和大家分享的是微博中KV服务的探索与实践。

先介绍一下目前Redis和Memcached在微博中的应用,我们遇到的问题以及如何解决。接下来介绍几个落地案例,最后做个总结。重点是我们的解决方案。

1.背景1.1 Redis/Memcached在微博的应用情况

Redis/Memcached在微博中的应用现状

Redis和Memcached在互联网中被广泛使用。从2010年开始,微博引入了Redis和Memcached,并在社区版的基础上做了大量的定制化开发,广泛应用于Feed流量、用户关系、转发、评论、赞和计数等方面。目前Redis和Memcached的实例数是10000,数据量是PB,日调用量是10万亿。大部分业务的性能要求是P99要在10ms以内,所以管理复杂度高。

1.2典型服务状态

典型使用姿势

商务的典型使用姿势是什么?首先业务RD会做出选择,是用Redis还是Memcached还是其他一些KV存储,根据自己的业务情况做容量预估和性能预估,然后和DBA一起做相应的配置规划,比如分多少个端口。

获取资源

然后将配置交给业务端,业务RD将配置文件配置到自己的业务SDK,SDK实现对后端资源的连接。在这种情况下,有时会出现问题。其中一个典型的场景是,随着业务的增长,原来单个切片的容量可能不够用了。比如读容量不够,写容量达到上限,或者单个切片的数据太大,达不到单个实例的上限,给后期运维带来很大的麻烦。一般会考虑业务拓展,但是怎么拓展、拓展多少是个问题,谁参与、怎么参与也是个问题。

1.3所面临问题的扩展通常根据具体情况而定。例如,如果写容量有瓶颈,则相应的端口可以被分割。拆分的时候,怎么拆分?拆分方式有两种:线下和线上。对于线上的场景,线下的方式很少,所以一般都是线上拆分。如何在线拆分?业务会根据拆分前后的资源进行双写,或者在情况复杂时使用专门的拆分工具。

作为R & ampd人员的基本服务,我们应该考虑是否可以减轻企业研发的负担。RD只想使用KV缓存或服务,但拆分时要考虑资源的拆分和分配,并做相应的资源评估,这会给他引入额外的负担。也可能给DBA增加负担,因为他要时刻关注资源的性能。

2.我们怎么做呢?2.1从组件转向服务能否减轻业务研发和DBA的负担?为什么会有这些问题?其实根源是业务RD和DBA看到的是组件,组件是通过一组域名或者端口来访问资源的,所以需要关注这些资源使用前后的细节。比如容量,如果初始容量评估准确,未来资源的浮动可能相对稳定。如果初始容量不准确或者容量快速增加,则需要更改后续容量。然后是碎片数量。如果单个片段中的数据量相对较大,可能需要稍后重新分段。读写能力也是一样,需要人工跟踪,在业务上线后根据情况随时调整。

那么,你能从资源的后端屏蔽这些资源细节,让服务R

D 和 DBA 不用去关注这些细节?对外不提供组件,而是提供服务,让服务自己内部去消化资源上的管理细节。

系统架构示意图

这是我们现在做的一个架构的示意图,资源服务是由两个部分组成,一部分是资源访问,一部分是资源管理。资源管理由逻辑上的 Manager 实现,资源访问由资源 Mesh 实现。资源管理和资源访问交互的界面是 Config server, 也就是配置中心。

2.2 资源 Mesh

资源 Mesh 的定位是资源访问,在 Service Mesh 架构里面属于 Sidecar 模式。资源 Mesh 的核心功能有四点。第一是服务发现,这是基础功能。第二是流量协议请求和响应路由。第三是连接管理和优化。连接管理优化很重要,因为后端资源能承载的连接数有限,如果连接数设置较少,前端应用可能会有性能上的问题。如果设置的过多,后端资源可能会对连接数产生竞争,例如扩容前端应用时没有连接数可用往往会导致扩容失败。第四是特定协议的个性化需求。我们针对 MC 的 Memacached 协议做了一些定制化的开发,实现了跨机房的数据同步。

资源 Mesh 屏蔽资源使用细节

另外一个需要考虑的重点是性能,主要体现在耗时方面,资源 Mesh 引入的耗时不能太多。资源 Mesh 怎么去屏蔽资源的使用细节?以前的模式是业务 RD 根据配置文件访问资源,SDK 通过这种配置文件直接访问后端的资源连接,通过 Mesh 业务只看到一个 namespace,通过 namespace 和资源 Mesh 建立连接,由资源 Mesh 具体实现和后端的资源连接。这样在整个业务的生命周期里 namespace 不变,所以业务方访问的资源是不变的。

2.3 端口扩容

端口扩容的常规做法

这时后端资源的这种变化就由资源 Mesh 来屏蔽了,比如说端口扩容。端口扩容的常规做法是先进行后端资源扩容,接着业务方更新相应的 confs 文件,然后使用新的 confs 文件上线,这时需要业务 RD 和 DBA 共同参与。


资源 Mesh 配合

如果资源 Mesh 来实现这个扩容要怎么做?应用这边通过 namespace 去访问资源 Mesh,因为整个生命周期里面 namespace 不变,所以端口扩容期间业务 RD 也是无感知的,Mesh 这边监听后端资源的变化,当资源发生变更之后就会连接新的一套资源列表。这样就实现了业务和 DBA 都无感知的场景。

2.4 资源管理服务

资源管理服务还有一些其他功能,比如内置的扩缩容服务。刚才介绍的是资源 Mesh 的服务,现在介绍一下资源管理相关的服务,其中之一是内置的平滑扩缩容服务。

传统的垂直扩容

传统的垂直扩缩容是这样的,业务方准备一些代码变更,要兼容扩容前后数据分片情况,接着 DBA 进行拆分前后资源数据准备,再做数据的拆分。我们之前的模式采用的是在线拆分,就是针对线上的一个资源数据做一个伪装的从实例,然后从伪装的从上面把数据给拆到新的资源列表上面去。数据拆分完成后业务方校验,如果拆分前后的数据校验没问题,就会做流量切换。

内置扩容服务

内置的扩缩容服务相对来说更简单一些,只需要先把资源和拆分后的数据准备好,资源管理服务可以通过 API 启动,通过资源 API 调用资源管理服务的接口就可以实现数据拆分。以前的扩容模式持续时间需要数周,现在通过这种内置扩容服务仅需几天就可以完成。

资源管理服务还有一些其他的功能,比如常见的一些自动故障处理。一个场景是实例宕机。资源管理服务实际上内部也是拆分成多个小的模块,它在每一个宿主机上或者说在 Kubernetes 里面每一个 Pod 上会部署一个执行的角色,它实现资源状况的信息汇报,二进制程序的安装以及实例的启动,会有一个资源管理的角色执行资源服务。比如实例宕机场景,Executor 监测到实例宕机就会把它汇报给资源管理,资源管理这边识别之后会自动寻找有空闲的主机资源 ,去部署一个新的实例,挂到线上的服务里面去。

实例 SLA 异常与之类似,Excutor 采取的策略是定时地 Ping 相应的资源,如果实例异常了,比如 Hang 长时间不响应就会对它进行处理,把它从服务池里面摘掉,扩建一个新区域去提供相应的服务。

3. 落地案例

接下来讲一下我们的案例。其实落地的时候就会有一些策略,首先会涉及到的一个问题是选择谁去落地?是选择核心业务,还是边缘业务去落地?如果选核心业务,优势在于推广时很容易推广,劣势在于如果出现问题再想推广就会很麻烦。如果选边缘业务,优势是如果它出现问题不会影响到大局,可以很容易地把它恢复过来。

我们的策略是选核心业务,因为后续推广时比较好推广。既然选定了对象就涉及到怎么去落地,涉及到一些准备,要提前做一些预案。事先要充分验证服务功能,比如从现场拷贝一些流量做上线前的准备验证。还要做预案,出现问题之后怎么回滚?要有回滚的策略,要有怎么去发现问题的策略。

上线涉及到替换,替换原有的服务是全量替换还是少量替换?功能方面是全部的功能替换还是部分功能替换?在开发时我们就定了一些策略,可以只替换一部分功能,可以逐步打开资源 Mesh 相应的功能,所以我们选取的策略是先替换部分功能,做少量实例的替换,也就是说业务在落地的时候是逐步放量的,这样有利于控制风险。上线之后会涉及到监控指标和预警,从业务层面和资源 Mesh 服务层面都要做相应的监控,要有相应的预警指标和应对方案。

3.1 Memcached

Memcached 资源数据拓扑示意图

这是 Memcached 资源数据拓扑示意图,上面有两个机房,中间竖线两侧是两个机房,一个 IDC 永丰, 一个 IDC 土城。微博针对 Memcached 做了一个缓存预热和跨地域同步方案,由 Mesh 来实现这里的逻辑。其逻辑是这样的,竖轴方向也就是 Y 轴方向将数据分成四片,横轴方向是横向分层,看到有 L1 层、Master 层、Slave 层。层间的数据有一个同步策略,也由资源 Mesh 实现。

这种跨机房数据同步是怎么实现的?IDC 永丰机房的 Master 在逻辑上是 IDC 土城机房的 Slave。这样在有数据需要回种时,数据访问的顺序是先访问 L1,如果 L1Miss 会访问 Master,如果 Master 有,会回写到 L1 和其他层。如果 Master 也 Miss 了可能要通过 DB 回种。这种场景就是通过 Master 对于各层间数据的回写来实现跨机房数据同步。

为什么需要这种方式呢?比如单片数据上的访问量是 100 万 QPS,假设有 1% 的访问 Miss,折算下来就是 1 万 QPS。如果后端 DB 用的 MySQL,1 万的访问量很可能会把 MySQL 打死。在微博场景下,尤其是有热点时,访问量可能会飙升至千万 QPS,如果 Cache Miss 的量比较大,会导致后端的资源访问回穿 DB,把 DB 打穿,那么整个服务可能会崩掉。

所以我们采取固定分片的方式,通过多层 Cache 实现数据的缓存同步以及缓存预热。当出现急速热点时,我们会扩几层 L1,通过多层 L1 分担读的压力,这就是数据分片。

还有一种策略是一致性 Hash。比如有一片数据宕掉,它的访问会打到它临近的 Hash 节点上去,在量特别大的场景下会使得单个节点的数据量也变得很大,那么一方面单片资源数据量容易出现内存溢出之类的问题,另一方面读量可能也无法承担。所以微博采取固定分片的方式做数据拆分,通过多级 Cache 一致性实现数据的缓存和预热以及跨机房的数据同步。整个逻辑是在 Mesh 这边实现的,这是 Memcached 的落地情况,目前应用在信息流分发的一些场景里。

3.2 Redis

资源数据拓扑示意图竖轴方向

这是 Redis 的落地情况,Redis 也采取固定分片的方式落地,Mesh 主要实现读写连接管理策略。单片数据的同步通过 Redis 自己的主从实现同步机制,因为 Memcached 是没有主从概念的,所以 Mesh 自己实现主从同步机制。

4. 总结

基础服务的出发点和落脚点都是易用可靠,让业务 RD 和 DBA 用起来简单。此外,我们在实现这个系统时针对系统服务侧的资源访问和资源管理都做了功能上的解耦,如果一个服务特别大,把这个服务的多个功能适当解耦有利于项目的推进和质量控制。

关于 Memcached 落地的场景,我的经验就是在大流量高并发的场景下资源的固定分片策略比一致性 Hash 策略更有优势。从落地的情况来看,对于存量项目的架构改造需要循序渐进,可以从小的功能点着手替代,再逐步推进项目。

复盘一下整个项目,如果从头再来有什么能做得更好的地方?比如业务分片规则,我们在推广时发现不同的业务使用不同的分片规则,那么资源 Mesh 就要做相应的适配。实际上业务上线时可能随意地选了一个分片规则,如果上线时统一分片规则或者定量地描述分片规则,就会给后续的架构改造和升级省很多事。

此外,在系统上线服务的运行当中我们发现在故障管理方面还有很多优化空间。管理的资源数量实例非常多,现在是基于规则的检测,人工根据经验或者常见问题制定相应的规则,基于这种规则去报警并做出应对措施。如此一来就会存在误报风险,给运维工作带来干扰。如何引入和细化 AIOps 也是一个不小的课题,这需要多方的力量共同推进。

日拱一卒

最后来分享一个我非常喜欢的词:“日拱一卒”。我为什么会喜欢这个词呢?在项目管理领域,如果有一个大项目,把大项目拆解成小项目或者小目标,能够阶段性地实现这些目标一方面能够鼓舞团队士气,另一方面也为达成大目标提供了路线图,这样会更容易达成整体目标。

另外在学习领域,我们常常会定一个比较大的学习目标,比如要学习一种新的语言,可以把这个大目标拆解成小目标,再逐步实现这些小的目标,累积起来之后就会实现整体的大目标。前段时间有个定律很流行,叫一万小时定律,在一个领域持续累积一万个小时,你很可能会成为这个领域的专家。我们对于制定自己的学习目标也是如此,通过小目标的累积去实现大目标通常会有非常可观的收获。

作者简介

臣勇微博研发中心基础架构部资深系统架构开发工程师目前就职于微博基础架构部,主要从事缓存、计数、发号、KV 存储、消息队列、数据备份与恢复等基础服务的研发工作。拥有丰富的高并发、高性能、高可用基础服务架构与开发经验。

标签:资源 业务 数据
大厂企业系列仓库建设规划(整理需要一周时间 建议收藏~)
« 上一篇 2022-06-21
  • 大厂企业系列仓库建设规划(整理需要一周时间 建议收藏~)
    0阅读 0条评论 个赞
    以下文章来源于公众号-大数据兵工厂,作者大数据兵工厂大家好,推荐一下老兵抽空整理了企业级数仓建设方案。整体内容包括:数仓架构数仓分层规划数据流向规划数据同步策略数仓命名规范通篇内容紧贴企业级建设主题,……
  • 用于自动监控磁盘使用的Linux —— Shell脚本
    0阅读 0条评论 个赞
    如果在服务器上运行关键任务,那么监控和通知管理员磁盘使用情况很重要。本文介绍编写一个脚本来自动监控并在达到阈值时将报告发送到自己的邮箱。在文章中,我们写一个shell脚本,它在crontab中……
  • 数据科学中10个重要概念和图表的意义
    0阅读 0条评论 个赞
    来源:DeepHubIMBA本文共1200字,建议阅读5分钟“当算法给你一条曲线时,一定要知道这个曲线的含义!”1、偏差-方差权衡这是一个总是在机器学习最重要理论中名列前茅的概念。机器学习中的几乎所……
  • 整顿00后职场?成立了“00后部门”
    0阅读 0条评论 个赞
    整理|于轩出品|程序人生(ID:coder_life)据教育部统计,2022届高校应届毕业生人数高达1076万。同时,今年也是00后的第一个毕业季。随着大批00后涌入职场,作为职场新人的他们会有……
  • 数据湖VS数据仓库之争?万紫详解数据仓库与湖湖数据仓库的集成
    0阅读 0条评论 个赞
    随着近几年数据湖概念的兴起,业界对于数据仓库和数据湖的对比甚至争论就一直不断。有人说数据湖是下一代大数据平台,各大云厂商也在纷纷的提出自己的数据湖解决方案,一些云数仓产品也增加了和数据湖联动的特性。但……
发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表
  • 彻底根除MySQL查询慢 这12个问题不能落下
    0阅读 0条评论 个赞
    前言日常开发中,我们经常会遇到数据库慢查询。那么导致数据慢查询都有哪些常见的原因呢?今天田螺哥就跟大家聊聊导致MySQL慢查询的12个常见原因,以及对应的解决方法。一、SQL没加索引1、反例sel……
  • Python中6个堪称不朽的内置函数
    1阅读 0条评论 个赞
    以下文章来源于公众号-快学Python,作者朱小五在很多计算机书籍中,它们也通常作为高阶函数来介绍。而我自己在日常工作中,经常使用它们来使代码更快,更易于理解。Lambda函数Lambda函数用于创……
  • Kafka负载平衡在体内的实现
    1阅读 0条评论 个赞
    vivo互联网服务器团队-YouShuo副本迁移是Kafka最高频的操作,对于一个拥有几十万个副本的集群,通过人工去完成副本迁移是一件很困难的事情。CruiseControl作为Kafka的运维……
  • 如何在Mac上愉快地使用Docker
    0阅读 0条评论 个赞
    一、目标任务首先要明确的是,作为了一个每天在LinuxServer上rm-rf的人来说,如果想在Mac上使用Docker,最舒服的也是兼容所有dockercli命令行操作……
  • 用Docke r构建自己的dns服务器
    0阅读 0条评论 个赞
    在开发运维过程中经常需要自定义一个域名来管理服务,通常的方法是修改hosts文件,但还有一种更便捷的方法,从源头上解决问题,也就是使用DNS来实现。1.搭建搭建依然使用docker,安装前请安装好do……
  • 如何在K8S的Pod中连续执行容器?不要错过这个方法
    1阅读 0条评论 个赞
    出于某些目的,有时需要在Kubernetes的一个Pod中,连续依次运行多个Container。这种有明确结束预期的运行,即Kubernetes的Job。但是,虽然一个Job可以在……
  • 写Python脚本 一定要加这个!
    1阅读 0条评论 个赞
    以下文章来源于公众号-Python技术,作者派森酱大家好,使用Python的人,平时经常会写一些脚本,不管是为了提升工作效率,还是为了满足一些特定的需求,Python脚本都是一个常见又有用的东西……
  • 如何通过缓存提高系统性能
    1阅读 0条评论 个赞
    缓存在系统中最消耗性能的地方就是对数据库的访问了,一般来说,增、删、改操作不会出现什么性能问题,除非索引太多,并且数据量有十分庞大的情况下,这三个操作才会导致性能问题。一般可以限制单表索引的数量来提升……
  • 程序员如何创造一门编程语言?
    0阅读 0条评论 个赞
    作者|MdShuvo译者|弯月出品|CSDN(ID:CSDNnews)虽然每位开发人员都掌握了一种甚至多种编程语言,但你是否曾想过自己动手创建一种编程语言?首先,我们来看看什么是编……
  • 记得保命!捕捉Linux下的所有高危命令!
    1阅读 0条评论 个赞
    1、rm-rf命令该命令可能导致不可恢复的系统崩坏。>rm-rf/#强制删除根目录下所有东西。>rm-rf*#强制删除当前目录的所有文件。>rm-rf.#强制删除当前……
  • 30个重要的Python字符串方法
    0阅读 0条评论 个赞
    以下文章来源于公众号-法纳斯特,作者小F字符串是Python中基本的数据类型,几乎在每个Python程序中都会使用到它。这次给大家介绍30个最重要的内置字符串方法,希望大家能从中找到对自己有帮助的技巧……
  • Kubernetes 4000节点运维经验分享
    1阅读 0条评论 个赞
    1摘要在PayPal,我们最近开始试水Kubernetes。我们大部分的工作负载都运行在ApacheMesos上,而作为迁移的一部分,我们需要从性能方面了解下运行Kubernetes集群……
  • 还记得发现redis使用不当导致的应用卡顿bug的过程吗?
    1阅读 0条评论 个赞
    首先说下问题现象:内网sandbox环境API持续1周出现应用卡死,所有api无响应现象。刚开始当测试抱怨环境响应慢的时候,我们重启一下应用,应用恢复正常,于是没做处理。但是后来问题出现频率越来越频……
  • 运维入坑必看:Kubernetes平台架构解读
    1阅读 0条评论 个赞
    Kubernetes是一个开源容器编排平台,管理大规模分布式容器化软件应用,是云计算发展演进的一次彻底革命性的突破。Kubernetes是谷歌的第三代容器管理系统,是Borg独特的控制器和Omega灵……
  • 无监控 无运维!普罗米修斯在线服务监控实用指南
    1阅读 0条评论 个赞
    本文可以看做是对《SRE》一书第10章《基于时间序列数据进行有效报警》的实践总结。Prometheus是一款开源的业务监控软件,可以看作是Google内部监控系统Borgmon的一个(非官方)实现……
  • 【网关对比】Java亿流量架构的网关设计思路
    0阅读 0条评论 个赞
    本文准备围绕七个点来讲网关,分别是网关的基本概念、网关设计思路、网关设计重点、流量网关、业务网关、常见网关对比,对基础概念熟悉的朋友可以根据目录查看自己感兴趣的部分。Part1什么是网关网关,很多地方……
  • 从单点Redis到1主2从3哨兵的建筑进化之路
    1阅读 0条评论 个赞
    这是悟空的第150篇原创文章官网:www.passjava.cn你好,我是悟空呀~本文目录如下:一、前言二、部署拓扑图三、搭建Redis一主两从1.1备份和还原Redis镜像1.2主节点配……
  • 微服务和消息队列的建筑师图册
    0阅读 0条评论 个赞
    概述“架构师图谱”是一个很宏大的命题,特别是优秀的架构师自身也是“由点到面再到图”,一点点成长积累起来,尝试写这篇文章的目的更多的是结合自身的一些架构、研发、管理经验对现阶段做一个复盘总结,所以这里更……
  • 是时候告别Linux 5.17内核系列了
    0阅读 0条评论 个赞
    是时候告别Linux5.17内核系列了,因为它现在在kernel.org网站上被标记为EOL(End-of-Life),这意味着它将不再接收维护更新。LinuxKernel5.17于……
  • 好的架构不是设计出来的 是进化出来的~
    0阅读 0条评论 个赞
    大家好,我是飘渺。各位肯定都听过这样一句话:"好的架构不是设计出来的,而是演进出来的,没有完美的架构,只有不断演变、不断完善的架构。"今天我们来看一下1号店App服务端架构改造的例子,来具……
最近发布资讯
更多