本页介绍了客户托管型部署最常见的架构模式，并介绍了实现这些模式的最佳实践。为了有效地使用此页面，您应该熟悉系统架构概念和做法。
工作流策略
确定自行托管是实现 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，则增加 RAM 的效果会逐渐递减，因为垃圾回收事件是单线程的，会暂停所有其他线程的执行。配备 16 个 CPU 和 64 GB RAM 的节点可在价格与性能之间取得较好的平衡。
- 我们建议您的部署的存储空间每 GB 每秒有 2 次操作 (IOPS)。
虚拟机集群
将 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) 测试人员（在 QA 环境实例中测试内容）以及在生产环境实例中使用内容的用户、应用和脚本之间的内容流。
优点
- LookML 和内容验证在非生产环境中进行，可确保对模型逻辑的任何修改都经过全面审核，然后才提供给生产用户。
- 实例级功能，例如 在生产环境中启用实验室功能或身份验证协议之前，可对其进行隔离测试。
- 您可以在非生产环境中测试数据集群和缓存政策。
- Looker 生产模式测试与负责为最终用户提供服务的生产环境相互分离。
- Looker 版本可以在非生产环境中进行测试，这样您就有充足的时间在更新生产环境之前测试新功能、工作流程更改和问题。
最佳做法
- 在至少三个单独的实例中隔离同时发生的各种活动：
- 开发实例：开发者使用开发环境来提交代码、进行实验、修复 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 进程提供更大的内存缓冲区。而不是为 Java 分配 60% 的内存，而是分配 40-50% 的内存。
- 非渲染节点的内存压力风险已降低，因此可以增加专用于 Looker 的内存量。请考虑使用更高的百分比（例如 80%），而不是默认的 60%。
- 我们建议您为部署使用每 GB 2 IOPS 的存储空间。