分布式数据库架构的复杂性体现在哪些方面？又是如何平衡其易用性的？

使用分布式数据库要提前进行数据库标准的统一和技术的夯实，都要制定数据库开发规范，对数据库进行一些技术要求，比如事务大小的限制，比如禁止存储过程使用，特殊函数的使用， 在应用开发阶段要多采用并发机制，较少串形机制的使用。分库分表架构还有提前规划分片健的设计，较少聚合和复杂查询跨多个节点等。数据库规范统一和标准之后，将数据库的一些复杂处理都上升到应用层面解决，数据库回归到本质的数据存储，后续不管采用什么数据库架构都变得非常轻松。

相较于传统数据库的局限性，分布式数据库在高并发、低延时、海量存储、高可靠性、容灾能力等方面进行了一定程度的提升，以适应并解决现有业务场景越来越极致的功能、非功能需求。传统应用系统起步通常都是典型的三层架构，即展示层、应用层、数据层，其业务实现一般都重度依赖数据库系统，在功能迭代过程中数据处理相关的模块会越来越复杂，并且会强绑定具体的数据库产品特性，因为首要解决的是业务实现诉求。随着数据规模和处理复杂度的不断增大，系统性能、稳定性等非功能表现持续下降，应用系统不得不采用业务垂直拆分、水平拆分等手段进行缓解，但是又会引入新的问题。所以，分布式数据库的出现，其实还是为了解决业务场景上的复杂度，让应用系统在满足非功能需求的基础上能够专注于业务功能的迭代。但是，技术发展还是需要一个渐进的过程，过程中仍然会带来一定的侵入性，主要关注点包括以下几方面：
1.整体架构层面，针对某个系统替换数据库不会对其系统架构有本质的影响（分片键改造除外），但是放眼到该系统在企业架构中的定位以及上下游关系，还需关注是否对数据交换方式造成了影响，特别是分库分表类分布式数据库，需要关注相关产品在数据全量/增量同步方面的能力以及生态，比如我们公司的TiDB通过产品本身+周边工具能够支持上下游数据交换的易用性。如果产品层面无法解决，还需应用侧通过后置库汇聚、下游系统增加数据整合能力等方式实现
2.数据处理规范层面，这一点非常重要，为了减少对特定数据库产品的依赖，应在技术标准层面提前进行约束和规范，如字符集、隔离级别、索引设计（外键限制）、临时表、存储过程、动态sql、事务大小（尤其批量场景）、join的表数量等，以便应用适配提前梳理
3.数据管理/组织层面，这一步与具体的分布式数据库特性有关，对于中间件+单机数据库模式的，需要应用侧明确分片键并进行适配，同时，还需考虑非分片键的反向路由，如果批量场景涉及非分片键情况还会更加复杂，此外还需要避免跨数据节点的聚合查询。对于原生分布式模式的，由于数据库产品已经封装了复杂性，所以应用侧仍以原有方式使用即可，包括一定程度的复杂查询
4.事务一致性层面，同样也需要关注数据库产品是否支持分布式事务，如不支持，也需要应用侧采用补偿、tcc等模式进行补足
5.投产切换层面，对于改造替换类场景，由于一般都会涉及(全量)旧-写读/新-热备、旧-写读/(部分-全量)新-读、旧-写/新-(全量)读+(部分-全量)写、旧-热备/新-写读等阶段，需要考虑不同阶段应用侧的流量切换机制，以及应急场景下的回切，确保整体过程风险可控
6.运行监控层面，由于分布式数据库的架构更为复杂，组件也更多，还需要关注与内部现有监控体系的集成