Higress 是阿里巴巴开源的 AI 原生云原生 API 网关，当前版本 v2.1.8，基于 Istio + Envoy 内核，使用 Go 语言 开发。

核心定位

AI 网关：统一协议对接国内外所有主流 LLM 模型厂商（OpenAI、通义千问、DeepSeek 等），支持 AI 可观测、多模型负载均衡、token 流控、AI 缓存等 MCP Server 托管：通过插件机制托管 MCP Server，使 AI Agent 能方便调用各类工具和服务 K8s Ingress 网关：兼容 Nginx Ingress 注解，支持 Gateway API 标准 微服务网关：对接 Nacos、ZooKeeper、Consul 等服务注册中心，深度集成 Dubbo 安全网关：提供 WAF 防护、多种认证鉴权策略

组件级拆解

higress网关基于istio+envoy构建，所以我们首先需要弄清楚 istio 和 envoy 是什么，higress是如何围绕它们进行构建的。

istio：云原生服务网格控制平面

Istio 是由 Google、IBM、Lyft 联合推出的开源服务网格框架，同样为 CNCF 毕业项目，核心定位是流量管理层。

它本身不直接处理流量，而是作为控制中心管理所有 Envoy 代理实例，将用户的治理规则统一转换为 Envoy 可识别的 xDS 配置并下发。核心能力包括：

• 流量治理：灰度发布、流量拆分、熔断限流、故障注入等
• 安全治理：服务间 mTLS 加密、身份认证、授权策略
• 服务发现：对接 Kubernetes 等平台的服务注册体系
• 可观测性：统一采集数据面的指标、日志、链路数据

其核心控制组件为 Istiod，内部整合了 Pilot-Discovery（配置转换与 xDS 下发）、Citadel（证书管理）、Galley（配置校验）等模块。

我们都知道，Prometheus可用于监控，但这是一个比较模糊的描述，我们需要对Prometheus 进行更具体的拆解，所以本文会介绍 Promethes 是什么以及它的部署架构。话不多说，让我们正式开始吧。

什么是Prometheus

Prometheus官网对其描述如下：

使用领先的开源监控解决方案监控您的应用程序、系统和服务。检测、收集、存储和查询您的指标，用于告警、仪表板和其他用例。 所以Prometheus不仅是组件应用，更是一套成熟的开源监控解决方案。

通常，一个完整的应用监控体系通常包含以下三个层面：

1. ‌指标监控（Metrics）‌：采集数值型数据（如吞吐量、JVM 内存），用于趋势分析和阈值告警。
2. ‌链路追踪（Tracing）‌：记录请求在微服务间的完整调用路径，精准定位分布式架构中的性能瓶颈。 ‌3. 日志监控（Logging）‌：收集文本型事件日志，用于异常细节排查和上下文还原

而Prometheus聚焦于监控体系的指标监控层面，将指标作为时间序列数据收集并存储，即指标信息与记录的时间戳一起存储，同时也包含了称为标签的可选键值对，用于形成对指标数据的多维管理。

主要特征

Prometheus 主要特征如下：

• 一个多维数据模型，其时间序列数据由指标名称和键/值对标识，多维是通过键值对标签实现；
• PromQL，利用多维特征进行灵活查询的语言；
• 不依赖分布式存储，单个服务器节点是自主的，即每个Prometheus实例不能共享存储；
• 基于HTTP的pull模型收集时间序列数据；
• 支持通过中间网关推送时间序列数据，这通常适用于短job，即还未等到Prometheus拉取，对应目标就可能已经结束运行；
• 可通过服务发现或静态配置发现目标，在k8s中，还可以通过Pod标签匹配等方式自动发现集群中部署的资源；
• 图形和仪表板支持多种模式

Prometheus专为云原生世界而设计，与Kubernetes和其他云和容器管理器集成，以不断发现和监控您的服务。这是继Kubernetes之后从CNCF毕业的第二个项目。

组件

Prometheus 生态系统由多个组件组成，其中许多是可选的：

