如何实现虚拟云桌面？

云桌面后台云平台在实践中进行了多次迭代，原有架构如上图所示。该架构特点是，直接在 OpenStack Nova 进行定制开发，添加了分配虚拟的接口，实现瘦客户端直接访问 OpenStack 获取虚拟机信息。

这个架构下，云桌面平台可以直接访问全部的虚拟机信息，直接进行全部的虚拟机操作，数据也集中存在 OpenStack 数据库，部署方便。用户权限通过 OpenStack Keystone 直接管控，管理界面使用 OpenStack Horizon 并添加云桌面管理页面。

典型的分配虚拟机用例中，瘦客户端通过 OpenStack Keystone 进行认证、获取 Token，然后访问 Nova 请求虚拟机。如上图所示，瘦客户端会通过 Keystone 进行认证，Keystone 确认用户存在后向域 LDAP 进行密码校验，确认用户合法后返回 Token；瘦客户端再通过 Token 向 Nova 申请虚拟机。

Nova 根据瘦客户端设置的坐席信息，首先查找这个坐席是否已分配虚拟机。如有直接返回对应虚拟机。如无，从后台空闲虚拟机中进行分配并更新数据库分配，返回远程桌面协议连接信息。原架构出现一些局限性，首先，业务与 OpenStack 呈强绑定关系，导致 OpenStack 升级涉及业务重写；修改业务逻辑需要对整个云平台做回归测试。

其次，用户必须要是 Keystone 用户，用户管理必须使用 Keystone 模型。导致 Keystone 与 LDAP 之间要定期同步进行，有时还需手工同步特殊用户。管理层面，因为 Horizon 的面向云资源管理的，但业务主要面向运维的。这部分差异，导致我们开发新的 Portal 来弥补，管理人员需要通过两套系统来进行运维。

整体方案上，云桌面远程桌面协议由第三方提供，如果第三方方案不支持 OpenStack，就无法在云桌面系统使用。

最后，用户部门有各种需求，直接在 OpenStack 内进行开发难度大，上线时间长，开发人员很难实现技术引领业务发展。经过架构调整，新架构实现了 OpenStack 与我们的业务解耦，同时适应用户部门的业务发展方向，方便功能快速迭代上线。

从图中可以看出，云桌面业务逻辑从 OpenStack 中独立出来，成为了 VMPool，Allocator；管理层独立开发一套面向 IT 运维的 Portal 系统，取代 Horizon；云平台可直接原生的 OpenStack。

其中 VMPool 负责维护某种规格虚拟机的可用数量，避免需要的时候没有虚拟机可用，让用户等待。Allocator 满足符合条件的用户请求，返回用户对应的虚拟机或者从 VMPool 分配虚拟机分配用户。

对于用户分配虚拟机的典型用例，与原有架构改动较大。首先，业务层瘦客户端将直接访问业务层的 API。API 层会直接通过 LDAP 进行用户认证，并获取用户 OU、组别等信息。

接着，业务层将进行用户规则匹配。每个 Allocator 通过用户组、OU、tag 等进行规则匹配，以确定该用户是否由自己进行服务。如不满足 Allocator 所定义的规则，将按 Allocator 的优先等级，继续选取下一个 Allocator 进行匹配，直到匹配或者默认规则为止。

匹配后，如果是有绑定关系的分配规则，比如用户绑定或者坐席绑定、TC 绑定，那 Allocator 将直接从数据库返回已有的绑定；如果无绑定关系，Allocator 就会从对应的 VMPool 分配一台虚拟给，返回给用户。

最后，对用户部门来说，看到的是用户属于一个组，这个组对应特定的虚拟机。只需调整用户属性，即可实现用户分配特定的虚拟机，充分满足他们的各种需求。