第一次听到「三及第」这个名字的时候觉得这个名字起的真好，寓意也很棒，一下子就和「状元及第」这个事儿联系起来了，下次如果有考试什么的，考前来喝上一碗哈哈 。这个好像也是地域性非常强的食物，甚至只在广东省内的一部分才有这个食物，深圳这个地方得益于是个移民城市，所以虽然小众但是也能吃到，也有客家同事吃过这里的说是味道也能有个七七八八。

客家

广东有三大民系，潮汕、客家、广府，而且他们都有自己的语系方言：潮汕话、客家话、粤语。这个食物就是属于客家地区的，大致是在广东、江西、福建的三省交界的地方，据说客家地区的早餐、夜宵一般都有这个，一碗三及第汤，再加上一碗腌面作为标准配置。

腌面

一般和三及第汤配在一起的叫「腌面」，最著名的是梅州腌面，这个「腌」字儿呢，不是我们通常理解的那个「腌菜」的腌那个意思，而是在客家话里「腌」的意思是把烫熟的食物加上调料汁，然后用筷子翻拌均匀这一做法，所以可以理解为广东常见的叫法「捞面」，或者更通俗一点叫「拌面」也行。现在外面的除了配腌面，也可以配米饭，或者腌细米粉、腌河粉之类的其他主食。

腌面通常使用的是扁一点的生面条，跟武汉的热干面有个类似的地方就是也是使用的碱水面，做法非常简单，就是把面条煮熟以后，趁热加上猪油、炸的成金黄色的，香香脆脆的蒜末、以及一些葱花，加上少许鱼露或其他生抽之类的调料，还有肉末之类的，用筷子拌匀即可上桌，香味非常浓郁，一定得趁热吃，醇厚香浓的味道才能发挥到最大。

三及第汤

根据广东省人民政府的官网介绍，三及第的由来：

在科举取仕时代，状元、榜眼、探花为 殿试头三名，合称三及第。林召棠（清朝状元）用猪肝、瘦肉、猪肚子三种猪内脏比作三及第，三及第汤由此而得名。

汤底基本上就是使用猪骨高汤，加点酒糟、咸菜一起煮沸，煮沸之后加入枸杞叶，再加上上面说的「三及第」，等到猪杂刚刚熟好，就可以盛出开吃，枸杞叶做汤也是在广东才知道的，枸杞叶竟然能做汤。汤的味道我还记得第一次吃给我的感觉就是一个字「鲜」，一碗汤里也没什么异味、仿佛是把这个猪杂里面的鲜味全部都提取到这里来了，猪杂也是非常嫩爽可口，一点也不柴，当前前提是猪杂得新鲜。

不知道传统的客家的及第汤里有没有「五及第」「六及第」这个说法，还是说这些个超过「三」的如同椰子鸡一样是「深圳发明」，由于没去过客家地区，也暂时无从考证，不过这些也都是在原有的三种内脏上加了其他猪杂来扩充汤的复合味道，也未尝不可。

从小时候起到在很长的一段时间里，「糊饽」这俩字儿我是真的不知道怎么写的，虽然从小到大一直这么叫它，毕竟这个东西更广泛的叫法可能被称作「薄饼」或者「烙馍」、「烙饼」，为了写这篇文章我问了AI才知道这俩字儿原来是这么写。但是它和广义上的「薄饼」还是有点差别的，毕竟它是作为一种像「面条」一样的食物是带汤吃的，通俗点就是把「薄饼」切成宽点的面条状叫「糊饽」。

砂锅糊饽真的是太少见了，上一次吃它应该我都不记得是在初中或者高中了，襄阳牛肉面至少还能吃到，砂锅糊饽真的是完全吃不到了，连卖的都找不到了，我只能回想一下这个面食的味道，不知道这个砂锅糊饽是不是真的只在我们这个南不南北不北的小地方才有。

砂锅

砂锅就是那种最便宜的砂锅，随处可见，颜色有深有浅，丢了也不心疼的那种，带一个长一点的把手防烫。吃的最多的时候就是在上学的路上，尤其是秋冬时候，最喜欢吃这个了，外面的雪刚停，路上还有不南不北地区的半化不化的雪水混合物，踩上去既是「嘎吱嘎吱」又「噗嗤噗嗤」的那种，比正在下雪的时候还冷得多，一大早上六点钟不到就出门上学去，走在路上天都还没有彻底亮，天色就是半墨半留白的，带点脏脏的灰色的那种天。

