| 导读 | 2006年Google的CEO埃里克·施密特首次提出了云计算(Cloud Computing)的概念。2011年，哥伦比亚大学的Prof.Stolfo教授提出雾计算(Fog Computing)，后被思科公司理论化。云计算是集中式计算，埃森哲(Accenture)公司给出了的云计算定义：第三方提供商通过网络动态提供及配置IT功能(硬件、软件或服务)。 |
雾计算是云计算概念的延伸，是局域网的分布式计算方式，符合互联网的“去中心化”特征，其低延时、位置感知、广泛的地理分布、适应移动性的应用特征，使得该计算范式可支持更多的边缘节点。
2011年，同时出现了边缘计算(Edge Computing)的概念，OpenStack社区给出的定义为：边缘计算是为应用开发者和服务提供商在网络的边缘侧提供云服务和IT环境服务，目标是在靠近数据输入或用户的地方提供计算、存储和网络带宽。
雾计算和边缘计算的区别在于，雾计算具有层次性、网式架构;而边缘计算依赖于不构成网络的单独节点。雾计算中的不同节点之间具有广泛的对等互连能力，而边缘计算是孤岛中运行的节点，这样的节点被容纳入云或雾的网络中可实现流量传输。
云计算、雾计算、边缘计算，是三种不同但又相关的计算范式，每种范式对于数据库系统而言，都有提出不同需求的可能。如今，云计算中的云数据库的特征基本探明，但也在发展中。而雾计算中的雾数据库的特征尚未有提出，边缘计算中的数据库是否是可从传统的单机数据库系统稍加演化得到，也尚未有提及或讨论。
但是，三种不同的计算方式，必然适用于不同类型的应用，对于数据的存储、管理、计算、交换的需求，也必有差异，深入研究不同应用的需求和特点，可得到不同类型的数据库。未来数据库的类型或形态必然会更加丰富多彩。
早在云原生概念出现之前，就出现了Cloud Foundry的概念，其内容可以被概括为一种方法论，称为12要素应用程序(12-Factor App)。根据这12个要素，人们对数据库提出了如下一些具体的要求，使得数据库的架构和功能发生了变化。
- 12要素应用的任意部署，都应该可以在不进行任何代码改动的情况下完成，将本地MySQL数据库换成第三方服务(例如 Amazon RDS)。与此类似，本地SMTP服务应该也可以和第三方SMTP服务(例如Postmark)互换。这使得云应用研发不深度依赖于数据库系统，使得云数据库之间的功能差异化竞争被消灭。
- 12要素反对与会话具有高黏性。会话中的数据应该保存在诸如Memcached或Redis等带有过期时间的缓存中。这就要求云数据库服务要么有多种产品支持不同能力，要么在一个产品内提供带有过期时间的缓存。
- 12要素应用本身从不考虑存储自己的输出流，即不提倡提供日志功能(不写或者管理日志文件)，而是把信息直接输出到标准输出(stdout)事件流。在开发环境中，开发人员可以通过这些数据流，在终端实时看到应用的活动。在应用端不能提供日志以供确认问题，这对服务端的数据库提出了更高的要求：第一数据绝对保持强一致而不存储，第二数据库自身有分析等位问题的能力。但是，不是所有类型的应用都适合进行这方面的设计和实现，大型复杂类应用和网站类应用的定位问题多依赖于日志。
Matt Stine于2017年在一次技术大会的分享中提出“Cloud Foundry与微服务：一种共生关系”的概念，云原生(Cloud Native)的概念正式诞生。他将云原生归纳模块化、可观察、可部署、可测试、可替换、可处理6个特质。
Matt Stine认为：服务的基本原则是有一个清晰的专注点(对应用功能细分的要求)、一个清晰的契约(应用与后台服务之间的接口定义要清晰)、一个清晰的API(应用与后台服务之间的接口在形式上要明确好用)。
云原生通常被认为是一个思想的集合，包括了诸多内容：DevOps、持续交付(Continuous Delivery)、微服务(MicroServices)、敏捷基础设施(Agile Infrastructure)、康威定律(Conways Law)等，以及根据商业能力对公司进行重组。
这使得云原生的概念全面且复杂，其成为一系列技术、企业管理方法的集合，其中既包含了技术(微服务、敏捷基础设施)，也包含了管理(从DevOps、持续交付、康威定律、重组等层面对技术进行管理)。
云计算使得传统的应用方式发生了变化，其自身具有的特点如下。
IT设施从零散化走向集中化、规模化。大型数据中心被大量建立，作为基础设施向全社会提供集中式服务。
IT设施规模化以后，基于弹性服务的要求，需要对硬件资源统一管理。业务规模应可动态瞬时扩缩容，因此要池化硬件资源以提供弹性服务。
云计算，是期望通过互联网络为用户提供按需使用的IT资源服务。因此，云服务商要保证在所提供的硬件资源上拥有容量充足的资源池，以保证在并发业务高峰时刻可以满足用户的服务要求，这就是云服务的资源池化。
云数据库作为一种服务，同云计算相似，其所能管理使用的资源同样需要资源池化。这样用户在使用云数据库的服务时就无须了解云数据库中的实际架构和技术实现了，用户所感知的是其使用的独立完整的数据管理服务和相应的计算资源。
对于用户而言，资源管理在云数据库内部体现为实现多租户特性，根据租户所租用的资源来提供服务。数据库内部资源池化后，可为用户的应用提供弹性伸缩服务。
云计算使得过去IT业所能提供的内容发生了变化。
- 交付方式从软件交付走向服务交付。用户看似在使用一个软件其实不再是一个软件，一系列软件组合成一个服务后提供给用户，对用户而言一项项具体的服务是可直接感受到的。
- 开发方式从底层(IaaS+PaaS)走向上层(SaaS)。云计算不仅提供CPU和机架，更多的是提供用户可感受的软件服务(SaaS)，或者软件都感受不到，直接感受到的就是服务(Serverless)。
数据形式及应用场景从单一化走向多样化。服务、微服务等已经各自成型，无服务(Serverless)也作为一种FaaS(Function-as-a-Service)开始为世界的多样性和精彩性贡献力量。
为了应对云应用的研发需求，云上提供服务的数据库系统也相应发生了一些变化。云原生数据库是指通过云平台进行构建、部署、交付和自动运维的数据库服务。
该服务通常以DBaaS (Database-as-a-Service)的形态，将数据库架构和实现细节隐藏起来，采用多租户和资源有效分发的形式将云资源自动管理起来，为用户提供一个能够满足弹性伸缩、高可用、高可靠、高安全性、强一致等需求，且可以随时随地访问的数据库服务。
该服务具备自动化运维能力(仅需要极少的人力)，可提供自动备份和恢复、自动性能调优、自动对规模化的数据库集群的资源进行调节等可超越传统DBA所做工作的能力(具备智能数据库的特征)。这种能力使得云数据库系统托管和维护的成本降低，规模化地提高资源的利用率。
总体来说，云数据库的特征可以概括为解放用户和适应业务两类。具体可以转化为如下6条内容，其中前3条属于解放用户的范畴，后3条属于适应业务的范畴。
故障可自愈，包括宕机自动迁移、故障隔离、异常流量自动调度、负载均衡、自动限流降级等。数据库可自动调优，自动调节资源的使用，拥有自适应算法以应对应用的负载等。这样的能力可以概括为自调优、自适应、自动驾驶(工业界将自动驾驶的标准分为6个级别，数据库界借用了此级别来定义数据库自动驾驶的概念)。
智能运维的表现就是易于管理。云数据库具备自动化异常分析诊断能力，可在运维操作中实现白屏化、智能化、规模化、少人化。
用户对于数据库的申请、创建、监控、报警、故障定位都可以最简单的方式完成，给用户以极致便捷的体验。
能够根据业务的应用负载自动伸缩，具备秒级扩缩容能力，可灵活动态分配或释放资源，结合弹性计费策略，可以大幅度降低用户的使用成本。这一条中部分内容和智能运维重合，但描述问题的角度不同，本条是从系统可扩展性的角度，对云数据库的重要特征进行描述。
业务或系统上云，是购买了一种应对未来的可能。对于正处于业务发展中的商户而言，随着数据的积累在云端可随时扩展存储，也可自由扩展计算节点，这样对于一个从小向大发展的商户而言，是一种最佳的资源利用方式，也是一种成本最低的方式。
而支持这种业务发展的技术，就是弹性伸缩。在弹性伸缩中需要考虑事务执行的先后次序，这个次序对于数据库架构而言，就是存算分离。
支持按量(如流量、存储量、调用次数、调用时长、核数、内存资源占用量等)制定多种定价策略，使用户可根据业务情况灵活匹配出最优计量模式，节约用户成本。
云数据库采用共享池化技术来提高计算、存储、网络等资源的利用率，隔离用户对资源的并发争用;另外提供多租户方式以做到安全隔离，避免信息泄露或遭受攻击等。
上述内容为云数据库的设计指出了方向。
Serverless是一种无服务器架构，其不是一个具体的编程框架、工具，而是一种软件系统架构思想和方法，其核心思想是让用户无须关注支撑应用服务运行的底层主机，用户可根据应用需要，按需使用底层服务器(硬件以及软件系统)，并根据使用量付费。Serverless类应用所需要的计算资源由底层的云计算平台动态提供。
云原生数据库作为后台服务，其提供一种数据库服务/访问方式连接用户，该方式即是Serverless方式。但是，Serverless不只是连接数据库的一种服务方式，还是连通其他各类服务的一种方式。Serverless与云数据库都是一种服务能力。云数据库把数据存储、管理、计算能力转化为服务提供给用户。
具备了Serverless能力的数据库系统，在存储层面要解决无限量的数据存储能力;在计算层面，要提供弹性计算的能力;在系统内部的架构方面，要提供监控调度能力，使资源分配可动态进行;对于数据库的各个组件，要有可被池化的能力，即具备自动资源管理的能力;对于用户接入层面，要能响应用户接入的事件请求，根据访问量，利用前述的存储、计算、管理的基础进行弹性扩缩容以应对应用层的波峰或波谷，按量计费。
如果云数据库具备了无服务器架构的能力并可支持依赖于数据库Serverless类的应用，则该数据库就可称为ServerlessDB。而云数据库在构建Serverless能力时，应具备如下特性。
- 单一职责：该云数据库的业务是独立的，负责的团队是自主的。云数据库负责单一的服务且该服务处于核心领域。该云数据库具有高内聚、低耦合、与其他系统和领域有明确边界的特点。
- 轻量级通信：云数据间的通信应该简单、轻量，且与语言和平台无关。
- 独立性：该云数据库应是独立开发、独立测试和独立部署的。
▲图1 Aurora数据库具备有Serverless的能力
在应用层，形式上Aurora可以通过函数或事件的方式接入服务平台。如AWS的API接口会触发AWS的Lambda函数或者无服务器函数，这些函数再从数据库表中获取数据流，返回应用时数据的格式是固定的。不同云计算厂家有不同的设计方案， 但使用的思想是类似的。
原文来自：
本文地址：//q13zd.cn/cloud-computing-and-database.html编辑：KSJXAXOAS，审核员：清蒸github
Linux大全：
Linux系统大全：
