如今，信息技术一直在不断发展。而这种技术进步继续以极快的速度发生，需要更快的处理和大量的数据存储，而在过去二十年中引入了改变数据中心设计和部署的云计算模型。简而言之，云计算是按需应用程序和计算资源的交付。云计算解决方案通常由第三方通过互联网提供，但将组织数据中心内的模型应用为私有云也很常见。

云计算模型与以前的数据中心策略不同，因为该模型提供了可供用户作为服务使用的资源池，而不是将基础设施专用于每个单独的应用程序。在公共云的情况下，这些服务可以采用最终用户应用程序、后台平台或虚拟服务器的形式，所有这些服务都通过互联网托管，其简单的计费模式向用户收取的费用仅限于用户。

人们理所当然地认为可以采用云平台进行个人互动。人们的移动设备上运行的大多数应用程序都利用了云计算技术，并且人们期望这些服务全天候可用。云计算提供的“永远在线、永不宕机”的预期、易扩展性和成本模型的改变，直接影响了企业首席信息官如何利用数据中心和在公司内部交付数据的策略。企业的首席安全信息官通过其多个数据中心、多个存储解决方案以及服务器和应用程序的大规模部署来了解其传统IT环境，并看到高成本和低效率的损失。因此，企业越来越多地利用公共云来增强传统IT并利用这些优势。

企业可以将最初分配给其私有数据中心的资本支出转换为与云计算相关的运营支出，并且可以开始转向更多的终端用户自助服务模式，这有助于支付IT成本。当云计算首次推出时，随着模型的成熟，许多首席信息官采取了“观望”的方法，但现在云采用量急剧增加，调研机构Gartner公司估计40%的IT预算被分配给云计算和云计算相关服务。云计算对数据中心的变革影响体现在许多组织的“云优先”政策上，包括美国联邦政府和通用电气等大型企业。他们在亚马逊的AWS re：Invent用户大会上宣布将其组织60%的IT工作负载从数据中心迁入公共云。

什么适合云计算，什么不适合云计算?

行业研究表明，云计算的思路发生了重大转变，但传统的数据中心模型和云计算并不是相互排斥的。数据中心转型将继续发展，与传统数据中心托管相比，企业首席信息官不要将云计算视为一种非已即彼的策略，而是一种共存的策略。那么，组织如何利用云计算作为其IT战略的一部分的一些具体示例是什么?是什么促使组织选择云计算而不是自己构建和维护解决方案?企业首席信息官应首先了解哪些应用程序适合云计算，哪些应用程序不适合。

适合云计算的应用程序通常具有内置于应用程序中的灵活性，因此不存在系统或安全功能的自定义的硬编码。应用程序和数据可以在单独的工作区中运行，以便应用程序可以利用动态资源利用率。增加额外的资源，例如为Web应用程序添加Web服务器，应该是其模块化设计的一部分。这些功能允许IT组织在云中运行应用程序，而不是在自己的数据中心中部署和维护基础设施。但是，同样重要的是人们要认识到，在将应用程序迁移到公共云时，对互联网的依赖将会增加。因此，如果互联网因最终用户而中断，那么业务和生产力就会停止。

不适合云计算或适合在组织数据中心部署的应用程序通常具有特殊要求，使其无法迁移到公共云。这些要求可能具有监管性质，依赖于基础设施或存在延迟问题。合规性问题通常出现在医疗保健和金融服务中，这可能会限制数据所在的位置以及访问方式。尽管在公共云的早期阶段出现了特殊的安全问题，但许多云计算提供商正在提供与标准数据中心相同甚至超过某些私有数据中心性能的安全解决方案。云中改进的安全技术将加速采用，并进一步让数据中心进行转变，因为其主题不再是企业首席信息官关注的问题。

在移动性方面，工作场所发生了巨大变化。云计算转型最受欢迎的一个例子是软件即服务(SaaS)。IT组织已经能够通过SaaS模型利用许多最终用户生产力的应用程序，而不是自己构建和维护解决方案。像Microsoft Office365这样的解决方案通过互联网提供应用程序(Word、Excel等)，但仍然利用IT组织配置的身份验证和安全功能。在这种情况下，组织每月添加和删除用户，并在使用时支付使用Office365权利。管理、修补和运行这些应用程序的基础设施由云计算提供商提供，允许IT组织将成本和精力集中在其他计划上。

除了向最终用户提供应用程序之外，公共云提供的服务还可以采用其他形式。由于其远程和基于消费的特性，云计算正在改变企业首席信息官查看备份和复制解决方案的方式。IT组织不是部署辅助数据中心进行异地恢复，而是能够在自己的主数据中心内维护生产应用程序和数据，同时利用远程云进行异地备份、复制和故障转移。因此，IT组织不必仅为备份和恢复维护辅助设备，并且可以通过只为其使用的服务支付费用来利用基于消耗的成本模型。

在另一个常见的例子中，IT组织可以选择通过公共云来部署Web或数据库服务，通过每月消费该平台并将其配置应用到该平台——也称为平台即服务(PaaS)。应用程序和使用它们的最终用户不知道该平台是托管在云中的，但该解决方案提供了可扩展性，并为实现IT组织的部分成本提供了机会。这与传统的数据中心托管模型不同，后者必须由IT组织部署和维护平台，而不仅仅是应用程序本身。

最后，IT组织通常将云计算用于各种服务器工作负载。这些工作负载本质上可能是动态的，也可能是测试/开发环境的一部分，但在每种情况下，都需要计算资源(服务器)。云端不是将服务器部署为数据中心中的专用机器，而是为企业提供了“自助服务”具有弹性和可扩展性的虚拟服务器的新选择。

据Gartner公司称，这种类型的计算资源利用被称为基础设施即服务(IaaS)，并且是增长最快的云计算部分。IaaS彻底改变了IT组织在数据中心中部署新服务器的想法。而在2016年，IaaS市场规模增长了60亿美元，达到224.3亿美元，并在未来几年将会得到继续增长。

无论是向最终用户提供应用程序还是部署动态Web应用程序，云计算都为IT组织提供了可扩展性、易管理性和运营成本模型，通过完全不同的模型为客户提供高质量的服务。云计算已经达到了成熟水平，现在正在改变IT组织的数据中心，从大型企业到小型企业，并且允许企业专注于他们的核心业务和消费IT，而不是从事IT交付业务。

