[TOC]

WSO2身份服务器的多地域部署 - 第1部分

作者： Johann Nallathamby
2018年4月2日

对于当今大多数面向客户的软件应用程序，多地域部署变得越来越重要。以下是考虑多地域部署的一些主要原因：

多地域高可用性（灾难恢复）
为用户和应用程序提供最佳的响应时间
遵从法规——无需在其所属地域之外存储敏感信息

很明显，您无法在同一部署中实现上述所有3个目标。例如，如果您需要按地域划分用户信息以符合规定，则必须在一定程度上放弃响应时间。同样，您需要根据您的优先顺序进行权衡。

本文将重点关注WSO2身份服务器（IS）的多地域部署，因此，我们假设受WSO2 IS保护的资源（如Web应用程序，API等）尽可能接近用户又接近WSO2 IS，以及彼此之间，以便它们对整体响应时间没有显着影响。

数据复制

在考虑多地域部署时，数据复制是一个至关重要的讨论主题。 WSO2 IS数据可以大致分为与本文主题相关的三种重要类型：

身份和权利数据（用户名，用户密码，用户属性，角色和用户角色分配等）
配置数据（服务提供商，身份提供商，XACML政策等）
操作数据（用户会话，OAuth2访问令牌，日志，分析等）

可以在数据库级别或应用程序级别处理数据复制。在数据库级别，我们依靠数据库技术来处理复制，主要有两种技术：

跨多个地域的多主复制
跨多个地域的主从复制

在跨地域的多主复制中，所有地域都可以接受写请求并同步对其余地域的修改，从而通过地域故障维持读写可用性。在主从复制中，单个地域被指定为负责写操作的主设备。多个从属地域可以读取数据，并且数据始终从主站同步到从站。

多主复制技术有其局限性。大多数多主系统只是松散一致，即懒惰和异步，违反了ACID属性。同步复制很复杂，并且会增加通信延迟。当节点数量增加并且延迟也增加时，冲突解决等问题变得非常棘手。相反，主从技术不会遇到这些问题。

并非所有数据库供应商都能够支持跨多个地域的多主机复制。例如，Oracle可以使用Golden Gate软件支持它。在撰写本文时，Amazon Aurora MySQL多地域多主复制预计将在2018年底普遍推出。

另一方面，有些多地域用例中，只有主从复制将是不够的。例如，一些组织拥有全球用户群，但这些身份和IAM系统的管理是从一个地域集中处理的。主从复制可以在诸如此类的场景中使用。还有其他的组织也拥有全球用户群（例如，他们可能在不同地区拥有员工和客户），并且IT管理在每个地域进行，包括身份管理和IAM系统。诸如此类的场景需要多主复制（而不是主从复制）。

另一点需要注意的是，通过主从复制技术，从节点无法进行需要在所有地域内保持一致性的写操作。他们可能能够执行不需要跨地域同步的写入操作以保持一致性。

众所周知，LDAP目录不支持跨地域的多主复制。

考虑到上述所有事实，独立于底层数据库技术的数据复制技术可能是您的首选。

