作者：乔雷，Vesoft.Inc 云原生技能专家
NebulaGraph 介绍
NebulaGraph 是由杭州悦数科技有限公司自主研发的一款开源分布式图数据库产品，擅长处理千亿节点万亿条边的超大数据集，一起保持毫秒级查询延时。得益于其 shared-nothing 以及存储与核算别离的架构规划，NebulaGraph 具有在线水平扩缩容才能；原生分布式架构，运用 Raft 协议保证数据一致性，确保集群高可用；一起兼容 openCypher，能够无缝对接 Neo4j 用户，下降学习及迁移本钱。
NebulaGraph 经过几年的发展，目前现已构成由云服务、可视化东西、图核算、大数据生态支撑、工程相关的 Chaos 以及功能压测等产品构成的生态，接下来会围绕云服务打开，共享落地过程中的实践经验。
交给形式
NebulaGraph 在云上的交给形式分为自管形式、半保管形式与全保管形式三种。
自管形式
自管形式依据各家云厂商的的资源堆栈编列产品交给，例如 AWS Cloudformation、Azure ResourceManager、Aliyun Resource Orchestration Service、GCP DeploymentManager 等等。自管形式的特点是一切资源布置在客户的租户内，用户自己运维办理，软件服务商负责将产品上架到 Marketplace，依照最佳实践给客户供给服务装备拼装和一键布置的才能，相比于传统形式下以天计的交给周期，现在几分钟内就能够在云上布置一个图数据库。
半保管形式
半保管形式是在自管形式的基础上为客户供给了代运维的才能，阿里云核算巢经过将使用发布为服务的办法，为服务商供给了一个智能简捷的服务发布和办理渠道，掩盖了服务的整个生命周期，包括服务的交给、布置、运维等。当客户的集群出现问题时，服务商运维人员的一切操作均被记载，资源操作经过 ActionTrail 记载日志，实例操作保留录屏，还原运维过程，做到运维安全合规可追溯，防止服务纠纷。
NebulaGraph 采用存储与核算别离的架构。存储核算别离有许多优势，最直接的优势便是，核算层和存储层能够依据各自的状况弹性扩容、缩容。存储核算别离还带来了另一个优势：使水平扩展成为可能，经过核算巢供给的弹性弹性才能，保障本身扩缩容需求。
全保管形式
全保管形式交给由服务商保管的图数据库产品，客户按需订阅付费，只需挑选产品标准与节点，NebulaGraph 全栈产品便可在几分钟内交给。客户无需重视底层资源的监控运维，数据库集群的稳定性保障作业，这些都将由服务商处理。
NebulaGraph DBaaS 依托于 Kubernetes 构建，Kubernetes 的架构规划带来以下优势：经过声明式 API 将整体运维复杂性下沉，交给 IaaS 层完结和持续优化；笼统出 Loadbalance Service、Ingress、NodePool、PVC 等方针，协助使用层能够更好经过事务语义运用基础设施，无需重视底层完结差异；经过 CRD（Custom Resource Definition）/ Operator 等办法供给范畴相关的扩展完结，最大化 Kubernetes 的使用价值。
落地实践
落地实践首要叙述全保管形式产品的架构演进，云原生技能与事务渠道的融合。
IaC
下图是 Azure 事务侧基础设施的架构，初始装备时对接到办理渠道需求耗时几个小时，这在有很多用户申请订阅实例的状况下是完全不能承受的。
因而，咱们想到了将基础设施模板化，先界说出 dev、test、prod 三种运转环境，再将资源划分为 VPC & Peering、Private DNS Zone、Kubernetes、Database、Container Registry、Bastion 等几个类别，运用 terraform 完结自动化装备。可是，仅完结这一步是远远不够的，为了满意客户侧 Kubernetes 集群及时弹性要求，咱们界说了 Cluster CRD，将 Cluster 的一切操作放入 Operator 里履行，terraform 的可履行文件与模板代码打包到容器镜像后由 Job 驱动运转，Operator 向 Job 注入云厂商、地域、子网等环境变量，事务集群的状况保存到 Cluster Status 里。到此，装备基础设施完结了手意向自动化的演进。
Operators
红帽出品了一本关于 Kubernetes 规划形式的书本 《 Kubernetes Patterns 》，重视这个范畴的同学想必不会生疏，这本书的出现是针对目前云原生时代的规划形式，之前的规划形式更多的是对单个模块或是简单体系的，可是云原生时代的开发办法和理念与之前的主机开发形式仍是存在很大差异的。
在 DBaaS 渠道上线初期，创立一个订阅实例大致由以下流程构成：
咱们在数据库里界说了 Task 表，包括 succeed、failed、running、pending 四种状况，每个订阅实例流程的使命节点状况会存储到 Task 表。服务发动后会拉起一个监控线程，它首要负责定时查看订阅实例状况，当订阅实例状况反常后会发送告警通知，然后依据预期的状况履行恢复使命。订阅实例的生命周期办理是一个长耗时的异步使命，这里涉及基础设施资源办理，事务数据的更新等步骤，针对反常状况下不同流程的恢复处理导致事务逻辑复杂，后期再保护的本钱逐渐添加，因而，咱们对服务做了拆分重构。
咱们先行调研了作业流编列体系，比方 Uber 的 Cadence，基础设施编列范畴的老练事例有 Banzai Cloud，Hashicorp，可是也因引进三方体系带来额外的运维本钱。
另一套计划依据 Operator 的规划形式完结，中心原理是循环操控和谐，直到运转成功，将每个订阅实例的办理流程放入和谐器里，实例状况保存到到 Status ，渠道事务层模块驱动 Operator 并同步各种 Event。最终咱们挑选了依据 Operator 的完结计划，将各种长耗时的使命剥离出来笼统为 CRD，一致交由 workflow-operator 来办理。
经过重构后，订阅实例的生命周期办理十分简练，复杂度大幅下降。
本钱操控
跟着企业将更多中心事务从数据中心迁移到云上，越来越多的企业迫切需求对云上环境进行预算拟定、本钱核算和本钱优化。同样地，客户也对云上的费用开销反常敏感。
首要，咱们在存储层服务做了优化，经过 NVMe cache 下降存储资费。NVMe 是专门为 NAND、闪存等非易失性存储规划的，NVMe 协议建立在高速 PCIe 通道上。运用NVMe Cache，能够取得相比于平等大小的高功能磁盘不差的功能，而本钱至少能够减少50%。
前次共享有介绍过咱们的日志存储依据 ES 体系，大家都知道，ES 体系存储是十分耗费资源的，因而咱们对事务渠道的使用日志存储做了优化。首要是对 filebeat 做了定制开发，支撑多家云厂商的方针存储服务，改造 Rotater 支撑文件顺序索引，能够依照行数切开文件；依据 fsnotify 库监听文件事情，将切开出来的小文件上传到方针存储；当获取日志时，能够依据 offset 核算出对应的日志文件索引然后快速获取日志。
从用户操控台到数据库的请求链路也做了相应优化。每个云厂商都会为类型为 LoadBalancer 的 Service 或者 Ingress 供给配套的服务组件，这些组件能够处理负载均衡设备装备流程繁琐的问题，经过在 Ingress 资源的 Annotation 里添加几个装备项，就能够轻松拉起一个负载均衡设备。但凡事总有利弊，作为服务商简化了办理，对应的在用户端就会添加资费本钱。别的，在实践的过程中发现每家云厂商对基础设施支撑的完结度不尽相同，综合以上因素考虑，咱们依据 nginx-ingress-controller 做了链路优化，在办理渠道与事务集群打通网络的条件下，经过 External Service 将流量转发到对应的订阅实例。
在开发测验流程上咱们依据 Kubesphere 做了以下尝试。 将基础设施层笼统出 Cloud 接口，里边包括节点池、 负载均衡、DNS 域名等各个子接口，咱们针对本地环境供给 Local Provider 的完结，除非像 Privatelink 比较特别的服务，可是不会影响整体功能测验。
咱们将 Kubernetes 集群分为两种，一类是由云厂商保管的 cloud 集群，别的一类便是自己建立的本地集群，将他们导入到 Kubesphere 一致办理。
操控本钱的中心是资源收回。咱们经过 CronJob 定时创立、毁掉 cloud 类型的开发、测验集群，一起设置 k8s 集群的体系节点池标准满意最小化运转需求，内测期间无拜访流量的实例自动收回，经过这些战略将本钱操控在一个比较理想的状况。
为了给不熟悉 Kubernetes 的同学测验事务流程，咱们为必要的服务组件供给了 helm charts 包，将他们上传到 Kubesphere 使用仓库然后供给使用模板来测验流程。
总结与展望
总结
经过1年多的实践，咱们总结出以下几点心得：
为了满意安全合规、本钱优化、提高地域掩盖性和防止厂商锁等需求，以及客户出于数据主权和安全隐私的考虑，混合云/多云架构现已成为通用处理计划。云原生软件架构的方针是构建松耦合、具有弹性、耐性的分布式使用软件架构，能够更好地应对事务需求的改变和发展，保障体系稳定性。IaC 能够进一步延伸到 Evething as Code，掩盖整个云原生软件的交给、运维流程，开释生产力。本钱优化至关重要，不论是对客户仍是对服务商而言。
展望
在使用研发的过程中，越来越多的开发者承受了无服务器的理念。Serverless 数据库可按需求自动缩放装备，依据使用程序的需求自动扩展容量，并内置高可用和容错才能，采用 Serverless 数据库开发者将无需考虑选型问题，只需求重视如何规划 schema ，怎样查询数据，及如何进行相应的优化即可。对于 NebulaGraph，咱们希望未来能够协助用户完结端到端的 Serverless 架构，进一步提高用户体会。
本文由博客一文多发渠道 OpenWrite 发布！
