Flomesh架构、组件与核心概念

整体设计目标

Flomesh的整体设计目标是:

  • 简单的。Flomesh在理解、操作、管理上,应该是简单的

需要理解的是,就像所有工具一样,工具被用来提高工作效率,但是工具并不会降低问题本身的复杂度。Flomesh可以帮助简化服务网格的部署、实现、管理;但是服务网格本身的复杂度并不会降低。

  • 完整的。Flomesh支持企业内部全部应用流量的管理

支持企业“全部流量”是一个非常大的话题,目前我们从常用的应用间流量开始,支持HTTP和RPC类

  • 安全的。Flomesh是安全的,并且可以保护Flomesh上流量的安全
  • 跨地域。Flomesh可以跨地域、跨数据中心使用
  • 普适的。Flomesh不绑定到特定的微服务框架和架构上
  • 云原生的。Flomesh可以部署到任意的云环境,是无状态的、是弹性的、是面向多租户自服务的

整体架构设计

针对这样的目标,Flomesh设计参考了Google BeyondCorp的整体架构,整体方面包括如下三大类组件:

  • 中央控制器(CCP=Central Control Plane)。
  • 控制器(Controller)。
  • 数据平面(Data Plane)及访问代理( AP=Access Proxy)。

需要注意的是,我们需要区分Flomesh的整体架构设计和基于Flomesh方案的部署拓扑,虽然他们有很强的关联,但是Flomesh是一个独立软件,这里我们介绍的是Flomesh的架构;对于基于Flomesh的部署拓扑,我们需要根据需求具体分析、具体设计、具体部署。

如果你正在使用快速向导部署出来的环境,那么他的部署拓扑是这样的。

这里是一个可以作为参考的生产部署方案

中央控制器接受用户输入、系统采集数据输入、信任引擎的计算结果作为输入、指标计算引擎的结果作为输入,完成了规则和配置的中央化存储,并且通过GraphQL和控制器对接;同时,中央控制器也和外围的监控、日志、跟踪等系统做只读对接,实现这些数据的中央化展示。中央控制器核心是关系型数据库,外部接口采用GraphQL。中央控制平面是高可用的,是可以跨地域工作的。

在Flomesh所管理的服务网格之内,应用被根据逻辑属性、地理部署属性等划分成若干的“区”,比如一个kubernetes集群可以是一个区、一个数据中心的网关可以是一个区、一个Spring Cloud集群可以是一个区。这些分区,每个分区由一个控制器管理,控制器一方面获取中央控制器的配置、规则、调度,一方面收集、汇总、初加工所管理分区内的数据、状态等。控制器和中央控制平面之间通过GraphQL连接,每一个控制器有独立的配置文件,有唯一的编号。

数据平面访问代理组成。参考BeyondCorp的叫法,我们把数据平面叫做Front Engine(所有的数据接入层整体被成为Front Engine)和Access Proxy(AP在多数上下文里指网关)。数据平面也是分区部署、分区管理、分区运行的,一个分区内的访问代理之间是共享配置的关系。需要注意的是,访问代理并不仅仅是HTTP/HTTPS代理,访问代理也需要处理非HTTP/HTTPS的流量。Flomesh在AP这个组件的部分,采用了可插拔的设计:通过实现不同的适配器,可以管理不同的AP;一方面Flomesh的设计是组件功能尽可能单一,另一方面相同功能的AP组件在实现上有很多选择,有时候需要根据客户实际情况来选择不同的AP。这个部分在下文有详细讨论。

整体架构

模型与核心概念

如上描述,Flomesh采用“控制平面”(中央控制器)和“数据平面”分离的设计模式;在此基础之上,应用被按照逻辑和物理的划分成了若干的“分区”,每个分区有自己独立的“控制器”,“管理平面”和“数据平面”通过“控制器”进行耦合:

  • 配置与规则下发:
    • 管理员或者租户,在控制平台完成配置
    • 控制器从控制平面获取配置,并且完成对数据平面的配置
  • 监控数据、状态采集与汇报:
    • 控制器采集和获取数据平面的状态,比如网关是否可用,该类信息上报给控制平面
    • 控制平面根据监控规则,产生相应的事件;事件引擎完成事件处理,比如通知管理员,或者触发自动化运维操作

