微服务

本主题介绍在堆栈面向服务或依赖于微服务时实现云眼灰度实验的最佳实践和特殊注意事项。

如果堆栈面向服务或依赖于微服务，则应了解一些实现 云眼 功能实验的最佳实践和特殊注意事项。

面向服务的网站有两个实现选项：将 云眼 用作服务或在每个服务中包含 云眼 功能实验 SDK。本主题介绍每个选项的优缺点。

选项 1：将优化用作服务

如果堆栈是面向服务的，并且将从集中式决策服务中受益，我们强烈建议使用 云眼 Agent，这是一种云眼开发的开源服务，在具有自定义配置选项的 docker 容器中运行 Go SDK。云眼 代理公开映射到所有 云眼 功能实验 SDK 函数的 HTTP 终结点。

这种方法的优点是集中了具有挑战性的任务，如数据文件管理和事件调度。您只需实施一次这些解决方案，团队在开始测试时无需担心它们。仅在一个位置处理数据文件和事件调度到 云眼 可减少整体设置和维护工作。

此方法的缺点是需要对 云眼 Agent 进行网络调用来确定是激活实验还是授予用户对标帜变体的访问权限。与 云眼 Agent 通信比直接在服务中使用 云眼 功能实验 SDK 具有更高的延迟。

选项 2：在每个核心服务中安装云眼灰度实验 SDK

在此方法中，你将在每个服务中包含云眼灰度实验 SDK 的实例，并依靠 SDK 的确定性和无状态性质来向用户显示每个服务中的相同体验。如果选择此选项，则需要在 SDK 的所有实例之间同步数据文件。

此选项的主要优点是它保留了 SDK 的微秒级延迟决策。它比选项 1 的性能更高，因为所有决策都是在内存中做出的，无需对服务进行网络调用。此选项也更具可配置性：每个团队设置最适合其实现的 SDK。

此选项的缺点是团队必须自己实现其 SDK，并且维护成本会增加。例如，如果 云眼 发布了新的 SDK，则需要在安装了 SDK 的每个服务中更新该 SDK。

📘 注意

尽管此方法要求跨服务同步数据文件，但大多数客户发现他们不需要在所有位置强制实施精确同步。只要每个实现的缓存过期时间相对较短，偶尔出现短暂的差异就可以了。