架构需求
摘要
OpenTelemetry 社区演示应用旨在成为生产轻量级云原生应用中 OpenTelemetry API、SDK 和工具的“展示窗口”。这个应用的总体目标不仅是提供 OpenTelemetry 组件的规范“演示”，还可以作为最终用户、供应商和其他相关方进一步自定义的框架。
需求
应用目标
- 为开发人员提供一个强大的示例应用，以便他们在学习 OpenTelemetry 仪表化时使用。
- 为可观察性供应商提供一个单一且得到良好支持的演示平台，以便他们可以进一步自定义（或直接使用）。
- 为 OpenTelemetry 社区提供一个可以展示 OTel API、SDK 和工具的功能和能力的实物。
- 为 OpenTelemetry 维护人员和工作组提供一个展示新特性/概念“实际应用”的平台。
下面是演示应用的逻辑组件的通用描述。
主应用
演示应用的主体部分是一个独立的基于微服务的应用程序，执行一些有用的“现实世界”工作，比如一个电子商务网站。这个应用由多个服务组成，它们通过 gRPC 和 HTTP 彼此通信，并在 Kubernetes（或本地 Docker）上运行。
每个服务都应该使用 OpenTelemetry 进行追踪、度量和日志记录（适用/可用时）。
每个服务应该可以替换为执行相同业务逻辑、实现相同 gRPC 端点的服务，但由不同的语言/实现编写。对于演示的初始实现，我们应该着重于将现有服务替换为使用未支持的语言编写的实现。在未来的版本中，我们将尝试为每个服务添加更多不同的语言选项。
每个服务应该与一个功能标志服务进行通信，以便启用/禁用可用于说明遥测如何解决分布式应用中的问题的“故障”。
应该向主应用添加一个 PHP 服务作为“管理服务”。还应该添加一个数据库以实现对产品目录的增删改查功能。
应该使用 Rust 重新实现“shippingservice”服务。
应该使用 C++ 重新实现“currencyservice”服务。
应该使用 Ruby 重新实现“emailservice”服务。
对于将来的迭代，可以在“前端”服务中扩展一个使用 Swift 编写的移动应用程序。
功能标志组件
该组件应该由一个（或多个）服务组成，为主应用提供一个简单的功能标志配置工具。它由一个基于浏览器的客户端/管理员界面和一个后端服务或服务组成。客户端的作用是允许操作员可视化可用的功能标志并切换它们的状态。服务器应该提供一个功能标志目录，主应用服务可以注册并查询其当前状态和定位规则。
功能标志组件应该采用 Erlang+Elixir/Phoenix 服务实现。功能标志目录应该存储在数据库中。
编排和部署
所有服务都应该在 Kubernetes 上运行。OpenTelemetry Collector 应该通过 OpenTelemetry Operator 部署，并以边车+网关模式运行。每个 pod 的遥测数据应该从代理路由到网关，并且默认情况下，网关应该将遥测导出到一个开源的跟踪+度量可视化工具。
对于本地/非 Kubernetes 部署，Collector 应该通过组合文件部署，并且不仅监视应用程序的遥测数据，还监视 dockerstatsreceiver 所代表的 Docker 容器。
这个项目的设计目标之一是包含一个用于自我部署到云环境的 CI/CD 流水线。对于本地开发，可以跳过该步骤。