跳转至

术语表

本页按字母顺序列出 DEC 5.0 常见的一些术语。

A

  • Abstraction, 抽象

    在计算的上下文中，抽象是一种对服务的消费者（消费者可以是计算机程序或人类）隐藏其细节的表示法，使系统更通用也更容易理解。 你的笔记本电脑的操作系统就是一个很好的例子。它把计算机工作的所有细节都抽象出来了。 你不需要知道任何关于 CPU、内存以及程序如何被运行，你只需操作操作系统，操作系统会处理这些细节。 所有这些细节都隐藏在操作系统的“幕布”或抽象概念后面。

    系统通常有多个抽象层。这大大简化了开发工作。 在编程时，开发人员构建与特定抽象层兼容的组件，而不必担心可能非常异构的所有底层细节。 如果组件能与抽象层一起工作，无论底层是什么样的，它就能与系统一起工作。

  • Alert Rule, 告警规则

    基于资源状态创建告警对象，自定义触发规则的条件以及通过何种方式发送通知的规则。

  • API

    API (Application Programming Interface, 即应用程序接口) 是计算机程序间交互的一种方式。 就像人类可以通过网页与网站进行交互一样，API 允许计算机程序之间进行交互。 与人类的交互不同，API 可以限制对方可以问什么和不能问什么。对交互的限制有助于在程序之间创建稳定、实用的信息传输。

  • API 网关

    API 网关是一种通过聚合多个应用程序的 API，并实现一站式管理的工具。 它允许组织将关键性功能移交到一个可集中管理的地方，例如身份验证和授权、限制应用程序之间的请求数量。 一个 API 网关则作为一个公共的接口，向 API 消费者（通常来自外部）提供服务。

  • Audit log, 审计日志

    审计日志提供了对系统中对象所做更改的历史记录。

  • Autoscaling, 自动伸缩

    自动伸缩，通常是指在计算资源方面，系统能够进行自动伸缩的能力。自动伸缩系统可在需要时自动添置资源，通过伸缩来满足不断变化的用户需求。 自动伸缩的过程各不相同，可基于不同指标进行配置，例如内存或处理时间。托管云服务相较于大多数本地部署环境，有更多的可选项和实施项，因此往往都搭配有自动伸缩功能。

    在此之前，基础设施和应用程序的架构设计会考虑到系统峰值的使用情况。这种架构意味着大部分资源没有得到充分利用，并且在面对不断变化的用户需求时缺乏弹性。 缺乏弹性则意味着低谷时的业务成本增加，而在高峰时又会由于需求过盛引起的服务中断而导致业务流失。

    通过利用云，虚拟化和容器化应用程序及其依赖项等手段，组织可以构建随用户需求而伸缩的应用程序。 他们可以监控应用程序的流量并自动伸缩，从而提供最佳的用户体验。以 Netflix 每周五晚上的收视率增长为例，自动伸缩意味着动态添置更多资源：即增加服务器数量以支持更多视频播放需求，并在需求回落后同步缩减。

