案例分享：NGINX 助力 HCS 构建灵活的前端应用层

荷兰的一家政府机构有着多种的利益相关者和用户，希望将其工作流从纸质流程转向现代数字基础架构，以便提高运营效率，并减轻其用户和员工的操作流程。

这将面临哪些挑战呢？该机构允许每个参与环节制定一些独特流程并提出相关特殊要求。最初，这家机构付出了巨大的努力试图开发一款具有大量定制功能且保罗万象的单体应用，然而，这一努力终因过度定制而失败 — 用一个词形容就是众口难调。于是，该机构委托荷兰专业开源和 Red Hat® 技术 IT 咨询公司（HCS 公司）尝试采用不同的方法助其实现工作流数字化。

 

轻松重建：可灵活组合的微前端、容器及微服务

该机构的 DevOps 团队与 HCS 首席站点可靠性工程师 (SRE) Benoit Schipper 合作开展了该项目。他们首先一同深入分析了所要解决的问题。政府官员、律师、会计师和居民等各色用户都需要登录该机构的应用，查看项目或流程的状态，并上传 PDF。最终 Benoit 和 DevOps 团队决定，首先需要构建一个简单的基础。Benoit 解释道：“我们分析后认为：我们要先建立通用基础，对于任何特殊要求，均可基于此通用基础而构建。”DevOps 团队还希望该基础能够满足未来需求，确保现有基础架构的可扩展性，并能够支持未来可能需要的其他位置和应用。

Benoit 和 DevOps 团队构思并设计了一种独特新颖的极小（微型）前端架构，它可以组成不同的应用以映射到后端不同的小型服务（微服务）。Benoit 表示：“我们选择了微服务，因为借助这种架构，您可以随时上云，并随其发展而不断扩展。它就像是一张拼图，可拆分成许多可拼接的碎片。”

在实施方面的首要决策是将专用环境中的 Microsoft Windows 服务器迁移到云端基于容器的环境，后者更适合可灵活组合的微服务。该团队选择使用 Red Hat OpenShift® 作为容器平台。

OpenShift 具有两大优势。首先，RedHat 拥有与政府长期合作的丰富经验，因此其设计很容易获得政府批准。其次，OpenShift 提供了许多工具和应用，可轻松构建并维护微服务和微服务架构，包括：

• Red Hat Ceph® Storage – 可通过 S3 兼容 API 访问的 blob 存储服务
• Red Hat AMQ Broker – 一种消息总线服务，用于管理工作负载和应用状态并对 worker 进行队列化
• 对 Kubernetes 的内置认证支持 — 如果 HCS 和该机构确定 Kubernetes 是合适的容器编排工具，那么对 Kubernetes 的内置认证支持对于进一步满足未来需求而言至关重要

 

从 Windows 到 Linux、.Net Core 及 NGINX 开源版

转向容器意味着替换该机构以前的 .Net 后端，后者在 Windows 服务器上运行。幸运的是，很容易迁移到针对容器优化的 .Net 版本 .Net Core。另一个好处是，该机构的开发人员可以继续使用他们熟悉的 Windows 应用语言和框架进行编码。

DevOps 团队构建了一组核心 REST API，用于访问 .Net Core 后端服务。这组 API 是将应用功能和逻辑及微前端整合在一起的粘合剂。对于前端环境，该团队选择了 AngularJS，因为它是一个强大、可靠的 JavaScript 框架并拥有强大社区，得到了政府组织的广泛认可。

为了在前端和后端之间创建一个统一的路由层，用于流量和 API 调用的交互，DevOps 团队探索了多种选择后最终确定了 NGINX 开源版，因为它具有多功能性。该机构网站上的页面是通过动态组合微前端来构建的，通过引入内容元素和使用相同的 CSS 逻辑来“润色”多个后端服务。对用户来说，看似一切都在同一个应用中进行——“但实际上我们使用了 NGINX 的智能代理和重写。为了在前端屏幕上填充适当信息，我们通过 NGINX 进行后端 API 调用”，Benoit 解释道。

为了将应用暴露到公共互联网，Benoit 在该机构 DMZ 中运行的虚拟机上部署了一个 F5 NGINX Plus 实例作为 Web 服务器和反向代理。他解释了为何 NGINX Plus 是理想之选：“我们需要 TLS 1.3，并希望实现更高效的处理。与专用设备相比，它经济实惠，并支持轻松添加许可。”