到学校半路途中常吃的那家砂锅店的灯还亮着，店老板把煮砂锅的整套装备都直接放在门口两排小灶砂锅轮番上阵，整个门头基本都被水蒸气笼罩，光是远远瞅着就感觉气温上升了好几个摄氏度，这个时候来一碗这个还正在沸腾着的砂锅糊饽，一碗下肚从头到脚寒气彻底被驱赶一空，有时候甚至脖颈背后还能有微微出汗的感觉，这也让在这家店过早，成为我们寒冬腊月上学路上必不可少的一项仪式了。

糊饽

炕的有点微微发糊的薄饼，切成大约两指宽，其实这个干的糊饽就是可以直接吃的，只是在砂锅里过了一遍热汤之后，味道会更浓厚了，汤头基本上就是一些调料加上鸡骨头熬成的鲜汤，微微发糊的糊饽直接把汤汁吸得饱满浓厚，有些年纪大一点的喜欢把糊饽在砂锅里煮的软软的，舌头一抿就吸溜下去了。而我还是喜欢有点口感的，等待砂锅里的汤刚刚开，利用余温直接把糊饽过一下就可以端上来了，这样吃起来糊饽的表面上还是有汤的味道，内芯儿里面可以让牙齿过瘾的嚼劲还在。

有时候老板还会允许我们这些学生自己带上几个鸡蛋丢进去窝成荷包蛋，早餐营养直接提升一个层次，其他的配料上都还是常规选项，肉丁、胡萝卜、土豆、豆腐丁儿之类的，辣椒自助，基本也要不了多久就可以干光一整锅。除了砂锅糊饽，还有砂锅面可以选，汤底配菜都一样，只是把糊饽换成了手擀面，有时候糊饽吃腻了，也会换成面来吃一吃。不知道啥时候能再吃一次砂锅糊饽。

还是广西美食，暂时还没跑出两广，也是另外一种口味比较重的美食，也是到了广东才吃到这个粉，而且还是最近几年才吃过的，它的知名程度没有柳州螺蛳粉那么大，可能出了两广基本就吃不到了，而且做这个粉还需要使用小锅烩炒一下，更增加了它推广的难度。由于是现炒现烩的，风味满满、锅气腾腾，基本上算是跟柳州螺蛳粉不相伯仲。最近经常吃的那家老友粉倒闭了，卖老友粉的门店也没那么多，想再吃一下得跑好远。

南宁

提到广西，最出名的应该是「山水甲天下」的桂林，其次是「五菱宏光上山了」的柳州，好多人可能还以为广西的省会是桂林，实际上南宁才是广西的首府，穿插一个小知识，民族自治区的省会一般叫「首府」，南宁也算是一个低调的首府之一。

老友

这俩字的来源是一个温馨的传说：

据说很久以前，一位老翁每天都光顾南宁一家茶馆。有一天，老翁因感冒没去茶馆，茶馆老板便以爆香的蒜末、豆豉、辣椒、酸笋、肉末、胡椒粉等配料，煮了一碗热气腾腾的面条送给这位老友吃。老翁吃后出了一身热汗，病状减轻，这碗饱含友情的面条就被称为“老友面”。后来，这种面条的做法逐渐演变成了老友粉。

我在没听到这个来源传说以前，笃定的认为这个「老友」的意思是指里面的各种猪杂，肉片、粉肠、猪肝什么的它们都是来自于猪身上，算是「老友」，我真的好地狱的想法。

老友粉的做法就是一碗一烩，热锅凉油，放入蒜末，小火慢炒，炒香后放入酸笋，然后放辣椒、豆豉一起翻炒到干爽、炒出酸香，通常会加一些切碎的番茄丁，一起继续翻炒
不过有些人可能是吃不惯带番茄的，在店里点单的时候，会有「去番茄」的选项。炒到差不多的时候，加上生抽、盐、鸡精，加入水，沸腾之后加入肉片或者猪杂划熟，如果觉得不够酸还可以加点醋，最后放入米粉，煮熟后出锅的时候加点葱花，还可以加点紫苏。大功告成，酸辣开胃、汤浓味稠、鲜香扑鼻。

