集群架构的反思

PXC上线平稳运行一段时间后，我们逐步开始认识到PXC在一些痛点上并不能给我们提供帮助，比如：

i.PXC并非Scale Out方案：当单机的容量发生瓶颈时，很难真的依靠PXC做读写能力扩容，因为它和HA的本意是矛盾的。目前我们使用的规模为3台集群，还没有试验过更大规模。

ii．一个大集群VS多个小集群：笔者的理解倾向于把大集群拆分成小集群，标准化做到极致的很多个小集群，在运维代价和灵活性上都有很大优势，笨重的大集群终究是整个系统的瓶颈和要害。

iii．集群数据准入原则：核心集群要尽量精简，包括数据进入、数据访问、复制Slave的引入等。一般的演化是“合久必分，分久必合”，但差别在于后边的合并和集中是更理智，精确可控的集中。

iv．数据访问层的需求： DAL可以作为数据访问的统一入口，方便审计、权限管理、SQL分析、性能统计、下层数据库变更的透明化。

v．非关系性数据的分离：Log、文件、图片、JSON、映射表等非关系型数据，一定要考虑转接到Key-value、文档存储型数据库或服务上。

vi．脑裂：分布式系统必须要考虑脑裂问题。PXC采用Majority Quorum的策略，集群节点数必须为奇数，必须配合VIP的可写探测，才能达到脑裂时自动转接的能力。在平衡复杂性和实际网络稳定性的基础上，我们做了取舍，只使用了只读可达的探测。但当三节点跨DC时，这其中的风险一定要充分考虑。

DBA团队在最初驱动这个项目时真的未曾想到，随着调研和项目的深入，会出现诸多潜在问题和拓展知识需要深入探究，中间更是驱动了全公司北京和纽约等全球各个部门（开发、测试、网络、甚至系统层面）的同事一起协同、有序工作，才真正得以实现。除了技术层面的挑战以外，对于人员之间的交流沟通能力，项目的协调安排，甚至是忍耐和对压力的承受能力都是极大的考验。DBA团队也在这个过程中主动或被动地收获了个人的进步，提高了应对复杂项目的能力。某种程度上来说，改造现有的线上体系甚至比重新建立一个新体系要困难得多。