✍️
HyperGraph-Decentralized Data Engine
  • 欢迎了解 HyperGraph
  • 💰Farm - 挖矿帮助
    • 了解挖矿
      • DeFi挖矿的本质
      • 挖矿需要的准备工作
      • DeFi挖矿与其他挖矿的异同
      • 挖矿产出、轮次
      • 矿池介绍
    • 钱包基本操作
      • 火币钱包注册Heco地址
      • TokenPocket(Heco)
      • MetaMask 的网页版
      • MetaMask 连接 Heco 主网
      • BitKeep 钱包
    • 挖矿资产准备
      • 如何转入HT或者其他主流资产
      • 兑换所需币种
      • 添加流动性
    • 质押挖矿
    • 常用术语
    • 合约操作
      • 合约操作介绍
      • 合约操作环境准备
      • 合约数据读取
      • 合约写操作执行
  • 🛠️Product - 产品帮助
    • 产品使用篇
      • HyperGraph 的产品业务
      • 控制台注册与登录
      • 添加子图
      • 查看子图
    • 程序开发
      • 业务交互流程
      • 快速入门
      • 远程部署
      • 开发部署 FAQ
      • 子图开发
      • GraphQL API
      • AssemblyScript API(一)
      • AssemblyScript API(二)
    • 项目范例
      • Uniswap subgraph 范例
      • Uniswap-info 范例
    • 常用子图
    • 服务用户
  • 🪜HyperBridge
    • HyperBridge
    • Token 跨链
    • 主流跨链
    • 主流流动性提供
    • 主流购买Gas
  • 🧩 Network - 节点网络
    • 总体介绍
    • 网络建设
    • 节点角色
    • 节点设备
    • 节点查看与管理
    • 节点托管类型
    • 定价方案第二版
    • 节点网络 FAQ
    • Heco 网络公开归档节点
  • 📖 INTRODUCTION - 项目介绍
    • HyperGraph 简介
    • HyperGraph 优势
    • 跨链支持
    • 常用合约地址
    • 通证分配
    • HyperGraph 审计报告
  • 🔬DApp开发教程
    • DApp开发基础认识
    • 开发前的准备
    • 基础开发环境
    • Web3与Solidity基础
    • ERC720 开发实例
    • ERC721 DApp 开发实例
  • 🔗 Links - 其他链接
    • HyperGraph 官网
    • HyperGraph White Paper
    • HyperGraph 挖矿页
    • Heco 区块浏览器
    • BSC 区块浏览器
    • English Document
Powered by GitBook
On this page
  • 节点托管类型
  • 服务质量要求

Was this helpful?

  1. Network - 节点网络

节点托管类型

虽然开发团队会逐步和尽量让节点的软件安装、监控更为自动化,但是作为互联网设备,不可避免会存在问题需要处理,所以每个节点存在一定的运维管理工作。

而不同节点的技术储备也各不相同,比如有的节点可能本身就提供过互联网服务,有服务器和技术人力,有的节点可能根本不懂技术。但是为了保证HyperGraph网络的整体稳定性并给HyperGraph用户提供一致的服务,对服务的响应速度和质量,以及标准化程度都有相当的要求,所以针对这种情况,对节点的托管以及服务等级做出界定。

节点托管类型

1、全托管

全托管是节点报名之后,协商采购完成服务器,除了硬件升级需要继续参与之外,对于软件的安装维护、服务的稳定性监控,完全不需要参与管理,甚至都不需要登录服务器。

但节点仍可以通过节点的后台查看节点的统计,也可以可选获得云平台子账户,通过分配的子账户在云服务器后台来获得服务器的配置以及运行状况,为了避免对服务造成不稳定因素和留下安全隐患,不能登录服务器和管理服务器。

在这种托管类型下,节点只需要关注自己的统计与业务量,而不需要关心服务器的运行情况,因此也不需要技术人员,节点发起人也不需要懂技术。

目前对于服务器全托管,开发团队不收取额外技术支持费用。

2、半托管

