我们希望利用我们十年来构建和运营企业级Cassandra部署的经验，为Apache Cassandra构建世界一流的云原生服务。
我们正在Kubernetes上构建“Cassandra即服务”，也正在积极踊跃地使C*成为世界上最好的开源、可扩展的云原生数据库。
01 云原生的Apache Cassandra
我们希望Apache Cassandra成为云原生。在这个意义上，成千上万的开发者和运营商，以及从初创企业到Apple和Netflix等巨头公司，都和我们站在同一行列。
为了有资格表述这样一个观点，我们做了大量的工作：Astra是建立在Kubernetes、Prometheus和Envoy基础上的，而且参与GKE和EKS的本机控制和管理平面。我们也考量了其他人在这方面做的工作，特别是那些在开源Kubernetes operators方面对Cassandra做出了分享贡献的人们。
为了在云上的Kubernetes大规模运行C*，我们进行了一些必要的技术工作、更改和权衡取舍。在此基础上，我们形成了对于Astra的以上观点。随着我们继续交付和改进Astra，我们的观点将随之演进。
我们通过对C*开源生态系统做出贡献来分享着这样的观点，特别是通过OSS项目（包括Kubernetes operators、管理辅助工具、指标收集器、配置构建器和NoSQL测试系统）。
交流意见的必然结果是倾听他人的意见。在强化Cassandra的提案过程中，我们看到了一系列充满活力而来之不易的经验，这些经验为Cassandra赢来了很多Kubernetes operators。
互相倾听将有利于大家共同思考和合作，以集体的经验来改进我们的主张，并为用户发布更好的代码。
02 我们的关注点
我们已经了解了Apache Cassandra与云部署相关的体系和架构，这有助于我们为社区思考做出贡献。在C* 4.0发布后，我们将必须在架构选择上做出共同的抉择。
在Cassandra的分支中我们已经将部分领会付诸实践，希望将来我们能与大家分享。为了让Cassandra能满足Kubernetes和云原生的特定需求，我们已经尽可能地添加了代码。
使用Apache Cassandra 3.11运行云原生服务需要涉及到四个工作领域：网关，操作，管理和部署。
Astra 在 GKE/GCP 的高层架构
网关(Gateway) 2-1
Astra集群通过网关接收流量。Astra使用Envoy来路由Cassandra二进制端口的请求并简化驱动程序配置。在云原生配置中，拥有单个入口IP对于管理具有弹性后端的连接性是至关重要的。这也减少了开放端口的数量，使Astra能够在云中支持CQL，同时具有弹性和安全性。
Astra还使用网关开放REST和GraphQL API，在与数据资产进行交互时，减轻开发者的负担。我们相信，这些将为新一代开发者在全栈应用程序开发方面提供更好的体验。
操作(Operations) 2-2
集群操作需要自动化。Astra通过一对组件来完成此任务: Cass Operator和用于Apache Cassandra的管理API(MAAC)。Cass Operator是为Apache Cassandra服务的Kubernetes operators。MAAC是Kubernetes的附属工具。
Cass Operator提供了一个由C*节点组成的StatefulSet，并把通常由C*管理员执行的手动任务自动化了。这包括启动集群的开始顺序、在删除节点时排干节点、以及将正确的节点放置在正确的容器中（例如防止多个节点部署到同一主机）。
为了能够优雅地参与Kubernetes环境，我们必须提供对集群状态的洞察力。实际上，这意味着某些以前属于数据库内部的操作（例如自动重试或建立Gossip链接以跟踪内部集群状态）现在要被提升到应用程序层了。
Kubernetes可以根据整个集群的健康状况来做出决策，而不是每个C*节点自行做出独立的决策。例如，在滚动重启时，与其通过内部检查来查看节点是否正常运行，这些信号会发出给Cass Operator，由Cass Operator确保集群中的每个C*节点都能达到超过半数（quorum）要求。
MAAC提供了一个JSON接口来调用nodetool命令并注入Vault机密。C*通过使用标准C*工具来保持操作一致性，感觉更像Kubernetes。该组件负责进行启动、停止、配置和检查活动性和一致性水平的操作。
MAAC作为辅助工具（sidecar）运行，并通过本地Unix套接字（通过mTLS作为可选项）通过CQL与C *通信。每个Sidecar进程仅负责本地C*实例。这就简化了拓扑结构，增强了Cass Operator作为集群协调系统的作用。
管理(Management) 2-3
指标度量对于大规模运行C*是必不可少的。Astra使用Apache Cassandra的Metrics Collector（MCAC）提供与Kubernetes和云环境集成的管理功能。
MCAC简化了Cassandra用户的指标收集。C*中的传统度量标准机制是JMX，它与Kubernetes上部署的性能需求和扩展需求不匹配。我们把MCAC建立在collectd的基础上，并捆绑到Cass Operator中。它适用于2.2至4.0 beta的所有开源Apache Cassandra版本。
使用collectd意味着每个节点可以导出成千上万个指标系列，而对C*的性能影响最小。它与Prometheus（Kubernetes环境中用于监察的标准）保持一致，并且我们可以分析MCAC指标以及operators级别的指标，例如上下文切换、磁盘性能和网络性能。最后，MCAC写出历史日志，记载下度量指标和生命周期事件（例如落盘，压实，异常和垃圾收集）。
MCAC是Astra的一个关键部分，它能够使用户监测到其实例的实时运行特征。Astra可以完善地管理着下面的Cassandra节点的操作，但用户必须了解其数据模型的影响和查询对集群操作特性的影响。
部署(Deployment) 2-4
在Kubernetes环境中部署是连续的。通过将配置更改的控制权交给操作系统，Astra能提供更加动态且可靠的数据层。Astra使用cass-config-builder来驱动配置，并使用NoSQLBench进行环境的连续测试。
Cass-config-builder根据环境要求以参数方式生成cassandra.yaml文件。启动C* 容器时，它会吸收此配置。IP地址、网络信息、性能调整、安全性、磁盘优化和种子提供者都是正确运行C*的关键组件。Kubernetes控制着整个环境，同时在不断地扩大和缩小规模，对硬件故障做出反应，或更改集群范围的属性，因此C*需要采用新的配置与之适应。
为了确保集群的可靠度，NoSQLBench用户能够创建任意大小的合成数据集，并根据实际应用程序的工作负载需要，运用这些数据集进行大规模负载测试。NoSQLBench适用于任何NoSQL数据库。
作为持续部署环境的一部分，数据库的测试自动化可以驱动数十亿次写入和读取操作，大幅减少存储量，并用实际经验展示云环境的优质性能特征。
03 总结
我们希望利用我们十年来构建和运营企业级Cassandra部署的经验，为Apache Cassandra构建世界一流的云原生服务。
从Cassandra用户的反馈中我们看到，Kubernetes需要Cassandra，Cassandra需要Kubernetes。我们正在Kubernetes上构建“Cassandra即服务”，也正在积极踊跃地使C*成为世界上最好的开源、可扩展的云原生数据库。
Cassandra正在成为云原生。很高兴大家能与我们共同走在这一征途上。
Reference:
https://www.datastax.com/blog/why-astra-good-cassandra