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

本文涉及的产品
无影云电脑企业版,4核8GB 120小时 1个月
无影云电脑个人版,1个月黄金款+200核时
简介: 无影是终端用户计算产品线,由云桌面、云应用、云数据、终端等共同组成。无影云桌面,在架构上,也经历了几次大的架构调整和升级。无影云桌面是一个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和控制台在体验上合为一体,计划引入更多自研终端,计划发布自己的云端一体的操作系统,计划发布独立的个人版无影,计划搭建比肩淘宝的的无影商店。敬请期待!

 

 

目录
相关文章
|
2月前
|
Cloud Native Java API
聊聊从单体到微服务架构服务演化过程
本文介绍了从单体应用到微服务再到云原生架构的演进过程。单体应用虽易于搭建和部署,但难以局部更新;面向服务架构(SOA)通过模块化和服务总线提升了组件复用性和分布式部署能力;微服务则进一步实现了服务的独立开发与部署,提高了灵活性;云原生架构则利用容器化、微服务和自动化工具,实现了应用在动态环境中的弹性扩展与高效管理。这一演进体现了软件架构向着更灵活、更高效的方向发展。
|
3月前
|
存储 Linux KVM
Proxmox VE (PVE) 主要架构和重要服务介绍
Proxmox VE (PVE) 是一款开源的虚拟化平台,它基于 KVM (Kernel-based Virtual Machine) 和 LXC (Linux Containers) 技术,支持虚拟机和容器的运行。PVE 还提供高可用集群管理、软件定义存储、备份和恢复以及网络管理等企业级功能。
1341 7
|
3天前
|
消息中间件 存储 安全
分布式系统架构3:服务容错
分布式系统因其复杂性,故障几乎是必然的。那么如何让系统在不可避免的故障中依然保持稳定?本文详细介绍了分布式架构中7种核心的服务容错策略,包括故障转移、快速失败、安全失败等,以及它们在实际业务场景中的应用。无论是支付场景的快速失败,还是日志采集的安全失败,每种策略都有自己的适用领域和优缺点。此外,文章还为技术面试提供了解题思路,助你在关键时刻脱颖而出。掌握这些策略,不仅能提升系统健壮性,还能让你的技术栈更上一层楼!快来深入学习,走向架构师之路吧!
31 11
|
28天前
|
Kubernetes Cloud Native Docker
云原生之旅:从传统架构到容器化服务的演变
随着技术的快速发展,云计算已经从简单的虚拟化服务演进到了更加灵活和高效的云原生时代。本文将带你了解云原生的概念、优势以及如何通过容器化技术实现应用的快速部署和扩展。我们将以一个简单的Python Web应用为例,展示如何利用Docker容器进行打包和部署,进而探索Kubernetes如何管理这些容器,确保服务的高可用性和弹性伸缩。
|
2月前
|
消息中间件 Kafka 数据库
微服务架构中,如何确保服务之间的数据一致性?
微服务架构中,如何确保服务之间的数据一致性?
|
2月前
|
存储 分布式计算 druid
大数据-155 Apache Druid 架构与原理详解 数据存储 索引服务 压缩机制
大数据-155 Apache Druid 架构与原理详解 数据存储 索引服务 压缩机制
69 3
|
3月前
|
消息中间件 Kafka 数据库
微服务架构中,如何确保服务之间的数据一致性
微服务架构中,如何确保服务之间的数据一致性
|
3月前
|
存储 搜索推荐 数据库
MarkLogic在微服务架构中的应用:提供服务间通信和数据共享的机制
随着微服务架构的发展,服务间通信和数据共享成为关键挑战。本文介绍MarkLogic数据库在微服务架构中的应用,阐述其多模型支持、索引搜索、事务处理及高可用性等优势,以及如何利用MarkLogic实现数据共享、服务间通信、事件驱动架构和数据分析,提升系统的可伸缩性和可靠性。
55 5
|
3月前
|
XML Java 数据库
在微服务架构中,请求常跨越多个服务,涉及多组件交互,问题定位因此变得复杂
【9月更文挑战第8天】在微服务架构中,请求常跨越多个服务,涉及多组件交互,问题定位因此变得复杂。日志作为系统行为的第一手资料,传统记录方式因缺乏全局视角而难以满足跨服务追踪需求。本文通过一个电商系统的案例,介绍如何在Spring Boot应用中手动实现日志链路追踪,提升调试效率。我们生成并传递唯一追踪ID,确保日志记录包含该ID,即使日志分散也能串联。示例代码展示了使用过滤器设置追踪ID,并在日志记录及配置中自动包含该ID。这种方法不仅简化了问题定位,还具有良好的扩展性,适用于各种基于Spring Boot的微服务架构。
57 3
|
3月前
|
编解码 Linux 开发工具
Linux平台x86_64|aarch64架构RTMP推送|轻量级RTSP服务模块集成说明
支持x64_64架构、aarch64架构(需要glibc-2.21及以上版本的Linux系统, 需要libX11.so.6, 需要GLib–2.0, 需安装 libstdc++.so.6.0.21、GLIBCXX_3.4.21、 CXXABI_1.3.9)。
下一篇
DataWorks