粉

据说以前老友粉是面，后面改成了粉，粉是又宽又扁的，跟广东这边的河粉还是有点差别，不过我吃到的基本就是河粉做的了，河粉这种有棱有角的粉，比圆粉更能挂汤，再加上这个汤本身就够浓，嗦起来那是相当过瘾。

Kong Gateway 3.7 版本已经重磅上线，我们给 AI Gateway 带来了一系列升级，下面是 AI Gateway 的更新亮点一览。
文转载自 Kong Inc 公众号，原文查看 https://mp.weixin.qq.com/s/zMZpuEA1tI0UNlD7X7PP8A

AI Gateway 正式 GA

在 Kong Gateway 的最新版本 3.7 中，我们正式宣布 Kong AI Gateway 达到了通用可用性（GA）阶段。

现在，AI 开发者们可以专注于开发 AI 定制应用，比如利用大型语言模型（LLM）和检索增强生成（RAG）技术打造的聊天机器人，或者其他 AI 集成方案。他们无需再从零开始搭建底层架构，去构建保证 AI 应用在生产环境中安全、可监控的基础设施。Kong Konnect 和 Kong Gateway Enterprise 平台将提供所需的扩展性支持。

此外，Kong AI Gateway 现在也可以作为一个软件即服务（SaaS）解决方案完全部署在云端。同时，Kong 还推出了新的 Konnect Dedicated Cloud Gateways 选项，供用户进行云端部署。

Kong AI Gateway 可以用于广泛的场景，帮助加速新的人工智能应用程序在生产环境中的落地。

对现有的 OpenAI SDK 提供支持

Kong AI Gateway 允许让用户通过 OpenAI API 规范作为统一标准，访问其支持的所有 LLM。

使用开发人员熟悉的 OpenAI API 规范将大大简化大家上手的难度。

并且， Kong AI Gateway 原生支持了 OpenAI SDK 客户端库，进一步简化了构建 AI 代理和应用程序的过程。您只需将请求重定向到指向 AI Gateway 路由的 URL，即可通过 AI Gateway 使用LLM。

如果您已经使用 OpenAI SDK 编写了现有的业务逻辑，则可以重用它来使用 Kong AI Gateway 支持的每个 LLM，无需修改代码，因为它是100%兼容的。

引入流式 AI 消息支持

Kong AI Gateway 已在”ai-proxy” 插件中，对所有LLM引擎加入了对AI的流式交互能力的原生支持。这将解锁更多实时体验，而不用等待 LLM 完成处理后再发送回客户端。

在流式模式下，响应将以词元（token）为单位通过 HTTP 响应块（SSE）逐个发送。用户可以通过设置“ ai-proxy” 的以下属性来启用该功能：

1
2
3
4

config:
  model:
    options:
      response_streaming: "allow"

功能启用后，客户端便可在请求体中显式地进行流式请求，例如：

1
2
3
4

{
  "prompt": "What is 1 + 1?",
  "stream": true
}

凭借这项新功能，Kong AI Gateway 的用户将能够打造更具吸引力和互动性的人工智能体验。

基于 Token 的高级限流能力 (企业版)

我们正在引入一项基于 token 请求量进行限流的企业级功能。通过启用新的“ai-rate-limiting-advanced” 插件，客户可以更好地管理组织中不同团队的 token 消耗水平，从而更好地控制整体 AI 开销。对于自托管 LLM 提供商，当应用程序中的 AI 流量增加时，客户将能够更好地调整其在 AI 基础设施上的流量。

Kong 已经提供了基于发送到 API 的请求数量进行速率限制的 API 速率限制功能。而新版“ai-rate-limiting-advanced” 插件则专注于所请求 AI token 的数量，并不考虑发送给它们原始 HTTP 请求的数量。如果客户希望同时对原始请求和特定AI Token进行速率限制，则“ai-rate-limiting-advanced” 插件可以与标准 Kong 速率限制插件结合使用。

ai-rate-limiting-advanced 插件是目前市面上唯一可以用于 AI 的速率限制插件。

基于 Azure 的内容安全能力 (企业版)

新的企业插件“ai-azure-content-safety”允许客户与包括“Azure AI”在内的多个内容安全服务无缝集成，以验证每个通过AI网关的prompt请求。这项功能也被所有ai-proxy插件的所有LLM引擎所支持。

