2019 年 3 月 23 日,OpenResty 社区联合又拍云,举办 OpenResty × Open Talk 全国巡回沙龙·北京站圆满结束,Polaristech 技术专家刘洋在活动上做了《基于 OpenResty / Kong 构建边缘计算平台》的分享。

OpenResty x Open Talk 全国巡回沙龙是由 OpenResty 社区、又拍云发起,邀请业内资深的 OpenResty 技术专家,分享 OpenResty 实战经验,增进 OpenResty 使用者的交流与学习,推动 OpenResty 开源项目的发展。活动将陆续在深圳、北京、上海、杭州、成都、武汉等城市巡回举办。

image.png

刘洋,Polaristech 技术专家,曾就职于 Redhat、阿里云,10 余年研发经验,近期加入 Polaristech 投入边缘计算领域。作为 RHCA,不仅在 Linux 领域拥有丰富的技术积累,同时在工作中也积累了大量的市场经验。

以下是分享全文:

大家好,我是刘洋,首先介绍一下我们 Polaristech 团队做的几件事情,第一是 Nginx as a Service,因为很多传统的厂商大量使用 Nginx 作为网关,但是流量上来之后管理非常困难;第二是 API 网关,一方面是大家常理解的网关,另外部分是微服务的治理,比如 Service Mesh,我们用提供了一个优雅的方式解决微服务的网关问题;第三个部分就是边缘计算。

边缘计算与边缘节点

什么是边缘节点

始,都可以叫做边缘。相对于传统“中心计算“,数据上传到数据中心,通过中心的资源完成存储和计算。

但随着万物互联时代的到来,智慧城市、智能制造、智能交通、智能家居,5G 时代、宽带提速、IPv6 的不断普及,导致数百亿的设备接入网络,在网络边缘产生 ZB 级数据,传统计算难以满足物联网时代大带宽、低时延、大连接的诉求,在这种情况下,今天的技术架构还能不能支撑那时大家的想象当中的计算机的世界?所以,我们想做一些架构上的创新,或者是尝试。

image.png

”边缘计算“谷歌趋势

上图可以看到从 2015-2019 年,边缘计算的趋势一直往上走。关于边缘计算,有很多定义的方式,首先定义边缘节点:非数据中心的计算资源, 都是边缘节点。需要注意的是作为边缘计算平台,不仅仅由边缘计算节点组成,也包含数据中心的节点,在实际中,我们遇到了许多的边缘节点场景,比如说楼宇、园区、基站、监控设备、车辆等,把这些的非中心的计算资源、网络资源、存储资源都叫做边缘节点。

边缘节点的环境和特点

我认为环境是边缘计算的最大前提,数据中心通常是可靠计算环境,包括电力、网络、温度、专业运维等。如果把计算放到边缘,比如在一个居民楼中有边缘节点,我们总结了几点:

  • 电力不可靠,可能停电或者是插线板坏了。
  • 网络不稳定,带宽没有保障,延迟没有保障。
  • 物理环境缺乏统一的条件,包括温度、湿度、气压等。
  • 算力不统一,今天两核的,明天可能弄一个四核的。
  • 连接方式以 TCP/IP 为主,包括基于移动通信的 4G 和 WIFI,或通过 IoT 的协议 LoRa、NB-IoT 等。

总结起来,边缘节点处于不可靠计算环境中,而且没有专业的运维,在中关村还方便找运维,万一如果在攀枝花、牡丹江呢?不好说。

为什么基于 OpenResty / Kong

image.png

基于数据中心的“云计算”是以“计算资源”为中心的,而边缘计算本质是以“网络资源”为中心的,是面向网络的计算。那么为什么我们选择 OpenResty 和 Kong 为核心来构建边缘计算平台?

第一,因为 OpenResty 是面向应用的网络架构,现在有一个流行词叫做应用交付网络简称 ADN。OpenResty 具有小巧、灵活、可靠、高效稳定的网络处理能力,因为 OpenResty 下面都是 Nginx 非常高效一个包不到 20 兆,基本上可以稳定运行在一切能够支持 Linux 的平台上。

第二,OpenResty 是可扩展的,数据到达边缘节点后,OpenResty 可以把各种数据和常见的计算框架结合起来。

第三,Kong 可以看成是 OpenResty 领域里的 Struts(类比 Java)或者 Rails(类比 Ruby),提供了很多配置能力和开发框架,对于数据的处理非常方便。