• main prometheus server：负责抓取和存储时间序列数据；
• client libraries：用于检测应用代码的客户端库，这些客户端库实现了Prometheus的指标类型，选择与编写应用程序的语言相匹配的Prometheus客户端库，可以让您通过应用程序实例上的HTTP端点定义和公开内部指标；
• push gateay：支持短期工作的推送网关；
• 专门用于HAProxy、StatsD、Graphite等服务的专用导出器；
• alertmanager：处理告警。

大多数Prometheus组件都是用Go书写的，使它们易于作为静态二进制文件构建和部署。

架构

下图来自于官网，说明了普罗米修斯的架构及其一些生态系统组件：

整个Prometheus架构可以分为以下四部分：

1. 目标（拉模型）：指标数据的来源，可以是server通过服务发现的k8s服务，也可以是在配置中指定的静态目标；
2. Prometheus Server：拉取指标，并存储在本地的时序数据库中，也可以对这些数据运行规则，以从现有数据中聚合和记录新的时间序列，或生成警报。同时通过HTTP服务对数据可视化组件暴露这些指标数据；
3. alertmanager：用于接收 server推送的告警，并转发至不同邮件等用户接口通道；
4. 数据可视化：通过PromQL从Server暴露的HTTP服务中查询指标数据，进行可视化。

概念

Prometheus基本上将所有数据存储为时间序列：属于同一指标和同一组标记维度的带时间戳的值流。除了存储的时间序列外，Prometheus还可以根据查询结果生成临时导出的时间序列。

1. 指标名称和标签 每个时间序列都由其指标名称和称为标签的可选键值对作为唯一标识。

2. job和instance 在Prometheus术语中，可以抓取的端点称为instance，通常对应于单个进程。具有相同目的的实例集合，例如为了可扩展性或可靠性而复制的进程，称为job。

配置

Prometheus 的配置文件是 prometheus.yml 文件，文件的主要内容如下：

本文将介绍本体的历史、学术研究成果以及现实的应用场景。（本文主要内容来自豆老师，我对其进行了分析与整理）

本体是连接哲学与计算机科学的桥梁，从古希腊对世界本质的追问，到现代人工智能的核心基础设施，它经历了两千多年的演变。今天，本体已经成为知识工程、语义网、知识图谱等领域的基石，为解决"语义孤岛"问题提供了根本方案。

何为语义孤岛问题？ 是指不同系统、部门或数据源中，相同概念因定义、命名或口径不一致，导致机器或人无法正确理解、关联或互通其真实含义的现象，造成“数据通了但意思不通”的现象。

一、本体的历史演进：从哲学思辨到工程实践

1. 哲学起源（公元前4世纪-19世纪）

本体论（Ontology）一词源自希腊语"ontos"（存在）和"logos"（研究），字面意思是"关于存在的研究"。

• 亚里士多德（公元前384-322年）：本体论的奠基人。他在《范畴篇》中提出了著名的"十范畴"（实体、数量、性质、关系、地点、时间、姿态、状况、活动、遭受），这是人类历史上第一个系统的本体分类体系。
• 中世纪经院哲学：将本体论发展为神学的工具，研究"上帝的存在"和"共相问题"（简单来说，我们用来描述一类事物的普遍概念（比如“苹果”“红色”“人”），除了用来称呼具体的个别事物外，本身是否是独立存在的真实实体）。
• 莱布尼茨（1646-1716年）：提出了"普遍语言“和”理性演算“的思想，希望用数学符号表示所有概念和推理，这是现代形式化本体的思想源头。
• 康德（1724-1804年）：区分了"物自体"和"现象”，认为我们只能认识现象，而不能认识事物本身，这对后来的知识表示理论产生了深远影响。

2. 计算机科学中的早期探索（1950s-1980s）

随着人工智能的诞生，哲学家们关于知识表示的思考开始转化为工程实践。

• 1956年：人工智能诞生，知识表示成为AI的核心问题之一。
• 1960s：奎利安（Quillian）提出了语义网络（Semantic Network），用节点表示概念，用边表示概念之间的关系，这是知识图谱的雏形。
• 1970s：明斯基（Minsky）提出了框架系统（Frame System），用框架表示对象和类，包含槽（属性）和值，这是面向对象编程和本体中"类"概念的前身。
• 1980年：**约翰·麦卡锡（John McCarthy）**在论文《Circumscription - A Form of Non-Monotonic Reasoning》中首次将"本体"一词引入计算机科学，用来表示"一个程序所使用的存在物的集合"。

