架构要求
摘要
OpenTelemetry 社区演示应用程序旨在成为一个生产级 Lite 云原生应用程序中 OpenTelemetry API、SDK 和工具的展示。该应用程序的总体目标不仅是提供 OpenTelemetry 组件的规范化“演示”，而且还充当了一个框架，供最终用户、供应商和其他利益相关者进行进一步的定制。
要求
应用目标
- 为开发人员提供一个强大的示例应用程序，可用于学习 OpenTelemetry 仪器。
- 为可观测性供应商提供一个单一的、受良好支持的演示平台，他们可以在此平台上进行进一步的定制（或直接使用 OOB）。
- 为 OpenTelemetry 社区提供一个活动的产物，展示 OTel API、SDK 和工具的功能和能力。
- 为 OpenTelemetry 维护者和工作组提供一个平台，以便在“实战”中展示新功能/概念。
以下是演示应用程序逻辑组件的一般描述。
主应用程序
演示应用程序的大部分是一个自包含的、基于微服务的应用程序，它执行一些有用的“真实世界”任务，例如电子商务网站。该应用程序由多个服务组成，它们通过 gRPC 和 HTTP 进行通信，并在 Kubernetes（或本地 Docker）上运行。
每个服务都应使用 OpenTelemetry 进行仪器化，以处理跟踪、指标和日志（如果适用/可用）。
每个服务都应可与执行相同业务逻辑的服务互换，实现相同的 gRPC 端点，但使用不同的语言/实现编写。
每个服务都应能够与功能开关服务进行通信，以便启用/禁用可用于说明遥测如何解决分布式应用程序中的问题的故障。
功能开关组件
功能开关是云原生应用程序开发的关键部分。该演示使用 CNCF 孵化项目 OpenFeature 来管理功能开关。
可以通过 flagd 配置器用户界面设置功能开关。
编排与部署
所有服务都在 Kubernetes 上运行。OpenTelemetry Collector 应通过 OpenTelemetry Operator 部署，并以 sidecar + gateway 模式运行。来自每个 pod 的遥测数据应从代理路由到一个网关，该网关默认将遥测数据导出到一个开源的跟踪+指标可视化器。
对于本地/非 Kubernetes 部署，Collector 应通过 compose 文件部署，并不仅监控应用程序的跟踪/指标，还通过 dockerstatsreceiver 监控 docker 容器。
该项目的设计目标之一是包含一个 CI/CD 管道，用于将应用程序自部署到云环境中。本地开发可以跳过此步骤。