“世界第一款自治型数据库”，甲骨文2017年的open world大会第一天，依旧保持了一如既往的“狂傲”，甲骨文执行董事会主席兼首席技术官拉里·埃里森（Larry Ellison）在宣布推出号称无人驾驶的Oracle自治式数据库云（Oracle Autonomous Database Cloud）时表示：“我并不会每年都在甲骨文全球大会上使用‘革命性新技术’这个说法。因为并不会有很多革命性新技术。但这的确是一个。”他甚至嘲笑对手说：“甲骨文并没有杜撰了一些演示来让亚马逊看起来很糟糕。这是我们实际使用来进行压力测试、性能测试和验证Oracle数据库的数据集合。”在他提供的对比数据显示，与Oracle自治式数据库相比，亚马逊运行同样工作负载的成本要高5～8倍，“我们可以通过合同的方式向您保证，将您使用亚马逊的费用减少一半。对此，我们很有信心。”

要解析拉里·埃里森为何敢于这样讲，首先要了解：到底什么是自治式数据库云？

与传统的数据库相比，此处甲骨文推出的Oracle自治式数据库云由Oracle数据库18c驱动，强调引入了机器学习技术，从而在某种程度上的自动化特征。

具体包括：无需相关人力介入，即可在数据库运行的情况下实现自动升级、微调、修补、更新、维护数据库与自行调整计算和存储资源。由于不会出现人为错误，也无需人工进行性能测试，因此如果采用该产品，也可将代价高昂的计划性与非计划性停机时间缩短至一年30分钟以下。

很显然，对于常常被应用到业务管理场景当中的机器学习技术，首次被应用于企业级的底层数据管理，的确从某种程度上完成了数据库产品本身应用方式的革命性转化。

这种转化从用户的角度，最显而易见的利益在于可以以更低的成本应用更高可用性、高性能和高安全性数据库产品。而对于甲骨文和拉里·埃里森来说，则是完成了既定的全部产品云化的最关键、最重要的一个步骤。

或许有人会说，早在2012年10月1日发布的Oracle 12c就是一款针对云计算（Cloud）而设计的数据库，那么此次的Oracle自治式数据库云又怎么是甲骨文全部产品云化的关键步骤呢？

用甲骨文公司副总裁及中国区技术产品事业部总经理吴承杨的说法是：Oracle自治式数据库云实际上是在为“PaaS的标准定义了一条红线”。

从传统意义上说，企业级用户对于云计算产品的应用，有一个非常明确的要求，即：在保证高可靠性、安全性、高性能的同时，最大程度降低用户自身对于系统的管理难度和强度。这一点在今天的Iaas和SaaS的应用当中，基本得到了认同，已经成为市场上产品彼此竞争的基本考量因素。但是对于PaaS来讲，这样的标准是不存在，用吴承杨的话说：“服务的承诺却少之又少。99.995%的可靠性几乎是不可能。至于自动打补丁，自动升级，自动检测安全问题更是无从谈起。”

作为一直强调能够提供从SaaS直到Paas、Iaas和Daas各个层级云服务的系统提供商，甲骨文的的战略是向市场提供一个包含应用、平台和基础设施的统一标准化、规模化的云应用系统。因此，保证自身的产品本身能够全部复合用户对云计算产品服务的要求，就成为其考量自身产品是否云化的重要指标。

这也是为什么拉里·埃里森在发布现场反复强调：在Oracle云上运行Oracle数据库，能够确保99.995%的可靠性和可用性，从而将需要大量费用的计划内和意外宕机时间减少至每年不到30分钟——这就使得甲骨文PaaS核心的数据库产品真正达到的云计算产品的标准，也意味着甲骨文全部产品当中最核心的部分，已经顺利实现了云化过程。

全部产品实现云化的另一个方面也不容忽视：如何让用户能够跟随你的脚步，共同迈入云端？

就在Oracle自治式数据库云发布前几天，拉里·埃里森还宣布推出了一项新的商业计划：Oracle云计划包含自带许可证（Bring Your Own License）使用PaaS和通用授权（Universal Credits）。

简单地说，自带许可证使用Oracle Database PaaS，就说是此前客户可以将其本地部署的授权软件许可证用于Oracle IaaS得到了扩大，客户也可以把其现有授权软件许可证用于Oracle PaaS，其中包括Oracle数据库、Oracle中间件和Oracle分析软件等——即：已拥有本地部署的授权软件许可证的客户可即刻使用Oracle数据库云。

而通用授权，则是说，客户可通过一份简单的合同来无限使用所有目前和未来的Oracle PaaS和IaaS服务，包括Oracle云和Oracle Cloud at Customer。通过通用授权，客户可自由地切换正在使用的PaaS或IaaS服务，无需另外告知甲骨文。

拉里·埃里森的计划当中尤其强调：“客户也可通过现有云授权使用新推出的服务。”

联系此次推出的Oracle自治式数据库云，以及2017年9月25日正式实行的全新计划，不难发现，甲骨文和拉里·埃里森正在不遗余力地向用户传递这样的信息：我们支持你们选择云端的应用！你可以因此获得更多的服务，而需要负担的工作和成本将更低。

虽然，我们暂时不能确认价格的吸引力能够左右多大比例的用户真正转向云端应用，但是对于某些价格敏感的中小型企业、初创企业来讲，甲骨文的金字招牌加上值得信赖的技术、更具吸引力的价格，要做出怎样的选择，恐怕比之前更容易下定决心。

写在最后

“100%的应用开发和测试将在云端进行；80%的生产应用程序将部署在云端；80%的IT预算将用于云服务；80%的IT预算将用于业务创新，只有20%用于系统维护；所有企业数据将存储在云端；企业云将成为IT业务最安全的场所。”按照传统，甲骨文首席执行官马克·赫德依旧在甲骨文全球大会主题演讲中预测了未来云领域的发展，并且将网络上调侃、攻击他以往所做预测的评论放在大屏幕上，表示说，所有的预测都仅仅是一种个人行为，在某种程度上，这已经成为行业内的一种共识，他尤其强调说：“甲骨文的工作是为用户提供了一个标准化、规模化的云服务系统，不同层次和应用之间时互融、互通的，用户不需要去维护，甲骨文来做。这不仅仅是为了帮助客户降低成本，更重要的是，这样才能够真正帮助用户去做更多的创新：做个性定制，做更多产业的创新。”

本篇首先引入编程微课项目作为数据库的应用案例，通过对项目功能及涉及的相关数据的介绍，让读者对数据库的应用有一个感性认识，然后重点讲述关系数据库的理论基础知识。通过本篇的学习，读者应该能掌握以下内容：

● 编程微课的主要功能

● 数据库的基本原理及数据模型

● 关系数据库

1、编程微课

编程微课项目使用图文，语言，视频等方式进行内容教学，再附加各种训练题，帮助练习和巩固知识。

微课内容来自于编程达人，编程达人撰写课程内容，通过编程微课平台为编程爱好者提供课程内容，获得收益。读者可以通过PC浏览器、微信小程序支付课程费用和学习课程内容，并可以加入编程达人的朋友圈，与编程达人进一步互动交流学习。

2、理解数据库

