数据架构的发展
在互联网大数据时代，海量数据的存储只能数据分片与分布式存储，在数据处理时又需读写分离、结果归并到应用服务节点。在云原生与微服务中，以下几种数据库均占有自己的一席之地，没有谁可以代替谁：
- 传统关系数据库的MySQL、PostgreSQL等，节省空间，可联合查询。
- NoSQL的MongoDB、HBase等，具有天生的分布式能力。
- NewSQL的TiDB、ShardingSphere中间件、云数据库。NewSQL数据库与云数据库，很新很强大，但是成熟度不高。
在微服务系统中，数据架构经历了以下几个过程：
- 原始方式，在业务代码中与不同的分片数据库交互，在业务代码中结果归并。
- 侵入式Library，业务代码中不感知分片信息，但不支持跨语言。
- 中间件Proxy模式，独立的中间件服务，支持不同的语言。是目前最流行的大数据架构方案。
- 未来Database Mesh，跨语言，去中心化。
说明：App 1/2/N 表示同一个App服务的多个实例；Shard 1/2/x表示同一个App服务数据的不同分片；Config表示分片元信息的配置、管理与存储。下图中，仅从App 1中画出与数据库交互的路径做样例，App 2/N均与App 1有相同的交互路径。
原始方式
原始方式，只有在大数据时代初期使用到。在没有稳定的传统数据库侵入式分片组件或中间件服务时，为了应用能够快速上线，只能选择这种方式。如今，开源中已有分片中间件，传统数据数据库也提供Cluster方案，不应该选择最低端、副作用最大的原始方式。
侵入式Library
数据分片逻辑与业务代码库解耦，但分片Library更新时，需要更新应用服务。不同语言的应用服务，需要使用不同的分片Library，有重复开发的成本。
中间件Proxy模式（目前最流行）
中间件服务像一个完整的数据库对外提供服务，支持不同语言的客户端服务去访问。可以做到客户端无感知的在线重新分片。
目前，MySQL集群、MangoDB集群、ShardingSphere中间件都是使用这种架构模式。
未来Database Mesh
参考Service Mesh使用容器技术，App与Sharding进程隔离，完全去中心化，避免单点故障。中间件Proxy模式有的优点，Database Mesh都有。对处理大众用户请求的服务，应该确保该架构满足需求。
目前，该方案未有实际的应用，仅在理论与试验层面。
分析海量数据时，计算资源中一般最先不足的是内存。如果把结果归并都放到Sharding sidecar中处理，应用服务节点可能挂掉。因此，我们可能需要如下的架构：结果多级归并。处理冷数据时，选择Hadoop、Spark才是正确的大数据处理方案。
