规范化服务最佳做法

注意：Cloud Service Mesh 1.6.8 及更高版本会自动支持规范化服务。

借助规范化服务，您可以导航多种不同配置。获享 Cloud Service Mesh 的最佳体验 服务信息中心，那么在设置时，请考虑采用以下标准做法 您的服务：

• 在整个网状网中预留唯一服务 [命名空间，名称]。
• 为每项规范化服务定义一个软件应用。
  • 请勿跨环境对规范服务进行分组（例如 prod/stage/dev）。
  • 使用 Cloud Monitoring 信息中心来创建多项服务的高级视图。
• 计划将规范化服务长期用于生产环境。

在整个网状网中预留唯一服务 [命名空间，名称]

如果部署在一个集群或区域中的规范服务具有相同的 Kubernetes 命名空间和规范服务的名称 区域中，Cloud Service Mesh 会假定这是相同的逻辑服务。

此行为符合队列的“相同性”原则，即命名空间应具有相同的含义，并且在整个队列中表示同一实体。

重要提示：请确保逻辑上不同的服务（例如 Payment Accounting API 和 Payment Transaction API）不会使用相同的 [命名空间，名称] 对（例如，"payments/api")，因为它们无意中会加入一个服务信息中心。请注意，这种概念性加入操作甚至会跨区域边界发生。此外，服务的功能可能会受到影响。

每项规范化服务一个软件应用

规范化服务旨在表示单项逻辑服务或微服务。它们旨在跨越表示相同软件应用和业务功能的同构二进制文件/工作负载。

虽然您可以定义一项规范服务，以便从概念上将多个 不同的微服务组合时，服务信息中心将无法提供其 服务信息中心会显示不同类别的汇总信息 单独执行和配置的方式可能截然不同的组件。 您可能很难了解甚至无法了解整体的运行状况、性能和配置。

以下做法不一定是不良做法，但如果存在这些做法，则您的规范化服务可能会过于庞大：

• 单项规范化服务内的不同工作负载之间存在网络流量。
• 规范化服务包含多个基于不同发布时间表部署的工作负载。
• 组织中的不同团队负责运营单项规范化服务的不同部分。

请勿跨环境对规范服务进行分组

许多技术组织都采用多种部署环境来确保软件质量并限制风险。这些环境通常包括开发环境、测试环境、预演环境、生产环境或某个子集。

即使您在各个环境中部署相同的概念服务，但将这些服务构建成为一项规范化服务却是不良的做法。这些服务并不相同，而且不代表组织的同等运营问题或侧重点。

例如，一项关键生产服务的故障可能会导致凌晨 3 点 消防如果“开发者”Deployment 失败 。了解性能、容量和版本安全同样如此。

重要提示：我们建议您将各种环境中的服务分离成单独的规范化服务。您可以通过三种方式之一来执行此操作。

将服务分离到不同的环境有三种方式（从最简单、最宽松的方式到最严谨、最强大的方式）：

1. 使用多个服务名称（例如 payments-prod 和 payments-test）进行分离。
2. 使用多个命名空间（例如 billing-team 和 billing-team-test）进行分离。
3. 使用多个队列（每个环境一个）进行分离。

首选 Cloud Monitoring 自定义信息中心进行任意聚合

使用 Cloud Monitoring 信息中心一次性创建多项逻辑服务的高级视图，而不是通过人工方式将规范化服务扩大到汇总数据的更大范围。

规范化服务旨在长期提供

除了开发、探索和测试用例之外，规范化服务应代表全球的高级逻辑服务。这些服务变化缓慢，旨在长期提供。这种长期性包括不更改服务名称。虽然您可以更改它们的名称，但这样做会影响指标、SLO 和日志。不过，您可以自由调整 Display name 字段而不会中断服务。

新的规范化服务通常代表新软件或更新的软件，而规范化服务消失通常意味着服务弃用。您能否了解服务、方案和项目容量的历史性能，取决于您在其整个生命周期内维护 Cloud Service Mesh 中该服务的单一概念情况。

请注意，这与虚拟机实例、Kubernetes Pod/Deployment 甚至整个集群等低级资源有所不同，这些资源在您更新和维护生产系统过程中通常会发生变化。

后续步骤

• 详细了解规范化服务。
• 了解如何定义规范化服务。