【技术架构】本地高可用性灾难恢复:主动 - 主动 - 备用拓扑
要提高数据中心中运行的系统的可用性和灾难恢复功能,可以跨三个数据中心实施主动 - 主动 - 备用或主动 - 主动 - 主动拓扑。与两个数据中心的主动 - 主动拓扑相比,这两种拓扑都具有非常高的弹性。该架构描述了一种主动 - 主动 - 备用拓扑,其弹性比两个数据中心拓扑具有更好的弹性,但弹性低于三个数据中心的主动 - 主动 - 主动拓扑。
业务挑战
适用于主动 - 主动 - 备用架构实施的一些重大挑战包括:
- 业务连续性:尽管存在人为或自然灾害,应用程序及其支持的业务流程仍可保持可用且无任何中断,并可无缝地提供其预期功能。
- 持续可用性:精心设计的HA解决方案可通过快速的系统响应时间保持最佳的客户体验。它能够处理因业务交易激增而导致的额外工作量,并降低收入机会损失的风险。
- 操作灵活性:这意味着具有设计良好的DR拓扑,在辅助站点中复制代码和数据,并以足够的地理距离隔开。它允许在另一个位置重新构建和/或激活应用程序,并在主站点发生意外灾难性故障后处理工作。
流程
主要的分销公司需要提高在其数据中心运行的B2B订单系统的可用性和灾难恢复能力。它将系统部署在三个数据中心的主动 - 主动 - 备用拓扑中,与主动 - 主动拓扑相比,它提供了非常高的弹性。根据建议的该组件的最佳实践,B2B订单系统中的每个单独组件都可以水平或垂直聚类。
步骤1
B2B客户从Web浏览器访问本地应用程序。
第2步
边缘服务是一组服务,用于处理请求并将其发送到数据中心应用程序区域中的正确目标应用程序。它确定数据中心1或数据中心2中的UI应用程序是否可以更快地响应用户请求并相应地路由请求。
第3步
UI应用程序将请求转发到分析应用程序,该应用程序返回要在用户的Web浏览器中显示的产品列表。接下来,它向订单应用程序转发请求,以获取用户所选产品的价格信息和交付日期可用性。它向用户显示响应数据。 UI应用程序将请求转发给订单应用程序,以便为用户选择的产品下订单。它显示从用户浏览器中的企业应用程序接收的订单信息。
第4步
目录应用程序接收转发的请求,从NoSQL数据库中检索符合条件的产品信息,并将其返回给UI应用程序。
第5步
订单应用程序从UI应用程序接收由企业应用程序管理的产品可用性和价格信息的请求。订单应用程序将其转发到集成服务组件。它稍后向集成服务发送请求,以便在ERP中为用户选择的产品下订单。
第6步
企业集成服务处理接收到的请求,并根据需要转换数据和协议,以供企业应用程序处理。此过程是针对产品价格的第一次请求完成的,随后是为了在用户所选产品的ERP中创建订单而完成的。
第7步
数据中心1中的负载均衡器确定数据中心1或数据中心2中的企业应用程序是否能够更好地服务于来自数据中心1中的企业集成服务的请求,并相应地路由该请求。数据中心2中的负载平衡器以相同的方式起作用。结果是一种高度可用的解决方案,可以更快地响应用户的请求。
第8步
企业应用程序处理产品价格和可用性请求,并通过企业集成服务向订单应用程序返回响应。稍后,企业应用程序会收到为客户选择的产品创建订单并返回订单数据的请求。
第9步
决策服务应用程序从订单应用程序接收请求并对其进行处理以确定合格的价格折扣百分比或促销。此外,它还确定是否需要批准以及合格的审批者角色或人员。它返回信息以响应订单应用程序的请求。
第10步
订单应用程序向工作流应用程序发送请求以创建人工审批任务。工作流程批准完成后会发送响应。
功能要求
- 最大限度地减少应用程序正常操作的中断。 如果任何应用程序组件存在可用性问题,请确保将应用程序组件平稳快速地恢复到正常操作。
- 恢复任何应用程序组件的服务必须完全自动化,或者必须由人员通过单一操作激活。
- 监控每个应用程序组件的可用性 在服务级别问题的情况下发出警报,例如响应时间慢或任何应用程序组件没有响应。 通过自动化或由负责应用程序高可用性的人工专家的单一操作激活应用程序组件的快速恢复。
讨论:请加入知识星球【首席架构师圈】
- 57 次浏览