B, C

  • Bare Metal Machine，裸机

    裸机是指一台物理计算机，更具体地说是一台服务器，它只有一个操作系统。 这样区分在现代计算环境中很重要，因为许多（甚至可以说大部分）服务器都是虚拟机。 物理服务器通常是一台相当大的计算机，内置强大的硬件。 直接在该物理硬件上安装操作系统并运行应用程序，无需虚拟化，称为在“裸机”上运行。

  • Blue Green Deployment，蓝绿部署

    蓝绿部署是一种以最小的停机时间更新运行中的计算机系统的策略。 运营商维护两个环境，被称为 "蓝" 和 "绿"。一个为生产流量服务（所有用户目前正在使用的版本），而另一个则被更新。 一旦在非活动（绿色）环境中的测试结束，生产流量就会被切换过来（通常通过使用负载平衡器）。 请注意，蓝绿色的部署通常意味着一次性切换整个环境，包括许多服务。 令人困惑的是，有时这个术语被用于系统内的单个服务。为了避免这种歧义，在提到单个组件时，最好使用 "零停机部署" 一词。

  • Canary Deployment, 金丝雀部署

    金丝雀部署是一种部署策略，开始时有两个环境：一个有实时流量，另一个包含没有实时流量的更新代码。 流量逐渐从应用程序的原始版本转移到更新版本。 它可以从移动 1% 的实时流量开始，然后是 10%，25%，以此类推，直到所有流量都通过更新的版本运行。 企业可以在生产中测试新版本的软件，获得反馈，诊断错误，并在必要时快速回滚到稳定版本。

    “金丝雀” 一词是指 “煤矿中的金丝雀” 的做法，即把金丝雀带入煤矿以保证矿工的安全。 如果出现无味的有害气体，鸟就会死亡，而矿工们知道他们必须迅速撤离。 同样，如果更新后的代码出了问题，现场交通就会被 "疏散" 回原来的版本。

  • Chaos Engineering, 混沌工程

    混沌工程或 CE 是在生产中对分布式系统进行实验的学科，以建立对系统承受动荡和意外情况时能力的信心。

    SRE 和 DevOps实践侧重于提高产品弹性和可靠性的技术。 系统在故障容灾时确保服务质量的能力通常是对软件开发提出的要求。这里涉及到几个方面可能导致应用程序中断， 例如基础设施、平台或（基于微服务）的应用程序的其他部分。 高频地持续部署新功能到生产环境会增加服务中断和恶性事件发生的可能性，乃至于对业务产生重大影响。

    混沌工程是一种满足弹性要求的技术。它用于实现对基础架构、平台和应用程序等意外发生时的故障容灾。 混沌工程师使用混沌实验主动注入随机故障，以验证应用程序、基础架构或平台是否可以自我修复，并且故障不会对客户产生明显影响。 混沌实验旨在发现盲点（例如监控或自动伸缩技术）并在恶性事件发生期间增强团队之间的沟通。 这种方法有助于提高复杂系统的弹性和团队对其的信心，尤其是在生产环境。

  • Client Server Architecture, 主从式架构

    在主从式架构（客户端-服务器架构）中，构成应用程序的逻辑（或代码）会被分成两个或多个组件： 一个期望工作被完成的客户端（例如，运行在你的 web 浏览器中的 Gmail web 应用程序）， 以及一个或多个满足该请求的服务器（例如，运行在云中心的谷歌计算机上的“发送电子邮件”服务）。 在这个例子中，你所写的外发邮件是由客户端（运行在您的 web 浏览器中的 web 应用程序）发送到服务器（Gmail 的计算机，它将您的外发邮件转发给对应的收件人）。

    这与在一个地方完成所有工作的独立应用程序（如桌面应用程序）形成了对比。 例如，像 Microsoft Word 这样的文字处理程序可能会完全安装并运行在你的计算机上。

  • Cloud Computing, 云计算

    云计算是一种通过互联网按需提供计算资源（如 CPU、网络和磁盘功能）的模型。 云计算使用户能够在远程物理位置访问和使用计算能力。 AWS、GCP、Azure、DigitalOcean 等云提供商都为第三方提供了在多个地理位置租用计算资源的能力。

    传统上，组织在尝试扩展计算能力的使用时面临两个主要问题。 他们要么获取、支持、设计和支付托管物理服务器和网络的设施，要么扩展和维护这些设施。 云计算允许组织将部分计算需求外包给另一个组织。

    云提供商为组织提供按需租用计算资源并按使用付费的能力。这允许进行两项主要创新： 组织可以在不浪费时间计划和花费金钱或资源在新的物理基础设施上的情况下进行尝试，并且他们可以根据需要和按需伸缩。 云计算允许组织根据需要采用尽可能多或尽可能少的基础设施。

  • Cloud-Native Apps, 云原生应用程序

    云原生应用程序专门设计用于利用云计算中的创新。 这些应用程序可以轻松地与其各自的云架构集成，充分利用云的资源和可伸缩性功能。 它还指利用云计算驱动的基础设施创新的应用程序。 今天的云原生应用程序包括在云提供商的数据中心和本地云原生平台上运行的应用程序。

    传统上，本地环境以相当定制的方式提供计算资源。 每个数据中心都有与特定环境紧密耦合应用程序的服务，通常严重依赖于基础设施的手动配置，例如虚拟机和服务。 这反过来又将开发人员及其应用程序限制在该特定数据中心。 不是为云设计的应用程序无法利用云环境的弹性和伸缩能力。 例如，需要手动干预才能正确启动的应用程序无法自动伸缩，也无法在发生故障时自动重启。

    虽然云原生应用程序没有“一刀切”的路径，但它们确实有一些共性。 云原生应用程序具有弹性、可管理性，并由配套的云服务套件提供帮助。 各种云服务实现了高度的可观测性，使用户能够在问题升级之前检测和解决问题。 结合强大的自动化，它们使工程师能够以最少的工作频繁且可预测地进行高影响力的更改。

  • Cloud-Native Security, 云原生安全

    云原生安全是一种将安全性构建到云原生应用程序中的方法。 它确保安全是从开发到生产的整个应用程序生命周期的一部分。 云原生安全旨在确保与传统安全模型相同的标准，同时适应云原生环境的特殊性，即快速的代码更改和高度短暂的基础设施。 云原生安全与称为测试左移的实践高度相关。

    传统的安全模型是根据许多不再有效的假设构建的。 云原生应用程序变化频繁，使用大量开源工具和库，通常运行在供应商控制的基础设施中，并且会受到快速的基础设施变化的影响。 代码审查、长质量保证周期、基于主机的漏洞扫描和最后一分钟的安全审查无法与云原生应用程序一起伸缩。

    云原生安全引入了一种新的工作方式，通过从传统的安全模型迁移到发布周期的每个步骤都涉及安全的模型来保护应用程序。 人工审核和检查在很大程度上被自动扫描所取代。 快速代码发布管道与在编译之前扫描代码以查找漏洞的工具集成在一起。 开源库从受信任的来源中提取并监控漏洞。 云原生安全模型不是减缓变化，而是通过频繁更新易受攻击的组件或确保定期更换基础设施来拥抱它。

  • Cloud-Native Tech, 云原生技术

    云原生技术，也称为云原生技术栈，是用于构建云原生应用程序的技术。 使组织能够在公共云、私有云和混合云等现代动态环境中构建和运行可伸缩的应用程序，他们坚持“云的承诺”并充分利用云计算的优势。 它们从头开始设计，以利用云计算和容器的功能，服务网格、微服务和不可变的基础设施就是这种方法的例证。

    云原生技术栈有许多不同的技术类别，可应对各种挑战。 如果你看看 CNCF 云原生全景图，你会看到它涉及到多少不同的领域。 但在高层次上，它们解决了一组主要挑战：传统 IT 运营模式的缺点。挑战包括难以创建可伸缩、容错、自我修复的应用程序，以及资源利用效率低下等。

    虽然每种技术都解决了一个非常具体的问题，但作为一个整体，云原生技术支持松散耦合的系统，这些系统具有弹性、可管理性和可观察性。 结合强大的自动化，它们使工程师能够以最少的工作频繁且可预测地进行高影响力的更改。 云原生系统的理想特性更容易通过云原生堆栈实现。

  • Threshold, 保护阈值

    阈值是一个 0 到 1 之间的浮点数。 当健康实例数占总服务实例数的比例小于该值时，无论实例是否健康，都会将这个实例返回给客户端。 这样可以防止流量压力把健康实例压垮并形成雪崩效应。

  • Cluster, 集群

    集群是运行容器化应用程序的一组计算节点。通常，组成集群的计算节点彼此可以直接连接。集群通过规则或策略限制外部访问。

    集群是一组计算机或应用程序，它们为一个共同的目标一起工作。 在云原生计算的背景下，这个术语最常被应用于 Kubernetes。 Kubernetes 集群是一组服务（或工作负载），它们在各自的容器中运行，通常在不同的机器上。 所有这些容器化服务的集合，通过网络连接，代表一个集群。

    在单台计算机上运行的软件会出现单点故障——如果这台计算机崩溃了，或者有人不小心拔掉了电源线，那么一些关键的业务系统就可能被下线。 这就是为什么现代软件通常被构建为分布式应用，以集群的形式组合在一起。

    集群式的分布式应用在多台机器上运行，消除了单点故障。但构建分布式系统真的很难，事实上，它本身就是一门计算机科学的学科。 对全球系统的需求和多年的试验和错误导致了一种新的技术栈的发展：云原生技术，这些新技术是使分布式系统的操作和创建更容易的构件。

  • Container Image, 容器镜像

    容器镜像是一个不可改变的静态文件，包含创建容器的依赖性。 这些依赖可能包括一个可执行的二进制文件、系统库、系统工具、环境变量和其他必要的平台设置。 容器镜像是应用程序容器化的结果，通常存储在容器注册表中，在那里可以下载并使用容器运行时接口（CRI）作为一个孤立的进程运行。 容器镜像框架必须遵循开放容器倡议（OCI）定义的标准模式。

    传统上，应用服务器是按环境配置的，而应用则被部署到这些环境中。 环境之间的任何错误配置都是有问题的，常常导致停机或部署失败。 一个应用程序的环境需要是可重复的和定义明确的；否则，与环境有关的错误的机会就会增加。 当应用程序的环境定义不足或不准确时，应用程序的横向和纵向伸缩就会成为挑战。

    容器镜像将一个应用程序与它的任何运行时的依赖性捆绑在一起，例如一个应用程序服务器。 这提供了所有环境的一致性，包括开发人员的机器。 容器镜像可用于实例化所需的多个容器，允许更大的可伸缩性。

  • Container, 容器

    容器是由计算机操作系统管理的具有资源和能力限制的运行进程。 容器进程可用的文件被打包为容器镜像。 容器在同一台机器上彼此相邻运行，但通常操作系统会阻止单独的容器进程相互交互。

    在容器可用之前，需要单独的机器来运行应用程序。每台机器都需要自己的操作系统，它占用 CPU、内存和磁盘空间， 所有这些都是为了让单个应用程序运行。此外，操作系统的维护、升级和启动是另一个重要的工作来源。

    容器共享相同的操作系统及其机器资源，分散了操作系统的资源开销并创建了物理机器的有效使用。 这种能力之所以成为可能，是因为容器之间的交互通常受到限制。 这允许更多的应用程序在同一台物理机器上运行。

    但是，有一些限制。由于容器共享相同的操作系统，因此可以认为进程不如替代方法安全。 容器还需要对共享资源进行限制。 为了保证资源， 管理员必须约束和限制内存和 CPU 的使用，以使其他应用程序不会表现不佳。

  • Containerization, 容器化

    容器化是将一个应用程序及其依赖关系捆绑到容器镜像中的过程。 容器构建过程需要遵守开放容器倡议 (OCI) 标准。 只要输出的是一个符合这个标准的容器镜像，使用哪种容器化工具并不重要。

    在容器盛行之前，企业依靠虚拟机 (VMs) 在一台裸机上协调多个应用程序。 虚拟机比容器大得多，需要一个管理程序来运行。由于这些较大的虚拟机模板的存储、备份和传输，创建虚拟机模板也很慢。 此外，虚拟机可能会出现配置漂移，这违反了不变性的原则。

    容器镜像是轻量级的（与传统的虚拟机不同），容器化过程需要一个带有依赖性列表的文件。 这个文件可以被版本控制，构建过程也可以自动化，允许一个组织在自动化过程中关注其他优先事项。 容器镜像由一个唯一的标识符来存储，该标识符与它的确切内容和配置相联系。 当容器被安排和重新安排时，它们总是被重置为其初始状态，从而消除了配置漂移。

  • Container as a service (CaaS), 容器即服务

    容器即服务（CaaS）是一种云服务，有助于使用基于容器的抽象管理和部署应用程序。 这项服务可以部署在企业内部或云中。

    CaaS 供应商提供了一个框架或协调平台，使容器部署和管理的关键 IT 功能自动化。 它帮助开发者建立安全和可伸缩的容器化应用。 因为用户只购买他们需要的资源（调度能力、负载平衡等），他们可以节省资金并提高效率。 容器创造了一致的环境，以快速开发和交付可以在任何地方运行的云原生应用。

    如果没有 CaaS，软件开发团队需要部署、管理和监控容器运行的底层基础设施。

    当把容器化应用部署到 CaaS 平台时，用户可以通过日志聚合和监控工具获得对系统性能的可见性。 CaaS 还包括自动伸缩和协调管理的内置功能。 它使团队能够建立高可见性和高可用性的分布式系统。 此外，通过允许快速部署，CaaS 提高了团队的开发速度。在容器确保一致的部署目标的同时，CaaS 通过减少管理部署所需的 DevOps 资源，降低了工程运营成本。

  • Counter, 计数器

    计数器是一种累计型的度量指标，它是一个 只能递增 的数值。计数器主要用于统计类似于服务请求数、任务完成数和错误出现次数这样的数据。

  • Contour, 网关控制节点

    Contour 作为微服务网关的控制面，被部署为控制节点，充当 Envoy 的后端管理服务能力。 Contour 提供便捷的网关配置，支持动态配置更新，多集群部署能力。 Contour 同时提供了 HTTPProxy CRD 用于增强 Kubernetes Ingress 的核心配置能力， Contour 以 Deployment 的方式部署，为保障生产服务稳定性，建议部署在多个副本。

  • Control Plane, 控制平面

    控制平面是一组系统服务，这些服务配置网格或者网格的子网来管理工作负载实例之间的通信。 单个网格中控制平面的所有实例共享相同的配置资源。

  • CRD, 自定义资源定义

    自定义资源定义是默认的 Kubernetes API 扩展，服务网格使用 Kubernetes CRD API 来进行配置。

