本页面是多篇系列文章中的一篇，该系列讨论了 Looker 托管、部署方法以及相关组件的最佳实践。本页面介绍了客户托管的部署中最常见的架构模式，并介绍了实现这些架构的最佳实践。为了有效地使用本页，您应该熟悉系统架构概念和做法。
本系列文章包含三部分：
- 客户托管的基础架构概览
- 客户托管的基础架构架构模式（本页）
- 客户托管的基础架构组件演示
工作流程策略
在确定实现 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 在达到 64 GB 后会受到返回值递减的影响，因为垃圾回收事件是单线程的，会让所有其他线程停止执行。配备 16 个 CPU 和 64 GB RAM 的节点能够很好地平衡性价比。
- 我们建议您的部署使用每 GB 每秒操作次数 (IOPS) 2 次的存储空间。
虚拟机集群
将 Looker 作为实例集群运行在多个虚拟机中是一种灵活的模式，可受益于服务故障切换和冗余。横向可伸缩性可提供更高的吞吐量，而不会出现堆膨胀和过多的垃圾回收成本。节点可以选择工作负载专用选项，这样就可以根据不同的业务需求定制多个部署选项。集群部署至少需要一名熟悉 Linux 系统并能够管理组件的系统管理员。
标准集群
对于大多数标准部署，使用相同服务节点的集群就足够了。集群中的所有节点都采用相同的配置方式，并且都位于同一负载平衡器池中。此配置中的所有节点都不太可能处理 Looker 用户请求、渲染任务、计划任务、API 请求等。
当大多数请求直接来自正在运行查询并与 Looker 交互的 Looker 用户时，这种配置非常合适。当大量请求来自调度器、渲染程序或其他来源时，它就会开始分解。在这种情况下，最好指定某些服务节点来处理调度和渲染等任务。
例如，用户通常会安排在星期一早上运行报告。如果用户在周一早上尝试运行 Looker 查询，那么在 Looker 处理积压的计划请求时可能会遇到性能问题。通过增加服务节点的数量，集群可以在所有 Looker 功能之间按比例提升吞吐量。
下图描绘了用户、应用和脚本向 Looker 发出的请求如何在一个集群的 Looker 实例之间保持平衡。
优点
- 标准集群在整个过程中只需最低限度的集群拓扑配置即可实现总体最大化。
- 当分配的内存阈值为 64 GB 时，Java 虚拟机会发生性能下降；因此，横向伸缩的回报大于纵向伸缩。
- 集群配置可确保服务冗余和故障切换。
最佳做法
- 每个 Looker 节点都应托管在各自的专用虚拟机中。
- 负载均衡器（集群入站流量点）应该是第 4 层负载均衡器。它应具有很长的超时时间（3,600 秒），配备有已签名的 SSL 证书，并配置为从 443 (https) 端口转发到 9999（端口 Looker 服务器监听）。
- 我们建议您的部署使用每 GB 2 IOPS。
开发/预演/正式版
对于优先为最终用户提供最长内容正常运行时间的用例，我们建议采用单独的 Looker 环境，将开发工作和分析工作分隔开来。此架构将生产环境的更改控制在独立的开发和测试环境之后，以保持尽可能稳定的生产环境。
这些优势需要设置相互连接的环境，并采用可靠的发布周期。开发/预演/生产部署还需要一个熟悉 Looker API 和 Git 的开发者团队来管理工作流。
下图描绘了在开发实例上开发内容的 LookML 开发者、在质量检查实例上测试内容的质量保证 (QA) 测试人员，以及生产环境实例上使用相应内容的用户、应用和脚本之间的内容流。
优点
- LookML 和内容验证是在非生产环境中进行，从而确保对模型逻辑的任何修改都经过全面审查，然后才到达生产用户。
- 在生产环境中启用实例级功能（例如实验室功能或身份验证协议）之前，可以进行单独测试。
- 数据组和缓存政策可以在非生产环境中测试。
- Looker 生产模式测试与负责为最终用户提供服务的生产环境分离。
- Looker 版本可以在非生产环境中进行测试，让您有充足的时间在更新生产环境之前测试新功能、工作流变更和问题。
最佳做法
- 隔离至少三个单独实例中同时发生的各种 activity：
- 开发实例：开发者使用开发环境提交代码、进行实验、修复 bug 并放心地犯错。
- QA 实例：也称为“测试”或“预演”环境，开发者在此环境中运行手动和自动测试。QA 环境很复杂，会消耗大量的资源。
- 生产环境实例：即为客户和/或企业创造价值的阶段。生产环境是一个可见度高的环境，应该没有错误。
- 维护有记录且可重复的发布周期工作流。
- 如果需要为大量开发者和 QA 测试人员提供服务，则可以对开发和/或 QA 实例进行聚类。无论是作为独立虚拟机还是虚拟机集群保留，开发实例和质量检查实例在架构方面需要考虑上述各个部分介绍的相同。
高调度吞吐量
对于需要高定期报告吞吐量和及时可靠交付的用例，我们建议在配置中添加一个集群，其中包含一个专用于安排的节点池。此配置将有助于保持 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 进程。
优点
- 为特定函数指定节点可将开发函数和临时分析函数用于渲染的资源分隔开来。
- 用户可以开发 LookML 并探索内容，而无需从负责渲染 PNG 和 PDF 的节点占用循环。
- 流向常规节点的高用户流量不会影响由渲染节点服务的工作负载。
最佳做法
- 每个 Looker 节点都应托管在各自的专用虚拟机中。
- 负载均衡器（集群入站流量点）应该是第 4 层负载均衡器。它应具有很长的超时时间（3,600 秒），配备有已签名的 SSL 证书，并配置为从 443 (https) 端口转发到 9999（端口 Looker 服务器监听）。
- 从负载均衡规则中省略渲染节点，使这些节点不处理最终用户流量和内部 API 请求。
- 在渲染节点中，为 Java 分配相对较少的内存，以便为 Chromium 进程提供更大的内存缓冲区。不要将 60% 的内存分配给 Java，而是分配 40-50% 的内存。
- 非渲染节点上内存压力的风险已降低，因此可以增加专用于 Looker 的内存量。请考虑使用一个较大的数字，例如 80%，而不是默认的 60%。
- 我们建议您的部署使用每 GB 2 IOPS。