LDAP是一个常见的目录信息源；该协议的第一个版本是在1993年编纂的。它通常用于各种应用，包括管理Linux实例的用户/组信息，以及控制VPN和传统应用的认证。
传统上，公司的LDAP服务器是在内部运行的；通常是微软的Active Directory的一部分，或者是开放源码OpenLDAP项目的一个部署。 现在，SaaS供应商可以提供LDAP支持；包括Foxpass，它是第一个从头开始建立一个多用户、以云为中心的LDAP实施的云LDAP供应商。
简单介绍一下：LDAP通常有以下基元：绑定、搜索、比较和添加。在创建一个TCP连接后，应用程序首先需要通过发送一个用户名和密码进行绑定。一旦绑定成功，客户端将向LDAP服务器发出命令；通常是与过滤器一起的搜索命令。TCP连接一直保持到客户端或服务器断开连接。
在 Foxpass，我们的 LDAP 服务是在 Twisted 之上编写的，Twisted 是一种流行的基于事件的 Python 服务框架。 该服务托管在 AWS 的 ECS 平台上，运行在数十个容器（节点）上。 由于 LDAP 连接是持久的，因此集群必须能够同时维护数十万个 TCP 会话。
我们将客户的数据保存在 RAM 中。 这样做的原因是多方面的。 首先，数据集相对较小，即使对于大客户也是如此。 其次，LDAP 查询语言允许搜索任意字段（这很重要，因为 Foxpass 允许自定义字段）。 这意味着传统的 RDBMS 系统将无法构建有效的索引，我们必须将数据转换为不同的内存表示形式。 第三，将数据保存在 RAM 中可以实现最快的响应时间：延迟通常在 100 毫秒左右（见图 a）。
|
|
|
图 a：“搜索”命令的第 95 个百分位响应时间 |
这种方法的一个缺点是缓存失效。 当客户的数据发生变化时（例如，添加或删除用户），LDAP 节点必须从我们的主 RDBMS 刷新它们的数据。 在我们之前的架构中，这是一个相对昂贵的操作； 当每个节点刷新同一家公司的数据时，它可能会导致 LDAP 延迟和后备存储负载出现明显的峰值。
如上所述，由于延迟要求，每个容器都将所有客户的数据存储在内存中（见图 a）。 当请求到达一个节点时（如果它尚未存在），数据将按需获取，然后只要来自该客户的至少一个连接存在，数据就会一直存在。
由于传入的连接请求可以到达任何容器（通过负载均衡器），因此提供查询的容器也会加载和存储客户的所有数据。 随后，容器向 redis pubsub 服务注册以接收失效消息。 当公司数据发生更新时，将广播无效信号，接收节点会清除该公司的数据缓存，并转到数据库重新获取公司数据。 随着我们不断发展并将新客户添加到我们的系统中，这对扩展我们的 LDAP 服务提出了以下挑战：
上述挑战非常明显，让我们倾向于跨节点分布客户数据，而不是在每个节点上复制所有客户的数据。 这使我们找到了分布式缓存管理解决方案。
|
|
|
图a |
我们在 LDAP 服务中引入了一个智能路由层，如果连接所在的容器未托管数据，该层会将请求转发到托管客户数据的节点。 为实现这一目标，我们缩小了路由层的以下设计要求：
我们引入了 Apache Helix，它可以跨实例分配资源。 Helix 控制器是 helix 生态系统的大脑。 当添加或删除节点或客户时，它会跨节点做出资源分配决策。 我们对 Apache Helix 控制器、Rest 服务器进行了 docker 化，并将其部署在 ECS 上。 Helix 控制器依赖于 Zookeeper 来监听集群的变化。 我们实施了一种在 ECS 上部署 Zookeeper 的可靠方法。 Helix 和 Zookeeper 的整个基础架构都运行在 ECS 上。
每个 LDAP 节点都与 Zookeeper 交互以注册自己以加入集群。 每个 LDAP 实例作为 Helix 参与者出现，参与集群以由 Helix 控制器进行客户到节点的分配。 当 LDAP 节点动态创建新客户时，该客户的分区数（每个分区代表一个托管数据的节点）根据用户数确定。 通过这种集成，我们的 LDAP 节点可以了解集群中发生的事件，即添加新客户或可用节点集发生变化时。
有了这种集群意识，我们 LDAP 服务中的路由层提供了节点和客户之间的映射。 现在每个传入连接都将通过路由层来决定连接必须路由到哪个节点。 这样，客户的数据就会分配给特定的节点（见图 b）。
|
|
|
图b |
路由层托管一个缓存，其中包含客户和节点的路由信息。 路由层监视任何客户到节点的分配更改，并在检测到更改时立即更新。 这样，每个 LDAP 节点都会在客户到节点的更改发生时立即意识到它们。 通过上述缓存管理解决方案，解决了延迟敏感性挑战部分中提到的可扩展性挑战：
|
|
|
|
对于上述实现，挑战之一是节点接收到不相等数量的 TCP 连接。 与其他节点相比，这种分布不平衡会导致某些节点（热节点）上的 CPU 使用率更高。 但是与以前相比，节点间的平均整体 CPU 利用率仍然保持不变。