数据库可以理解为存储数据的仓库，每个数据项在数据仓库中都有编号，通过编号就可以找到该数据项。例如，图书馆就是存储图书的仓库，在图书馆存储的每本图书都有一个编号，编号表示了书的类别和顺序号，同类别的书放在一个书架上，便于图书管理员和读者查找图书。

图书馆存储的是图书，数据库存储的是数据，每条数据称为数据项。数据是对客观事物的符号表示，如文字、图形、数字等。在日常生活中，人们直接用语言来描述事物，例如在描述一门课程时，人们常用“Java编程课程—入门篇由编程达人郎老师编写，编程语言课，课程面向青少年编程爱好者，课程以浅显易懂的语言，以常见的生活场景为案例，带领大家逐步进入计算机编程世界”。

在计算机中，为了存储和处理这些事物，就要将事物的特征抽象出来组成一个记录来描述。

例如，将课程事物抽象为数据项记录（课程名称，授课老师，类别、学生对象，课程简介）。课程事物的一条数据可以描述为（Java编程课程—入门篇，郎老师，编程语言，面向青少年爱好者，课程以浅显易懂的语言，以常见的生活场景为案例，带领大家逐步进入计算机编程世界）。

当需要存储多个课程数据项时，就构成了数据库。因此，数据库是存储在一起的相关数据的集合，这些数据是结构化的，无有害的或不必要的冗余，并为多种应用提供数据服务。

3、数据库发展简史

计算机应用于数据管理的初期，由于没有必要的软件、硬件环境的支持，用户只能直接在裸机上操作。当时编写的应用程序不仅要设计如何处理和存储数据，还要指明数据在存储器上的存储地址。在这一管理方式下，应用程序和数据之间相互结合，不可分割，数据独立性差，缺少共享性，编程效率低下。这一阶段称为人工管理阶段。

随着计算机软、硬件的发展，数据管理进入了文件管理阶段，这一阶段的主要标志是计算机有了专门管理数据库的软件——操作系统（文件管理）。文件管理方式是把有关的数据组织成一种文件，这种数据文件可以脱离程序而独立存在，有一个专门的文件管理系统实施统一管理。在这一管理方式下，应用程序通过文件管理系统对数据文件中的数据进行加工处理，应用程序的数据具有一定的独立性和共享性，比手工管理方式更进了一步。

在文件管理阶度，数据虽然具备了一定的独立性和共享性，但由于数据的组织依然是面向程序，数据不但存在大量冗余，而且数据自身的逻辑结构也难以满足不同用户对数据的要求。为了减少数据冗余，提高数据的共享性和独立性，人们对需要对使用的数据进行统一规划管理，形成一个数据中心，构成一个数据库。数据库中数据能够满足所有用户的不同要求，供不同用户共享。这个阶段称为数据库管理系统阶段。

4、数据模型

数据模型是数据库的基础，数据是对客观事物的符号表示，模型是现实世界的抽象。数据模型是对数据特征的抽象。

将客观事物抽象为数据模型，是一个逐步转化的过程，经历了现实世界、信息世界和计算机世界这三个不同的世界，经历了两级抽象和转换，如下图所示：

现实世界是指客观存在的事物及其相互间的联系，人们一般选择事物的基本特征来描述事物。事物可以是抽象的，也可以是具体的，如课程属于抽象的事物，人们通常用课程名称、授课老师、类别、学生对象、课程简介等特征来描述和区分。学生就属于具体的事物，通常用学号、姓名、班级、成绩等特征来描述和区分。

信息世界是对现实世界的抽象，人们把事物的特征和联系通过符号记录下来，并用规范化的语言描述现实世界的事物，从而构成一个基于现实世界的信息世界，这个信息世界就是概念模型。概念模型主要用来描述显示世界的概念化结构，它使数据库的设计人员在设计的初始阶段，摆脱计算机系统及数据库管理系统的具体技术问题，集中精力分析数据以及数据之间的联系。在概念模型中，最常用的设计模型就是实体—联系模型（ER模型），关于课程的ER模型如下图所示：

信息世界的概念模型还不能被数据库管理系统直接使用，需要将概念模型进一步转换为逻辑数据模型，形成便于计算机处理的数据形式。逻辑数据模型是具体的数据库管理系统所支持的数据模型，主要有关系数据模型、层次数据模型和网状数据模型。关系数据模型是目前最流行的数据库模型，支持关系数据模型的数据库管理系统称为关系数据库管理系统，MySQL就属于关系数据库管理系统。关系数据模型以二维表结构来表示事物与事物之间的联系，也可以称为实体与实体之间的联系。关于课程关系的二维表如下表所示：

逻辑数据模型反映了数据的逻辑结构，当需要把逻辑模型数据存储到物理介质时，就需要用到物理数据模型了，物理数据模型是面向计算机物理表示的模型，描述了数据在存储介质上的组织结构，它不但与具体的数据库管理系统有关，而且还与操作系统和硬件相关，每一种逻辑数据模型在实现时都有对应的物理数据模型。本课程重点讨论概念数据模型和逻辑数据模型，物理数据模型不是本课程讨论的重点。

5、 关系数据库

要设计一个数据库系统，首先要将现实世界抽象到数据的世界，即将现实世界用数据进行描述，得到一个现实世界的数据模型。

关系数据模型是目前描述现实世界主要的抽象化方法，它将用户数据的逻辑结构归纳为满足一定条件的二维表的形式。由于关系数据模型概念简单、清晰，用户易懂易用，又有严格的数学基础。因此，20世纪80年代以来推出的数据库管理系统都支持关系数据模，支持关系数据模型的数据库管理系统也称为关系数据库。

在描述现实世界的过程中，为了分析的方便，可以将这一抽象过程分为两个阶段，首先应用ER模型将现实世界抽象为一个信息世界，这种信息的结构不依赖于具体的计算机实现，然后将信息世界的数据抽象为结构化的二维表形式，形成关系数据模型。

下面以编程微课项目的学生与课程两个事物（实体）为例，对两个阶段的抽象过程作具体说明。

在现实世界中描述学生和课程，要结合具体的事物场景来分析。编程微课项目使用图文，语言，视频等方式进行在线教学，学生可以在任何时间、任何地点使用手机或电脑打开课程学习。结合上面的场景来分析学生和课程的特征。学生有名称、账号、登录密码、性别、年龄等基本特征；课程有课程名称、授课老师、类别、学生对象、课程简介等基本特征；学生与课程的主要关系是学生学习课程。

经过上面对学生和课程的分析，可以画出学生与课程的ER模型，完成第一阶段从现实世界到概念世界的抽象。ER模型如下图所示：

