共计 4032 个字符，预计需要花费 11 分钟才能阅读完成。
作者：乔雷，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 公布！