D

  • Data ID

    Nacos 中某个配置集的 ID。配置集是一组配置项的集合，通常表现为一个配置文件，其中包括系统各方面的配置。

  • Data Plane, 数据平面

    数据平面是网格的一部分，直接控制工作负载实例之间的通信。 服务网格的数据平面使用智能 Envoy 代理部署成边车去调节和控制服务网格中发送和接受的流量。

  • Dependency topology, 依赖拓扑

    以拓扑图的方式展示服务调用之间的依赖关系。

  • Destination, 目标服务

    目标服务是 envoy 代表一个源服务工作负载与之打交道的远程上游服务。 这些上游服务可以有多个服务版本，envoy 根据路由选择对应的版本。

  • Destination Rule, 目标规则

    目标规则定义了在路由发生后应用于服务的流量策略。 这些规则指定负载均衡的配置、来自边车代理的连接池大小以及异常检测设置，从而实现从负载均衡池中检测和熔断不健康的主机。

  • Diagnosis, 诊断模式

    诊断模式即对 Contour 进行功能调试，支持在 Contour 启动时附加对应的启动参数。

E

  • Envoy

    Envoy 是在服务网格里使用的高性能代理，用于为所有服务网格里的服务调度进出的流量。

  • External Control Plane, 外部控制平面

    外部控制平面可以从外部管理运行在自己的集群或者其他基础设施中的网格工作负载。 控制屏幕可以部署在一个集群中，但是不能部署在它所控制的网格的一部分集群中。 它的目的是将控制平面与网格的数据屏幕完全分离。