第二阶段将设计的ER模型抽象为结构化的二维表形式，形成关系数据模型。将ER模型转换为结构化的二维表形式非常简单，一个事物（实体）对应一个表，事物（实体）的属性为表的字段，事物（实体）之间的关系可以在一个实体的二维表中增加另一个实体的主要字段来实现。ER模型转换后的二维表如下图所示：

■ 课程小结

可以把关系数据库理解为超市，超市摆放商品的每一排货架为数据库表，货架中每一列为表的字段，每一行为表的一条记录。假设货架每行同列摆放的商品类别相同，则可以把超市的每一排货架理解为数据库的二维表结构。由此可以看出，关系数据库是由多个二维表组成的，在每个二维表中每行同列存储的数据类别相同。

设计关系数据库时，需要两个阶段。第一个阶段是需要将现实世界的事物进行概念化，抽象为概念数据模型，此阶段最常用的工具是实体—联系模型（ER图）；第二个阶段是将ER模型转换为二维表结构（关系数据模型），此阶段一般需要利用数据库设计工具进行设计，如PowerDesigner、Visio等设计软件。

业务高可用是我们每个项目的需求，一个经常故障的项目，会让我们觉得不靠谱而选择放弃，从而导致项目的失败。今天，我们来聊一聊，如何让你自己的业务能够更加稳固的运行！

本次我们从四个不同的角度，来分析，如何让我们的应用更加稳固，平稳运行。

一、 程序架构

优秀的代码

优秀的代码非常重要，即使我们拥有最好的硬件资源和架构，如果我们没有一套健壮的代码，其他资源再好都没有用，所以代码在设计和编写时，应当注意代码的健壮程度。优秀的代码不止开发起来方便，同时维护成本也较低，对于后续的优化来说，健壮的代码会让优化人员更加容易的找到问题的关键。

合理的架构

一个大型的、负载的单体应用可能会让你的整个开发进度缓慢、部署困难。所以，为了解决这种问题，不妨在开发初期便将应用程序设计为微服务架构的程序，虽然可能会提升程序之间的沟通难度，但却为你的应用提供了后续自由伸缩的可能，帮你解决后期发展起来的伸缩难题。

对于已经上线的应用，整体微服务化可能是非常困难的，毕竟你不可能让整个团队重新开发一套系统出来，这样的情况下，不妨把核心的、请求量较高的业务单独拆分出来，作为一个服务，让每一个服务都变成专注与单一的责任和功能的小的区块，更好的对外提供服务。

二、 资源架构

在云计算的时代，云计算大行其道，为各行各业提供计算能力的支持，合理的利用云计算所提供的能力，就能帮助我们更加轻松的去做好应用的高可用。

一般来说，我们的每一个应用大体上都可以分为四层：入口层、业务层、缓存层、数据库层。当我们做好每一层的优化，那么我们的应用本身对于可能出现的问题进行避免。

入口层

入口层通常的情况下指的是Nginx、Apache等层面的东西，来负责应用的入口。一般情况下，我们会将应用程序定位在某一个IP，那么如果我们这个IP宕机了，就会导致服务的不可用，所以，在入口层我们不妨使用负载均衡，通过对压力的评估和成本的预估以及技术实现的难度，我们可以选择自建负载均衡或者使用云服务商提供的负载均衡器，在这样的情况下，当我们入口层后面的业务出现了单点故障时，可以自动借助于负载均衡的健康检查和请求分发的机制，把请求转发分配到可用的节点，保证服务的正常运转。

业务层

业务层通常是由PHP、Java、Python、Go等写的逻辑代码构成的，需要依赖于后台数据库及一些缓存层面的东西。如何实现业务层的高可用呢？最核心的就是，业务层不要有状态,将状态分散到缓存层和数据库。目前大家通常喜欢将以下几种数据放入业务层。

第一个是session，即用户登录相关的数据，但好的做法是将session放在数据库里，或者一个比较稳定的缓存系统中。

第二个是缓存，在访问数据库时，如果一个查询很慢，就希望将这些结果暂时放到进程里，下次再做查询时就不用再访问数据库了。

一个简单的原则就是业务层不要有状态。在业务层没有状态时，一台业务层服务器当掉了之后，Nginx/Apache会自动将所有的请求打到另外一台业务层的服务器上。由于没有状态，两台服务器没有任何差异，所以用户完全感受不到。如果把session放在业务层里面的话，那么面临的问题是，这个用户以前是登录在一台机器上的，这个进程死掉后，用户就会被登出了。

缓存层

非常简单的架构里是没有缓存这个概念的。但在访问量上来之后，MySQL之类的数据库扛不住了，比如在SATA盘里跑MySQL，QPS到达200、300甚至500时，MySQL的性能会大幅下降，这时就可以考虑用缓存层来挡住绝大部分服务请求，提升系统整体的容量。

缓存层如果希望实现高可用的架构，最好的方案就是将缓存层分的细一些，采用分布式的缓存或者是云计算服务商提供的云缓存能力，来减轻数据库层的压力。

数据库层

在数据库层面实现高可用，通常是在软件层面来做。例如，MySQL有主从模式(Master-Slave)，还有主主模式(Master-Master)都能满足需求。MongoDB也有ReplicaSet的概念,基本都能满足大家的需求。

三、 云计算资源利用

上述的内容，主要还是和开发层面有关的，接下来我们来聊聊和运维强相关的内容

业务不单点

无论我们怎么对服务器的能力进行优化，终归是有个上限的，而且，单点服务器也更容易出现安全的故障问题。即便是云计算，也无法保证业务的永久可运行，即便是国内TOP1的阿里云，也出现过机房光缆被挖断过。所以，不要指望云计算服务商为你提供绝对可用的服务，更何况，在他们自己的服务等级协议里也不是100%。

所以，对于我们自己来说，要让自己的应用尽可能的不要单机运行，即使你的应用是单体服务，也可以让他跑在同一个节点的不同可用区（节点故障很少见）、不同节点的多个可用区（异地多活）、甚至，为了保证业务的运行，不要相信一家服务商，你可以同时采购多家的云计算资源（如果预算足够），就算有百分之一的可能，这个服务商挂掉了，你还可以切换到别的服务商去提供服务。

合理利用云资源

除了云计算最基础的计算能力，我们往往会购买一些附加的业务，比如云数据库、云缓存、云存储等等。

通过云存储，我们可以将非结构化的附件数据，存储到云服务商所提供的对象存储服务中，减少本地的文件存储压力，同时为业务服务器减少IO读写压力，更加专注于运算。

通过云缓存，我们可以在使用同一个可用区的多台主机时，将状态进行同步。帮助我们的应用同步状态，以免用户登录状态的丢失。

通过云数据库，我们可以借助云服务厂商所提供的能力，来拓展我们数据库的多备份、主从分离等等。让我们的业务数据查询请求进行分流，避免单一数据库的读写压力过大而导致业务的崩溃。