例如：凭借该功能，客户可以使用 Azure 的原生安全服务策略，在 Kong AI Gateway 中检测和过滤所有不和谐的内容，并将该策略应用于所有 LLM 提供商的prompt请求，以实现内容安全的统一管理。

基于 URL 动态选择 LLM

该特性使用户可以通过客户端请求的 URL 路径动态调用所需的模型。同时，用户可以通过在插件配置中硬编码其名称来使用模型。通过启用此功能，Kong AI Gateway 便可以更容易地扩展到希望尝试各种模型的团队，而无需预先在 “ai-proxy” 插件中进行配置。

该功能可以通过 “ai-proxy” 的新 “config.route_source” 配置参数进行配置。并且，用户只需配置一次，便可使所有模型均通过识别URL路径的方式来动态地、灵活地调用。

支持 Anthropic Claude 2.1 Messages API

Kong AI Gateway 提供一个 API 接口，使用户可以随意调用部署在云端的或自托管提供商提供的模型。该接口在新版本中得到了扩展，以支持 Anthropic Claude 2.1 Messages 这样的通常用于创建聊天机器人或虚拟助手应用程序的API，用于管理用户与 Anthropic Claude 模型（助手）之间的对话交流。

基于用户需求， Kong AI Gateway 将持续增加对更多 LLM 的支持。

更新 AI 用量统计的格式

随着 Kong AI Gateway 进入 GA 阶段，我们已经更新了所有由 Kong 处理的 AI 请求的分析日志格式。

通过这种新的日志格式，用户可以测量 “ai-proxy”，“ai-request-transformer”和“ai-response-transformer” 所请求的每个模型的消耗情况。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

