参考架构:利用 Citrix 和Red Hat OpenShift 进行基于微服务的应用交付

概述

Companya一直使用整体架构来开发主要在本地托管的系统应用程序。他们遇到了正常运行时间和性能不一致的问题,特别是对于远程用户而言,这种情况在疫情期间更加严重。作为迁移到云的努力的一部分,他们打算使用微服务架构。这种架构使他们能够开发具有更强恢复能力和可扩展性的新应用程序。

Companya 决定构建一对冗余的多云Red Hat OpenShift (RHOS) 集群。它们托管在Microsoft Azure 和 Amazon AWS 中,Citrix 为微服务实例提供负载平衡。这使他们能够为远程用户提供一个弹性环境,使他们能够以始终如一的良好性能访问关键的业务 Web 服务。

该参考架构解释了Companya如何规划其环境,托管云原生平台,开发新应用程序或迁移旧应用程序。

简介

A 公司决定与 Citrix 和 RHOS 一起开发基于云原生微服务的应用程序交付,为其企业带来多项好处,并最终提高工作效率。

云原生

开发云原生应用程序是为了利用云的分布式和可扩展特性。它包括企业生产力、运营效率和用户体验方面的许多好处。

云原生的好处

  • 容器化应用程序可在主机基础架构之间移植
  • 允许敏捷、持续的开发和交付
  • 使用云主机基础架构进行扩展
  • 支持高效的软件开发流程

Red Hat OpenShift

Red Hat OpenShift 是一款企业 Kubernetes 容器平台,可帮助企业跨混合云部署、运营和保护微服务应用。

Red Hat OpenShift (RHOS) 的优势

  • 高效管理 Kubernetes 云原生环境,以开发和运营业务关键型企业应用程序
  • 提高开发团队的生产力
  • 通过迅速向现有客户推出新服务来增加收入
  • 通过减少在管理和支持上花费的时间来减少运营开支

有关更多信息,请参阅 什么是Red Hat OpenShift?

Citrix

Citrix 根据要求为微服务环境中的流量管理提供灵活的拓扑,包括全网状、ServiceMesh Lite、单层和双层。

拓扑:

  • 全网状 — 全网状群集包括对各种微服务的支持,这些微服务需要在集群内的微服务之间进行东西向通信以及集群外部的南北 (N-S) 通信。
  • Service Mesh Lite-Ingress 解决方案通常对南北流量执行 L7 代理功能。服务网格精简版架构使用相同的入口解决方案来管理东西向(E-W)流量,并克服了 Kubernetes 内置服务的局限性。
  • 单层 — 单层集群包含微服务,这些微服务作为冗余副本运行,并且由外部负载均衡器提供南北流量。
  • 双层 — 双层架构还具有由外部负载均衡器传送的南北流量。然而,微服务还附加了一个网络组件,以支持使用本机群集服务未提供的其他网络协议和优化进行通信。

有关更多信息,请参阅: 如何加快使用基于微服务的应用程序的步伐

Citrix Ingress Controller (CIC) 的优点

  • 标准 Kubernetes Ingress 解决方案仅在第 7 层(HTTP 或 HTTPS 流量)提供负载均衡,而 CIC 还支持 TCP、TCP-SSL 和 UDP 流量
  • CIC 可跨多个云或本地数据中心无缝协作

Citrix ADC VPX 的好处

  • Citrix ADC VPX 提供企业级流量管理策略,例如重写和响应程序策略,用于在第 7 层高效地平衡流量负载,而 Kubernetes 没有提供
  • Citrix ADC VPX 还支持全局服务器负载平衡 (GSLB)

Citrix CPX 的好处

  • Citrix CPX 允许将 Citrix ADC 部署为数据平面代理,既可以作为入口网关,也可以作为基于 xDS 的服务网格中的边车。
  • 它在 Kubernetes 集群内的微服务之间提供第 7 层流量管理,而 Kubernetes 仅支持第 4 层。

有关更多信息,请参阅 Citrix Developer 文档

成功标准

A公司定义了一系列成功标准,这些标准构成了总体设计的基础。

注意:A 公司在生产试运行中部署 Apache Web 服务以进行远程用户验证。

成功标准

概念体系结构

