HCS 使用 NGINX 构建灵活的前端application层

荷兰的一个国家政府机构拥有多种利益相关者和用户，该机构希望将其工作流程从纸质流程转移到现代数字基础设施。 这将使该机构能够更快地采取行动并简化其用户和员工的生活。

挑战？ 该机构允许每个参与地方制定略显独特的流程和要求。 最初，该机构付出了巨大的努力来创建一个包含大量定制功能的包罗万象的整体式应用。 第一次尝试因过度定制而失败——“上千个要求导致失败”。 HCS Company是一家专门从事开源和 Red Hat® 技术的荷兰 IT 咨询公司，该公司被邀请尝试以不同的方式将该机构的流程数字化。

重建简单： 可组合的微前端、容器和微服务

该机构的 DevOps 团队与 HCS 的首席站点可靠性工程师 (SRE) Benoit Schipper 合作开展该项目。 他们首先一起深入研究了他们正在解决的问题。 从政府官员到律师、会计师和普通公民的用户都需要登录机构应用程序，检查项目或流程的状态，并上传 PDF。 Benoit 和团队决定构建一个简单的基础作为解决方案的起点。 Benoit 解释道，“我们看到了这一点，并说‘让我们制作一些非常通用的东西，对于任何特殊要求，我们都可以在通用的基础上进行构建’”。 DevOps 团队还希望基础能够面向未来，确保现有基础设施以及未来可能需要的其他位置和应用的可扩展性。

Benoit 和团队在白板上描绘了未来，并设计出了一种新颖的架构，它由非常小（微）的前端组成，可以组合成不同的应用，并映射到后端的小型、独特的服务（微服务）。 Benoit 表示：“我们选择微服务是因为有了这种架构，你就可以迁移到云端，而且在规模变得很大时还可以进行扩展。” “我们将拼图分成可以粘在一起的小块。”

关于实施的第一个决定是从专用环境中的 Microsoft Windows 服务器迁移到云中的基于容器的环境，这更适合可组合和灵活的微服务。 该团队选择Red Hat OpenShift®作为容器平台。

OpenShift 有两个有利的因素。 首先，RedHat 长期与政府合作的经验使其设计很容易获得政府批准。 其次，OpenShift 包含许多专为轻松构建和维护微服务和微服务架构而设计的工具和应用，其中包括：

• Red Hat Ceph® 存储– 可通过 S3 兼容 API 访问的 Blob 存储服务
• Red Hat AMQ Broker – 用于管理工作负载和应用状态以及排队工作者的消息总线服务
• 内置、经过认证的 Kubernetes 支持——如果 HCS 和该机构确定 Kubernetes 是适合容器编排的工具，那么这对于进一步确保未来发展至关重要

从 Windows 到 Linux、.Net Core 和 NGINX 开源

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

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

为了在前端和后端之间创建一个用于流量和 API 调用的统一路由层，团队探索了各种选项，最后由于其多功能性而选择了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，用户可以点击该 URL 进行查看或下载。

由于该应用是任务关键型的，因此该团队设计了一个主动高可用性架构，所有应用至少在两个集群中运行。 这为所有服务、微前端和 API 提供了冗余，确保它们在某个集群发生中断时能够继续工作。

为了提高性能并为跨多个服务的复合应用启用控制平面，团队使用 AMQ Broker 消息总线来为服务配置主题和队列。 “因此，只要有任何可以在后台运行的操作，我们就会在后台进行，”Benoit 说道。 “如果有消息进来并且需要调整某些方法数据，我们会有监听器来处理某些事情或者找到工作人员来运行该流程。” 为了确保跨集群用户的状态一致，团队保留了现有的高可用性Microsoft SQL Server数据库基础架构，以维护 pod 状态并实现会话持久性。

可观察性、可扩展性和灵活性的设计

为了提高可观察性，Benoit 推荐使用Grafana作为云原生仪表板。 为了获取 NGINX 指标，DevOps 团队利用与每个 pod 配对的 Sidecar 中的NGINX Prometheus Exporter 。 导出器从 NGINX 开源存根状态模块和NGINX Plus API 中抓取第 4 层指标，将每个指标与字符串匹配，创建键值对，然后将该键值对推送到Prometheus中。 从那里，该对被发布到一个单独的 Grafana 实例，该实例仅向开发人员和 DevOps 团队公开。 “这太棒了。 我可以在所有 NGINX 开源和 NGINX Plus 实例中在一个地方构建仪表板并收集指标。 DevOps 团队掌控一切。 他们可以看到正在运行的内容并获取问题警报，”Benoit 说道。

该团队还使用这些指标来管理应用的性能。 Prometheus 会对应用中的异常和未处理的连接生成警报，这表明运行的工作程序不够多。 Benoit 已将这些指标与 OpenShift 中的自动扩展功能联系起来。 他解释说，“我已经为一定数量的工作者配置了 NGINX 设置，并计算了所需的 RAM 和 CPU。 如果事情超出了基线，OpenShift 会自动扩展并向我发送警报。”

当渗透测试表明应用未使用强大的内容安全策略（CSP）时，该团队能够使用策略配置 NGINX Open Source 和 NGINX Plus，以在线实施 CSP。 他们还设置了自定义配置，从容器平台提取 JSON 日志信息并将其发送到Splunk日志平台进行历史分析和记录保存。

改善开发者体验

对于使用 Google Analytics 和Lighthouse的前端开发人员，HCS 可以将 Lighthouse 检查纳入机构的管道中，并编码到 NGINX 配置中。 Benoit 表示：“我们很快发现，通过改用 GZIP 压缩库，我们可以显著提高性能”，最终应用延迟改善了 60%。

此外，借助新的架构，开发人员现在可以直接与最终用户联系，因为他们可以如此详细地了解实时行为。 “反馈循环更快，如果发生某些事情并且需要更改，我们可以在一天之内投入生产。 对于政府来说，这已经非常快了，而过去的变革通常需要几个月甚至几年的时间。”Benoit 说道。 “对于我们的开发人员来说，这就像是白天与黑夜。”

技术栈

• 后端– .Net Core
• 前端——AngularJS
• 网络（Web 服务器、反向代理、API 网关、入口控制器、全局负载均衡器）– 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 天免费试用或联系我们讨论您的用例。