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