基于上述要求,CompanyA 创建了以下高级概念架构。此架构满足所有初始要求,同时为 CompanyA 在未来扩展到更多用例奠定了基础。

概念体系结构

体系结构框架分为多个层。该框架为理解微服务基础架构的技术架构奠定了基础。所有层一起流动,创建完整的端到端解决方案。

在较高的层面上:

用户层: 用户层描述用于连接资源的最终用户环境和端点设备。

用户可以使用 Citrix Workspace 应用程序安全地连接到 Web 服务。或者,用户可以使用具有 HTTP/HTTPS 传输的标准浏览器连接到 Web 服务。

接入层: 接入层描述用户如何访问 Web 服务和南北流量传输。

  • Web 服务的主 FQDN 解析为 Citrix ADC VPX 上托管的名称服务器。
  • 运行 GSLB 的 Citrix ADC VPX 使用连接最少的 Content Switch 虚拟服务器的公有 IP 地址响应域名服务 (DNS) 查询。
  • 虚拟服务器由 Citrix Ingress Controller 配置为将连接转发到连接数最少的 Citrix CPX 托管的群集
  • 群集托管的 Citrix CPX 接受连接并响应 Citrix ADC VPX。它建立了一个流向 Web 服务的流程,通过该流量传送有效负载。

资源层: 资源层指定在此参考架构中以微服务形式交付给用户的应用程序。

  • 四个 Apache Web 服务以 RHOS Pod 的形式托管。它们是通过 RHOS 运营商中心部署的。

控制层: 控制层定义如何管理和监视资源。

  • Red Hat OpenShift 用于构建集群以及部署、管理和监控微服务资源。

主机层: 托管层定义承载资源(包括内存、存储和计算)的底层基础架构。

  • Microsoft Azure 和 Amazon AWS 是用于托管 RHOS 群集和微服务的公共 IaaS。

接下来的部分将更详细地介绍使用 Citrix 和 Red Hat OpenShift 交付基于微服务的应用程序的具体设计决策。

用户层

用户层是用户请求和访问受支持端点上的目标资源的地方。

用户层

用户可以使用 Citrix Workspace 应用程序安全地连接到 Web 服务。

  • Citrix Workspace — Web 服务作为应用程序发布在 Citrix Workspace 中。安装在用户终端上的 Citrix Workspace 应用程序将启动与 Citrix Cloud 中已发布应用程序的代理连接
  • Citrix Secure Internet Access — 与云托管的 Citrix ADC VPX 的连接由 Citrix Secure Internet Access 代理进行全栈检查,包括 SWG、DLP、CASB 和 NGFW
  • Citrix Web 应用程序和 API 保护 — 与云托管的 Citrix ADC VPX 的连接由 Citrix Web 应用程序和 API 保护 Web 应用程序防火墙签名代理和检查。

访问层

接入层是托管网络交付组件的地方,用于协调用户会话请求并将其定向到控制和资源组件。

概述

Citrix CPX

Companya 决定实施 2 层架构,并使用 Citrix CPX 来管理集群内的服务流量交付。CPX 接收来自云托管的 Citrix ADC VPX 的用户流量请求,并平衡微服务实例之间的流量负载。Citrix CPX 由群集管理员使用 RHOS 控件通过 YAML 文件配置进行部署。Citrix CPX 以相同的方式部署在 AWS 和 Azure 群集中。

Citrix Ingress Controller

Companya 决定使用 Citrix Ingress Controller(CIC)在其 RHOS 群集中管理 Citrix Cloud 原生网络。Citrix Ingress Controller 用于管理入口群集流量。它使用全局群集自定义资源域 (CRD) 来获取和监视 Citrix CPX 和服务状态。根据这些信息,它会动态配置 Citrix ADC VPX 以平衡负载并将流量路由到群集内的 Citrix CPX。

Citrix ADC VPX

Companya 决定使用 Citrix ADC VPX 来管理其南北流量流量,并在 Azure 和 AWS 集群之间实施全局服务器负载平衡 (GSLB)。

南北 流量由分别托管在 AWS 和 Azure 集群站点的 Citrix ADC VPX 管理。CIC 设置中提供了 IP 寻址信息和访问密钥,允许其配置负载平衡和内容交换策略。