"ai": {
    "ai-proxy": {
      "meta": {
        "request_model": "gpt-35-turbo",
        "provider_name": "azure",
        "response_model": "gpt-35-turbo",
        "plugin_id": "5df193be-47a3-4f1b-8c37-37e31af0568b"
      },
      "payload": {},
      "usage": {
        "prompt_token": 89,
        "completion_token": 56,
        "total_tokens": 145
      }
    },
    … more AI Plugins

这种新的分析日志格式取代了旧的格式，以便企业用户实现更精细化的用量管理。

在之前的《岂因福祸避趋之，跑完还得继续吃》里面有提到过襄阳牛肉面，但是鉴于我真的好久没吃过了，势必是要单独为襄阳牛肉面写一篇。这个面也真的算是比较有特色的了，比如使用的面条是碱面，碗底垫着的是绿豆芽，除了这个面，我去过这么地方还没碰到第二个这么加的。要说口味的话「火锅面」算是跟它比较接近，而且火锅还得必须是麻辣的牛油火锅，就是放冷了会有橙红色的固体油脂封在锅口的那种。

襄阳

我长大的地方算是个三省交界的地方，也没有什么享誉全国的美食特产什么的，但是我一直都挺喜欢隔壁市的这个牛肉面 – 襄阳牛肉面，虽然我并不是襄阳人。其实我一直叫它襄樊牛肉面，没别的，因为从小就这么叫的，那时候知道襄樊这个名字的来源是因为城区是分了襄城和樊城，后来这个牛肉面名字也随着城市的改名也一起改名了。

牛肉

牛肉面里面最有味道的辣卤一般都是在店门头放一口陶锅，两口三口的都有，一口放辣卤的牛肉，一口放卤过的海带豆腐，还有放肥肠的，迎客的硬招牌就从这些陶锅的味道里蔓延开来。小时候吃的更多的是海带豆腐面因为它更便宜，海带也是卤过一遍的，豆腐呢，有些店是直接就用豆腐过卤，我更喜欢的一种是切成豆腐丁之后，过油炸过一道的，每一颗油炸豆腐丁都吸满了辣卤汤汁，顺着碱面一口下去毫不留情，一干到底。

说到底辣卤的卤，精髓还是飘在最外面的那层红油上，红油除了牛油熬制的香味，通常也还会有一些碾碎的辣椒面，比较细的那种，吃完了面，有时候在碗边上还能看到点点斑驳的辣椒面，升华的辣味就是从这里来的。吃完还依旧会回味一下子，吃不惯这个麻味的也挺多的。

面

牛肉面的用料是碱面，跟热干面是一样的，而且我特别喜欢细一点的那种碱面，出了湖北之后真的就没有吃过细的碱面了，太粗的减免咀嚼起来没有那种爽脆感，蔫蔫的黏糊。碱面吃起来的口感更加劲道有嚼劲，刚好我个人也不喜欢那种煮的软塌塌的面。襄阳牛肉面的面一般都是提前煮熟了之后放在那，点单之后用笊篱盛面在沸水中来回浸烫数次，待熟透滚热后迅速盛入碗中即可。通常做襄阳牛肉面的小馆子也会做热干面、汤面之类的，面可以通用嘛。

垫在碗底的豆芽才是一绝，必须是使用的绿豆芽，不需要二次汆烫，直接垫在碗底，面煮好之后直接盖在上面，浇上热汤、辣卤，靠着这些余温直接把绿豆芽烫到将脆不脆。我特别喜欢这个绿豆芽的口感，每次去点的时候我都会嘱咐一下，多放一些豆芽。

看到苹果发的这个Apple Vision Pro，瞬间想到微软当年发布的HoloLens，2015年发布第一代，2019年发布第二代，有幸在2016年的时候，在前公司玩过同事的这个HoloLens的一代产品，当时觉得非常惊艳，现在想来也觉得挺震撼。

苹果的这个新品和HoloLens一样，不单纯的是VR产品，更多的是AR（虚拟现实增强），或者说是更接近与MR（混合虚拟现实增强）？，大致意思就是通过摄像头实时的获取现实中的所有场景，在此场景的基础之上实时建模计算拟合之后再输出。

当时用 这个HoloLens印象最深的就是内置了 一个演示游戏，我带着眼镜看向地面，眼镜就实时建模计算 地面的材质、三维、光照以及周围环境等等信息，然后立马模拟出地面碎裂掉落的场景，实时输出到眼镜画面之上，不过碍于分辨率和计算能力，当时看起来还稍微有点假，不过等硬件和算力跟上去之后，应该会有更多的玩法，也会更加惊艳。

不过一些缺点也是明显存在，重量非常感人，基本就是大半个头盔的感觉，做不了什么太大的动作；戴上之后过一阵子发热就非常严重。二代应该比我当时玩的一代重量和发热控制好很多。

目前微软的这个产品除了给消费者使用，企业级应用也不少[1]，例如应用于航空航天、建筑改造、汽车行业、军事训练与作战[2]，基本上各个领域都有探索与应用。

不知道苹果的这个消费级的能做到什么地步，如果有配套的能特别让人惊艳的游戏或者应用相辅相成，应该会有概率成功，至于能不能引领下一个时代，还是需要加上一个问号。

如果把这类产品加上AI ，《头号玩家》会不会就真的到来了吧！？

参考：

• https://www.microsoftstore.com.cn/vr-and-mr/microsoft-hololens-2-industrial-edition
• https://www.uchstar.com/news_page/247.html

今天在V2EX上看到一个帖子是问怎么灭蟑，想起来与蟑螂对抗这么多年，也走了不少弯路，之前买过城中村的「蟑螂药」「老鼠药」无效不要钱的、也用过拜耳的饵胶、还有蟑螂贴、贴墙上的那种黑色小盒子、虽然都有些效果，不过都是反反复复，不能达到一个持续灭蟑的效果。目前正在使用的灭蟑方案是比较可行的，也已经持续了很长一段时间家里基本看不见蟑螂了。

总结一波使用经验，水一篇文章😁。

呋虫胺

买带「呋虫胺」成分的那种喷剂，或者买粉剂回来自己兑，然后持续喷一段时间就可以了，过一段时间定期喷，基本都能保持住，这个东西算是比较新的技术，目前能应对大部分的蟑螂。

成分或者使用效果在知乎上面有很多介绍，基本就是类似于蟑螂的兴奋剂，所以杀死的时候蟑螂都特别兴奋，最主要的事还可以抑制蟑螂卵鞘，防止下一代祸害人间。

使用经验

1. 喷的地点： 家里其实有很多蟑螂窝点，就照着这些地方喷，蟑螂经常出没的地方也喷一些，还有一个经常忽略的就是外来蟑螂，领居家、大楼里、等等地方，家里杀干净了，蟑螂还是会从外面进来，所以家里出入口、门缝内外、外窗户、窗户缝都喷一些最好。
2. 喷的时间： 第一次喷完之后会发现死一大批成年蟑螂，然后很长一段时间家里会比较干净，那如何判断下一次啥时候喷呢，就是会看到一些零零碎碎的小蟑螂出没的时候，这时候其实就是下一批小蟑螂又出生了，再按照 [1] 的方法喷一次。如此循环往复，这样就会发现后面每次需要喷的时间间隔会拉大，就会保持比较干净。后面可以定时去喷，就可以长期保持住了。
3. 最开始喷完的时候会看到蟑螂全部都四面八方的跑出来手舞足蹈挂掉的是正常现象，尤其是第一次喷量大的会吓一跳，勿惊慌，基操。
4. 「呋虫胺」对人体是有微毒的，虽然杀蟑螂含量很低，但是家里有小孩的还是要注意一些，不要让小孩靠近。
5. 「呋虫胺」的宠物毒性木有了解过，可自行搜索一下，但是应该也都在可控范围内。

品牌

直接在马云网搜含有「呋虫胺」的都可以，成分基本都是很低很安全，直接有喷剂，或者买粉剂自己兑，找便宜的买就行，现在卖的比较好的就是「巴斯夫」，目前用的就是这个。

原文链接：https://konghq.com/blog/kong-gateway-3-0

Kong Gateway 3.0是一个重要的里程碑版本，它引入了我们原生云API平台的下一个发展。Kong Gateway 3.0的企业版和开源版现在都可以从各个发行渠道获得。

在Kong Gateway 3.0中，我们引入了许多功能强大的功能，可带来以下主要好处：

• 更强的安全性和治理能力：符合 FIPS 140-2 的安全机密存储的合规要求(跨网关操作和插件)
• 灵活性和可扩展性：客户可以选择他们的插件执行顺序，添加对WebSocket通信的本地支持，深度集成OpenTelemetry。
• 简单的API管理：Kong Manager UI的新功能增强了用户体验。引入一个功能强大的新路由引擎，优化了复杂路由的表达，同时也提高了运行性能。
• 显著的性能改进：与Kong 2.8.1.4相比，在高复杂性的路由场景，吞吐量提高37%，延迟至少降低27%、很大概率(99%的情况下)降低47%，内存消耗减少了9%。

Tracing 和 OpenTelemetry

了解Kong Gateway如何执行是部署的关键一环，我们很高兴地宣布在Kong Gateway 开源版和企业版中都提供了广泛的跟踪支持。有两种方法可以开始。可以使用开箱即用的 OpenTelemetry 插件直接将OTel发送到任何兼容的后端，或发送到 OpenTelemetry 收集器。我们一直在用 Honeycomb 测试 Kong Gateway，它很管用。

这是一个代理一个请求到 mockbin.org 的跟踪：

图1:将单个请求代理到mockbin.org的跟踪

然后同样的请求，一旦启用速率限制插件(使用Redis)：

图2:启用速率限制插件的相同请求

第二个选择是使用Kong的跟踪插件开发工具包(PDK)来挂钩所有关键事件。这就是 OpenTelemetry 插件的工作方式，它可以完全控制如何收集和抽样跟踪信息，以及如何将数据导出到其他系统。

无论您选择哪种选择，了解Kong Gateway的表现是关键。确定在每个请求上花费的时间可以帮助您优化更高的性能，从而优化用户体验。

Websockets (Beta) (企业版)

秘钥管理(GA)

我们最初在 Kong Gateway 2.8 中发布了 Secrets Management 测试版，我们很高兴地宣布，在本版本中已正式支持。

Secrets Management 允许您将敏感信息安全地存储在外部存储中(用于OSS的环境变量、AWS Secrets Manager 和用于企业的HashiCorp Vault)中，Kong可以在运行时访问这些外部存储。通过将敏感值作为机密存储，可以确保它们不以明文形式通过平台、在Kong.conf或声明性配置文件、日志或 Kong Manager UI 中可见。

此外，使用 Secrets Management 可以为开发、预发布和生产环境提供特定的值，同时使用完全相同的声明性配置文件配置每个环境。

开始Secrets Management 是很容易的，在之前设置明文密码的任何地方，将其替换为一个保险库路径，例如:

1

{vault://hcv/redis/password}

Kong将检测到此引用，并在运行的时候安全地解析。

要更深入地了解秘密管理，请关注我们即将发布的博客，该博客将介绍如何在使用代理缓存高级插件时在 HashiCorp Vault 中存储 Redis 密码。

FIPS 140-2 Compliance(企业版)

插件排序(企业版)

新的路由引擎

这个新功能还是有一些技术含量，Kong Gateway 3.0附带了一个全新的「表达式」路由引擎，可以使用该引擎将请求路由到上游 api。

假设想要路由GET和POST请求，但仅当它们是HTTP请求时。如果不用使用 JSON 来配置路由，可以写一个如下所示的表达式:

1

net.protocol == "https" && (http.method == "GET" || http.method == "POST")

这是一个简单的示例，但是假设希望路由与特定主机匹配的请求，并包含包含主机名的头信息。这是很难预想的，所以让我们来看看它是什么样子的：

1
2
3

(http.host == "example.com" && http.headers.x_example_version == "v2" ) ||
(http.host == "store.example.com" && http.headers.x_store_version == "v1")

只有当主机为example.com且header头x-example-version头的值是v2，或者host为store.example.com且header头x-store-version头为v1时，此路由才会匹配。这是Kong Gateway 3.0新路由引擎灵活性的一个很好的例子。如果在2.x中实现相同的功能将要创建两个单独的路由。

新路由器不仅表现力更强，性能也更好，大型路由配置现在可以增量地重新加载，而不是每次配置更改时都重新构建整个路由器。这使得P99时间在我们的测试中从1.5s减少到0.1s。

最后，介绍一下2.x中的JSON路由器。在这个版本中依旧可以使用，因为目前需要支持现有的路由规则，所以在3.0中保留了现有的路由器。你可以在 kong.conf 中将 router_flavor 设置为traditional，那么路由匹配会和2.x版本一样。

Kong Manager 3.0(企业版)

弃用项和删除项

Kong对稳定性的承诺意味着我们在一个主要版本的所有发行版中都保持向后兼容性。Kong Gateway 3.0让我们有机会弃用一些功能，并删除其他功能，以提高产品的质量。

以下是已弃用或删除的项目:

• Kong Gateway不再使用启发式来猜测一条路径是否正确。Path是一个正则表达式模式。从3.0开始，所有的正则表达式路径都必须以“~”前缀开头，所有不以“~”开头的路径都将被视为纯文本。从2.x升级到3.0.x，迁移过程应该会自动转换正则表达式路径。
• 3.0版本弃用对nginx-opentracing模块的支持，将在4.0版本时移除。并使用新的跟踪PDK和OpenTracing模块作为替换
• Amazon Linux 1 和 Debian Jesse 不再是官方支持的操作系统。
• 目标端点上的POST请求不再能够更新现有实体。他们只能创造新的。如果您有使用POST请求修改/目标的脚本，在更新到Kong Gateway 3.0之前，将它们更改为对适当端点的PUT请求。
• Prometheus 插件默认禁用高基数度量。这样 Prometheus 在清除统计信息时会减少数据库的负载。

额外亮点

• 插件版本一致：要确定你之前运行的是哪个版本的插件是很困难的。从Kong Gateway 3.0开始，插件版本与网关版本保持一致，这样人们就可以确切地知道他们运行的是哪个版本的插件
• Slim/UBI 镜像：我们已经将Docker构建的基本镜像切换为debian-slim 和 rhel-ubi。这意味着镜像更小，安装的软件包更小，从而获得更安全的镜像。
• 系统证书颁发机构：Kong 现在默认使用安装在主机操作系统上的任何CA证书。这允许您在一个地方为所有软件管理证书颁发机构
• LDAP认证：LDAP 认证插件可以通过对 LDAP 服务进行认证来保护服务。Kong Gateway 3.0 增加了基于组成员资格的授权支持。例如「只有 FinanceDev 团队的成员才能访问这个API」。

原文链接：https://konghq.com/blog/kong-gateway-2-8
今天，我们激动地宣布，Kong Gateway 2.8发布啦，它进一步简化了API管理，并提高提高跨任何基础架构的服务安全性。Kong 对客户和社区的持续承诺，通过提供下一代服务连接平台，在现代架构中智能地代理各类信息。

Kong Gateway 2.8的开源和商业版本现在都可以从各个分销渠道下载或购买使用。

秘钥管理( Beta ）【Kong开源版/Kong企业版】

在Kong Gateway 2.8发布的新功能中，首先是一个名为秘钥管理管理的新功能集，目前还是测试版。

在我们开始之前，先定义一下「secret」的含义。在这种情况下，一个秘钥是正确的网关操作所需的敏感信息。秘钥可能是核心网关配置的一部分，例如，数据库连接信息，或者作为与网关服务的api关联的配置的一部分。一些最常见的秘密类型包括:

• 特殊帐户凭据
• 密码
• 证书
• API密钥

从「分散秘钥」转向集中化管理

通过Kong的秘钥管理，客户可以利用他们自己的集中管理的秘钥管理基础设施。有助于遵守IT安全策略，并确保网关操作所需的敏感信息是最新的，并由适合的使用者来掌握。

提高整体安全性

有了Kong的秘钥管理功能，运营商和开发者可以在开发、测试和部署api时独立工作。随着运营商将更多的基础设施(如new一个数据库)在线化，以支持不断变化的应用程序需求，敏感信息首先根据IT安全治理需求添加到集中式秘密管理器(如HashiCorp Vault)。这些秘钥将作为变量在Kong Gateway配置中引用，从而使Kong部署更加便携和安全。

配置秘钥管理后，Kong Gateway数据平面将向第三方秘钥管理器(如AWS secrets Manager和Hashicorp Vault)请求秘钥，并在数据平面上解析秘钥的值。通过使用具有直观语法的简单变量，开发人员可以在声明性的配置、OpenAPI规范和CI/CD管道中引用秘钥的值，以便在运行时仅在需要的地方临时解除对秘钥值的引用，例如，Kong数据平面。

通过Kong的新秘钥管理功能，在整个API管理生命周期中使用的任务关键密钥和网关部署都是集中管理的，可审计的，并防止未经授权的使用。这个秘密管理功能包括以下功能:

• 使用预先构建的「Connectors」到AWS Secrets Manager 和Hashicorp Vault，甚至使用环境变量访问和存储秘钥。
• 使用一个简单和直观的变量使用到Kong的配置中。
• 在Kong数据平面上自动解析秘钥，秘钥的值只存在于内存中，并在整个部署过程中被混淆。

《Kong Gateway 2.8》的秘钥管理功能目前已提供公测版本。企业客户可以使用AWS秘密管理器和Hashicorp Vault集成。有关可用性和功能的详细信息，请查看此处的文档。

Kong Manager 新增过滤/分类功能【Kong企业版】

（略）

双向TSL认证Forward Proxy高级插件【Kong企业版】

（略）

其他亮点

在插件前端，我们添加了一些新功能：

• 我们已经为我们流行的OpenID Connect (OIDC)插件添加了对Distributed Claims 的支持，它被一些OIDC提供商使用，比如Azure Active Directory和其他。

• 我们收到了一个社区合并请求，要求在限速插件上增加配置Redis用户名的能力(感谢27ascii!)我们已经合并了这个功能，不仅在速率限制插件中，而且在我们的速率限制高级插件、响应速率限制插件、OIDC插件和代理缓存高级插件中添加了这个功能。

作为一个独立且值得关注的版本，decK在v1.11中得到了增强，改善了声明式配置体验:

• 首先，decK现在支持核心实体的默认值，并在schema端点的帮助下支持插件。总的来说，这将降低管理Kong Gateway所需的配置文件的复杂性。
• 其次，在validate命令中添加了一个--online标志，它将对Kong API执行验证，而不会影响Kong Gateway的状态。使用该标志将有助于捕获配置问题之前，试图通过deck sync设置网关。

开始使用Kong Gateway 2.8吧

相关功能，修复和更新的完整列表，请查看这里，Kong Gateway OSS查看这里

现在就开始使用Kong Gateway 2.8 - 商业版和开源版都可以免费下载!如果你已经安装了Kong Gateway，升级到2.8是很容易的，可以查看升级指南。别忘了让我们知道你对Kong Nation的看法!

请继续关注我们即将发布的博文，我们将更多地讨论Kong Gateway 2.8的秘钥管理能力。