开拓电脑云市场的前浪(Citrix)落幕：openstack/kubernetes夺嫡战

2023年12月，国际知名云电脑厂商Citrix（美国思杰公司）正式宣布退出中国市场（包括香港地区和澳门地区），此消息一出，引起了全行业的热议。

Citrix作为全球VDI的杰出代表，在巅峰阶段，全球市场占有率曾达到近乎一半的水平。

进入中国市场后，一度占据鳌头，中国客户一度超过2400家，其中包括了中国移动、中国石化等国内知名企业。可以说是曾经凭借一己之力开拓了中国的云电脑市场。

但是现在，请看巨型外包公司的报告：《这些银行已经大规模替换掉Citrix→》（深圳XF，监控项目，让我觉得十分恶心）

Citrix落幕

Citrix成立于1989年，曾是VDI的代名词，其桌面虚拟化产品高峰时在全球市场占有一半的市场份额。Citrix的桌面传输协议ICA非常高效，在ICA的面前，其他的协议都是小弟。甚至大名鼎鼎的VMware也得称Citrix一声大哥，VMware成立于1998年，其第一代桌面虚拟化产品View问世的时候，Citrix早已经功成名就了。中国做桌面虚拟化的，华为、新华三、锐捷、深信服等大厂的工程师大都研究过Citrix的产品。

2007年收购了XenSource：

开始开源服务器虚拟化软件大多数用的是Xen，2007年，XenSource被Citrix以5亿美金收购，后来Citrix将其开源。

然而，Citrix收购Xen不久，KVM冒了出来，并很快取代了Xen的地位。比如OpenStack等很多开源云平台也从最初的Xen替换为KVM。中国的一些桌面虚拟化产品，也经历了从Xen换到KVM的这个过程。比如，新华三的CAS最初就是用的Xen，后来才换为KVM。

2011年收购CloudStack

cloustack可以说是最早的云平台之一！

• Apache CloudStack 是顶级开源云板之一。它提供了一个带有 API 的简单电子界面，可帮助企业理解分布式计算。

• Apache CloudStack 支持许多服务，包括：VMware、Microsoft HyperV 管理程序、Citrix XenServer 和 KVM。与隐藏目标和资产的关联通常偏爱 Apache CloudStack。
  

在AWS刚起步，cloustack的老东家Citrix作为XenServer虚拟化技术的拥有着，已经开始在虚拟化上层，做自己的管理调度平台了，当时他们的商业版本叫Cloud Platform，开源版本才叫cloudstack，而且当时还是自己开源，没有交给github，没有交给Apache，可以说，是行业先驱了，关键人家东西做的也真不错，具备一切那个时代商业产品应该具备的特性，说实话，对于中小型虚拟化应用环境来讲，你装了Citrix的cloudstack，绝对够用了。

与Xen的命运有点相似， CloudStack被收购后也将其开源。但OpenStack很快就起来，风头盖过了CloudStack，很快就没有CloudStack什么事了。

cloustack可以说是最早的云平台之一，它的场景是企业内中小型虚拟化环境的管理平台，这就是它的基因。

openstack可以说是曾经最火的虚拟化云平台，没有之一；

kubernetes（以下称k8s）是现在最火最热门的容器云平台，

曾经最火的虚拟化云平台openstack

openstack，在AWS做公有云大火和vmware做私有云vcloud贼贵的时候，它出现了

随着云场景的发展，它的场景已经不再局限于企业内部使用，而是面向公有云的，面向云应用场景的，要求有能力承载公众客户的平台，并且期望兼顾企业内私有云的应用，这就是它的基因。

openstack是希望做成一个大而全的平台，保罗众生。这也是为什么它选择了使用胶水语言python（话说openstack采用python，真的是助推了python语言的普及一把，跟现在的tensorflow异曲同工），又选择采用了易扩展的微服务架构以及接口设计。可以说，从出生的那天开始，它就希望自己会演变成一个巨人，众人堆砌的巨人。当然，这个想法是好的，但没想到时至今日，大家堆砌的可能不是一个巨人，倒像是一个步履蹒跚的胖子，渐行渐远，这也许就是设计和执行，在时间长河中无法规避的分流吧