G

  • Gateway node, 网关工作节点

    工作节点主要运行 Envoy 开源应用，主要提供高性能的反向代理能力，支持负载均衡、路由、缓存、自定义路由等功能。 工作节点的数量和性能将直接影响网关的性能，建议根据需要部署足够的工作节点。

  • Gateway, 网关规则

    网关规则（Gateway）定义了在网格南北向连接操作的负载均衡器，用于建立入站和出站的 HTTP/TCP 访问连接。 它描述了需要公开的一组端口、服务域名、协议类型、负载均衡器的 SNI 配置等信息。

  • Gauge, 计量器

    计量器是一个 既可增又可减 的度量指标值。计量器主要用于测量类似于温度、内存使用量这样的瞬时数据。

  • Global rate limit, 全局限流

    可选择增加网关限流组件，通过限流组件可以支持更多的流量管控能力。 但是，限流组件也会导致一定的资源消耗和性能损失，默认情况下不启用。请根据实际情况判断是否需要启用。

  • Grafana

    Grafana 是一个开源的可视化平台，提供了多样的监控数据可视化面板。

  • Group

    Nacos 中的一组配置集。

H, L

  • Heartbeat, 心跳

    实例启动后每隔一段时间，内置的 Nacos 客户端会主动向 Nacos 服务器发起心跳包（HeartBeat），表示实例仍存活，避免被服务端剔除。 心跳包包含当前服务实例的名称、IP、端口、集群名称、权重等信息。

  • Histogram, 直方图

    直方图对观察结果（通常是请求持续时间或者响应大小这样的数据）进行采样，并在可配置的桶中对其进行统计。 有以下几种方式来产生直方图（假设度量指标为 <basename>）：

    • 按桶计数，相当于 <basename>_bucket{le="<upper inclusive bound>"}
    • 采样值总和，相当于<basename>_sum
    • 采样值总数，相当于 <basename>_count ，也等同于把所有采样值放到一个桶里来计数 <basename>_bucket{le="+Inf"}

    Histogram 可以理解为柱状图，典型的应用如：请求持续时间，响应大小。可以对观察结果采样，分组及统计。

  • Logging, 日志

    系统运行过程中变化的一种抽象数据，其内容为指定对象的操作和其操作结果按时间的有序集合。

