Linuxeden开源社区作者
云目录服务，在云计算的领域里并不是一个为人熟知的产品类型，但是在企业应用的场景下，它的价值会凸显出来，甚至会对云服务和 SaaS 提供商带来战略层面的意义。
Cloud Directory Services，云目录服务，在云计算的领域里并不是一个为人熟知的产品类型。对于大多数互联网应用和 SaaS 产品来说，用户的元数据往往被认为是产品的一部分，表面上看起来不容易作为独立的服务层。
然而在企业应用的场景下，云目录服务的价值会凸显出来，甚至会对云服务和 SaaS 提供商带来战略层面的意义。
国际主要的云服务商都在 PaaS 的目录服务方面作出布局以适应各自的业务发展：
- 微软有 Azure Active Directory
- Amazon 在现有的 AWS Directory Service 之外又推出 AWS Cloud Directory 和AWS Cognito
- Google 也有 G Suite Directory Service
相比之下，国内的阿里云和腾讯云等云计算领导者，尽管已经在 PaaS 和 SaaS 上发力，但还没有将目录服务作为主要的中间件产品推出。华为云虽然包含了一个叫做云目录的产品，但它只是一个给研发团队用来登记常用开发工具的用户界面，不是本文要讨论的一般意义的目录服务。
本人结合自己这几年的相关工作经验，在这里和大家简单讨论一点云目录服务的相关话题。
目录服务和云
通俗地讲目录服务是一个 根据索引来查找对象 的服务，最常见的例子是通过姓名或用户名来查找一个用户对象并使用其关联的信息。
这种听起来很常见的数据库查询之所以被专门称为“目录”，主要在于其数据对象的通用性和查找的高重用性。
关于目录服务的现实应用场景，首先来看一个互联网用户登录的问题。
互联网发展初期，用户经常需要到很多网站上去注册账户，在每个网站都要填写用户名、密码、邮箱等等信息。这给用户和网站都带来诸多不便，甚至导致帐号安全问题，而其繁琐步骤常常成为用户放弃注册的原因。
随着互联网发展到一定成熟的阶段，所有参与者都清楚地知道只有拥有用户和数据才可能有竞争力，因此互联网巨头们向开发者提供验证服务来帮助构建自己的生态圈和开发者平台。
随着巨头对社交网络的垄断，基于 OAuth 的第三方用户登录服务越来越成熟和流行，国外有 Facebook、Google＋、MSA；国内有微博、微信、QQ 和支付宝。
在身份验证的基础上，应用程序也能根据自身需要请求获得用户的基本信息，例如昵称和好友列表。这种现代的验证方式极大地帮助了网站开发者，既减少了工作量，又避免了因为注册过程的繁琐而造成的用户流失。
(点击放大图像)
上面提到的身份 (Identity) 验证服务，某种程度上可以看做是一种扁平化了的用户目录服务。在企业应用的背景下，目录服务的功能场景则更加复杂和有意义。
举个例子，一名新员工即将加入一个中等规模的公司，在该员工入职之前，公司的 IT 系统就在目录里创建好了该员工的帐号，并生成了临时密码。
之后人力资源专员将给他分配的员工编号、电话和工位信息也录入到了目录中。该员工的上级领导也在此时将他加入了平时工作所需要的邮件和即时通讯群组中，并且开通了访问共享文档的权限。
该员工入职以后，他所有的电脑和办公自动化软件就可以立即使用，并能迅速查找任何同事的联系方式。
可以想象，如果没有基于 整个组织 的 目录数据，而需要他本人手动添加同事的电子邮件或者即时通讯地址的的话，将是效率低下而且容易出错的过程。
假设该员工入职以后需要报销入职的差旅费，于是他使用公司的电脑自动登录到相应的 ERP 系统提交了报销的表格和收据的照片，ERP 系统会将该报销请求以电子邮件的方式发到各级领导处等待批复，并发送通知短信。当报销单被批准后，ERP 系统会发邮件通知该员工。
在这个流程里面 ERP 系统需要获得员工和领导的电子邮件和手机号，而且可能根据组织结构图决定谁需要批复、谁需要收到抄送邮件等。可以看出，对于这样的 ERP 系统，一个可靠的目录服务是该类型软件业务逻辑的基础。
(点击放大图像)
目录服务从广义上讲是一种提供通用对象信息的 数据库服务，通常包括用户信息的浏览和查找、身份验证等功能。这种类型数据库一般来说有以下特性：
- 读请求的访问量极高，但写请求的访问量相对较低，Schema 相对静态
- 具有层级的树状结构
- 对象之间有引用或者隶属关系
- 对象数据有较高的通用性，能够被多种应用程序所使用
- 强调高可用性（Availability）
- 通常支持数据同步协议
部分读者可能对微软的 活动目录 Active Directory（以下简称 AD）有所了解，也许还知道早些年一个叫做 MCSE 的微软认证。
AD 是最具有代表性的目录服务，除了支持微软自己的多个服务器或客户端软件之外，也是大量第三方软件的用户平台。
但 AD 是 Windows Server 的一部分，是一套典型的 组织内部 部署的系统，也就是平时说的 on-premises 解决方案，并且对网络拓扑结构和安全模型都有要求，不容易用来支撑来自互联网的外部应用。
随着计算逐渐移到云端，企业 SaaS 应用的发展，验证方式和协议的完全 HTTP 化，目录服务也顺应需求成为了云计算服务的一部分。
微软借助其 Office 365 的市场地位，在 Azure 上推出了全托管（fully-managed，即客户完全通过 Internet 访问而无需关心物理服务器的部署）的 Azure AD。
AWS 最初只提供基于 AD 的托管目录服务，后来也推出了完全自主设计的目录服务。
云目录服务促进了 SaaS 产品的开发和市场采用，同时也简化了行业（Line of Business）应用程序的开发和部署。一些面向个人用户的网站和服务在稍加修改后，也可以支持企业用户登录和使用。
对象和纬度
数据类型
理论上目录服务可以支持 任何对象类型，但现实情况下 通用的数据类型 才有作为目录服务的价值。常见的数据类型包括：
- 用户 User
- 群组 Group （包括角色 Role）
- 应用程序 App （一般意义上指 OAuth 中的 app）
- 程序账户 Service Account 和 Security Principal
- 设备资源 Device（包括会议室、仓库、打印机、工作站、货车、IoT 等）
基于这些基本对象可以实现大量的办公自动化和 ERP 相关的功能，举几个最简单的例子：
- 基于 OAuth 2.0 和 OpenID Connect 的用户登录和身份验证
- 组织结构图和通讯录，查询某用户所在的部门以及其上级领导
- 查询某用户是否是一个群组的成员，从而作出相应的授权（Authorization）决定，给用户访问某一资源的权限
角色
基于目录服务的生态系统通常由以下几方角色组成：
- 目录服务提供商，通常是云计算平台的提供者
- 隶属于公司和组织的终端用户
- 公司和组织的管理员
- 应用程序
- 被访问的服务或资源
(点击放大图像)
相比于个人用户的 OAuth 场景，企业目录服务的一大不同点是 管理员 这个角色的加入。在企业环境下，用户本身的操作和授权通常是受管控的，比如管理员可以禁止用户登录某一个应用程序。
价值和战略意义
对于 SaaS 客户
前面提到，目录服务能帮助应用程序简化处理用户和群组的相关逻辑。某些公司因为安全合规要求，要求用户登录时进行 多重身份验证（Multi－Factor Authentication），在输入用户名密码以后还需要手机验证。
这样复杂的验证流程应该由目录服务来统一高效提供，而不是应用程序来实现。计算机和互联网已经发展到相对成熟的阶段，如果把每一个互联网用户都当做是潜在的应用程序用户的话，用户的实体和基本画像是相对稳定的，但应用程序的数量却在爆炸性增长，并且以很快的速度更新换代。
SaaS 的代表产品 Office 365 就将用户和群组的基本信息和具体应用本身分离开来，由 Azure AD（后文简称 AAD）来统一管理。
很多 SaaS 产品中都有群组的概念，但传统的群组都是产品本身的群组，要在产品内部创建和管理。
Office 365 则采用了基于另一种纬度的模式：一个工作群组在 AAD 中创建，而属于该群组的应用程序数据则由各自的程序负责和管理。Exchange 存储电子邮件和日历，SharePoint 存储共享文档，Skype 和 Teams 存储群聊天记录等。
去年 Office 365 中加入了 Teams 作为 Slack 的竞争产品，让 Office 365 的用户免费得到现成的协作工具。
Teams 能够横空出世并且直接获取用户的原因之一就是因为它的用户空间其实已经在 AAD 中创建好了。AAD 也使微软能够很快整合从公司外部收购来的产品。
除了能很好与微软及其合作伙伴的产品协同工作外，AAD 同时也是完全面向第三方应用的，所以能让用户的组织更易于采用其它第三方或者自己 IT 部门开发的 LOB 应用。
从设计和开发的角度来看，类似于 AAD 和 Office 365 这样的架构也对应用程序开发的敏捷性起到了积极作用。各种应用之间有很低的耦合度甚至完全独立，还可以基于某一个应用的 API 进行二次开发，这也和目前比较流行的 微服务 的思想是一致的。
国内的云计算巨头腾讯和阿里，在 SaaS 层都有各自的企业邮箱服务和企业即时通讯工具，例如企业微信、企业 QQ、阿里钉钉等。
未来腾讯和阿里都会开发更多的办公自动化及 ERP 系统，那么这些产品之间的用户及群组的同步和一致性就变得很有意义。
政府市场的 SaaS 应用对于用户和权限的管理有更严格的要求，而这也是腾讯和阿里拓展企业应用市场要解决的问题之一。
对于 PaaS 服务商
上面讨论的是云目录服务对于其客户 SaaS 的意义，那么作为 PaaS 的一部分，提供目录服务的商业价值又何在？
云计算平台都从 IaaS 开始，然后逐步提供上层托管式的 PaaS 服务，同时大部分云计算提供商也借助自己的平台提供一些 SaaS 层面的应用。这三层平台最终要形成一个有机的生态系统，并和各个层的用户和开发者紧密结合。
和互联网社交平台提供用户登录服务类似，企业目录服务是构建整体生态圈的重要支柱，而这也是微软，Amazon 和 Google 在各自平台上都推目录服务的原因。
值得强调的是，企业应用和互联网产品相比，其生态系统的黏性更加重要，因为企业客户往往会选择一家提供商长期合作，而且偏向于采购多个产品。
在全民云计算的时代，食物链上的每一级生产者和消费者在选择依赖对象的时候都会考虑生态系统的长期稳定和发展前景。
作为云计算平台的一部分，身份识别及访问控制管理工具（IAM）也是基于用户、群组和角色等对象的 RBAC 模型，和目录服务有大部分重合的空间。
举个例子，一个互联网公司使用了某个云计算平台来部署和运行自己的系统，公司的每个开发和运维工程师都可能需要登录该云计算平台的 IAM 控制台，这个时候该互联网公司的用户和群组目录与 IAM 中的用户就可能有较大的重合。
如果这个公司的规模相对较大，而且人员流动频繁的话，那么 IAM 用户的管理可能会变成一件繁琐的工作，而且疏忽的情况下甚至可能成为一个安全问题。
传统的观点认为云计算平台是完全面向开发者的，对最终用户是不可见的，但随着云计算的发展和普及，生态系统和功能逐渐丰富完善，一些服务是 PaaS 还是 SaaS 的界定逐渐模糊，甚至可能 SaaS 的用户入口和云计算平台的入口被统一。
企业应用的用户本身就是潜在的云计算平台用户，而搭建目录服务对云计算平台而言就可能上升到战略层面意义。从企业应用的角度来看，云计算提供商的终极目标之一是将所有到公司和组织收录到自己的目录服务中。
PaaS 提供者同时也是提供单点登录（Single Sign-on）最理想的中间经纪人和仲裁者。由 PaaS 托管的验证服务可以比较容易地实现跨应用程序之间或者跨公司组织之间的 SSO。
应用设计
目录服务的存储对象是具有通用性的，并且目录服务都是为读操作而非写操作优化的。这些特性在很大程度上会影响使用云目录服务的应用程序的设计。
假设目录中已经导入了一个组织所有用户的基本信息，那么一些基于用户对象的轻量应用程序数据，是否可以直接存储在目录中？
这样的做法等于直接将数据追加在用户对象上，好像也符合当前 NoSQL 数据模型的思想， 但事实上需要谨慎考虑多个因素。
首先应用程序很可能没有权限对目录数据进行写操作，因为目录服务的提供商，或者目录数据的拥有者企业客户，通常情况下都不愿意让第三方应用程序更改用户数据。
其次要考虑数据是不是要求高频率的写操作，高写操作的数据并不适合直接使用目录来存储。另外某些应用程序的最终实际用户集合也许只是整个组织用户集合的一个小子集，那么使用额外的数据库更加合理。
现实当中的大多数应用场景下，应用程序需要使用自己的数据库来存储用户数据，然后在自己的用户对象或者记录中保存目录服务中对象的 ID 作为关联。
尽管应用程序有自己的用户数据库，仍应该将目录服务中的用户信息作为 Single-Source-of-Truth 来构建用户对象的映射。
应用程序可以使用简单的延迟创建（Lazy Provisioning）的方式，在本地数据库中查询不到用户数据时候建立用户映射。对于支持数据同步的目录服务，应用程序也可以选择定期去轮询目录的更新情况，将需要的信息同步到本地数据库。
目录服务的实现
目录服务实际上是一种封装了的数据库服务，其下层实现则需要依赖某种 通用的数据库引擎。
Azure AD 和 AWS Directory Service 的 后台都是 Active Directory，其下层是微软早期实现的一种叫做 JET 的数据库引擎，而 AWS 新的 Cloud Directory 据猜测可能是用 DynamoDB 实现的。
和上个世纪相比，现如今市面上有很多种开源的数据库引擎可以选择，对实现自有云目录服务来说是个好消息。
目前主流的观点认为 NoSQL 类型的数据库是实现目录服务的较好选择，在 CAP 原则中，高可用性是目录服务的重心，而数据一致性一般来说则是可以适当让步的。
除了原生数据库所提供的数据读写和查询功能外，现实中还需要引入 缓存机制 来提高性能。
用户登录和获取 token 直接影响用户体验和系统整体吞吐量，整个请求和响应过程必须低延时完成。
分布式系统的缓存总是一个复杂的问题，尽管有像 Redis 这样很成熟的工具，仍需要根据业务逻辑的需求来做一些处理。
当由于安全原因需要立即停用一个用户的账号，或者撤销某个 app 的权限的时候，这种比较敏感的的变动不应当因为缓存数据更新不及时而被延迟。
(点击放大图像)
对于新开发的目录服务，将客户组织信息导入到目录中是一项有挑战性的工作，不仅要在市场和销售方面下足功夫，技术上也要准备好相应的数据迁移工具。
除了支持最基本的 Excel 表格和 CSV 格式之外，还应该提供一些面向主流企业数据库或者企业 AD 的工具。
对于大型企业和组织，向云端迁移不是短时间就能完成的，可能要长期以混合云（Hybrid）的方式运行。在这种情况下，和 on-premises 的数据同步就是一个持续的过程，而云目录服务也应当提供相应的解决方案。
作者介绍
虞雷，Jason Yu， 微软 Office 365 Core 部门首席软件工程师，在生态系统项目组负责架构设计和项目协调。
转自 http://www.infoq.com/cn/articles/understanding-cloud-directory-services