本页介绍了客户托管型部署最常见的架构模式，并介绍了实现这些模式的最佳实践。若要有效使用本页面，您应熟悉系统架构概念和实践。
工作流策略
确定自行托管是实现 Looker 的可行方案后，下一步就是详细说明部署要采用的策略。
- 进行评估。确定计划的和现有工作流的候选列表。
- 列出适用的架构模式。从确定的候选工作流开始，确定适用的架构模式。
- 确定优先级并选择最佳架构模式。使架构模式与最重要的任务和结果保持一致。
- 配置架构组件并部署 Looker 应用。实现建立安全客户端连接所需的主机、第三方依赖项和网络拓扑。
架构选项
专用虚拟机
一种方法是在专用虚拟机 (VM) 中将 Looker 作为单个实例运行。单个实例可以通过纵向伸缩主机并增加默认线程池来处理要求苛刻的工作负载。但是，管理大型 Java 堆的处理开销会导致垂直伸缩受到边际效益递减规律的约束。对于中小型工作负载，通常可以接受。下图描绘了在专用虚拟机中运行的 Looker 实例、本地和远程代码库、SMTP 服务器以及此选项的优势和最佳实践部分中突出显示的数据源之间的默认和可选设置。
优点
- 专用虚拟机易于部署和维护。
- 内部数据库托管在 Looker 应用中。
- Looker 模型、Git 代码库、SMTP 服务器和后端数据库组件可在本地或远程配置。
- 您可以将 Looker 的默认 SMTP 服务器替换为您自己的服务器，以便接收电子邮件通知和执行定期任务。
最佳做法
- 默认情况下，Looker 可以为项目生成裸 Git 代码库。我们建议您设置远程 Git 代码库以实现冗余。
-
默认情况下，Looker 会先使用内存中 HyperSQL 数据库。此数据库既方便又轻量，但如果使用频繁，可能会出现性能问题。对于较大的部署，我们建议使用 MySQL 数据库。我们建议在
~/looker/.db/looker.script文件达到 600 MB 时迁移到远程 MySQL 数据库。 - 您的 Looker 部署需要通过 Looker 许可服务进行验证；必须有端口 443 上的出站流量。
- 您可以通过增加可用资源和 Looker 线程池来垂直扩缩专用虚拟机部署。不过，增加 RAM 的效果会随着 RAM 达到 64 GB 而递减，因为垃圾回收事件是单线程的，会暂停所有其他线程的执行。16 个 CPU 和 64 GB RAM 的节点在价格和性能之间取得了良好的平衡。
- 我们建议您的部署的存储空间每 GB 每秒有 2 次操作 (IOPS)。
虚拟机集群
将 Looker 作为多个虚拟机中的实例集群运行是一种灵活的模式，可受益于服务故障切换和冗余。水平可伸缩性可提高吞吐量，而不会出现堆膨胀和过多垃圾回收开销。节点可以选择专用工作负载，从而根据不同的业务需求量身定制多种部署选项。集群部署需要至少有一位熟悉 Linux 系统并能够管理组件部分的系统管理员。
标准集群
对于大多数标准部署，一个由完全相同的服务节点组成的集群就足够了。集群中的所有节点都采用相同的配置，并且都位于同一负载平衡器池中。在此配置中，任何节点都不会更有可能或更不可能处理 Looker 用户请求、渲染任务、安排的任务、API 请求等。
如果大多数请求直接来自正在运行查询并与 Looker 互动的 Looker 用户，则适合使用此类配置。当调度程序、渲染程序或其他来源发出大量请求时，该机制就会开始崩溃。在这种情况下，指定特定服务节点来处理时间表和渲染等任务会很有帮助。
例如，用户通常会安排在周一上午运行数据传送。当 Looker 处理排队的预定请求时，尝试在周一上午运行 Looker 查询的用户可能会遇到性能问题。通过增加服务节点的数量，集群可使 Looker 的所有功能的吞吐量成比例增加。
下图展示了用户、应用和脚本发送到 Looker 的请求如何在集群化 Looker 实例中进行负载均衡。
优点
- 标准集群通过对集群拓扑进行最少的配置来最大限度地提高整体吞吐量。
- Java VM 在分配内存阈值 64 GB 时会出现性能下降；因此，横向伸缩比纵向伸缩能带来更大的回报。
- 集群配置可确保服务冗余和故障切换。
最佳做法
- 每个 Looker 节点都应托管在自己的专用虚拟机中。
- 负载均衡器（即集群入站点）应为第 4 层负载均衡器。它应具有较长的超时时间（3,600 秒），配备已签名的 SSL 证书，并配置为从 443（https）端口转发到 9999（Looker 服务器监听的端口）。
- 我们建议您的部署的存储空间每 GB 有 2 IOPS。
开发/预演/生产
对于以向最终用户提供尽可能长的内容正常运行时间为首要任务的用例，我们建议使用单独的 Looker 环境来将开发工作和分析工作分隔开来。通过在隔离的开发和测试环境后面控制生产环境更改，这种架构可确保生产环境尽可能稳定。
要想获得这些优势，您需要设置互联的环境并采用稳健的发布周期。开发/预演/生产环境部署还需要一支熟悉 Looker API 和 Git 的工作流管理的开发者团队。
下图描绘了 LookML 开发者（在开发环境实例中开发内容）、质量检查 (QA) 测试人员（在 QA 环境实例中测试内容）以及在生产环境实例中使用内容的用户、应用和脚本之间的内容流。
优点
- LookML 和内容验证是在非生产环境中进行的，确保对模型逻辑的任何修改都能在面向生产环境用户之前得到彻底审核。
- 在正式版环境中启用实例级功能（例如实验室功能或身份验证协议）之前，您可以单独对其进行测试。
- 您可以在非生产环境中测试数据集群和缓存政策。
- Looker 正式版模式测试与负责为最终用户提供服务的正式版环境分离。
- Looker 版本可以在非生产环境中进行测试，这样您就有充足的时间在更新生产环境之前测试新功能、工作流程更改和问题。
最佳做法
- 在至少三个单独的实例中隔离同时发生的各种活动：
- 开发实例：开发者使用开发环境提交代码、开展实验、修复 bug 并安全地犯错。
- 质量检查实例：也称为测试或预演环境，这是开发者运行手动测试和自动化测试的地方。质量检查环境非常复杂，可能会消耗大量资源。
- 生产环境实例：这是为客户和/或企业创造价值的地方。生产环境是高度公开的环境，应不含错误。
- 维护可重复的发布周期工作流。
- 如果需要为大量开发者和质量检查测试人员提供服务，则可以将开发和/或质量检查实例进行集群。无论是作为独立虚拟机还是虚拟机集群保留，开发和质量检查实例都需要遵循之前在各个部分中介绍的相同架构注意事项。
高调度吞吐量
对于需要高安排的数据传送吞吐量和及时可靠的传送的用例，我们建议配置包含一个集群，其中包含一个专门用于安排的节点池。此配置有助于确保 Web 应用和嵌入式应用快速响应。若要获得这些优势，您需要使用自定义的启动选项和适当的负载均衡规则来设置节点，如以下图所示，并遵循此选项的优势和最佳实践部分中所述的说明。
优点
- 为特定函数专用节点可将资源划分为开发和临时分析函数的调度资源。
- 用户无需占用负责处理定期数据传送的节点的周期，即可开发 LookML 并探索内容。
- 引导到常规节点的高用户流量不会妨碍调度节点为调度工作负载提供服务。
最佳做法
- 每个 Looker 节点都应托管在自己的专用虚拟机中。
- 负载均衡器（即集群入站点）应为第 4 层负载均衡器。它应具有较长的超时时间（3,600 秒），配备已签名的 SSL 证书，并配置为将端口从 443（https）转发到 9999（Looker 服务器监听的端口）。
- 从负载均衡规则中省略调度程序节点，以便它们不会处理最终用户流量和内部 API 请求。
- 我们建议您的部署的存储空间每 GB 有 2 IOPS。
高渲染吞吐量
对于需要高渲染报告吞吐量的用例，我们建议配置一个集群，其中包含一组专用于渲染的节点。在 Looker 中，渲染 PDF 文件或 PNG/JPEG 图片是一项相对耗费资源的操作。渲染可能需要大量内存和 CPU，当 Linux 面临内存压力时，可能会终止正在运行的进程。由于无法预先确定渲染作业的内存用量，因此启动渲染作业可能会导致 Looker 进程被终止。配置专用渲染节点可对渲染作业进行最佳调优，同时保持交互式和嵌入式应用的响应速度。
如需获得这些优势，您需要使用自定义的启动选项和适当的负载均衡规则设置节点，如以下图所示，并参阅此选项的优势和最佳实践部分。此外，渲染节点可能需要的宿主资源比标准节点多，因为 Looker 的渲染服务依赖于共享 CPU 时间和内存的第三方 Chromium 进程。
优点
- 为特定函数专用节点可将用于渲染的资源与开发和临时分析函数隔离开来。
- 用户无需占用负责渲染 PNG 和 PDF 的节点的周期，即可开发 LookML 并探索内容。
- 引导到常规节点的高用户流量不会妨碍由渲染节点提供服务的渲染工作负载。
最佳做法
- 每个 Looker 节点都应托管在自己的专用虚拟机中。
- 负载均衡器（即集群入站点）应为第 4 层负载均衡器。它应具有较长的超时时间（3,600 秒），配备已签名的 SSL 证书，并配置为将端口从 443（https）转发到 9999（Looker 服务器监听的端口）。
- 从负载均衡规则中省略渲染节点，以便它们不会处理最终用户流量和内部 API 请求。
- 在渲染节点中向 Java 分配的内存相对较少，以便为 Chromium 的进程提供更大的内存缓冲区。请勿向 Java 分配 60% 的内存，而应分配 40-50% 的内存。
- 非渲染节点的内存压力风险已降低，因此可以增加专用于 Looker 的内存量。请考虑使用更高的百分比（例如 80%），而不是默认的 60%。
- 我们建议您的部署的存储空间每 GB 有 2 IOPS。