我在京东做研发丨【混合多云第一课】为何多云多活被称为“技术皇冠上的明珠”?

京东,研发,混合,多云,第一课,为何,称为,技术,皇冠,明珠 · 浏览次数 : 2

小编点评

**数据爆炸性增长对业务连续性的挑战** 数据爆炸性增长对业务连续性带来了巨大的挑战,传统灾备方式资源利用率低、切换时间长、成本高。 **云计算的多云多活技术**正在逐步兴起巨大的业务价值、超高的技术难度让“多云多活”成为“技术皇冠上的明珠”。 **京东云资深混合多云多活专家分享** 京东云资深产品经理杨牧将带来京东内部秒级容灾切换实战分享,并跨云迁移产品的整体规划和设计。 **杨牧的专业领域** * IBM亚太区二线支持团队负责人 * 多行业跨云多活实战  * 京东云混合云多云多活专家

正文

数据的爆炸性增长

对业务连续性带来了巨大的挑战

传统灾备方式资源利用率底、切换时间长、成本高

对此,基于云计算的多云多活技术正在逐步兴起

巨大的业务价值、超高的技术难度

让“多云多活”被称为“技术皇冠上的明珠”

本期,京东云资深混合多云多活专家将带来

京东内部秒级容灾切换实战分享

以及多行业跨云多活实战

 

嘉宾介绍

杨牧

京东云资深产品经理

目前负责京东云混合云多云多活,跨云迁移产品的整体规划和设计。杨牧此前曾是 IBM 亚太区二线支持团队负责人,多年来一直深耕银行、电信、保险、政府等行业,服务了众多KA客户,具有丰富的理论和实践经验。

 

与我在京东做研发丨【混合多云第一课】为何多云多活被称为“技术皇冠上的明珠”?相似的内容:

我在京东做研发丨【混合多云第一课】为何多云多活被称为“技术皇冠上的明珠”?

数据的爆炸性增长 对业务连续性带来了巨大的挑战 传统灾备方式资源利用率底、切换时间长、成本高 对此,基于云计算的多云多活技术正在逐步兴起 巨大的业务价值、超高的技术难度 让“多云多活”被称为“技术皇冠上的明珠” 本期,京东云资深混合多云多活专家将带来 京东内部秒级容灾切换实战分享 以及多行业跨云多活

我在京东做研发 | 京东云算法科学家解析爆火的ChatGPT

令人惊艳的ChatGPT横空出世 背后有怎样的前沿技术支撑 走向大规模产品应用又有何局限 深耕对话式AI技术十余年 京东云算法科学家将带您一同走进技术世界 解析ChatGPT的技术亮点与局限 分享下一代对话式AI技术趋势 从好玩到好用 探讨对话式AI的落地实践

我在京东做研发 | 揭秘支撑京东万人规模技术人员协作的行云DevOps平台

随着业务变化的速度越来越快各类IT系统的建设也越来越复杂大规模研发团队的管理问题日益突出如何提升研发效能成为时下各类技术团队面临的重要挑战 京东云DevOps专家将带您深入研发一线揭秘支撑京东集团万人级研发管理的行云DevOps平台 分享企业应该如何规划DevOps落地与演进 嘉宾介绍 孙长虹 京东

我在京东做研发第五期:京东云自研服务器,如何将开发成本降低 60% 的同时还更低碳环保?

随着互联网的不断发展,各类技术工程对cpu算力的需求持续飙高,这不仅带来了技术上的压力,对电力能耗的需求也越来越大。为在有限的电力内达到最佳的效果,京东云自研服务器围绕三大主轴,提升性能效率、降低整体成本,让地球环境可以永续经营。

【我在京东做研发】揭秘支撑京东万人规模技术人员协作的行云DevOps平台

分享人:孙长虹 京东云DevOps解决方案架构师 复旦大学计算机系毕业,并拥有人民大学心理学硕士学位。曾任职于Alcatel-Lucent,IBM和惠普,具有丰富的大型复杂产品研发及项目管理经验,擅长组织级敏捷和DevOps转型,并拥有EXIN Agile Coach, 业务敏捷,DevOps Ma

研发提测前测试到底能做些什么

作为测试,经常会遇到倒排期的项目,当研发已经占用了很多资源的情况下,此时测试要想提高效率。就不得不在研发提测前多做准备,那么研发提测前测试到底能做些什么,我将根据我的经验,在本次文章中与大家一起分享。

一种面向后端的微服务低代码平台架构设计

结合京东业务研发实际情况,针对后端研发人员,设计一个微服务低代码平台,助力更高效低交付业务需求。现已结业,将我在本次项目中沉淀设计出的设计文档整理成文,期待与大家有进一步的碰撞沟通

当“代码农”遇上“码农”:揭秘主干开发的那些事儿

前段时期我负责部门内部主干开发落地相关事宜,这个过程中,也真真切切的体会到了多人开发过程中,面对特性分支管理中,大家遇到的一些困扰,尤其面对敏捷迭代的开发方式,合并冲突,集成测试,代码重用等方面,都与高效两个字背离。当然,我在推进主干开发过程中,也遇到了一些问题和坎坷,在这里,集中的做一次分享。

分而治之 -- 浅谈分库分表及实践之路

今天想聊一下分库分表,因为对于快速增长的业务来说,这个是无法回避的一环。之前我在做商城相关的SAAS系统,商品池是一个存储瓶颈,商品池数量会基于租户增长和运营变得指数级增长,短短几个月就能涨到几千万的数据,而运营半年后就可能过亿。而对于订单这种数据,也会跟着业务的成长,也会变得愈发巨大。

分库表数据倾斜的处理让我联想到了AKF模型

1 背景 最近在做需求的时候需要在一张表中增加一个字段。 这张表情况如下: 1、拆分了多个库多张表 2、库表拆分按表中商户编码字段hash之后取模进行拆分 由于库表拆分按照商户编码,有些大商家的单子数量远远要高于其他普通商家,这样就造成了严重的数据倾斜。 在增加字段的时候尝试多种办法,执行多次都添加