规范化服务最佳做法
注意：Cloud Service Mesh 1.6.8 及更高版本会自动支持规范化服务。
借助规范化服务，您可以导航多种不同配置。获享 Cloud Service Mesh 的最佳体验 服务信息中心，那么在设置时，请考虑采用以下标准做法 您的服务：
- 在整个网状网中预留唯一服务 [命名空间，名称]。
- 为每项规范化服务定义一个软件应用。
- 请勿跨环境对规范服务进行分组（例如 prod/stage/dev）。
- 使用 Cloud Monitoring 信息中心来创建多项服务的高级视图。
- 计划将规范化服务长期用于生产环境。
在整个网状网中预留唯一服务 [命名空间，名称]
如果部署在一个集群或区域中的规范服务具有相同的 Kubernetes 命名空间和规范服务的名称 区域中，Cloud Service Mesh 会假定这是相同的逻辑服务。
此行为符合队列的“相同性”原则，即命名空间应具有相同的含义，并且在整个队列中表示同一实体。
每项规范化服务一个软件应用
规范化服务旨在表示单项逻辑服务或微服务。它们旨在跨越表示相同软件应用和业务功能的同构二进制文件/工作负载。
虽然您可以定义规范化服务来将几个概念上不同的微服务归为一组，但服务信息中心不会提供其全部价值。服务信息中心会显示一组不同组件，这些组件各自的性能和配置可能截然不同。您可能很难了解甚至无法了解整体的运行状况、性能和配置。
以下做法不一定是不良做法，但如果存在这些做法，则您的规范化服务可能会过于庞大：
- 单项规范化服务内的不同工作负载之间存在网络流量。
- 规范化服务包含多个基于不同发布时间表部署的工作负载。
- 组织中的不同团队负责运营单项规范化服务的不同部分。
不要跨环境对规范化服务进行分组
许多技术组织都采用多种部署环境来确保软件质量并限制风险。这些环境通常包括开发环境、测试环境、预演环境、生产环境或某个子集。
即使您在各个环境中部署相同的概念服务，但将这些服务构建成为一项规范化服务却是不良的做法。这些 服务不相同，也不代表相同水平的运营 组织关注的问题或重点。
例如，一项关键生产服务的故障可能会导致凌晨 3 点 消防如果“开发者”Deployment 失败 。了解性能、容量和版本安全同样如此。
将服务分离到不同的环境有三种方式（从最简单、最宽松的方式到最严谨、最强大的方式）：
- 使用多个服务名称（例如
payments-prod和payments-test）进行分离。 - 使用多个命名空间（例如
billing-team和billing-team-test）进行分离。 - 使用多个队列（每个环境一个）进行分离。
首选 Cloud Monitoring 自定义信息中心进行任意聚合
使用 Cloud Monitoring 信息中心一次性创建多项逻辑服务的高级视图，而不是通过人工方式将规范化服务扩大到汇总数据的更大范围。
规范化服务旨在长期提供
除了开发、探索和测试用例之外，规范化服务应代表全球的高级逻辑服务。这些服务变化缓慢，旨在长期提供。这种长期性包括不更改服务名称。虽然您可以更改它们的名称，但这样做会影响指标、SLO 和日志。不过，您可以自由调整 Display name 字段而不会中断服务。
新的规范化服务通常代表新软件或更新的软件，而规范化服务消失通常意味着服务弃用。您能否了解服务、方案和项目容量的历史性能，取决于您在其整个生命周期内维护 Cloud Service Mesh 中该服务的单一概念情况。
请注意，这与虚拟机实例、Kubernetes Pod/Deployment 甚至整个集群等低级资源有所不同，这些资源在您更新和维护生产系统过程中通常会发生变化。