M

  • Managed Control Plane, 托管控制平面

    托管控制平面是一个为客户提供管理的控制平面。 托管控制平面降低了用户部署的复杂性，并通常保证一定水平的性能和可用性。

  • Managed Mesh, 托管网格

    由服务网格在所选集群创建并托管的控制平面。具备简单、低成本、高可用、无需单独运维管理 的特点。

  • Master cluster, 主集群

    主集群是具有控制平面的集群。 一个网格可以有一个以上的主集群，以用于 HA 或需要低延迟的场景。 主集群可以充当工作集群的控制平面。

  • Metric, 指标

    对资源性能的数据描述或状态描述，指标由命名空间、维度、指标名称和单位组成。 采集目标暴露的、可以完整反映监控对象运行或者业务状态的一系列标签化数据。

  • Metadata, 元数据

    元数据是数据本身的描述信息，是关于数据的数据，例如服务版本、各种自定义标签等。 元数据分为服务级别的元数据、集群的元数据及实例的元数据。

  • Microservice, 微服务

    微服务是一种通过多个小型服务组合来构建单个应用的架构风格。在微服务引擎中，微服务指将一个完整的应用根据业务功能拆分而得到的各个小型服务。

  • Microservice instance, 微服务实例

    将同一个微服务部署在多个容器或虚拟机上，每个容器或虚拟机上运行的微服务副本就是一个微服务实例。多个微服务实例可以同时运行。

  • Microservice instance group, 微服务实例分组

    将同一个微服务下的所有微服务实例按照需求进一步划分得到的分组。

