公有云服务本质上是用户和传统 IT 基础设施的连接器, 通过将传统 IT 繁重的流程、低效的工作方式、不透明的价格以及糟糕的用户体验打碎, 重构出诸如云主机、云对象存储 /CDN、云数据库等产品, 让用户方便地获取计算和存储能力,同时保持使用习惯不变。
经过近十年的发展, 一个越来越明显的趋势是, 公有云服务,正逐渐从基于传统 IT 基础设施的包装和组合式创新, 演进为围绕公有云场景的, 计算和存储能力的重新进化和升级。 诸如容器云和 Serverless 架构、AWS Aurora 云数据库,UCloud 安全屋等, 便是这一趋势的典型代表。
由此,我们可以对公有云的发展进程,做一个两阶段的概括。云计算 1.0 的关键词是连接, 通过互联网和公有云,来连接用户和计算存储能力;而云计算 2.0 的关键词是进化,围绕公有云场景,重新看待全社会使用计算和存储资源的问题,对现有 IT 基础设施、模式做进一步的升级和进化。
站在云计算 1.0 向 2.0 进化和升级的档口,UCloud 云数据库团队, 将用一系列文章,来梳理过去、剖析当下、想象未来, 以期全面展现 UCloud 云数据库服务( UCloud DataBase Service,简称 UDB )的能力,分享我们过去的经验,以及对未来的思考。
考察一个云计算服务的发展,犹如观察一颗种子落地后的生长。传统 IT 设施向云端变迁的趋势,是云服务生长所需的阳光和雨露,但一颗种子能否长成参天大树, 除了足够的阳光雨露, 还要考察这颗种子的基因和成色。
在 UCloud 的公司四大价值观里,客户为先,是放在首位的价值观。 这体现了 UCloud 人一以贯之的理念: 只有为客户创造出真正的价值,企业才能够生存和发展。创造真正用户价值,是 UCloud 所有产品的基因,也是 UDB 产品和云数据库团队的基因。
对于 UDB 产品而言, 创造真正用户价值,体现在两个方面:
1.需求驱动的产品研发和运营。
需求驱动产品设计,技术评估实现可行性,必要时非标快速定制,定制逐渐沉淀为标准产品,整个过程循序渐进。小步快走,是互联网研发和运营的要领,也是公有云服务的要领。
以 UDB 跨地域跨可用区容灾为例, 从单机版 UDB 开始,不断有用户因跨可用区容灾场景提出建跨机房从库的需求,中大型互联网客户尤为强烈。起初,以一种非标形式来提供能力的支持。后期,因 VPC 2.0 上线,技术也愈加成熟,现已将这种非标能力转化为标准能力,即多可用区高可用 UDB 产品,同时也将 UDB 由可用区级提升为地域级,产品形态得到一次质的提升,传统模式下需要付出极高成本才能构建的异地容灾方案,通过 UDB 产品可以轻松获得, 用户价值进一步被创造。
2.一切以客户价值为归依,舍小我成就大我。
云计算产品是 IT 基础设施类产品,技术人员在云服务的研发中起主导作用。但技术并不直接等同于用户价值。即使再先进的技术,离真正的用户价值,还是会有一段距离。这段距离,则需要用做产品的匠心来来弥补。
所谓的产品匠心,非常重要的两点,是对需求的洞察和对技术的取舍。技术人员常见的一个毛病是先入为主,将自己觉得酷的牛的技术点,等同于用户价值。但事实往往证明不一定。真正的用户价值创造,要打破技术人员思维的藩篱,洞察到用户需求的本质,从需求角度出发做技术选型,必要时敢于放下自己的喜好甚至利益,成就真正的用户价值。
UDB 产品,在硬件架构上, 选择了物理机+Docker 的方案, 而不是业界普遍的云主机方案,则是这方面的经典案例。
云数据库是云主机之后出现的产品。如果基于云主机来构建云数据库产品,能够充分复用云主机成熟的能力,云数据库团队只需要关心硬件层面之上的问题。另外,选择云主机来构建,能够降低研发成本,快速推出云数据库产品。
但细究下来, 云主机的方案存在不少问题。最大的问题是 IO 性能。 云主机基于虚拟化技术,拥有完整的 OS 内核,这就导致 IO 协议栈太长,IO 有额外开销;而 Docker 利用 Linux 的机制做隔离,本身处于用户态,Docker 内进程的 IO 操作,由物理机 OS 内核统一管理,性能接近于原生物理机,远胜于云主机方案。在 IO 的稳定性上,云主机的 IO 管理涉及三个层次( Guest OS、Hypervisor、宿主机 OS ),而 Docker 的 IO 由物理机内核直接管理, 因此在 IO 稳定性上的表现,云主机亦不如物理机+Docker 的架构。
因此, 为了更好的 IO 性能和稳定性,UDB 从一开始就选择了物理机+Docker (前期是 CGroup,14 年全面转向 Docker )的架构。事实证明,这是一个明智的选择。 横向对比各大公有云厂商的云数据库产品,在性能上 UDB 每次都是完胜。
王国维在《人间词话》二六节写到:古今之成大事业、大学问者,必经过三种之境界。“昨夜西风凋碧树,独上高楼,望尽天涯路”,此第一境也。“衣带渐宽终不悔,为伊消得人憔悴”,此第二境也。“众里寻他千百度,回头蓦见,那人正在灯火阑珊处”,此第三境也。此等语皆非大词人不能道。然遽以此意解释诸词,恐晏、欧诸公所不许也。
如同任何伟大的事业,UDB 的成长之路,也经历三个阶段,细分为三重境界。这三个阶段互相独立,又存在一个内在的逻辑,将它们牢靠地连接在一起。 这个内在逻辑,就是 UDB 的基因:创造真正用户价值。UDB 在每一个阶段的萌芽,发展,跃迁,无一不是这个基因和理念,在发挥作用。
1.做透一个点:取代自建数据库
UDB 产品第一阶段要比拼的,是能否比用户自建数据库(基于云主机或者自建 IDC ),具备更大的用户价值。只有创造出更大价值,形成更高的价值势能,才能吸引用户将业务迁移到云数据库。所以,UDB 的第一个目标,就是把:取代自建数据库 这一个点给做透。
2.构建功能网:全方位覆盖用户需求
做透 取代自建数据库 这个点,本质上是公有来运营 DBMS 软件,创造出快速交付、运维托管等全新价值点。但仅仅有这一点,还不够。事实上,过去几十年来,围绕 DBMS,出现了从容灾、迁移、安全到读写分离、数据拆分等解决方案和软件,对应用户业务的各种需求。这些解决方案和软件同样需要云化,并且需要利用公有云的优势,产生比自建更大的价值。如此,才能不断强化云数据库的价值势能,服务好已有用户,并吸引更多用户向公有云转化。
因此,UDB 产品第二阶段要做的, 是构建一张云数据库功能网。在第一阶段的基础上,继续将用户需要的各个功能点做透,众多功能点,以及功能点的组合,最终构成一张大网, 全方位地覆盖用户的各种需求。
3.三位一体融合平台:云计算 2.0 下的内生进化
不管是第一阶段的做透一个点,还是第二阶段的构建功能网,对新价值的创造,都是基于成熟的软件或解决方案,利用公有云来实现功能的随手可得、快速部署和弹性扩展。这种模式清晰明确,但并不意味着云数据库价值创造的终点。
云计算 2.0 时代,公有云开始摆脱传统 IT 基础设施和软件的藩篱,在产品和技术上,围绕自身业务场景开启独立进化。其中,如何解决全社会大规模用云时的成本、效率和智能问题,是这场进化的核心。而 UCloud 云数据库团队,也需要进一步去思考,是否能提供更加廉价优质、高效智能的云数据库产品。
带着问题和思考,UCloud 云数据库团队内部做了多次探讨。最终达成这样一个认知:云计算 2.0 下的云数据库服务,必然会是对内架构同一化,对外需求支持多样化,以及数据库运维智能化这样三位一体的组合。
在接下来的内容中,将就做透一个点、构建功能网、架构统一的多样化数据处理体系展开详细介绍,用具体的例子,来勾勒 UDB 发展的三个层次,三层境界。
取代自建数据库,说起来好像很简单。但是如果列出取代自建数据库需要考虑的五个价值点:
a、可靠性 b、稳定性 c、高性能 d、零维护 e、性价比
并逐个剖析, 你会发现, 要将这些点做好,并非易事。UDB 产品,经过几年的努力,完美地实现了 做透一个点:取代自建数据库 这一目标。
a、可靠性
云数据库的可靠性强调数据安全性,包括两方面,一是 DB 数据,二是备份数据。DB 数据落盘的持久性通常要求 99.9999 %及以上,表明数据保持存储状态不丢失的概率。此类数据主要是指用户存储在数据库中的数据,不包括缓存和临时存储。DB 数据本地盘采用 RAID10 或者 RAID50 做好冗余,若是高可用机型,则再有实例级冗余。备份数据要求异地存储,多副本存储。
b、稳定性
这里强调的是单机稳定性。我们可以看下如何自建一套数据库,在数据中心的电力、物理网络、机架、物理服务器等基础设施之上,部署操作系统和补丁,安装数据库软件和补丁,运行数据库软件,启用数据库服务。如果是采用虚拟化部署,则额外涉及计算、网络、存储虚拟化。这是一套庞大的系统,各个环节都存在不可预知的故障风险。UDB 经过多年的运营,积累了诸多经验,在多方面多层次,保障其足够稳定。
c、高性能
如何通过软硬件结合, 使单机数据库的性能发挥到极致? 高性能 UDB 机型底层采用 PCI-E/NVMe SSD 存储硬件,定制化宿主机 Linux 内核专门适配最新型硬件。采用自研 IO 调度算法,可良好保障实例级的 IO 隔离。数据库层面通过参数调优、内核定制优化,使数据库发挥出最优性能。通常情况下,数据库的性能瓶颈会出现在磁盘 IO。采用虚拟机自建存在诸多弊端,例如 IO 路径过长、IO 稳定性较差、IO 竞争等。UDB 采用高性能物理机+Docker 架构+自研 IO 调度算法,打造出强劲的 IO 性能,持续保障稳定性和隔离性。
上图,是去年某技术博客关于三大云数据库( UCloud、阿里云、腾讯云)的评测数据(原文地址:https://www.felix021.com/blog/read.php?2163)。同样配置下,UCloud 云数据库的性能( Sysbench 测试),远超竞品数倍。这个评测在当时也引发了一场,业界关于云数据库性能的大讨论和优化。
d、零维护
通常情况下,数据库是后台服务框架里最为核心的组件,重要性不言而喻,日常运维工作慎之又慎。在第一个阶段,UDB 提供的是数据库的全托管运维能力,包括一键部署、保活、容灾、备份、恢复、迁移、配置、漏洞修复、升级、监控与告警、巡检等等一系列的后台运维类操作,解放了客户的 DBA 人力 /精力。本身在 UDB 产品上集成了上述多数的控制台操作,使客户对数据库基本可控。
e、性价比
客户对云数据库买不买账,性价比成为非常重要的因素。可靠、稳定、高性能、高可用、零维护等基础能力作为 UDB 的价值基础,在 UDB 产品上更是提供丰富的配置组合,自定义存储(普通盘 or SSD 盘)、内存大小、VPC 网络、可用区等,灵活多配,按需付费,一键交付。按业务增长,弹性扩容。客户完全省去自建数据库的一切环节,规划 IDC,规划资源,采购,上架,交付部署,以及后期一切运维工作。对于一些商业数据库(如 SQL Server )尤其划算,省去自购官方 license 费用。
全景图
最后, 给出第一阶段,UDB 的系统架构和产品全景图:
从下往上, 可以看到一个云数据库产品的生长历程:
1.UCloud 全球数据中心,是 UDB 开展所有工作的基础。截止 2017 年 7 月份,UCloud 目前已有 21 个数据中心,其中 9 个海外数据中心,遍布三大洲 10 个国家和地区,均部署有 UDB 产品。
2.UDB 数据中心自动化管理系统、以及 DBA 和数据库运维系统, 是支撑 UDB 产品现网运营的两大基础系统。UDB 全球任何一个数据中心的数据库资源和现网运行问题,最终都落实到这两个系统和负责团队之上。而 UCloud 公司级支撑平台,则包括但不限于:运营平台、运维平台、监控和告警平台、质量管理平台、发布和配置系统、变更系统、资产管理系统等,这些系统为 UDB 团队的日常运营,提供强有力支撑。同时,UDB 充分借助了兄弟部门的云服务,来简化 UDB 管理流程,优化管理质量,这些系统包括:对象存储 UFile、分布式文件系统 UFS、监控系统 UMonitor 等。
3.基于物理机的 Docker 虚拟化, 是 UDB 产品的硬件基础。物理机+Docker 的硬件架构,其优点已在上面充分说明,在此不做赘述。
4.多品类的数据库产品。基于物理机的 Docker,结合 UCloud SDN 基础网络,各种数据库软件得以部署。目前 UDB 产品已经支持 MySQL、Percona、MariaDB、PG、MongDB、SQL Server 六大主流数据库。更多的数据库产品,还在不断扩充中。
UDB 团队将推出一系列文章来介绍 UDB 产品的现有能力,并分享做产品的经验和对未来的思考。 本文作为这个系列的第一篇,以全景概览的方式,为大家介绍了 UDB 产品的基因,三个发展阶段;并就第一个阶段(取代自建数据库)进行了详细论述。
在下一篇文章,我们将展开对 UDB 产品发展第二,三阶段的讨论。后续将进一步深入, 推出涵盖 UDB 高可用和容灾、读写分离、分布式数据库等具体功能点的技术、产品文章,敬请期待。
这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.