利用云计算供应商的提供能力，能够为你自己维护减轻压力，把精力放在业务本身。

注意备份保安全

云服务商不是神，我们自己部署服务器会出现的问题，云服务商同样也会出现，只是他们可能比我们的优势在于能够更好的去帮我们保存数据，避免数据的丢失。同时借助数异地双活、异地多活、数据三备份等技术，保证我们数据的安全和可靠。我们在使用云服务商为我们提供的种种安全措施的同时，看清楚人家的能力，同时要保证自己的数据的定期备份，以免出现问题。

四、 关注服务商提供的公告信息

维护和故障是不可避免的，再大的云计算服务供应商，都有可能遇见这样或那样的故障文档，只要我们关注服务商所提供的公告信息，尽可能的去提前准备，那么就可以更换的提供服务。

这一方面做的比较好的是AWS和Azure，在每次出现故障后，他们都会提出故障公告，诚恳的说明故障的原因和解决方案，让用户明白故障的问题所在。这一方面，国内阿里云在完善故障通报机制，可以看到同一个故障出来阿里云都是通报最快，算是比较靠谱，其他云厂商，基本上官网不会公开，则大多是能瞒则瞒，能不报就不报，但是问题总归是问题，没有说明反而会让用户更加的疑惑，其他云厂商需要向AWS、Azure以及阿里云学习。

在维护方面，AWS、Azure就显得比较坑爹了，他们过往的维护周期比较长，如Xen底层的一个漏洞，无法采用热升级，一般就需要分批停机维护胡，用户如果没有准备，就需要关站一天，不过好在往往会提前一周发出维护公告，声明维护的节点，让用户提前做好准备。这一方面，国内遇到的还比较少，印象中如阿里云没有大规模停机维护的事件，一方面是AWS在前可作前车之鉴，另外也有技术上的因素。

不过，凡事无绝对。毕竟，云计算也是由一个个机房组成的，不是真正飘在天空中，飘在云上的服务器，我们在使用传统独立服务器可能会遇见的掉电、故障等问题，也会出现在云计算的主机上，只是相对来说，要少了很多，更加的安全。

所以，不管是AWS、Azure、还是阿里云或国内其他厂商，都在鼓励用户使用多个节点和可用区来部署业务，单点情况下出现的故障是不可避免的，当你使用多个节点时，出现故障的可能就大大的减小了。比如你可以在同一个可用区使用两台主机来做主备，再另外一个可用区做备份，这种情况下，即使一个可用区出现了问题，整体的服务也不会受影响。

最后，我们来总结下如何构建高可用的应用：

1.        健壮的代码为高可用保驾护航

2.        合理的架构为高并发情况下的伸缩提供可能

3.        入口层的请求分发

4.        业务层尽可能不存在状态

5.        缓存层使用分布式缓存缓解压力

6.        数据库层使用主备模式进行备份

7.        业务不单点运行

8.        合理利用云计算资源

9.        注意数据的安全与备份

10.     关注云计算厂商的维护公告

最后，祝大家的业务都能正常的运行！

如今，越来越多的组织正在将他们的下一代数据库体系结构转移到解决方案而不是服务器上，并且接受开源数据库技术的价值。

2017年对于数据库技术市场来说是关键的一年，在此期间经历了几个大规模的模式转变，并且没有迹象表明很快就会停止。企业正在逐步摆脱传统的单一数据库架构，数十年来，这些数据库架构经过多代的应用，以换取更优化的、灵活的、自我管理的云数据平台战略。

随着对规模、安全性、性能、高可用性，以及可能最重要的成本和操作优化的需求不断增加，人们可以确定为下一代数据库架构的“2.0版本”提供动力的三个重要驱动因素：

(1)客户正变得以云计算为中心。(2)客户越来越依赖平台即服务的数据库解决方案。(3)客户正在采用开源数据库引擎。

想要验证企业自己的IT数据库战略是否与数据库市场的总体发展方向保持一致?企业所要做的就是确保自己采用这些原则。以下更详细地探讨它们的含义。

以云计算为中心的数据库时代

早在2014年，当重新调整微软公司的整个软件和服务战略时，首席执行官Satya Nadella提出了“移动优先，云计算优先”的口号。Nadella一直在表达微软在移动，云服务和解决方案领域所付出的努力，而整个企业市场似乎都热衷于接受类似的优先事项。

例如，根据麦肯锡公司的主题为“IT即服务云”和“企业云基础架构调查”，云计算作为工作负载主要环境的企业采用率预计将从2015年的10%上升到2018年的51%。麦肯锡公司还指出，企业可能会选择超大规模的云解决方案提供商提供的服务，例如亚马逊、谷歌、微软。

即使是非常传统的公司，他们投资拥有数十年的数据中心业务经验的大型IT组织，都会发现需要接受以云计算为中心的IT战略的优势。

但是，仅仅打着“云计算”旗号让企业采用是不够的，甚至可能会让人混淆不清。企业是否计划将现有服务器从本地数据中心提升或转移到云端，或者更进一步，开始为企业的数据库采用原生云计算解决方案?

虽然“提升和转移”(IaaS)策略可以帮助减少企业的IT管理开销，并大幅提高运营的灵活性和可用性，但是对于许多“云优先”组织来说，这只是浅尝辄止，并没有完全深入地采用云解决方案和服务。

从思考服务器到思考服务

根据调研机构Gartner公司的“2017年PaaS关键趋势”调查报告，企业客户正在采用平台即服务(PaaS)来实施越来越多的战略举措，越来越多的客户认为PaaS将成为平台交付的主要形式。

其原因很简单：PaaS数据库技术是自我管理和自我操作的。这些解决方案大大降低了维护数据库体系结构的运营开销，使企业可以将IT人员(尤其是数据库管理员)的时间和精力投入到以应用程序为中心的活动中，从而推动业务成功，而不是保护过于复杂的数据库基础架构。

数据库软件和云计算供应商正将大量的研发力量投入到PaaS数据库解决方案中，这正成为云计算领域厂商(亚马逊、微软、谷歌以及Oracle))最重要的差异化因素之一。

早在2014年，亚马逊公司就宣布推出一款完全可管理的关系数据库引擎Aurora，它将高端商业数据库的速度和可用性与开源数据库的简单性和成本效益相结合。此外，也许更重要的是，Aurora是AWS公司的原生PaaS数据库解决方案。自推出以来，Aurora得到了很多应用和思想共享。在亚马逊2017年度re:Invent展会期间，亚马逊公司将其云数据库产品进一步推向市场，并宣布Aurora Serverless是一个完全可管理的“抽象”数据库，而在这个数据库中，用户需要为所使用的数据库资源付费。