第四,OpenResty / Kong 除了适应边缘节点环境,同样适用各种级别数据中心环境。在数据被最终存储之前,OpenResty / Kong 可以构建整个应用数据的传输链路,并完成各个环节的计算任务。

最后,OpenResty / Kong 很“皮实”,基于 OpenResty / Kong 组成的计算节点,可以做到“RESET即恢复功能” 我们希望做到什么?就是若干年前大家去网吧,网管只会一招"重启"。因为在边缘,没有专业的人员,所以希望当这个东西坏了,重启一下就可以恢复了。基于这几点,我们最后选择了 Kong 加 OpenResty。

除了 OpenResty / Kong 还用了什么

首先是使用 CentOS 作为操作系统。PostgreSQL 是 Kong 原生支持的一个数据库,Kong 原生支持两种数据库,一种是 PostgreSQL,一种是cassandra

还有我们自己加了一个MySQL,因为国内 MySQL 的用户群体非常大。PostgreSQL 是我们最常用和主推的数据库,虽然在国内不是特别火,但是 PostgreSQL 会有非常多的支持,效率也很高。

第三个是 RocksDB,主要部署在边缘节点,用于以 k/v 形式缓存数据,包括上行和下行数据。还有是基于 Nodejs 的调度程序,调度程序是边缘计算的核心能力。

最后是 Kubernetes,用于数据中心里计算资源管理,提供多租户的数据中心计算能力。

整体架构

image.png

核心架构图

核心架构采用三层或者是 1+N+1,最上层是数据中心,无论是在自己的本地数据中心里面还是在云上都可以。这一层使用 K8S 做数据的核心应用包括 ESS 和 OSS,做多租户的计量计费、数据的调度、节点管理等,然后是标准的 X86 服务器。

中间是中继节点,它的应用是多种多样的,比如一个小地方的数据中心,或者像一些云厂商,会提供边缘节点,在边缘节点和数据中心之间,上行和下行数据通过一层或者多层的中继节点中转和处理,从中继节点到数据中心很像 CDN,虽然不是专线,但是它的网络质量会比纯公网传输好一些。

最下面是边缘节点,做终端的流量下发以及上行流汇聚,在这一层首先是做静态或者是动态内容的缓存,静态缓存很简单,像 CDN 一样有图片、视频等的缓存,动态缓存是上行请求的数据,它可以把 HTTP body 、head 等缓存在边缘节点,这样就不用再走一遍 CDN 或者到数据中心进行请求了,大大加速用户的访问,同时我们也会用 RocksDB 把数据缓存下来。

总体来讲,首先我们做了集成管理系统,做边缘计算应用的交付与下发并把应用部署到边缘节点上,并对远程边缘的设备的进行管理、监控、调度、计量计费等,核心都是在这个中心系统来完成的。设备管理,主要是对设备状态的管理、应用的下发、配置的下发等。我们基于 HTTP 的框架,去实现边缘节点数据的上下行,特别是上行采取了类似 MQTT 的方式,简称叫 HTTPQ,在本地上传数据的时候先把数据存在 Q 里面。因为网络有可能会断掉,所以会通过 Q 的方式,先把数据放在边缘节点,然后通过 Q 的方式传回数据中心。在边缘用 FASTCGI 的方式,提供一个标准的应用方式,主要还是考虑到了边缘的不可靠环境。最后就是调度、监控和流量分发,也是最主要的核心点。

总结

image.png

我们的边缘计算平台是云计算加边缘计算,既有中心节点又有边缘节点;不同点就在于云或者是数据中心面对的是数据的计算和存储,边缘计算是面向数据流动;另外,常用的数据中心软件,不适合在边缘的环境里应用,它对环境和运维的要求比较高;在面对不确定、不可靠的计算环境,异步很重要,所以我们用 MQ 的方式去做数据的上行; “Reset-To-Work” 这个核心的设计观念,因为管理配置和下发都是通过中心节点做的,边缘节点出现了任何问题,只需重启就可以直接恢复了,因为在中心有对它的监控和配置的集中管理;边缘计算和云计算一样最重要的就是监控加调度,所以我们以网络监控为主去监控边缘节点的可用性,以及缘节点的适用应用、设备、环境、使用率等;系统中云计算是面向 SLA 的,边缘计算是面向流量的:把流量交付出去,和把流量收集上来,是边缘计算的核心述求。如果云计算是一个航母集群的话,那边缘计算就是一把 AK,适应于各种环境,能够用最小的代价去解决最核心的问题。