N, O

  • Nacos 集群节点角色

    节点在 Raft 协议中的角色。Raft 是一种实现分布式共识的协议，即如何让多个节点达成一致。 Leader 是所有请求的处理者，负责接收客户端发起的操作请求，将请求写入本地日志并向其他节点同步请求日志。 任何时候最多只能有一个 Leader。Follower 是 Leader 的跟随者，负责从 Leader 接收更新请求并将其写入本地日志，并在 Leader 通知可以提交日志时提交日志。

  • Namespace, 命名空间（微服务治理模块）

    在微服务引擎中，命名空间指的是 Nacos 命名空间，主要用于实现租户层级的配置隔离，例如隔离开发环境、测试环境、生产环境的资源配置。

  • Notification, 通知

    当资源存在异常而产生告警时，可将告警信息通过邮件、钉钉、企业微信、webhook等方式发送给指定的用户。

  • Objective, 目标

    Prometheus 抓取的采集目标。采集目标暴露自身状态，或者代理暴露监控对象的运行、业务指标。

  • Operator

    Operator 是打包，部署和管理 Kubernetes 应用程序的一种方法。

P

  • Pilot

    Pilot 是服务网格里的一个组件，它控制 Envoy 代理，负责服务发现、负载均衡和路由分发。

  • Pod

    Pod 中包含了一个或多个共享存储和网络的容器（例如 Docker 容器），以及如何运行容器的规约。 Pod 是 Kubernetes 部署的一个工作负载实例。

  • Prometheus

    Prometheus是一套开源的监控、报警、时间序列数据库的组合。

  • PromQL

    Prometheus 内置的数据查询语言，其提供对时间序列数据丰富的查询，聚合以及逻辑运算能力的支持。

R

  • Registration center, 注册中心

    注册中心相当于微服务架构中的“通讯录”，负责记录服务和服务地址的映射关系。 微服务引擎支持的注册中心类型有：Eureka、Zookeeper、Nacos、Mesh、Kubernetes。

  • Resource request, 资源请求值

    请求值规定了为实例预先分配多少可用资源。

  • Resource limit, 资源限制值

    限制值是实例的可用资源上限。请求值小于限制值。

  • Rolling update, 滚动更新

    滚动更新指一次只更新一小部分副本，成功后再更新更多的副本，最终完成所有副本的更新。 滚动更新的最大的好处是零停机，整个更新过程始终有副本在运行，从而保证业务的连续性。

  • Routing Rule, 路由规则

    在虚拟服务中配置的路由规则，遵循服务网格定义了请求的路径。 使用路由规则，可以定义将寻址到虚拟服务主机的流量路由到指定目标的工作负载。 路由规则使您可以控制流量，以实现按百分比分配流量的分阶段等任务。