很显然，亚马逊公司在云解决方案中的创新和颠覆，PaaS数据库产品在整个行业范围内掀起了浪潮。Oracle公司是传统高端企业关系数据库软件市场的领导者之一，也是一家在研发方面投入了数十年时间研发创建全球最强大、最优化的可配置和可调的关系数据库之一的公司，该公司在OpenWorld2017年度大会推出自己的“自我驱动”数据库产品。Oracle公司首席技术官Larry Ellison描述了自治数据库云的愿景的一部分，Oracle公司关注自驱动、自扩展、自修复数据库解决方案，试图消除与调整、修补、更新和维护Oracle数据库相关的人力成本。

不仅仅亚马逊和Oracle公司推出了数据库产品，微软公司也推出了Azure SQL DB，这是一个完全托管的关系型云数据库服务，并尝试自动调整数据库以改进性能和保护。Azure SQL DB是微软公司的PaaS产品，结合了微软云平台SQL Server和Azure的高端性能和功能。

开源数据库引擎的兴起

商业数据库引擎(Oracle，SQL Server和DB2等)在它们所提供的功能和性能的广度上是至高无上的。事实上，这是其许可价格高的传统理由。但是，开源数据库管理系统已经成熟，成为专有商业数据库引擎极其可行的替代方案。特别是近年来，随着PostgreSQL和MySQL的进步。对于许多使用情况来说，这些开源数据库可能会与商业数据库市场的行业巨头的产品正面交锋。

对于那些一直关注数据库行业状况的业界人士来说，采用开源数据库引擎的热潮不应该让人吃惊。Gartner公司的一个主题为“2015年开源RDBMs状况”的报告早在2015年就预测开放源代码的数据库将被用户广泛接受：“到2018年，70%以上的新的内部应用程序将在OSDBMS上开发，现有商用RDBMS实例中的50%将被转换为正在进行中。”

更重要的是，如果用户将开源数据库部署到云中，那么开源关系数据库的最大缺点也许就是它们缺乏某些高端功能(与其专有的数据相比)。

例如，Oracle公司和微软公司都提供了直接构建到其数据库产品中的异步消息传递/排队机制。Oracle公司称之为高级队列，微软公司称之为服务代理。PostgreSQL或MySQL本身不提供类似的功能。在开始使用开源数据库技术之前，企业需要思考这个潜在的问题。

采用云计算

通过利用主要云平台提供的功能，并将这些功能作为开源数据库架构的一部分进行集成，企业可以更轻松地实现与商业数据库的功能对等。

例如，如果企业使用Amazon Aurora MySQL，则还可以使用亚马逊简单队列服务(它是用于微服务和分布式系统的完全托管的消息队列)和Amazon Lambda(允许用户运行无代理程序代码)作为替代方法的组合针对Oracle AQ和SQL Server Service Broker。使用Amazon SQS + Lambda，用户可以直接从Amazon Aurora MySQL对消息进行排队，就好像数据库具有内置队列服务一样。

同样，如果用户需要定期执行复杂的数据转换，则在微软Azure中运行MySQL数据库将允许用户使用Azure数据工厂，从而通过云端PaaS解决方案减少源数据库引擎中的缺失功能。这些云服务以及许多其他云服务可以与PaaS开源数据库引擎集成，并作为完整解决方案体系结构的一部分。

总而言之，现代关系型数据库的整个概念正在从单一的体系结构转向数量庞大而功能强大的数据库服务器，这些数据库服务器内置了大量的功能，以敏捷的PaaS和利用云平台作为服务的开源模型解决方案和技术。

这是一个明确的范式转变，可能会为今后十年的数据库技术发展奠定基础。

在过去，实现数据仓库就像在数据质量和业务敏捷性之间走钢丝，建立一个数据仓库花了很多年，花费了数百万，这意味着只有最资本充裕的公司才能负担得起。

组织者往往因实施而泄气。例如，至少提前三年，IT团队必须估计有多少存储和计算能力是必要的。如果IT团队购买了太少的硬件，产能将耗尽，这将减缓或脱轨项目的交付，并负面影响企业的感知。数据仓库可以被认为是失败的。如果IT团队购买了太多的硬件，IT预算将失去巨大的资金在未充分利用的硬件，除了创建废弃设备的墓地。

然而，云计算项目只在他们需要的时候支付他们需要的成本。根据IDC的数据，预计数字数据将增长42%，2020年，许多组织已经开始评估云数据仓库作为应对日益增长的数据量的解决方案，许多公司在评估如何尽快将数据仓库移动到云上。需要考虑的有三点。

一、管理大数据的涌入

大数据的主要挑战之一是管理底层基础设施的开销，尤其是随着数据量的扩大。基于云的数据仓库对于面向大量数据涌入的组织来说是非常有用的，因为这些平台被设计成在不增加任何额外管理开销的情况下容易扩展。

这是一个重要的因素，因为随着时间的推移，业务需要改变，只需支付使用时的费用。数据基础设施的灵活计算，再加上数据基础设施自动化来管理和整合数据源，为企业提供了一种非常灵活和成本有效的方式，以比以往更快的速度向企业传递分析信息。

二、自动化手工过程

这不仅仅是可以存储和处理多少数据，而是可以从中得到更大的价值，企业可以确保数据的可用性和可访问性，以便在开发人员依赖手工编码来传递和操作数据基础设施时比以前更快地进行分析。自动化简化了开发，并降低了数据集成和基础设施项目的风险。这使得IT团队能够将注意力和资源集中在为企业提供分析价值的更具战略性的方面。

三、云投资收益最大化

通过自动化基于云的数据仓库，IT团队能够快速开发新的分析组件，而不必花费大量资金在基础设施上，并增加开发和运营能力，最大化一个组织在其云投资上的回报。

基于云的数据仓库平台，如Snowflake，提供了弹性、敏捷性、低系统管理开销、成本效益、可扩展性和性能的好处。自动化软件可以快速地跟踪新的基于云的基础设施的交付，通过自动化平台的最佳实践和本机能力，并消除传统设计、开发、部署和操作数据仓库所需的手工编码的95%。通过提供更快的IT和商业组织，可以开始更快地获取云投资的价值。

数据仓库正在迅速发展，云数据仓库和自动化提高了它管理大数据的能力，并提供了一个机会来消除过时的、手工的过程，从而压缩了它所能提供的组织价值。云计算必将成为未来的数据仓库，自动化是成功的关键。

数据库单机虚拟化承载可行性

在数据库单机方式部署模式下，可以采用服务器虚拟化环境进行承载，虚拟化环境中数据库单机系统基本可以正常运行并正常提供数据库的定义、操作、访问控制等功能，性能损失在可接受范围内（5%~26%）。

数据库集群虚拟化承载可行性