3. 知识工程时代（1980s-1990s）

专家系统的兴起推动了知识工程的发展，本体开始成为构建大型知识系统的关键技术。

• 1984年：道格拉斯·莱纳特（Douglas Lenat）启动了Cyc项目，目标是构建一个包含人类常识知识的大型本体。Cyc包含了数百万条断言，是历史上最雄心勃勃的本体工程尝试。
• 1991年：格鲁伯（Tom Gruber）给出了计算机科学中本体的经典定义：

  本体是对概念化的明确的规范说明（An ontology is an explicit specification of a conceptualization）。

• 1993年：格鲁伯开发了Ontolingua，第一个基于KIF（知识交换格式）的本体语言。
• 1990年代中期：出现了多种本体语言，如DAML、OIL等，为后来的OWL标准奠定了基础。

4. 语义网与标准化时代（2000s-2010s）

万维网的发展带来了信息爆炸，但计算机无法理解网页内容。蒂姆·伯纳斯-李（Tim Berners-Lee）提出了语义网的愿景，本体成为语义网的核心技术。

• 2001年：蒂姆·伯纳斯-李在《科学美国人》上发表《The Semantic Web》一文，正式提出语义网概念。
• 2004年：W3C发布OWL（Web Ontology Language）1.0标准，成为语义网的官方本体语言。
• 2009年：W3C发布OWL 2标准，增加了更多表达能力和配置文件。
• 2012年：谷歌发布知识图谱（Knowledge Graph），将本体技术从学术研究推向了大规模工业应用。

5. 大模型时代（2020s至今）

大语言模型的兴起给本体技术带来了新的机遇和挑战。本体不再只是人工构建的静态框架，而是可以与大模型结合，提升大模型的准确性、可解释性和可靠性。

• 2023年："Ontology-RAG"（本体增强检索增强生成）成为研究热点，使用本体指导知识提取和组织，解决大模型的幻觉问题。
• 2024-2026年：出现了多种基于大模型的本体自动构建工具，可以从非结构化文本中自动生成和完善本体。

二、本体的学术研究前沿

本体已经发展成为一个成熟的学术领域，形成了多个稳定的研究方向。

1. 本体工程方法论

本体工程是研究如何系统地构建、维护和使用本体的学科。

上周末，我通过与豆包交互，开始着手搭建我的个人博客网站，也就是你现在看见的这个，但在搭建的过程中，我发现了一个有趣的现象，

我大概可能似乎被豆包指挥了，我一步一步给它试错，踩雷，然后它高兴的排除了一个又一个错误答案，最终告诉了我一个100%不会报错的正确答案。

初试

事情的经过是这样的，我搭建的博客需要结合Github Pages，完成基于Github的自动托管。在这个过程中，需要用到Github的 workflow。 最开始，豆包是这样给我推荐配置的自动部署脚本：

我将脚本推送到Github执行时，执行结果显示了一个 Unexpected value 'workflow_dispatch' 错误，随后我将这个错误反馈给豆包，然后豆包告诉我，我的格式写错了。

拜托，你让我这样写的好不好，我根本不会写这个，我连这个错误的都写不出来。

好吧，它居然学会“赖账”了，这样看来，AI还是不要像人的好。

豆包在经过我的错误反馈后，终于意识到 workflow_dispatch 位置不对。

是的，就是在图中，豆包用手指重点指出的位置，它给我的第一版缩进不对，和on对齐了，正确的应该是和push对齐。

看在它使用了表情包的份上，我原谅它这次赖账了。

惊讶

随后，我又想给博客加个评论系统，因为涉及到 clientSecret，这需要保密，所以需要用到 Github 的环境变量，豆包推荐我如下配置：

关于保密clientSecret这点，也是我主动询问豆包的，它没有主动告知我，否则就可能将这类秘钥放到公共仓库了。其实Github也不会允许这类私钥推送到仓库中。