阿里云无影云桌面-桌面即服务的架构演进

简介: 无影是终端用户计算产品线,由云桌面、云应用、云数据、终端等共同组成。无影云桌面,在架构上,也经历了几次大的架构调整和升级。无影云桌面是一个Desktop As A Service产品。

前言

无影是终端用户计算产品线,由云桌面、云应用、云数据、终端等共同组成。作者是无影云桌面的总架构师和研发团队负责人。

本文所指的桌面,是指办公或者娱乐用的桌面电脑。云桌面,是相对本地桌面而言的,以云计算的方式交付的远程虚拟桌面。一个最常见的云桌面的场景就是企业的员工办公,本地办公桌上只有着显示器、键盘、鼠标、摄像头等各种外设,没有电脑主机,打开显示器后显示一个登录界面,直接登录到远程的虚拟桌面办公。

在业界,大家提及较多的是Virtual Desktop Infrastructure(VDI)和DAAS (Desktop As A Service)两种虚拟桌面。一般,简单的认为,VDI是私有云的方案,DAAS是公共云的方案。但两者的区别不止这些,真正的DAAS,还应该满足一个重要特征,使用者无须关心基础设施,看不到虚拟机更看不到物理机,也就是常说的Serverless。举个例子,VMware的Horizon产品,部署的前提是先准备好一个vCenter和若干台服务器,因此我们讲,VMware Horizon是VDI产品,无论其安装在公共云还是私有云。而相比之下,阿里云无影可以直接购买云桌面,无须提前准备任何服务器,是真正的DAAS产品。

VDI版本的云桌面

阿里云的云桌面,在架构上,也经历了几次大的架构调整和升级。较早版本的阿里云云桌面(那时候还不叫无影),与VDI领域的某领导者公司共同合作设计,有浓重的VDI的烙印。当时的产品架构图如下图所示:

  图片1.png



这个较早版本的架构设计,优点是利用了业界较为成熟的VDI方案,结合阿里云自己的身份认证系统和弹性计算(ECS)、VPC的基础设施,以较小的开发成本提供了一套较为稳定的虚拟桌面方案。

但缺点也非常明显:

1.对小企业用户来说,即使只有一台虚拟桌面,也需要额外的三台大规格ECS损耗,分别安装VDI必须的微软的AD、管理组件、终端用户认证访问组件,成本过高。

2.受限于1中所述的三台ECS的限制,此方案对单个用户最多只能支撑1000台虚拟桌面,无法满足大企业弹性要求。

3.虚拟桌面直接挂公网IP,客户端通过这个公网IP直接连接虚拟桌面,且虚拟桌面内的应用对外访问互联网也是通过这个公网IP,网络未隔离,存在安全风险。

4.虚拟桌面底层对应的ECS,位于用户自己的VPC,归属用户自己,在用户的ECS控制台可见,用户要付出额外的管理成本来维护ECS,因此,本质上,是一个公共云上的VDI方案。

5.无法与企业自身的微软AD进行集成。目前,较大比例的大企业正在使用微软AD进行windows桌面管理。

 

无影云桌面之初

为了客服这些缺点,在2020年,阿里云的云桌面进行了推到重来的设计,并正式命名为“无影云桌面”。此版本的架构图如下图所示(实际的无影服务VPC内的管控架构比下图要复杂很多,下图从简):

 图片2.png



这个版本的无影云桌面,在架构上,有以下四点重大升级:

1.无影实现了自研的大规模的多租户的桌面集群,在去除集群成本overhead的同时,实现了大规模的弹性扩容。举个例子,对小用户来说,假设一台桌面一个月100元,那么买一台就是100元,买两台就是200元,没有任何额外的费用。而对于大企业来说,也几乎没有规模上限。再举个例子,假设每个集群的桌面数量上限是5000台,那么,一个大企业的2万台桌面,会被自动的分配到四个不同的桌面集群中。

2.桌面底层的ECS位于无影服务VPC内,由无影的服务来管理和运维,用户在ECS控制台看不到这些ECS,也就无须再运维ECS,利用Serverless技术成为了真正的DAAS。而无影提供的99.9%的可连接性SLA,也远胜过客户自己维护ECS的稳定性。