openstack的代码管理，实际上因为目标大而全，且没有主导的maintainer，个人认为，维护的并不好，缺少统一原则，缺少规范，造成代码copy现象严重，设计风格迥异严重，到后期臃肿的并不好维护，当然，这也是微服务之殇，被openstack踩了遍

现在最火最热门的容器云平台k8s

kubernetes（k8s），在docker容器横空出世，大火特火的时候，它也随之出现了，最开始可能是谷歌无心为之，但后来则成了谷歌在云领域弯道超车的重要载具，对于谷歌的云事业可谓功勋卓著，它面向的场景，也很清晰，就是随着云环境的普及，在云上如何快速搭建应用，管理应用服务的能力，所以，与其说k8s是一个云平台，不如说它是一个云应用平台。这就是它的基因。可以说这个转变，已经不是云场景的转变，而是云理念的转变了，cloud native这种云应用理念也是因此而产生的。

k8s对于一些问题是有深入思考，才去设计并开发实施的，而且他们的思考应该是从基础理念出发，而非经验出发，都是有理有据的，从他们的文档中可以看出，它不强加于某种理念与你，但一定会告诉你它选择这种理念这种方式的原因，文档之细腻，可谓是开源典范。能做到如此，一定是想的清楚+很具备同理心（知道读者想知道什么）才能够做到的。总之，他们知道他们开发这个系统是想做什么，能做什么，并怎么样做到最好，而不是像前面openstack一样，追求大而全，追求包罗万象。这也许就是k8s相对openstack成功的地方，它抓住了云场景的核心需求，并形成了标准和理念。

选一个系统，涉及人，无非就是考虑开发+维护难度

架构颠覆，平台颠覆的内在原因到底是什么？规律和共性是什么？

也许每个人都有每个人的看法，但对于我来讲，是投入跟产出，是一个效率问题，是一个成本问题。

其实说到底，技术的迭代，本身就是一个成本问题。但是好多技术人却容易忽略这个问题，为什么，因为成本问题是个用户角度的问题，如果技术人本身缺少同理心，就很可能忽视这个角度，或者说开发开发，设计设计，就忘记了这个角度，这就是技术人可能犯的通病，但是谷歌这点就做的很好，他们的同理心很强（前文提到了，他们的同理心可以从文档的书写中看出来，思考很细腻，很能从读者的角度去考虑），所以k8s就相对做的好一些。那么话说回来，如果我们从用户的角度考虑，用户到底需要怎么样的一个云平台，或者说，他们云化的目的是什么？或者说云本身的目的是什么？我个人觉得，是为了规模、稳定、还有便捷（其实这三个点很类似CAP问题，是有相互制约的，你可以表述成在相同便捷程度下，要有更大的规模和更好的稳定程度，三者在这句话里，可以任意替换，但相互制约）。所以我们不是要有一个高大上的云平台，而是要有一个同时具备规模、稳定、便捷的底层，云平台的作为管理平台，只是为了达到底层这个目标而已，但像openstack那样，想做一个大而全的平台，就违背云平台存在的意义，它为了做完美的平台而做平台，为了全而全，就忽视了云真正的需求是什么，也是这个平台失败的原因（前文提到，规模、稳定、便捷，相互制约，可以说，openstack太看重便捷和规模，但是忽略了稳定，被颠覆是必然）。所以就我而言，我认为从平台的实际应用上来讲（非所谓技术学术价值和时代价值评判），openstack < cloudstack << k8s。

初创企业，企业内部用，强烈建议就直接上k8s好了，基于cloud native的模式设计，以后不管是在自建机房，还是在公有云，都可以较快的迁移，部署应用，而且基本上没有历史包袱的话，采用cloud native的原则设计应用，也是非常快捷的一种开发方式（尽可能用正确的方式做事情，不要先污染后治理）。

基本上，如果不打算自己解决问题，纯维护和具有排查能力的话，k8s两个人也就够了。

参考文章：

关于cloudstack，openstack，kubernetes三个开源云平台的架构演进思考 https://zhuanlan.zhihu.com/p/49523193

转载本站文章《开拓电脑云市场的前浪(Citrix)落幕：openstack/kubernetes夺嫡战》,
请注明出处：https://www.zhoulujun.cn/html/tools/Virtual/VMware/2024_1015_9280.html