现在业务上云，已经是一个很普遍的事情了，而目前传统业务上云的时候，大部分是先将非核心业务（包括数据库如oracle,mysql）迁上去；对应的核心业务，可能更多是是将WEB端迁上去，而库端还是用的物理机搭存储的集群模式如RAC。随着大数据，分布式技术的演进，政企部门，在下一代的服务架构（典型如微服务架构：见备注1）转型要求下，需要基础软件和数据平台能够实现原生的云化，以满足更新的需求。
一个比较重要的思潮就是数据库（持久化）和缓存开始有明确的分离——我觉得这个趋势是从 memcached 开始的。随着业务的并发越来越高，对于低延迟的要求也越来越高；另外一个原因是随着内存越来越便宜，基于内存的存储方案渐渐开始普及。当然内存缓存方案也经历了一个从单机到分布式的过程，但是这个过程相比关系型数据库的进化要快得多。这是因为 NoSQL 的另外一个重要的标志——数据模型的变化——大多 NoSQL 都抛弃了关系模型，选择更简单的键值或者文档类型进行存储。数据结构和查询接口都相对简单，没有了 SQL 的包袱，实现的难度会降低很多。另外 NoSQL 的设计几乎都选择牺牲掉复杂 SQL 的支持及 ACID 事务换取弹性扩展能力，也是从当时互联网的实际情况出发：业务模型简单、爆发性增长带来的海量并发及数据总量爆炸、历史包袱小、工程师强悍等等。其中最重要的还是业务模型相对简单。此类代表数据库有HBASE,MongoDB,memcached,Redis,Cassandra。
但是，传统业务是不会被消灭的，OLTP任然是一个重要的业务方式。2012 年 Google 在 OSDI 上发表了 Spanner 的论文，2013 年在 SIGMOD 发表了 F1 的论文。这两篇论文让业界第一次看到了关系模型和 NoSQL 的扩展性在超庞大集群规模上融合的可能性。
Spanner 和 F1 有以下几个重点：
完整的 SQL 支持，ACID 事务；
弹性伸缩能力；
自动的故障转移和故障恢复，多机房异地灾备。
云数据库（newsql）的技术需求也慢慢的有清晰的定义。
- 弹性扩张能力：数据库容量需要根据业务弹性扩展，满足不同业务的容量需求；
- 弹性部署与随需应变能力：除了数据库的存储，其他数据库功能也需要根据应用的需求，进行弹性的部署调整；
- 数据可靠性与服务持续能力：数据的可靠安全，全时在线是所有业务的必须要求；
- 计算存储分离：将计算和存储资源灵活配置，既可以选择多种计算方式也可以同时对应多种存储方式，满足更多业务需求；
- 多模式存储能力：结构化、非结构化、半结构化和图等多类型数据的存储；
- 自我管理能力：提供零停机维护、持续集成、以及滚动升级能力，提升开发人员效率；
- 自我监控以及问题修复能力：故障监控和问题修复，降低运维成本；
- 是否满足特定应用场景：针对特定场景的可插拔组件或工具；
- 监管与安全：满足监管的要求，保证数据的安全。
云数据库架构方向
1）存储-SQL 分离
存储-SQL分离架构，即指数据库的存储引擎和SQL引擎两部分互相松耦合独立工作的架构。通常这一架构，分为存储、SQL和元数据 三个部分。
· 存储层：即数据库的存储引擎，存储引擎负责处理数据的存储管理。同时包含路由及事务控制，保障数据的ACID特性。此外，存储层还应还具备索引、查询条件过滤、排序等一系列功能。
· SQL层：SQL层主要负责处理SQL请求，上层直接面对应用程序，将应用程序的访问请求分发给存储层，并且接受存储层返回的数据结果。
· 元数据区：元数据区负责存储整个数据库的所有元数据信息。
2）多模Multi-Model
数据库多模Multi-Model是指同一个数据库支持多个存储引擎，可以同时满足应用程序对于结构化、半结构化、非结构化数据的统一管理需求。
通常来说，结构化数据特指表单类型的数据存储结构，典型应用包括银行核心交易等传统业务；而半结构化数据则在用户画像、物联网设备日志采集、应用点击流分析等场景中得到大规模使用；非结构化数据则对应着海量的的图片、视频、和文档处理等业务，在金融科技的发展下增长迅速。
多模式数据管理能力，使得金融级数据库能够进行跨部门、跨业务的数据统一存储与管理，实现多业务数据融合，支撑多样化的金融服务。
在架构上，刚刚提到的多模Multi-model也是针对云数据库需求的，则使得数据库使用一套数据管理体系可以支撑多种数据类型，因此支持多种业务模式，大大降低使用和运维的成本。
3）灾备和多活
数据节点切换，甚至数据中心灾难接管的过程当中做到应用透明无感知。多活相比于传统的高可用来说，不仅在性能和安全性上实现了更大的提升，而这一架构也能在多活数据中心中充分的应用软硬件设备，减少冗余。
云数据库架构优势
在技术驱动的需求下，云数据库架构具备了几项主要的业务价值：
· 无需分库分表：此前，一种数据库分布式改造的方向是关系型数据库往分布式架构改造，MySQL分库分表就是其中一种方案。如今，存储-SQL分离的架构，在数据存储层已经实现原生分步实施，就避免了复杂冗长的“分库分表”方案。
· 灵活支撑业务需求：存储和SQL层都可以实现服务、存储的弹性调整，灵活地支撑业务的需求。
· 多存储引擎兼容：由于SQL和存储层的分离，在保持SQL接口不变的情况下，底层存储引擎可以支撑多个不同引擎，实现多种数据引擎的同时兼容。
· 完全兼容已有应用：由于SQL层更多使用已有的标准SQL解析器，因此对于原有应用在SQL上可以实现完全的兼容，没有任何应用改造的投入。
· 数据安全可用：分布式的存储和松耦合的架构，数据拥有安全的多副本，松耦合则大大增强了整个系统的容错性。相比传统单点架构，可以很好的实现数据双活甚至多活的架构，满足“两地三中心”“三地五中心”的合规监管安全要求。
备注1：
微服务microservice
微服务是指提供单个业务功能的服务，从技术角度看就是一种小而独立的处理过程，类似流程概念，能够自行单独启动或销毁，拥有自己独立的数据库。
部分参考：http://blog.sequoiadb.com/cn/Detail-id-73