3.桌面本身不挂公网IP,客户端通过一个无影自研的安全的接入网关,来接入桌面,从而实现了桌面与互联网的隔离,保证了桌面的安全接入。

4.桌面有两块网卡。主网卡,也就是管控网卡,负责客户端的接入流量,以及管控侧的控制流量,用户不能对主网卡进行任何修改,主网卡的网络安全规则也是严格受控的。另一个是应用网卡,也就是辅助网卡,位于用户自己的VPC内,负责桌面内的应用对外的流量,桌面内的应用可以直接通过应用网卡访问此VPC内的资源。

5.无影自研了一个AD Connector,可以允许客户集成自己的AD来管理这些桌面。AD Connector同样有两块网卡,一块位于无影服务VPC,一块位于用户VPC,从而桥接了无影管控服务与企业自己的AD。这样一来,客户端登录的时候,就可以使用企业自己的AD来完成认证了。值得注意的是,桌面和企业AD之间的流量,是通过应用网卡来直接通信的,不走AD Connector。

 

无影云桌面之云原生升级

但是,这种设计仍然有一个缺点,就是如果用户需要访问internet,需要自己在VPC内购买NAT网关,同一个企业的多个桌面可以共享一个NAT网关上网。这种设计,虽然给了企业足够的灵活性来控制自己的网络,但是也对中小企业造成了很大的困扰:我想要桌面,为什么必须要先创建并配置VPC和vSwitch?还要我自己去够买并配置NAT网关?我还要自己配置应用网卡的安全组规则来保证安全?

这些问题,违背了Serverless和DAAS的设计思想。为了提供最简化的管理体验,我们提出了“安全办公网络”和“工作区”的概念,把网络资源也全部放在了无影服务的管理VPC内,从而使得用户即使没有任何云计算背景和网络知识,也可以轻松地创建和管理自己的无影云桌面。

随着团队的扩大,业务逻辑越来越复杂,单体应用在稳定性和弹性上的不足也越来越明显,我们决定对管控进行微服务化改造。

同时,为了提供业界最好的终端用户体验,克服使用第三方协议的限制,我们把自研的ASP协议,也在管控层面做了实现。

 

2021版的无影云桌面架构图调整如下(实际远比下图复杂,下图从简):



 图片3.png

 

在2020版的基础上,无影做了如下变革:

1.桌面的应用网卡(辅助网卡)也由无影服务来管理。优点是,用户在创建无影桌面前,只需在无影控制台选择一个IP地址段(192,10,172等)创建一个无影工作区,无须再提前准备VPC、vSwitch等网络资源。桌面如果想要访问internet,只需要在无影控制台创建互利网访问包,无影会自动创建和管理NAT等资源,最大化的简化了用户的管理操作。

2.为了保留无影跟用户自己的AD集成的能力,以及桌面访问VPC私网的能力,我们引入云企业网(CEN)。用户可以先创建一个CEN,然后在无影云桌面控制台将无影的工作区加入到自己的CEN,从而使得无影云桌面的网络与自己的VPC打通。

3.为了满足部分企业客户的高安全的要求,我们支持了“私网客户端”的功能,通过privateLink终端节点服务,支持客户端只能在VPC以内,通过一个私网地址,连接云桌面,从而实现了企业的云桌面和公网彻底隔离的需求。

4.引入了微服务引擎,进行了微服务化拆分和改造,使得多个团队可以并行开发,并在稳定性、性能等多方面有所提高。我们的注册中心使用Nacos,服务间调用使用Dubbo,消息异步通知使用RocketMQ,缓存使用Redis,分布式锁、工作流框架为自研。

5.三方协议集群和自研的ASP集群并存,为ASP协议设计了单独的集群管理组件,实现心跳和健康监测、连接和会话管理、用户管理等功能。

面向未来的无影

在2022年,无影的架构,也会持续的迭代和更新。我们计划把数据、应用、桌面三者解耦,云数据、云应用和云桌面通过client和控制台在体验上合为一体,计划引入更多自研终端,计划发布自己的云端一体的操作系统,计划发布独立的个人版无影,计划搭建比肩淘宝的的无影商店。敬请期待!

 

 

