共计 4242 个字符，预计需要花费 11 分钟才能阅读完成。
本文是杭州站 Meetup 讲师乔雷依据其分享内容整顿而成的文章。
图数据库是一种应用图构造进行语义查问的数据库，它应用节点、边和属性来示意和存储数据。图数据库的应用领域十分宽泛，在反馈事物之间分割的计算都能够应用图数据库来解决，罕用的畛域如社交畛域里的好友举荐、金融畛域里的风控治理、批发畛域里的商品实时举荐等等。
Nebula Graph 简介与架构
Nebula Graph 是一个高性能、可线性扩大、开源的分布式图数据库，它采纳存储、计算拆散的架构，计算层和存储层能够依据各自的状况弹性扩容、缩容，这就意味着 Nebula Graph 能够最大化利用云原生技术实现弹性扩大、老本管制，可能包容千亿个顶点和万亿条边，并提供毫秒级查问延时的图数据库解决方案。
上图所示为 Nebula Graph 的架构，一个 Nebula 集群蕴含三个外围服务，Graph Service、Meta Service 和 Storage Service。每个服务由若干个正本组成，这些正本会依据调度策略平均地散布在部署节点上。
Graph Service 对应的过程是 nebula-graphd，它由无状态无关联的计算节点组成，计算节点之间互不通信。Graph Service 的次要性能，是解析客户端发送 nGQL 文本，通过词法解析 Lexer 和语法解析 Parser 生成执行打算，并通过优化后将执行打算交由执行引擎，执行引擎通过 Meta Service 获取图点和边的 schema，并通过存储引擎层获取点和边的数据。
Meta Service 对应的过程是 nebula-metad，它基于 Raft 协定实现分布式集群，leader 由集群中所有 Meta Service 节点选出，而后对外提供服务，followers 处于待命状态并从 leader 复制更新的数据。一旦 leader 节点 down 掉，会再选举其中一个 follower 成为新的 leader。Meta Service 不仅负责存储和提供图数据的 meta 信息，如 Space、Schema、Partition、Tag 和 Edge 的属性的各字段的类型等，还同时负责指挥数据迁徙及 leader 的变更等运维操作。
Storage Service 对应的过程是 nebula-storaged，采纳 shared-nothing 的分布式架构设计，每个存储节点都有多个本地 KV 存储实例作为物理存储其外围，Nebula 采纳 Raft 来保障这些 KV 存储之间的一致性。目前反对的次要存储引擎为 Rocksdb 和 HBase。
Nebula Graph 提供 C ++、Java、Golang、Python、Rust 等多种语言的客户端，与服务器之间的通信形式为 RPC，采纳的通信协议为 Facebook-Thrift。用户也可通过 nebula-console、nebula-studio 实现对 Nebula Graph 操作。
多云架构挑战
Nebula Graph 的云产品定位是 DBaaS（Database-as-a-Service）平台，因而必定要借助云原生技术来达成这一指标。到底该如何落地呢？首先要明确一点，任何技术都不是银弹，只有适合的场景应用适合的技术。尽管咱们领有很多可供筛选的开源产品来搭建这个平台，然而最终落实到交付给用户的产品上，还有很多挑战。
这里我列举了三个方面的挑战：
业务挑战
多个云厂商的资源适配，这里须要实现对立的资源形象模型，同时还要做好国际化，国际化须要思考地区文化差异、当地法律法规差别、用户生产习惯差别等多个因素，这些因素决定了须要在设计模式下来投合当地用户的应用习惯，从而晋升用户体验。
性能挑战
在大多数状况下，通过同一云厂商网络传输的数据挪动速度比必须通过寰球互联网从一个云厂商传输到另一个云厂商的数据挪动速度要快得多。这意味着跨云之间的网络连接可能成为多云体系结构的重大性能瓶颈。数据孤岛很难突破，因为企业无奈迁徙格局不同且驻留在不同技术中的数据，不足可迁移性会带给多云策略带来潜在的危险。在单个云厂商中，应用云厂商的原生主动扩大工具配置工作负载的主动扩大非常容易，当用户的工作负载逾越多个云厂商时，主动扩大就会变得辣手。
经营挑战
大规模的 Kubernetes 集群经营是十分有挑战的事件，满足业务的疾速倒退和用户需要也是对团队极大的考验。首先是做到集群的治理标准化、可视化，其次全副的运维操作流程化，这须要有一个深刻理解运维痛点的治理平台，能够解决咱们大部分的运维需要。数据安全上须要思考在没有适当的治理和安全控制的状况下，将数据从一个平台迁徙到另一个平台 (或从一个区域迁徙到另一个区域) 会带来数据安全危险。
DBaaS（Database-as-a-Service）
云原生技术简略概括就是为用户提供一种繁难的、麻利的、可弹性扩大的、可复制的形式，最大化应用云上资源的能力。云原生技术一直演进也是为了用户更好的专一于业务开发。大家能够看到这个金字塔，从 IaaS 到最下面的云原生应用层，产品状态越来越灵便，计算单元的粒度越来越细，模块化水平、自动化运维水平、弹性效率、故障恢复能力都是越来越高，这阐明每往上走一层，利用与底层物理基础设施解耦就越彻底，用户的关注点不再是从硬件服务器到业务实现整个链条，而是仅须要关注于当下业务自身。
PaaS 平台的容器编排零碎是 Kubernetes，自然而然地就能想到基于 Kubernetes 构建这套平台，Kubernetes 提供了容器运行时接口，你能够抉择任意一种实现这套接口的运行时来构建利用运行的根底环境。因而，利用好 Kubernetes 提供的能力，就能达到事倍功半的成果。Kubernetes 提供了从命令行终端 kubectl 到容器运行依赖的存储、网络、计算的多个扩大点，用户能够依据业务场景实现一些自定义扩大插件对接到 kubernetes 平台，而不必放心侵入性。
用户视图
NebulaCloud 目前为用户提供两种拜访形式，一种是通过浏览器进入 Studio 操作窗口，在数据导入后能够做图摸索，nGQL 语句执行等操作，另一种是通过厂商提供的 private-link 买通用户到 NebulaCloud 之间的网络连接，用户能够通过 nebula-console 或者 nebula client 直连到 Nebula 实例。
NebulaCloud 架构
从业务架构上看，NebulaCloud 能够分为三层，最底层是资源适配层，次要负责提供资源层面上的适配，提供对多云厂商、多地区集群、同构或异构资源池的形象形容。再往上是业务层与资源层，业务层涵盖根底服务、实例治理、租户治理、计费治理、数据导入治理等业务模块；资源层负责提供 Nebula 集群的运行环境，在调度策略下提供最佳的资源配置。最上层是网关层，对外提供拜访服务。
NebulaCloud 外部流程
这里以 AWS 为例策略地形容一个 Nebula 集群的创立过程。用户创立实例申请提交后，nebula-platform 服务依据输出的厂商、地区、规格等参数信息做资源调度，比方资源池、负载平衡、安全策略等配置，而后通过 nebula-operator 的 api 实现实例的创立，最初配置 ALB 规定，为用户提供拜访实例的入口。
Nebula-Operator
在 Kubernetes 中，定义一个新对象能够有两种形式，一个是 CustomResourceDefinition, 一个是 Aggregation ApiServer，其中 CRD 是目前支流的做法，nebula-operator 就是 CRD 来实现的。
CRD+Custom Controller 就是典型的 Operator 模式了。通过向 Kubernetes 零碎注册好的 CRD，咱们能够应用 controller 来察看 Nebula 集群以及与它相关联的资源对象状态，而后依照写的协调逻辑来驱动 Nebula 集群向冀望状态转移。这么实现能够把 Nebula 相干的管理工作都积淀到 Operator 里，用户应用 NebulaGraph 的复杂度升高，能够轻松实现弹性扩缩容、滚动降级等外围操作。咱们基于 kubernetes 的 Restful API 生成了一套治理 Nebula 集群的 API，这样用户能够拿着 API 就能实现对接本人的 PaaS 平台，搭建本人的图计算平台。
nebula-operator 目前的性能还在不断完善中，实例的滚动降级须要 Nebula 提供底层反对，预计往年会反对上。
KubeSphere 多集群治理
平台化治理
KubeSphere 衍生自青云私有云的操作面板，除了继承颜值，同时在性能上也是相当齐备。NebulaCloud 须要对接的支流云厂商都曾经反对上，因而一套治理平台就能够运维所有的 Kubernetes 集群。多集群治理是咱们最为看重的性能点。
咱们在本地环境部署了 Host 集群，其余的云上托管 Kubernetes 集群通过直连贯入的形式作为 Member 集群，这里须要留神 ApiServer 拜访配置放通单个 IP，比方本地环境的进口公网 IP。
流程化操作
咱们应用 IaC 工具 pulumi 部署新集群，再通过自动化脚本工具设置待治理集群 member 角色，全副过程无需人工操作。集群的创立由平台的告警模块来触发，当单集群的资源配额达到告警水位后，会主动触发弹性出一套新的集群。
自动化监控
KubeSphere 提供了丰盛的内置告警策略，同时还反对自定义告警策略，内置的告警策略根本能够笼罩日常所需的监控指标。在告警形式上也有多种抉择，咱们采纳了邮件与钉钉相结合的形式，重要紧急的能够通过钉钉间接钉到值班人员，一般级别的能够走邮件形式。
智能化经营
KubeSphere 提供了集群多个维度的全局展现视图，目前治理的集群数量少足够应用。将来随着接入 member 集群数量的减少，能够通过经营数据的剖析做资源的精细化调度和故障预测，进一步提前发现危险，晋升经营的品质。
其余
KubeSphere 还有很多好用的配套工具，比方日志查问、事件查问、操作审计日志等，这些工具在精细化经营都是必不可少的。咱们目前曾经接入了测试环境集群，在深度应用把握 KubeSphere 的全貌后会尝试接入生产集群。
将来布局
咱们将充沛开掘自定义告警策略并加以利用，同时联合 Nebula 集群本身的监控指标打造监控全景图；笼罩外围指标的多级、多维度的告警机制，将危险毁灭在源头；欠缺周边配套工具，通过被动、被动以及流程化等缩小误操作危险；启用 DevOps 工作流，买通开发、测试、预发、生产环境，缩小人力染指。
本文由博客一文多发平台 OpenWrite 公布！
