云和安全管理服务专家新钛云服 杨波原创

目录

Gloo学习资源：

引言：

Architechture(架构)

• Component Architechture
• Discovery Architechture
• Deployment Architecture

Concepts(核心概念)

• Virtual Services
• Routes
• Matchers
• Destinations
• Upstreams
• Functions
• Secrets

Traffic Management

• Gloo Configuration
• PetStore精确匹配
• Prefix前置匹配
• regex正则匹配
• 删除route
• Header路由
• Query Parameter路由
• Method路由

Transformations

• transformationTemplate
• Update Response Code
• Extrac Query Parameters
• Update Request Path

Gloo学习资源：

引言：

gloo edge是基于envoy proxy之上的API网关项目，是一个相对独立的系统，支持的平台较多（传统服务、ingress、knative、labmda等），独特之处是在网关的基本功能外，设计了自动发现的函数路由功能，缺点是有开源版和商业版之分，一些高级功能（高级认证、高级定制化限速和人性化管理UI等）只有商业版具备。

初步分析代码结构和依赖，目前相关的项目有两个：gloo edge和envoy gloo，前者主要是go语言开发，插件化设计比较先进和丰富，后者是基于envoy之上的filter能力增强等，主要是C++语言开发，总体来说各种插件和定制化开发入手难度中等，另外一个比较好的优点是文档等参考资料比较全面。

Architechture(架构)

Gloo通过Envoy XDS gRPC API来动态更新Envoy配置, 更方便的控制Envoy Proxy, 并保留扩展性..本质是一个Envoy xDS配置翻译引擎, 为Envoy提供高级配置(及定制的Envoy过滤器).它监控各种配置源的更新,并立即响应通过gRPC更新给Envoy。

Component Architechture

· Config Watcher: 监控Upstreams和Virtual Services配置变化.

· Secret Watcher: 监控敏感信息的配置变化,比如SSL配置信息.

· Endpoint Discovery: 服务注册和自动发现.

如上图kubenetes的Upstream自动发现机制: 通过自己的插件把注册信息写到Endpoint Discovery中,然后Gloo监控它变化,并把这些信息通过自己翻译引擎(Translation Engine)成一个完整的xDS Server快照,传给Envoy,让他构建这个服务的路由规则及过滤器设置.

· Reporter:会收集翻译引擎处理的所有Upstream及Vritual service验证报告.任何无效的配置对象都会反馈给用户.无效的对象会被标记为”Rejected”,并在用户配置中给出详细的错误信息.

Discovery Architechture

Gloo支持k8s, consul的Upstream discovery, 还要以自己开发自定义的组件。

Deployment Architecture

Gloo可以在各种基础设施上以多种方式部署, 推荐是使用kubernets,它可以简化操作.但并不一定要部署在kubernets上.

可到官网查看更多的部署方式。

Concepts(核心概念)

通过下面这个简单的vritual services来理解gloo的核心概念：

Virtual Services

· 将一组路由规则规范在某个或多个域(domains)下面.

· Gloo会建一个默认的virtualService是 default, 它会和*域名匹配.这会把header中没有Host(:authority)字段的请求,及那些不会找不到路由的请求都路由到这个域下面.

· VirtualService都在同一个Gloo必须是唯一的,否则找不到路由.

· 绝大多数实例使用中,让所有路由都放在一个VirtualService下就足够了,Gloo也会使用同一套路由规则来处理请求.如果只有一个VirtualServics时,会忽略header中的Host或:authority头部信息.

Routes

· Routes是VritualServices的核心组成.如果请求与路由上的matcher匹配了,那么它就把请求路由到对应的目的地上.路由由一系列的匹配规则(a list of matchers)及各种目的地组成.

o a single destination 一个目地的。

o a list of weighted destinations 一组有权重的目地的。

o **an upstream group ** 一组upstream。

· 因为多个matcher可以匹配一个请求,所以路由的先后顺序很重要.Gloo会选择第一个与请求匹配的路由.所以必须把匹配任何路径(像自定义的404页面)请求,放在路由列表的最后面.

Matchers

Matchers支持2种请求类型：

· HTTP requests中的请求属性: 对HTTP 来说就是: path, method, header, query parameters, 对应的HTTP2.0 就是header中的:path, :method属性.

· HTTP events根据CloudEvents规范匹配HTTP事件属性.但CloudEvents 规范还处于 0.2 版本，将来会有更改。Event Matcher目前唯一匹配的属性是事件的事件类型（由 x-event-type 请求头指定）

Destinations

· 匹配路由后,要将请求转发到Destinations,它可指向单一的目的地,也可以将路由流量分成到一系列加权的目地的上(a series of weighted destinations).

· Desinations可以是Upstream destination也可以是Function destination.

· Upstream destination类似于Evnoy集群.

· Function destination: Gloo支持将请求路由到各种Upstream中的函数中.函数可以是无服务器的函数调用(Lambda, Google Cloud Function)也可以是REST API OPENAPI, XML/SOAP请求.还可以发布到消息队列中.