目录
相关文章
|
10月前
|
消息中间件 负载均衡 中间件
⚡ 构建真正的高性能即时通讯服务:基于 Netty 集群的架构设计与实现
本文介绍了如何基于 Netty 构建分布式即时通讯集群。随着用户量增长,单体架构面临性能瓶颈,文章对比了三种集群方案:Nginx 负载均衡、注册中心服务发现与基于 ZooKeeper 的消息路由架构。最终选择第三种方案,通过 ZooKeeper 实现服务注册发现与消息路由,并结合 RabbitMQ 支持跨服务器消息广播。文中还详细讲解了 ZooKeeper 搭建、Netty 集群改造、动态端口分配、服务注册、负载均衡及消息广播的实现,构建了一个高可用、可水平扩展的即时通讯系统。
1106 0
|
10月前
|
文字识别 运维 监控
架构解密|一步步打造高可用的 JOCR OCR 识别服务
本文深入解析了JOCR OCR识别服务的高可用架构设计,涵盖从用户上传、智能调度、核心识别到容错监控的完整链路,助力打造高性能、低成本的工业级OCR服务。
417 0
架构解密|一步步打造高可用的 JOCR OCR 识别服务
|
存储 安全 网络安全
云桌面:云计算桌面
云桌面的定义和核心概念 云桌面是一种通过云计算技术提供的虚拟桌面服务,它允许用户通过网络访问远程服务器上的虚拟机,这些虚拟机为用户提供了一个完整的桌面环境。用户可以像使用本地计算机一样使用云桌面,进行文件编辑、上网浏览、运行应用程序等操作。
1947 68
|
消息中间件 人工智能 监控
文生图架构设计原来如此简单之分布式服务
想象一下,当成千上万的用户同时要求AI画图,如何公平高效地处理这些请求?文生图/图生图大模型的架构设计看似复杂,实则遵循简单而有效的原则:合理排队、分工明确、防患未然。
538 14
文生图架构设计原来如此简单之分布式服务
|
存储 JavaScript 开发工具
基于HarmonyOS 5.0(NEXT)与SpringCloud架构的跨平台应用开发与服务集成研究【实战】
本次的.HarmonyOS Next ,ArkTS语言,HarmonyOS的元服务和DevEco Studio 开发工具,为开发者提供了构建现代化、轻量化、高性能应用的便捷方式。这些技术和工具将帮助开发者更好地适应未来的智能设备和服务提供方式。
基于HarmonyOS 5.0(NEXT)与SpringCloud架构的跨平台应用开发与服务集成研究【实战】
|
消息中间件 存储 安全
分布式系统架构3:服务容错
分布式系统因其复杂性,故障几乎是必然的。那么如何让系统在不可避免的故障中依然保持稳定?本文详细介绍了分布式架构中7种核心的服务容错策略,包括故障转移、快速失败、安全失败等,以及它们在实际业务场景中的应用。无论是支付场景的快速失败,还是日志采集的安全失败,每种策略都有自己的适用领域和优缺点。此外,文章还为技术面试提供了解题思路,助你在关键时刻脱颖而出。掌握这些策略,不仅能提升系统健壮性,还能让你的技术栈更上一层楼!快来深入学习,走向架构师之路吧!
692 12
|
Kubernetes Cloud Native Docker
云原生之旅:从传统架构到容器化服务的演变
随着技术的快速发展,云计算已经从简单的虚拟化服务演进到了更加灵活和高效的云原生时代。本文将带你了解云原生的概念、优势以及如何通过容器化技术实现应用的快速部署和扩展。我们将以一个简单的Python Web应用为例,展示如何利用Docker容器进行打包和部署,进而探索Kubernetes如何管理这些容器,确保服务的高可用性和弹性伸缩。
|
监控 Nacos 数据安全/隐私保护
动态服务管理平台在微服务架构中的实践与探索
动态服务管理平台在微服务架构中的实践与探索
|
7月前
|
Cloud Native Serverless API
微服务架构实战指南:从单体应用到云原生的蜕变之路
🌟蒋星熠Jaxonic,代码为舟的星际旅人。深耕微服务架构,擅以DDD拆分服务、构建高可用通信与治理体系。分享从单体到云原生的实战经验,探索技术演进的无限可能。
微服务架构实战指南:从单体应用到云原生的蜕变之路