基于这个模型,我们利用一个模拟场景来介绍核心概念。在这个模型中,有两个微服务集群,一个是“订单服务”,以SpringCloud Fat Jar的方式运行在aws的多台虚拟机中;一个是“支付服务”,以容器打包的php程序方式运行在阿里云的容器平台上。当用户从手机APP(我们称这个APP为XAPP)提交订单的时候,订单首先访问“订单API”,该API实际提供者是“订单服务”,“订单服务”会调用“支付服务”。Flomesh用如下的概念描述这个场景:

  • 控制平面 -- Aiur。Aiur是Flomesh内部的一个组件,采用nodejs开发,数据存储在关系型数据库和NoSQL中。Aiur提供了图形界面给管理员和租户进行操作;Aiur也提供了GraphQL的接口。核心的配置数据存放在关系型数据库中,aiur支持大多数的关系型数据库,默认情况采用SQLite,生产环境推荐使用PostgreSQL;日志、监控、跟踪等数据,则存放在NoSQL中,比如ElasticSearch或者ClickHouse

Aiur这个名词的来历是星际争霸游戏中神族的母星,Aiur的开发者是游戏爱好者; ) aiur截图

  • 控制器 -- Fort。Fort是Flomesh的一个组件,采用nodejs开发,除了配置文件外,fort不使用任何存储。Fort和Aiur之间通过HTTP+GraphQL进行通讯;对于生产环境而言,该通讯链路建议采用双向HTTPS的方式连接 fort-config截图

  • HTTP网关 -- Kong。Kong是一个开源的HTTP网关,以Nginx为基础,采用OpenResty框架开发;Kong采用了插件结构,非常灵活,并且社区活跃。Flomesh利用Kong来管理HTTP/HTTPS流量。Kong是数据平面的一部分。Fort会从Aiur获取配置信息,然后调用Kong的REST Admin API来配置Kong

kong

  • 非HTTP网关 -- Piped。Piped是Flomesh团队用C++开发的一个网关,用于处理非HTTP/HTTPS的流量,比如gRPC和Dubbo RPC等。同时Piped包含了一个内置的监控指标计算引擎,网关(包括Kong和Piped)的监控数据,首先收集到piped完成第一次计算;然后发送给全局的监控平台Prometheus。通常Piped和Kong是一起部署的,也就是sidecar的方式。Piped也是数据平面的一部分。Fort从Aiur获取配置信息,通过修改配置文件来配置Piped。同时Piped收集的监控和状态数据,也会发送给Fort,Fort再进一步发送给Aiur

piped配置

  • 分区 -- Zone。在这个模型中,“订单服务”集群就是一个zone,这个zone包含了服务注册中心(比如Eureka)和实际运行的服务进程(比如jvm)。支付服务集群是另外的一个“分区”

zone

  • 项目 -- Project。在Flomesh中,“项目”用来分组资源,并且访问控制都是基于“项目”的。在这个案例中,我们把订单、支付、网关这三个分区都放在“DemoProject”这个项目中,然后对不同的角色做权限分配和访问控制

project配置

  • 应用 -- Application。在Flomesh里,组织外部的请求发起方,我们称为“Application”。在这个例子里,Application就是XAPP

app配置

  • API。在Flomesh里,API是一种逻辑上的定义,比如“订单提交接口”,“订单查询接口”等。API首先定义了如何访问,比如通过URL https://aws.demo-company.com/order/create访问;其次API定义了访问所需要的认证,比如JWT。当“应用”需要访问某个API的时候,这个应用需要首先“订阅”这个API,比如XAPP订阅“订单提交接口”。在确定了订阅关系后,Flomesh可以给“应用”分配具体的访问信令 -- Credential,比如给XAPP发放一个JWT的Token

api配置

  • 服务 -- Service。在例子中,订单服务集群和支付服务集群里边的服务,被注册到Flomesh中。可以认为,Flomesh所管理的微服务集群中的“服务”(比如Eureka中的服务)被“注册”到了Flomesh中成为“Flomesh的服务”。当然,对于非微服务环境,也是可以注册到Flomesh上作为“服务”,比如例子中采用PHP开发的支付接口程序

service配置

  • 订阅 -- Subscription。如上,一个应用在使用一个API的时候,需要先完成“订阅”。“订阅”是一种关系

subscription配置

  • 绑定 -- Bind。API定义了应用网络的逻辑上的接口,比如对于HTTP入口就是一个URL;而API的实现,就是“服务”,我们可以定义API上的规则,让符合规则的请求到达指定的“服务”。这种API和服务的映射关系,就是“绑定”。这种把接口是实现分开的设计,是为了实现如下一些场景:
    • API有多个版本,不同版本的实现是不同的,而这些版本是同时运行的,或者不同版本之间有时间上的交叠
    • 为了跨地域高可用,同一个API需要部署到超过一个数据中心,Flomesh需要根据条件路由流量(比如主数据中心出现故障,切换流量到从数据中心)
    • 就近服务,来自不同地域的请求,需要被路由到最近的数据中心
    • 灰度发布等发布的实现。同一个API的流量,在两个版本的实现上按条件比例切换

核心概念