S

  • Service, 服务

    使用服务名称标识一组具有关联行为的服务服务网格，并使用这些名称应用服务网格策略（例如负载均衡和路由）。 服务通常由一个或多个服务 Endpoint 实现，并且或许包含多个服务版本。

  • Service Discovery, 服务发现

    用于 Kubernetes 环境的服务发现配置，用于批量且自动地接入 Kubernetes 上的监控点。

  • Service Entry, 服务条目

    服务条目用于将一个无法注册到服务注册表的网格内部服务（例如：vm）或网格外部服务器添加到服务网格抽象模型中。 添加服务条目后，Envoy 代理可以将流量发送到该服务，这个服务条目将和网格中的其他服务一样。

  • Service Mesh, 服务网格

    服务网格是一个可管理、可观测以及支持工作负载实例之间进行安全通信的基础设施层。 在一个网格中，服务名称与命名空间组合具有唯一性。 例如，在一个多集群的网格中，cluster-1 集群的 foo 命名空间中的 bar 服务和 cluster-2 集群的 foo 命名空间中的 bar 服务被认为是同一个服务。

    由于服务网格会共享这种标识，因此同一服务网格内的工作负载实例可以相互认证通信。

  • Service Name, 服务名称

    服务名称是服务 Service 唯一的名字，是 Service 在服务网格里的唯一标识。服务名称是唯一的，不得重复。 一个服务有多个版本，但是服务名是与版本独立的。

  • Service Operator

    Service Operator 是在服务网格里管理 Service 的代理， 通过操纵配置状态并通过各种仪表板监视服务的运行状况来管理这些服务。

  • Service Registry, 服务注册表

    服务网格维护了一个内部服务注册表 (service registry)，包含在服务网格中运行的一组服务及其相应的服务 endpoints。服务网格使用服务注册表生成 Envoy 配置。

  • Summary, 汇总

    类似于直方图，汇总也对观察结果进行采样。除了可以统计采样值总和和总数，它还能够按分位数统计。有以下几种方式来产生汇总（假设度量指标为 <basename>）：

    • 按分位数，也就是采样值小于该分位数的个数占总数的比例小于 φ，相当于 <basename>{quantile="<φ>"}
    • 采样值总和，相当于 <basename>_sum
    • 采样值总数，相当于 <basename>_count

T

  • Temporary microservice instance, 临时微服务实例

    不能持久化存储在 Nacos 服务端的微服务实例。 临时微服务实例需要通过上报心跳的方式进行包活，如果一段时间内没有上报心跳，就会被 Nacos 服务端摘除。

  • Trace, 链路

    记录单次请求范围内的处理信息，其中包括服务调用和处理时长等数据。 一个 Trace 有一个唯一的 Trace ID ，并由多个 Span 组成。

V, W

  • Virtual Service, 虚拟服务

    虚拟服务定义了一系列针对指定服务的流量路由规则。 每个路由规则都针对特定协议定义流量匹配规则。 如果流量符合这些特征，就会根据规则发送到服务注册表中的目标服务（或者目标服务的子集或版本）。

  • Weight, 权重

    权重为浮点数。权重越大，表示分配给该实例的流量越大。

  • Workload, 工作负载

    工作负载是 Operator 部署的二进制文件，用于提供服务网格应用的一些功能。 工作负载有自己的名称、命名空间和唯一的 ID。这些属性可以通过下面的属性被策略配置和遥测配置使用：

    • source.workload.name, source.workload.namespace, source.workload.uid
    • destination.workload.name, destination.workload.namespace, destination.workload.uid

  • Workload Instance, 工作负载实例

    工作负载实例是工作负载的一个二进制实例化对象。 一个工作负载实例可以开放零个或多个服务 endpoint，也可以消费零个或多个服务。 工作负载实例具有许多属性：名称和命名空间、IP 地址、唯一的 ID、标签、主体等

  • Workload Instance Principal, 工作负载实例主体

    工作负载实例主体是工作负载实例的可验证权限。服务网格的服务到服务身份验证用于生成工作负载实例主体。 默认情况下，工作负载实例主体与 SPIFFE ID 格式兼容。

  • Workspace, 工作空间

    工作空间是一种资源范畴，代表一种资源层级关系。工作空间可以包含集群、命名空间、注册中心等资源。 通常一个工作空间对应一个项目，可以为每个工作空间分配不同的资源，指派不同的用户和用户组。

  • Worker Cluster, 工作集群

    工作集群是一个连接到集群外部控制平面的集群。 工作集群可以连接到主集群的控制平面，或连接到一个外部控制平面。

下载 DCE 5.0 安装 DCE 5.0 申请社区免费体验

评论