数据库HA双机集群和数据库网格集群可在部分厂商（Vmware、微软、华为、中兴）虚拟化环境中部署，可以提供较高和实时的可用性服务保障，但RAC系统搭建、部署配置工作复杂，同时RAC在虚拟化环境中扩展性能较弱，需要进一步研究和优化。

数据库双机虚拟化承载可行性

由于SQLServer Failover数据库集群系统故障切换时间在60-100秒，不能满足业务访问实时高可用的要求，建议在虚拟化环境考虑采用虚拟化HA高可用方式取代SQLServer Failover集群，以降低SQLServer Failover集群的资源占用量。

KVM与Windows虚拟机适配问题

Redhat KVM虚拟机承载SQLServer数据库时性能较差，不建议采用KVM虚拟机承载SQLServer数据库。

数据库虚拟化承载选型建议

考虑到虚拟化软件与不同操作系统兼容性存在适配优劣的限制，建议承载数据库虚拟机时优先选择Vmware虚拟化软件，其次在承载Window系统虚拟机时建议采用Hyper-V虚拟化技术，在承载Linux虚拟机时建议采用Xen、KVM虚拟化技术。

数据库高可靠性

1、对于可靠性要求不高的的数据库，可采用虚拟机的HA技术进行设计，数据库服务器发生故障时，故障时间为虚拟机服务器开启时间。一般在3-6分钟左右。此模式下应用层的数据库故障时，虚拟机HA不会触发

2、对于I/O较高的数据库可采用缓存数据库+主库的方式配置，适当降低I/O开销

3、当单机虚拟机开销占用物理机50%以上时可采用物理机资源直接部署数据库及相应的HA或者RAC

4、当平台需要多台物理机运行大型数据库时，可考虑分布式数据库解决I/O问题

【IT168 评论】“跨界”是现在很火的一个词，它是指从某一属性的事物进入另一属性的运作，其不只在演艺圈掀起了一阵热潮，同时也在科技圈也带起了一阵狂潮。今天，我们就来看看科技圈第一热潮——云计算公司是如何“跨界”数据库服务的。

现在看来，云计算公司“跨界”数据库并不是什么新鲜事儿。“云计算的下一个竞争战场是数据库”几乎成为了云计算公司的共识，目前云计算公司提供的数据库服务产品大多有这么几类，自研数据库、托管数据库服务、数据迁移服务、数据仓库、缓存服务等等。

上一篇文章我们盘点了国外的云计算厂商提供的数据库服务，这篇文章我们就来看看国内云计算公司都可以提供哪些数据库服务?

阿里云

阿里巴巴刚刚发布了第三财季财报，云服务的收入达到了5.33亿美元，同去年同期相比增幅达到了让人惊讶的104%。阿里云首次登上了Synergy Research发布的云计算基础设施市场份额报告的前5名。

阿里云作为中国云计算市场的霸主，其在数据库服务方面提供的产品较之前面两个公司也丝毫不差。云数据库POLARDB是阿里云自研的能满足高吞吐在线事务处理的关系型云数据库，完全兼容MySQL，性能最高提升至MySQL的6倍，自研的分布式存储引擎能提供在线扩容、故障快速恢复、数据备份容灾服务。

除此之外，我们还看到阿里云在数据库产品一栏还有三款在公测中的产品，分别是数据库应用与数据库迁移ADAM、混合云数据库管理HDM、数据库备份DBS。

腾讯云

根据腾讯发布的2017第四季度暨全年财报，2017年腾讯全年收入2377.60亿元人民币，其中腾讯云本年度快速增长，在云服务视频云和网络游戏等的垂直领域处于领先市场地位。

如果单看腾讯云的数据库服务也是比较丰富的，而且其中的两个产品HTAP数据库和腾讯云时序数据库让人印象深刻。HTAP数据库TiDB(HTAP Database for TiDB)是腾讯云基于国内最新的 NewSQL 开源数据库TiDB打造的一款同时支持联机事务处理(OLTP)和 联机分析处理(OLAP)两种业务类型的分布式数据库产品。

而腾讯云时序数据库(Cloud Time Series Database，CTSDB)更是让人惊喜，在之前的《一篇文章告诉你，为什么时序数据库会成为新趋势?》中，笔者提到了时序数据库可能会在数据库领域引领一种新的潮流，但是在前面几家云计算公司提供的产品中，我们并没有看到。腾讯云时序数据库是一种高效、安全、易用的云上时序数据存储服务，适用于物联网、大数据和互联网监控等拥有海量时序数据的场景。

百度云

相比于前面几家公司提供的数据库服务，百度云官网上列出的数据库服务略显单薄。其中分布式数据库DRDS是基于百度自研中间件的分布式多节点关系型数据库，提供大并发访问及TB级海量数据场景下的数据库存储服务，兼容MySQL协议。

另外，百度云云数据库 RDS 支持三种数据库引擎：MySQL、SQL Server、PostgreSQL，其云数据库SQL Server单机版也已经正式发布，只提供一个数据库节点，相对双机版RDS成本减半。

华为云

2010年，华为正式发布云战略，2017年3月华为副董事长、轮值CEO徐直军宣布成立Cloud BU，宣布大力进军公有云，同年8月， Cloud BU调整为一级部门。那么现在华为云的发展如何呢?据其官网显示，截至2018年2月，华为云已发布14大类共100+云服务，以及制造、医疗、电商、车联网、SAP、HPC、IoT等60多个解决方案。

数据库服务方面，华为云官网给出的云数据库产品包括关系型数据库、非关系型数据库和数据库生态。关系型数据库包括云数据库HWSQL、云数据库MySQL、云数据库PostgreSQL和云数据库SQL Server。非关系型数据库包括文档型数据库服务(DDS)和分布式缓存服务(DCS)。数据库生态包括分布式数据库中间件(DDM)、数据库安全服务(DBSS)、数据复制服务(DRS)和数据仓库服务(DWS)。

UCloud

UCloud是一家中立的云计算服务商，产品线的推出完善以云平台上客户需求为第一出发点，辅以最新的技术产品和细化产品。UCloud大部分的产品和服务都比较贴近国内用户习惯。

根据官网给出的信息，UCloud提供的数据库服务包括云数据库MySQL UDB、云数据库MongoDB UDB、云数据库PgSQL UDB、云内存存储UMem、数据仓库UDW、分布式数据库UDDB、云数据库SQL Server UDB和分布式数据库Cloud TiDB。其中Cloud TiDB还在公测中。

青云

青云QingCloud是一家成立于2012年的企业级云服务商和云计算整体解决方案提供商，已稳定运营着覆盖全国和亚太地区的10个数据中心，为逾70000家企业提供服务。根据其官网给出的信息，青云提供的数据库服务包括MySQL Plus、MySQL、PostgreSQL、MongoDB、RadonDB、Redis、Redis Cluster和Memcached。