Upstreams

Upstreams定义了路由规则最终去向(Destinations).一般是通过服务发现(services discovery)自动加入,最基本的Upstream类型就是静态的Upstream: 它只需要告诉Gloo一个静态主机或dns名列表.复杂的Upstream有kubernets及AWS lambda upstream。

一个简单的Upsteams例子

· name: 如何在Gloo中找到这个upstream.是一个标识符。

· spec: kubernetes插件的serviceName,serviceNamespaces,Gloo路由时需要用到。

Functions

有些Upstream支持函数destinations, 比如: 我们可以在Upstream中添加一些HTTP函数.让Gloo根据这些函数把检验请求参数,然后将传入的请求格式化为Upstream服务所期望的参数.一个简单的示例：

调用curl http://url/petstore/findWithId/100会路由到函数findPetById(id)中,其中Id的是通过parameters中的规则赋值的.

Secrets

· 某些插件(如AWS Lambda Plugin)需要使用secrets来进行身份验证,配置SSL证书和其它不应该存储在明文配置的数据.

· Gloo运行一个独立的(gorutine)控制器来保护Secrets.它有自己的storage layer.

Traffic Management

Gloo核心是一个强大的路由引擎.可以处理API到API的简单路由。

也可以处理HTTP到gRPC协议转换.

得益于envoy proxy灵活的扩展性,gloo中在上面每一个环节中支持的类型都非常多样. 下面以HTTP REST API为例子，演示一下基础路由功能。

Gloo Configuration

Gloo配置布局分3层: Gateway listeners, Virtual Services, Upstreams.大多数情况,我们只与VirtualServices进行交互.可以通过它配置暴露给Gateway的API细节,还可以配置具体的路由规则. Upstream代表后端服务, Gateway控制监听端口,请求的入口.

PetStore精确匹配

Prefix前置匹配

regex正则匹配

删除route

Header路由

Query Parameter路由

Method路由

Transformations

Gloo可以在请求到达到指定的Service前把请求进行任意修改(requestTransformation),也可以在应答返回给Client之前把应答进行任意修改(responseTransformation).

Transformations属性定义在Virtual Services, 你可以在它的VritualHosts, Routes, WeightedDestionations的属性下定义Transformations, 它们的格式都是一样的.唯一的区别是作用的范围大小不一样.所有的子属性都会受到对应的transformations影响.如果你要同时在VritualHosts和Routes都定义了2个transformations,那Routers不会合并VritualHosts,两者各不影响。

· clearRouterCache: 有时transformation会改变路由比如改了path后不应该再到这个路由条件下)后,如果设置为true,则在改变后会重新(根据新的path)找路由,如果是false,则还是走转换前的路由.默认为false.

· requestTransformation和responseTransformation一样的格式,处理方法也是一样的.他有两种形式

o headerBodyTransform: 把所有的header内容json的形式都写到body里面.分成headers及body字段.

o transformationTemplate: 使用转换模板.这是最灵活的.下面会详细介绍属性.

transformationTemplate

Templates是Transformation的核心,本质就是利用上面这几个关键字对Request/Response的所有内容进行任意转换,写出一个你想要的转换函数API.

· parseBodyBehavior: 默认为**ParseAsJson, **json的方式解析body , DontParse: 以`plain text的方式处理.

· ignoreErrorOnParse: 解析body为json时出错是否抛出异常, 默认为false.即抛出异常.

· extractors: 可以提出header及body里面的值作为变量,相当于定义变量,然后变量赋值.

· headers : 注意这里的headers不是extractors中的header, extractors是取值给变量,这里是把变量转换到请求/应答中的头中.

· body: 注意这里的body不是extractors中的body, extractors是取值给变量,这里是把变量转换到请求/应答中的body中.

· passthrough: 完全不想处理body,则设置它为true,这和parseBodyBehavior里面的DontParse有区别.如果完全不想管body,则设置为true, DontParse是以plain text处理.

· mergeExtractorsToBody: 他会把所有extrations得到的变量都合并到body里面.比如:

· dynamicMetadataValues: 动态设置metadata值.因为内置的这些函数和extractor值只能在TransformationTemplate中使用,有时我们需要其它的地方使用,这时间就要需要把在template中得到值赋值到动态的metadata中, 动态的metadata是可以全局使用的.比如:

· 内置函数

除了支持https://pantor.github.io/inja/里面的模板函数,可以写循环,if,math计算.还有gloo自定义函数:

o header(header_name)：返回header中叫header_name的值.

o extraction(extraction_name)：返回extraction中叫extraction_name的值.

o env(env_var_name)：返回环境变量值

o body()：返回body.

o context()：以json的方式返回所有的上下文(几乎是所有信息了,你打出来一看就知道了)。

Update Response Code

Extrac Query Parameters

Update Request Path