半托管是有一定云平台使用经验的节点,自行在指定的机构区域采购节点,所以加入网络的方式,也可以统一采购,通过分配子账户的方式得到服务器。因为涉及到同RPC节点大量的数据交互,所以必须在RPC节点相近的位置采购节点,否则节点将无法运转。采购完成后, 就由开发团队接手,对软件进行安装,对运维进行管理。双方均可以登录和管理节点服务器,节点可以自行对设备进行扩容,可以自行重启和停止服务器。

节点通过节点的后台查看节点的统计,也可以获得云平台子账户或者自行通过云平台,在云服务器后台来获得服务器的配置以及运行状况,但为了避免对服务造成不稳定因素和留下安全隐患,不能随便动服务器的设置,更不能随意重启服务器,哪怕是扩容,也要有开发团队的参与和支持。

在这种托管类型下,节点既可以关注自己的统计与业务量,也可以了解服务器的运行情况,服务配置情况,因此节点发起方需要有人需要对Linux的运维有一定的了解,了解云平台的操作,懂重互联网服务稳定的重要性,并保证该联络技术人员24小时电话能畅通,以联合处理问题,当然,常规的设备情况都会加入自动监控,一般情况下不会有什么问题。

3、全自助管理

全自助管理是指节点服务器从采购到提供服务,全程自助,开发者团队只提供安装程序与脚本,提供软件升级和必要的监控等服务,但是不需要开发者团队有账户,来登录服务器和管理程序,这类操作由节点方技术配合开发方进行。

节点通过节点的后台查看节点的统计,自行了解服务器的配置以及运行状况,但为了避免对服务造成不稳定因素和留下安全隐患,一旦提供线上服务,不要随便动服务器的设置,更不能随意重启服务器,哪怕是扩容,也要有开发团队的参与和支持。

在这种类型下,开发方没有权限登录和管理节点服务器,所以节点全权负责配置升级、扩容和服务管理。因此需要节点方有技术人员能够熟练地操作Linux数据库、Postgres数据库、Nodejs系列开发工具等软件,也了解云平台的操作和配置、扩容等操作,更懂得互联网服务稳定的重要性,节点方必须24小时有人可以接电话来处理问题。

因此为了保证服务质量的稳定性,除非是有经验的节点,否则原则不要全自助管理。

服务质量要求

提供互联网服务,7*24小时,遇到问题,难以避免,但是遇到问题,要能快速地恢复,或者让用户不可察觉,或者有问题影响小,都是处理互联网问题的原则。所以在HyperGraph 服务上,包括但不限于做到以下几点:

  1. 所有服务器核心资源,包括CPU、负载、磁盘空间,超过阈值,每5分钟邮件报警。

  2. 所以核心的服务进程,包括ipfs、graph-node、geth等进程,每分钟监控进程运行情况,如果进程丢失,则自动启动并邮件和短信报警

  3. 对于重点的用户,建议做备份查询部署,对于子图部署在两个以上的节点上,做部署和数据冗余,一旦一个出现问题,建议可以立即切换上线

  4. 对于所有节点的网络连接通,子图查询,以及RPC和子图健康状况,做监控和每分钟邮件和短信报警

做到这些以满足以下服务要求,第一步做到99.9%可靠性的标准,并朝着99.99%的可靠性而努力。这里解释一下这两个数据是什么意思。

在互联网服务领域,有一个词叫SLA,英文是 Service Level Assurance,可以翻译为服务级别。也可以理解为服务的可靠性,一般用百分数来描述这种可靠性。

99.9%的意思是:在99.9%的情况下是可以用的,这是什么概念呢,一年有365天,那么1/1000的情况不可以用,也就是1/3天将不可以用,一天只允许出现8个小时不可以用,算到一天的话,一天86400秒,一天只允许有86.4秒,也就是1分半钟不可以用,其他时间都要求能正常提供服务。这是一个不高的标准,但是也不容易达成。99.99%则属于比较高的标准了,一年只允许不到一个小时的宕机时间。

Previous节点查看与管理Next定价方案第二版

Last updated 3 years ago

Was this helpful?

🧩