2019 年 3 月 23 日，OpenResty 社区联合又拍云，举办 OpenResty × Open Talk 全国巡回沙龙·北京站圆满结束，Polaristech 技术专家刘洋在活动上做了《基于 OpenResty / Kong 构建边缘计算平台》的分享。
OpenResty x Open Talk 全国巡回沙龙是由 OpenResty 社区、又拍云发起，邀请业内资深的 OpenResty 技术专家，分享 OpenResty 实战经验，增进 OpenResty 使用者的交流与学习，推动 OpenResty 开源项目的发展。活动将陆续在深圳、北京、上海、杭州、成都、武汉等城市巡回举办。
刘洋，Polaristech 技术专家，曾就职于 Redhat、阿里云，10 余年研发经验，近期加入 Polaristech 投入边缘计算领域。作为 RHCA，不仅在 Linux 领域拥有丰富的技术积累，同时在工作中也积累了大量的市场经验。
以下是分享全文：
大家好，我是刘洋，首先介绍一下我们 Polaristech 团队做的几件事情，第一是 Nginx as a Service，因为很多传统的厂商大量使用 Nginx 作为网关，但是流量上来之后管理非常困难；第二是 API 网关，一方面是大家常理解的网关，另外部分是微服务的治理，比如 Service Mesh，我们用提供了一个优雅的方式解决微服务的网关问题；第三个部分就是边缘计算。
边缘计算与边缘节点
什么是边缘节点
始，都可以叫做边缘。相对于传统“中心计算“，数据上传到数据中心，通过中心的资源完成存储和计算。
但随着万物互联时代的到来，智慧城市、智能制造、智能交通、智能家居，5G 时代、宽带提速、IPv6 的不断普及，导致数百亿的设备接入网络，在网络边缘产生 ZB 级数据，传统计算难以满足物联网时代大带宽、低时延、大连接的诉求，在这种情况下，今天的技术架构还能不能支撑那时大家的想象当中的计算机的世界？所以，我们想做一些架构上的创新，或者是尝试。
”边缘计算“谷歌趋势
上图可以看到从 2015-2019 年，边缘计算的趋势一直往上走。关于边缘计算，有很多定义的方式,首先定义边缘节点：非数据中心的计算资源， 都是边缘节点。需要注意的是作为边缘计算平台，不仅仅由边缘计算节点组成，也包含数据中心的节点，在实际中，我们遇到了许多的边缘节点场景，比如说楼宇、园区、基站、监控设备、车辆等，把这些的非中心的计算资源、网络资源、存储资源都叫做边缘节点。
边缘节点的环境和特点
我认为环境是边缘计算的jiao大前提，数据中心通常是可靠计算环境，包括电力、网络、温度、专业运维等。如果把计算放到边缘，比如在一个居民楼中有边缘节点，我们总结了几点：
- 电力不可靠，可能停电或者是插线板坏了。
- 网络不稳定，带宽没有保障，延迟没有保障。
- 物理环境缺乏统一的条件，包括温度、湿度、气压等。
- 算力不统一，今天两核的，明天可能弄一个四核的。
- 连接方式以 TCP/IP 为主，包括基于移动通信的 4G 和 WIFI，或通过 IoT 的协议 LoRa、NB-IoT 等。
总结起来，边缘节点处于不可靠计算环境中，而且没有专业的运维，在中关村还方便找运维，万一如果在攀枝花、牡丹江呢？不好说。
为什么基于 OpenResty / Kong
基于数据中心的“云计算”是以“计算资源”为中心的，而边缘计算本质是以“网络资源”为中心的，是面向网络的计算。那么为什么我们选择 OpenResty 和 Kong 为核心来构建边缘计算平台？
第一，因为 OpenResty 是面向应用的网络架构，现在有一个流行词叫做应用交付网络简称 ADN。OpenResty 具有小巧、灵活、可靠、高效稳定的网络处理能力，因为 OpenResty 下面都是 Nginx 非常高效一个包不到 20 兆，基本上可以稳定运行在一切能够支持 Linux 的平台上。
第二，OpenResty 是可扩展的，数据到达边缘节点后，OpenResty 可以把各种数据和常见的计算框架结合起来。
第三，Kong 可以看成是 OpenResty 领域里的 Struts(类比 Java)或者 Rails(类比 Ruby)，提供了很多配置能力和开发框架，对于数据的处理非常方便。
第四，OpenResty / Kong 除了适应边缘节点环境，同样适用各种级别数据中心环境。在数据被jiao终存储之前，OpenResty / Kong 可以构建整个应用数据的传输链路，并完成各个环节的计算任务。
jiao后，OpenResty / Kong 很“皮实”，基于 OpenResty / Kong 组成的计算节点，可以做到“RESET即恢复功能” 我们希望做到什么？就是若干年前大家去网吧，网管只会一招"重启"。因为在边缘，没有专业的人员，所以希望当这个东西坏了，重启一下就可以恢复了。基于这几点，我们jiao后选择了 Kong 加 OpenResty。
除了 OpenResty / Kong 还用了什么
首先是使用 CentOS 作为操作系统。PostgreSQL 是 Kong 原生支持的一个数据库，Kong 原生支持两种数据库，一种是 PostgreSQL，一种是cassandra
还有我们自己加了一个MySQL，因为国内 MySQL 的用户群体非常大。PostgreSQL 是我们jiao常用和主推的数据库，虽然在国内不是特别火，但是 PostgreSQL 会有非常多的支持，效率也很高。
第三个是 RocksDB，主要部署在边缘节点，用于以 k/v 形式缓存数据，包括上行和下行数据。还有是基于 Nodejs 的调度程序，调度程序是边缘计算的核心能力。
jiao后是 Kubernetes，用于数据中心里计算资源管理，提供多租户的数据中心计算能力。
整体架构
核心架构图
核心架构采用三层或者是 1+N+1，jiao上层是数据中心，无论是在自己的本地数据中心里面还是在云上都可以。这一层使用 K8S 做数据的核心应用包括 ESS 和 OSS，做多租户的计量计费、数据的调度、节点管理等，然后是标准的 X86 服务器。
中间是中继节点，它的应用是多种多样的，比如一个小地方的数据中心，或者像一些云厂商，会提供边缘节点，在边缘节点和数据中心之间，上行和下行数据通过一层或者多层的中继节点中转和处理，从中继节点到数据中心很像 CDN，虽然不是专线，但是它的网络质量会比纯公网传输好一些。
jiao下面是边缘节点，做终端的流量下发以及上行流汇聚，在这一层首先是做静态或者是动态内容的缓存，静态缓存很简单，像 CDN 一样有图片、视频等的缓存，动态缓存是上行请求的数据，它可以把 HTTP body 、head 等缓存在边缘节点，这样就不用再走一遍 CDN 或者到数据中心进行请求了，大大加速用户的访问，同时我们也会用 RocksDB 把数据缓存下来。
总体来讲，首先我们做了集成管理系统，做边缘计算应用的交付与下发并把应用部署到边缘节点上，并对远程边缘的设备的进行管理、监控、调度、计量计费等，核心都是在这个中心系统来完成的。设备管理，主要是对设备状态的管理、应用的下发、配置的下发等。我们基于 HTTP 的框架，去实现边缘节点数据的上下行，特别是上行采取了类似 MQTT 的方式，简称叫 HTTPQ，在本地上传数据的时候先把数据存在 Q 里面。因为网络有可能会断掉，所以会通过 Q 的方式，先把数据放在边缘节点，然后通过 Q 的方式传回数据中心。在边缘用 FASTCGI 的方式，提供一个标准的应用方式，主要还是考虑到了边缘的不可靠环境。jiao后就是调度、监控和流量分发，也是jiao主要的核心点。
总结
我们的边缘计算平台是云计算加边缘计算，既有中心节点又有边缘节点；不同点就在于云或者是数据中心面对的是数据的计算和存储，边缘计算是面向数据流动；另外，常用的数据中心软件，不适合在边缘的环境里应用，它对环境和运维的要求比较高；在面对不确定、不可靠的计算环境，异步很重要，所以我们用 MQ 的方式去做数据的上行； “Reset-To-Work” 这个核心的设计观念，因为管理配置和下发都是通过中心节点做的，边缘节点出现了任何问题，只需重启就可以直接恢复了，因为在中心有对它的监控和配置的集中管理；边缘计算和云计算一样jiao重要的就是监控加调度，所以我们以网络监控为主去监控边缘节点的可用性，以及缘节点的适用应用、设备、环境、使用率等；系统中云计算是面向 SLA 的，边缘计算是面向流量的：把流量交付出去，和把流量收集上来，是边缘计算的核心述求。如果云计算是一个航母集群的话，那边缘计算就是一把 AK，适应于各种环境，能够用jiao小的代价去解决jiao核心的问题。