Benoit 强调，对于该机构而言，“NGINX 充当了我们应用层的 Web 服务器、代理和基本 API 网关，堪称“万能工具”，几乎可以搞定一切。因此我们选择了它。”举例来说，若要检索上传的 PDF，用户需要从其帐户上传的文档中选择所需的 PDF，PDF 交付应用会向附加到 Ceph 对象存储的后端 PDF 检索服务发送请求。Ceph 返回 PDF 在对象存储中位置的唯一 URL，以供用户点击查看或下载。

由于该应用为关键任务应用，因此 DevOps 团队设计了一个双活高可用性架构，其中所有应用至少在两个集群中运行。这为所有服务、微前端和 API 提供了冗余功能，可确保它们在其中一个集群发生中断时仍能正常运行。

为了提高性能并为跨多个服务的复合应用启用控制平面，该团队使用 AMQ Broker 消息总线为服务配置主题和队列。Benoit 表示：“若有可能在后台运行的话，我们会在后台进行。如果有消息传入并需要调整某些方法数据，我们的监听器能够处理一些工作，或者找到 worker 来运行这个过程。”为了确保用户在集群之间的状态一致性，该团队保留了其现有的高可用 Microsoft SQL Server 数据库架构，以维护 pod 状态并实现会话保持。

 

专为可观测性、可扩展性和灵活性而设计

在可观测性方面，Benoit 推荐 Grafana 作为云原生仪表盘。为了获得 NGINX 指标，DevOps 团队在与每个 pod 配对的 sidecar 中使用了 NGINX Prometheus Exporter。Exporter 可从 NGINX 开源版 Stub Status 模块和 NGINX Plus API 中抓取四层指标，将每个指标与字符串相匹配，创建键值对，并将该键值对推送到 Prometheus。由此，该键值对被发布到一个单独的 Grafana 实例，该实例仅暴露给开发人员和 DevOps 团队。Benoit 表示：“太神奇了。我可以跨所有 NGINX 开源版和 NGINX Plus 实例集中构建仪表盘并收集指标。DevOps 团队掌控一切。他们可以查看运行项目并收到问题警报。”

该团队还利用这些指标对应用进行性能管理。Prometheus 会针对应用中的异常情况和未处理连接发出警报，提示 worker 运行数量不足。Benoit 已将这些指标与 OpenShift 的自动扩展功能相关联。他解释道：“我已经为一定数量的 worker 配置了 NGINX 设置，并计算了所需的 RAM 和 CPU 资源。如果应用过于繁忙，OpenShift 会自动扩展并向我发出警报。”

当渗透测试表明应用没有采用强内容安全防护策略（CSP）时，该团队可利用 CSP 的内联执行策略来配置 NGINX 开源版和 NGINX Plus。他们还设置了自定义配置，以便从容器平台拉取 JSON 日志记录信息，并将其发送到 Splunk 日志记录平台进行历史分析和记录保存。

 

改进开发人员体验

对于使用 Google Analytics 和 Lighthouse 的前端开发人员而言，HCS 能够将 Lighthouse 检查添加到该机构的流水线（编码到 NGINX 配置中）。Benoit 表示：“我们很快发现，通过改用 GZIP 压缩库，我们可以显著提高性能”，应用延迟最终降低了 60%。

此外，有了新架构，开发人员现在可以直接联系最终用户，因为他们拥有对实时行为的详尽可见性。Benoit 表示：“反馈环更快了，如果某个组件因故需要进行调整，现在只需一天便可完成并恢复正常运行。这一速度对政府机构来说非常快，因为过去需要耗时数月甚至数年才能完成。对于我们的开发人员来说，真的是天壤之别。”

 

技术栈

• 后端 – .Net Core
• 前端 – AngularJS
• 网络连接（Web 服务器、反向代理、API 网关、Ingress Controller、全局负载均衡） – NGINX 开源版、NGINX Plus、F5 BIG‑IP、HAProxy（基于 OpenShift）
• 数据库 – Microsoft SQL Server、Red Hat Ceph Storage、用于 Lighthouse 数据的 InfluxDB
• CI/CD – Azure DevOps
• 基础架构 – Red Hat OpenShift、Linux 容器
• 消息传递 – Red Hat AMQ Broker（Active MQ 开源版）
• 可观测性和指标 – Grafana、Prometheus
• 日志记录 – Splunk

 

立即免费试用

心动不如行动。希望在 NGINX Plus 上构建您的技术栈以收获同样的成果吗？立即下载 30 天免费试用版，或者联系我们讨论您的用例。