GSLB 流量也由分别托管在 AWS 和 Azure 集群站点的 Citrix ADC VPX 进行管理。

  • Apache 微服务的 DNS 是通过该公司的全球 DNS 服务 AWS Route 53配置的
  • CNAME 记录分别映射到 Azure 和 AWS 中 Citrix ADC VPX 上托管的相应权威 DNS (ADNS) 服务。
    • ApacheService.companya.com
    • ApacheService.aws.companya.com
    • apacheservice.Azure.CompanyA.com
  • GSLB 负载平衡方法 — Citrix ADC GSLB 支持各种负载平衡方法。Companya决定使用Canary方法主要是为了通过持续的开发周期来支持较长的正常运行时间。方法选项:
    • 本地优先:在本地优先部署中,当一个应用程序想要与另一个应用程序通信时,它更喜欢同一个集群中的本地应用程序。当应用程序在本地不可用时,请求将被定向到其他集群或区域
    • Canary:Canary 发布是一种降低在生产环境中引入新软件版本风险的技术,它首先将更改推广到一小部分用户。在此解决方案中,如果您希望在将应用程序迁移到生产环境之前将新版本的应用程序部署到选定的集群,则可以使用 canary 部署
    • 故障转移:故障转移部署用于在主/主模式下无法部署应用程序时以主/被动配置部署应用程序
    • 往返时间 (RTT):在 RTT 部署中,网络的实时状态受到监控,并将客户端请求动态定向到 RTT 值最低的数据中心
    • 静态邻近:在静态邻近部署中,基于 IP 地址的静态邻近度数据库用于确定客户端的本地 DNS 服务器与 GSLB 站点之间的邻近程度。请求将发送到最符合邻近标准的站点
    • 轮询:在循环部署中,GSLB 设备持续轮换绑定到它的服务的列表。当它收到请求时,它会将连接分配给列表中的第一个服务,然后将该服务移到列表的底部
  • GSLB 服务 — 每个站点中的 Citrix ADC VPX 监视和管理向各自群集内托管的 Citrix CPX 实例的流量分配。

有关更多信息,请参阅 使用 Citrix 入口控制器的多集群入口和负载平衡解决方案

资源层

资源包括各种微服务应用程序,可通过RHOS Operator Hub获得,这些应用程序可以在内部开发,也可以通过第三方供应商获得,具体取决于需求。Companya 已决定部署 Apache Web 应用程序。

有关更多信息,请参阅 了解 RHOS 运营商中心

控制层

控制器层包括用于协调微服务交付的基本管理组件。

Red Hat OpenShift Companya 已选择使用Red Hat OpenShift 4.7 版来部署和管理其 Kubernetes 集群。

主机层

RHOS 集群受各种托管平台本地、云或混合云的支持。

Azure

Companya 决定在Microsoft Azure 租户中托管他们的一个 RHOS 环境。RHOS 群集使用 Azure CLI 来构建群集。

关键要求:

  • Azure Red Hat OpenShift 至少需要 40 个内核才能创建和运行 OpenShift 群集
  • Azure Red Hat OpenShift 群集由 3 个主节点和三个或更多工作服务器节点组成。
  • Azure CLI 版本 2.6.0 或更高版本

有关更多信息,请参阅 Azure Openshift 群集

AWS

Companya 决定在 AWS 租户中托管第二个 RHOS 环境。RHOS 集群使用 AWS 快速入门流程来构建集群。

关键要求:

  • 快速入门流程需要Red Hat 订阅 租户必须允许配置 Amazon EC2 M4.xlarge 实例
  • Red Hat 授权限制和 AWS 实例限制已设置为支持 3 个主实例和 3 个工作服务器节点的部署

有关更多信息,请参阅 AWS 上的Red Hat OpenShift — 参考部署

引用

许多文档链接可用于更好地了解 Citrix Cloud 原生联网概念、Kubernetes 微服务和 Red Hat OpenShift 平台。

在此处查找相关 Red Hat 参考文献的链接:

在此处查找相关 Citrix 参考文献的链接:

附录

术语

查找常用 RHOS 和微服务术语的描述。 RHOS 参考资料

参考架构:利用 Citrix 和Red Hat OpenShift 进行基于微服务的应用交付