基于3种类型的数据(身份和权利数据、配置数据、操作数据），我们可以为WSO2 IS确定3种类型的多地域部署用例：

跨所有地域同步身份，权利和配置
仅跨地域同步配置，但按地域划分身份和权利
按所属地域对所有数据进行分区

您可以看到所有想定中我们都已经遗漏了对操作数据的复制。这是因为由于这类数据的变更非常频繁而复制操作数据可能非常昂贵，并且WSO2 IS没有内置机制来跨地域同步操作数据，仅依靠数据库复制技术来处理此问题。如果用例要求我们复制操作数据，并且相关的数据库技术可以支持一致性和低延迟的需求，那么我们就可以使用它。无法跨地域复制操作数据的缺点之一是，在故障转移的情况下，可能要求用户重新进行身份验证，或者可能需要应用程序重新启动当前正在进行的操作。另一个缺点是如果路由策略被设置为路由到最近的地域，则如果用户在活动会话期间跨地域漫游则这可能改变，这又会导致重新认证用户或重新开始正在进行的操作。

我们将研究用例1的多地域部署模式，它将复制所有地域的身份，权利和配置。具体而言，我们将研究一种在全球范围内进行IT操作的组织的多主复制技术的替代方法。此用例将确保跨地域的高可用性，更好的用户响应时间，并且不按地域划分数据。

用例1的多地域部署 ——跨地域同步身份，权利和配置

为了更好地理解本节，需要定义一个地域身份提供者的术语。该术语是指地域中最接近的身份提供者，必须相对于物理用户或应用程序实例进行指定。

图1：WSO2 Identity Server的多地域高可用性部署

在此部署中，由于身份，权利和配置在所有地域中复制，因此用户和应用程序可能会与任何地域身份提供商进行交互。

来自用户和应用程序的流量将使用地理位置路由技术路由到地域身份提供商，从而确保用户和应用程序的响应时间最短。

在任何给定时间，每个地域都将有一个活动数据中心和一个被动数据中心（灾难恢复）相互镜像。在该地域内，流量将使用故障转移路由技术路由到活动数据中心。如果活动数据中心发生故障，则被动数据中心将作为新的活动数据中心接管。如果管理多个数据中心的成本是一个问题，一个地域可以充当另一个地域的灾难恢复站点。换句话说，数据中心将作为其地域的主要数据中心和另一个地域的辅助数据中心。在这种情况下，将不会有任何被动数据中心，因为所有数据中心都将主动为其所在地区的用户和应用程序提供服务。如果数据中心发生故障，则表示整个地域已关闭，因为地域中只有一个数据中心，并且在该数据中心恢复之前，流量将临时路由到最近的地域。这将导致受影响地域中的用户和应用程序所经历的响应时间增加，但是这可以被认为是可以容忍的，因为预期灾难恢复站点并不会长期运行。

群集仅在数据中心内完成，数据中心之间没有群集。

现在，我们将研究两种可能的网络拓扑，用于跨地域的身份和权利的应用程序级复制。

配置服务提供者的全连接网状拓扑

图2：用于双向同步的全连接网状拓扑

在此拓扑中，所有地域身份提供者也将充当配置服务提供者（PSP）和配置服务消费者（PSC）。将使用配置服务调用在PSP之间同步身份和权利数据。在PSP中添加/修改/删除身份或权利时，更改将保留在其本地用户存储中，并且将同步到所有其他PSP。

PSP的配置数据将不会同步，因为它们在网状拓扑中将彼此略有不同。此外，WSO2 IS没有内置机制来跨地域同步配置数据。因此，对于每个地域，将手动完成配置，因为该数量是可管理的。

只要PSP的数量可管理，全连接网状拓扑就是很好的方案。上述拓扑的缺点之一是如果PSP的数量增加，则这些数据中心PSP之间的连接数量呈二次方增长，变得难以管理。 PSP彼此紧密耦合，这意味着添加/移除/更新PSP变得困难。此外，没有一个地方可以管理同步过程。监视失败的请求并且必须在每个PSP中完成手动重试。为了解决这个问题，我们可以基于中心辐射拓扑重新设计此解决方案，我们将在下面讨论。

供应服务提供者的中心辐射拓扑（Hub-and-Spoke）拓扑

在此拓扑中，有一个中央配置服务中心（PSH），所有PSP（配置服务提供者）都连接到该PSH。

图3：用于双向同步的集线器和辐射拓扑

PSH可以以两种模式运行：

无状态中心模式
有状态中心模式

在无状态模式下，PSH仅将更改请求传播到连接的PSP。它不会保留入站更改请求。如果其中一个转发的出站请求失败，则必须回滚所有其他成功的出站更改请求。

在有状态模式下，PSH会在其持久存储中保留入站更改请求，以便在出站更改请求失败时能够重试同步。这提供了可靠的配置和中央位置，以检查未实现的出站变更请求并手动重试各个PSP。

通过引入中央PSH，我们却又引入了单点故障。从逻辑上来讲，下一步可通过在另一个地域中进行镜像部署来实现PSH的高可用部署。然而，通过这样做之后，我们又再次面临在PSH地域之间同步数据的相同挑战。

在无状态模式下，PSH中不存储操作数据，因此操作数据复制不是问题。仅需要复制配置数据，这可以在每个地域中手动完成，因为其数量是可管理的，或者在PSH很少时可以使用主从复制技术来进行配置。

但是，在有状态模式下，失败的出站更改请求将在运行时存储。为了确保跨地域的PSH容错，需要复制配置数据和操作数据。可以在每个地域手动完成配置数据。另一方面，对于操作数据，我们可以采用应用程序级复制技术，也可以继续而不进行复制，并且必须手动清空被动地域中失败的出站更改请求队列。鉴于数据库支持跨地域的多主技术，因此同步配置和操作数据并不是一个糟糕的解决方案，因为PSH的地域数量通常限制为2。

图4：用于双向同步的高度可用的中心和辐条拓扑

中心辐射模型的部署体系结构与图1非常相似，但另外还有类似于US，EU和APAC部署的PSH部署，如上图所示。

特别关注OAuth2

在深入研究本节之前，我想介绍术语地域授权服务器 ，它指的是地域中最近的授权服务器，其中注册了依赖方应用程序。必须相对于物理用户或应用程序实例指定。

虽然本文并未特别关注受WSO2 IS保护的资源地域，但必须针对某些用例讨论该主题。一个这样的用例是OAuth2授权代码授权流程，其由两个请求组成。第一个是授权请求，它是通过用户代理从OAuth2客户端应用程序重定向到WSO2 IS的授权端点。另一个是令牌请求，它是从OAuth2客户端应用程序到WSO2 IS的令牌端点的反向通道请求。作为通过用户代理的重定向的授权请求进入该多地域部署中的物理用户的地域授权服务器。但是，作为来自应用程序实例的反向通道请求的令牌请求将转到应用程序实例的地域授权服务器。这些地域可能不一定相同。

例如，在用户正在访问应用程序并且应用程序实例在与物理用户的地域不同的地域中运行的情况下，可能发生以下问题。授权呼叫将转到物理用户的地域授权服务器并成功返回授权代码，因为用户帐户数据和OAuth2客户端应用程序数据可在物理用户的地域授权服务器中找到。但是，由于应用程序实例在不同的地域中运行，因此令牌调用将转到应用程序实例的地域授权服务器并失败，因为它无法验证授权代码，因为授权代码未跨地域同步。

要解决此问题，应用程序必须使用地域特定的DNS URL进行令牌调用。可以考虑以下解决方案，并且它们按实现复杂度的递增顺序列出。

其中一些解决方案使用自包含的授权码来编码发布授权码的地域。例如，自包含授权代码可以是以下格式的JSON字符串：

{"random":"abcd…1234","region":"asia"}

1 具有在应用程序端基于IP查找用户代理的地域并调用相应的令牌端点的逻辑。

优点：

WSO2 IS不需要扩展
始终只能通过网络呼叫令牌端点以获取访问令牌

缺点：

应用程序中需要的其他代码，用于根据IP查找用户代理的地域

2 使用自包含的授权代码，以便应用程序可以读取它并调用相应的令牌端点。

优点：

始终只能通过网络呼叫令牌端点以获取访问令牌

缺点：

从当前版本的WSO2 IS开始，需要扩展来实现自包含的授权码
- 应用程序中需要自定义来解析自包含的授权码
- 由于授权代码对应用程序不透明，因此流程偏离了OAuth2最佳实践

3 使用自包含的授权码并使用来自应用程序的地域授权服务器的HTTP / 1.0 302或HTTP / 1.1 307状态代码进行响应，以通知客户端使用指定的地域授权服务器重复请求。

优点：

只要应用程序可以支持302或307状态代码，就不需要在应用程序中进行自定义

缺点

从当前版本的WSO2 IS开始，需要扩展来实现自包含的授权码
在最坏的情况下，将对令牌端点进行两次网络调用以获取访问令牌

4 使用自包含的授权码，以便应用程序实例的地域授权服务器可以将令牌调用桥接到物理用户的地域授权服务器。

优点：

应用程序中不需要自定义

缺点：

WSO2 IS中所需的扩展，在最坏的情况下，将有两个网络调用两个不同的WSO2 IS实例来获取访问令牌
- 从安全的角度来看，通常不鼓励这种设计，因为属于一个域的访问令牌通过另一个域代理，将其暴露给除客户端之外的另一方以及发布它的授权服务器

序列图将有助于更好地理解流程。应用解决方案1或2之后，序列图将如下所示 - 它与常规OAuth2流相同：

图5：应用解决方案1或2后OAuth2流程的序列图

应用解决方案3后的序列图如下：

图6：应用解决方案3后OAuth2流程的序列图

应用解决方案4后的序列图如下：

图7：应用解决方案4后OAuth2流程的序列图

中央身份验证服务器（CAS）也是一种类似的身份验证协议，由两个调用请求组成，一个是通过用户代理重定向，另一个是直接调用身份提供者。

OAuth2 bearer 访问令牌内省调用是资源地域变得重要的另一个用例。由授权服务器发布的bearer 访问令牌必须在资源服务器上通过将其发送到授权服务器以进行每次API调用来验证。对于单个地域解决方案，这通常是可接受的。但是，当您将同一解决方案扩展到多个地域时，跨越不同地域的访问令牌内省调用引入的延迟非常高。可用于减少此延迟的机制之一是在网关中具有访问令牌缓存。这将确保只有使用特定令牌的第一次API调用才能通过网络进行内省。具有相同访问令牌的后续调用将从网关缓存验证。

某些组织可以根据其安全策略在网关中进行缓存。但是，由于其严格的安全策略，某些组织可能无法接受。在这种情况下，您可以使用自我验证/自包含的访问令牌。使用这种访问令牌的优点是不必通过调用发出它们的授权服务器来内省它们，而是通过验证其签名并解析其中编码的信息来验证令牌的真实性。

在本文中，我提供了WSO2 Identity Server的不同多地域部署用例的高级概述。我们特别深入研究了用例1，在这里我们跨地域复制身份，权利和配置，而不是依赖于多主数据库复制技术，特别关注具有全局IT管理的组织。

在本系列文章的第2部分中，我们将深入探讨用例2和3，其中我们仅跨地域复制配置数据，但按地域划分用户数据，并分别按地域划分所有数据。