其中，QingCloud RadonDB 是基于 MySQL 研发的新一代分布式关系型数据库，可无限水平扩展，支持分布式事务，具备金融级数据强一致性，满足企业级核心数据库对大容量、高并发、高可靠及高可用的极致要求。

【IT168 评论】云计算时代，各大厂数据库架构设计经历了哪些改变?在SACC大会第二天下午的数据库架构设计的前世今生(上)专场，来自京东云、阿里巴巴、58速运、去哪儿网、京东的技术一线专家分享了各自在云计算时代下的数据库架构设计实践，遇到过哪些问题?如何解决?如何保证数据库的高可用和高可靠等等一揽子技术干货!

京东云数据库技术负责人张成远：云时代的数据库演变之路

数据库战国时代，往往每家企业使用的数据库都不止一种。面对市场上众多SQL、NoSQL以及NewSQL类数据库，我们该如何选择?京东云张成远表示，首先要从需求出发，梳理基本生命周期管理需求、运行期生存类需求以及随着数据量增大之后的高阶需求。

云计算时代的到来，意味着DBA手工执行的时代已经过去了，DBA可一键自动创建，实现分钟级搭建主/从秒级库表管理。对于众多DBA关注的高可用、高可靠主/从秒级库表管理方案设计，张成远认为，应该从业务需求出发，了解业务可忍受的延迟和数据丢失极限，京东云目前将数据存于云存储，由于云存储是三副本的，这种方式可以尽可能保证数据不丢。

对于访问量过大的情况，数据库是非常脆弱的，DBA可以层层过滤掉从链路打到数据库上的请求。一般DBA采取的方案是读写分离或一主多从，张成远认为，如果对数据质量要求不高，可以采用读写分离。否则，不建议使用读写分离方案。

58速运CTO沈剑：58速运数据库降压优化实践

一个喜欢写文章的技术人，这是很多人对沈剑的印象。不单单是文笔过硬，沈剑的技术能力也十分强。作为58速运的CTO，沈剑对DBA进行了很多思考：DBA的定位应该是什么?DBA的职责又是什么呢?

在很多公司内部，DBA和研发之间的关系都非常微妙。DBA往往是执行研发提交过来的工单，而渐渐沦为了工单执行工具。沈剑表示，业务DBA应该从专业的角度带给业务价值。从专业的角度，帮助研发做好早期设计;了解被执行工单的业务背景，来龙去脉，做好把关;结合业务进行优化，给出优化建议。

随着近些年业务体量的增大，很多数据库都面临着优化问题。DBA应该学会找主要矛盾，针对性优化。性能优化方面，MySQL分析工具还是很多的，比如可用于分析慢查询的pt-query-digest;调优过程中可以把慢SQL时间设为0，从slowlog中获取所有SQL的相关信息，对性能的影响在10%以内;同时，DBA可以获取总体分析结果，分组排序的分析结果，单Query ID的分析结果。

京东商城中间件技术部负责人丁俊：京东分布式KEY-VALUE存储设计与挑战

目前，很多企业在数据库架构设计上还面临着诸多挑战，比如故障检测与恢复、在线扩容、高可用、升级等，丁俊对这些问题逐一进行了解答。

在故障检测与恢复方面，京东目前的解决方案是非持久化存储—JIMDB和持久化存储— FBASE。JIMDB兼容REDIS协议，在线弹性伸缩的，数据全部保存在内存的K-V存储系统;FBASE支持多协议，支持范围查找的持久化K-V存储系统。JIMDB读写性能要求高，性能要求优先于数据可靠性;FBASE对数据可靠性要求高，数据量大，数据冷热分布明显。

在线扩容上面，要想平滑扩容，丁俊提出需要提前把将要变更的拓扑信息下发给客户端，客户端捕捉到特定异常后使用临时拓扑，扩容完成后临时拓扑变更为正式拓扑。扩容过程中，需要注意数据迁移最小单位为槽，单shard需要控制大小，避免迁移数据多时间长。

高可用方面，依然是异地灾备的方式，主要涉及一些副本的部署要求。升级方面，主要步骤为内存中的数据要做迁移;按照shard滚动升级;新版本的容器创建在同一台宿主机上;迁移完成后客户端捕捉到数据已迁移的异常，会使用新的拓扑。

除了京东分布式KEY-VALUE存储的具体设计和问题，丁俊也给出了对未来的功能规划，比如支持redis数据结构，支持二级索引以及事务等。

去哪儿网数据库架构师黄勇：Qunar网数据库架构的发展

去哪儿网数据库架构设计的前半生基本上可以总结为：解决问题——遇到问题——解决问题——遇到问题.......黄勇表示，早期的去哪儿网数据库也是“小作坊模式”，从单机房内的MySQL逐渐演变为现在的跨机房QMHA架构，同时可保证安全性和高可用。这一路，去哪儿网试用了不少架构体系设计模式，遇到问题就解决问题，对架构不断进行调整。

自2015年以来，去哪儿网一直在应用QMHA架构，QMHA架构主要有四大技术特点：GTID，GTID易于维护和切换，主从节点间可知数据差异;Sentineld，分布式哨兵，减少误切换和网络分区，raft算法，自动切换;Semi-Sync，提高数据节点一致性的同时提高集群安全性和可用性，多线程复制，且可以跨机房和网段部署;Zookeeper，全局namespace，通知客户端更新配置。

目前，去哪儿网的DBA操作平台中的SQL审核部分使用的自研技术已经开源，广大DBA可以尝试搜索试用。

阿里数据库架构师吕建枢：阿里巴巴数据库计算存储分离架构与实践

数据库容器化，当前面临的问题是什么?作为淘宝的运营商，阿里巴巴的数据库架构必须经得起双十一等大促带来的挑战，吕建枢表示，阿里巴巴的数据库容器化曾经面临着一些调度问题和成本问题，比如机型配比问题—CPU，内存以及存储之间的选择，如何应对大促又不至于提高日常运营成本等。

吕建枢表示，阿里主要从计算存储分离、分布式存储优化、数据库设计、数据库离在线混布等几方面介绍了数据库容器化设计的每一步以及遇到的问题。当前面的计算存储分离完成后，离在线混布成为可能;阿里巴巴目前所有的数据库都已完成容器化，预计今年完成离在线混布(DB隔离策略，时延敏感)，未来的数据库将是纯用户+RDMA+SPDK的结构。

面对云计算、海量数据、高流量并发等挑战，数据库架构设计需要不断迭代升级。高并发和高可用似乎是数据库架构设计一贯的基本要求，这些互联网大厂遇到的问题是否与你类似?这些解决方案是否打开了你的脑洞呢?未来的数据库架构设计又会是什么样子呢?

▲更多信息尽在IT168现场报道专题http://sacc.it168/topic2017/