鸿蒙＋欧拉！华为“筑魂”工程：未来整个数字世界需要统一操作系统_风闻

近日召开的华为全联接大会上，**面向数字基础设施的开源操作系统欧拉（openEuler）**全新发布。这是继欧拉操作系统于2019年开源之后，又一次重大升级。

据悉，未来欧拉操作系统可广泛部署于服务器、云计算、边缘计算、嵌入式等各种形态设备，应用场景覆盖IT（Information Technology）、CT（Communication Technology）和OT（Operational Technology），实现统一操作系统支持多设备，应用一次开发覆盖全场景。

华为计算产品线总裁邓泰华表示，操作系统“碎片化”现状，导致数字基础设施产生大量“软烟囱”，带来生态割裂、应用重复开发、协同繁琐的挑战，数字化新时代，呼唤新的统一操作系统。

在ICT领域，华为提供服务器、存储、云服务、边缘计算、基站、路由器、工业控制等产品和解决方案，都需要搭载操作系统，所以华为一直在构建能力，旨在通过统一的操作系统架构来满足不同应用场景的需求。

本次欧拉全新升级，同时支持服务器、云计算、边缘计算、嵌入式等各种形态设备的需求。支持多样性计算，致力于提供安全、稳定、易用的操作系统；并通过为应用提供确定性保障能力，支持OT领域应用及OT与ICT的融合。至此全新发布的欧拉操作系统可覆盖从IT、CT到OT数字基础设施全场景。

欧拉和鸿蒙已经实现了内核技术共享，未来计划在欧拉构筑分布式软总线能力，让搭载欧拉操作系统的设备可以自动识别和连接鸿蒙终端。

后续进一步在安全OS、设备驱动框架、以及新编程语言等方面实现共享。通过能力共享、实现生态互通，“欧拉+鸿蒙”更好的服务数字全场景。

总的来讲，操作系统被誉为“基础软件之魂”，这也是华为的“筑魂”工程。这一次，操作系统重新定位后，本质上解决的是缺“芯”少“魂”的问题。

过去操作系统存在“软烟囱”问题，限制了很多场景化的创新。欧拉定位数字基础设施操作系统，还跟鸿蒙实现了内核技术共享，未来构筑分布式软总线能力，同时还会在新编程语言方面与之实现共享。

在开源方面，基于欧拉开源版本做商业化发行版的企业，才有可能获取收入和价值。目前欧拉操作系统已经有工业场景商业发行版的计划。

此次媒体沟通中，华为计算产品线总裁邓泰华、华为计算产品线研发总裁熊彦等专家，就有关欧拉操作系统设计、生态，以及华为计算产品线包括服务器等硬件创新方面的部分进展情况进行了回答。雷锋网(公众号：雷锋网)作了不改变原意的整理与编辑：

Q：近期华为在计算业务包括服务器等都有一些变动，接下来华为计算产品线会有哪些调整？欧拉新的定位和升级，这是出于什么样的考虑?

A：最近我们X86服务器业务有些变化，我们也在寻找新的模式，让这块业务可延续。我们做X86服务器的定位和做鲲鹏、昇腾的定位是不一样的。X86服务器是做产品，把产品做得有竞争力、扩大市场份额；做鲲鹏、昇腾，是构建新的产业生态。在X86服务器上面临的挑战，进一步坚定了我们要面向鲲鹏、昇腾构建新的产业生态。

同时，我们也看到国内数字经济的发展，带来计算产业市场需求的快速增加。鲲鹏、昇腾能更好地满足未来端、边、云全场景协同的需求，提供多样性算力，构建更有生命力的产业生态。

未来，在鲲鹏、昇腾方面，我们有两个坚持：第一是进一步加大投资，聚焦在核心的基础软硬件，通过构建基础软硬件根技术，根深叶茂，发展生态；第二是坚持“硬件开放、软件开源、使能伙伴、发展人才”的生态发展战略，与伙伴一起共创、共享产业价值，共同构建繁荣的生态。本次发布欧拉，也是我们整个生态构建的一部分。

Q：根据任总最新发言，欧拉定位是瞄准国家数字基础设施操作系统和生态底座，既要面向服务器，又要面向通信和设施操作系统。服务器操作系统我们经常听说，面向通信和设施的操作系统，如何理解？这给欧拉带来哪些技术上的挑战？

A：首先，华为在ICT领域有非常多的产品，包括计算、存储、云服务、边缘计算、基站、路由器等。这些产品都需要搭载操作系统。在这么多广阔的场景里面，对操作系统的需求是非常多的，而且互不相同的。包括刚刚您问到的通信设备、工业控制领域操作系统往往它的运行环境会比较小，不像服务器的操作系统可能内存都在GB级以上。同时，它对确定性、可靠性、时延的要求也各不相同。所以华为公司一直都在构建能力，希望用一套统一的架构，来满足多种不同场景对操作系统的要求。

面向数字基础设施的开源操作系统，欧拉要达成这个目标，确实会有很多技术的要求。

首先，欧拉创造性地提出了全栈原子化解耦，可以根据设备不同的资源能力和业务特征，按需构建，灵活裁减。同时支持按需的服务化的构建，就是根据场景不同，开发者可以通过工具的帮助，自助的组成它需要的操作系统。同时，我们还提供了多设备协同套件，帮助我们的开发者在开发应用的时候能够在多设备之间进行有效地协同。此外，我们使能了应用一次开发，覆盖多场景。通过标准API、欧拉SDK、欧拉DevKit，帮助开发者的应用一次开发，可以在多种设备上进行部署。这些都是我们后续在技术上需要做的工作。

Q：操作系统是一个非常关键的核心部件，对于行业客户而言，替换时考虑的因素很多，目前欧拉在行业客户的应用进展如何？鲲鹏生态的成熟将给华为新兴业务带来哪些促进作用？

A：我们的欧拉操作系统之前在服务器领域发展其实一直很快，当前已经部署超过30万套，今年底可能突破商用100万套。希望后续能够和各个行业的应用开发者有更多的合作，在各个行业的操作系统里面发挥相关的作用。

Q：新的欧拉操作系统和鸿蒙也会打通。能否举例说明这两个操作系统打通到底会带来什么样的体验？

不同的领域都有不同的操作系统，我们把这个叫做软烟囱，它带来的问题是显而易见的，带来生态割裂、应用重复开发、难以有效协同的挑战。

我们要构建一个新生态，不能是简单的模仿、简单的跟随，一定是要创新，而且这个创新一定是面向未来，满足未来的技术发展趋势、满足未来的市场需求和用户需求。未来的需求是什么？就是端、边、云全场景需要协同，整个数字基础设施云、管、边、端都需要协同，这就是未来明确的趋势。我们就要面向未来的趋势，云、管、边、端如何做好有效协同，来打造新的操作系统，我们就通过欧拉加上鸿蒙。

鸿蒙是把含智能手机，各种智能终端、物联网终端，都能通过一套鸿蒙的架构实现，所以叫万物互联的智能终端操作系统。欧拉面向数字基础设施，ICT+OT，全场景就是一套欧拉。鸿蒙和欧拉的理念是类似的，就是要改变操作系统的现状。

鸿蒙和欧拉再进一步打通，在技术上怎么实现呢？首先是共享内核。在华为内部开发鸿蒙的、开发欧拉的内核团队是一个研发团队，天然我们在组织上就共享了。然后在内核的产品上进一步共享。第二是鸿蒙、欧拉整个设计理念也是类似，我们叫全栈原子化解耦，通过解耦、组件化，可以理解为抽屉式，面向不同的场景，可以组合出不同的版本，然后构建出不同的服务，满足不同的多样性设备的需求。

基于这样统一的设计理念、共享的内核，下一步我们就希望把欧拉和鸿蒙在能力共享上进一步增强，有几个具体的规划：

第一是未来计划在欧拉构筑分布式软总线能力，让搭载欧拉操作系统的设备可以自动识别和连接鸿蒙终端，这个网络设备不管是边缘还是工业场景还是云管边，一旦识别了鸿蒙的终端，自动识别、自动连接，就把整个云、管、边、端生态打通了。

同时，我们还会推出新的编程语言。本次，我们发布了毕昇C++底层编程语言。我们计划在明年发布仓颉应用编程语言。鸿蒙和欧拉，用全新推出的统一应用编程语言来开发，这样在上层应用用同样的一套编程语言，进一步实现应用生态的打通。

等等这些都是我们未来的一步步规划，把面向万物互联的智能终端操作系统鸿蒙和面向数字基础设施全场景的欧拉两个生态再进一步打通，这就是未来整个数字世界需要的统一的操作系统。

Q：欧拉是否也给自己定义了一个阶段性发展的小目标？

关于欧拉，我们是有目标的。首先，欧拉和鸿蒙都坚持开源。实际上欧拉和鸿蒙的产业发展我们坚持两点：第一是面向未来的端边云全场景构建的操作系统，更有竞争力；第二是坚持开源模式，汇聚开发者和生态伙伴的力量，共建共享共治社区，共同完善产业生态。欧拉开源社区已经是中国最主流的操作系统产业根社区。

我们不仅定位中国，也要走向全球。后续，我们有计划把欧拉社区延伸到海外，一步步把欧拉开源社区打造成全球主流的数字基础设施操作系统社区。这样让全球的开发者、全球的基础软件和应用软件伙伴都在社区上作贡献。通过社区打造一个全球主流的开源社区，构建一个全球主流的生态。有这个全球主流的生态的支持，在中国、海外，我们帮助社区的商业伙伴成为市场主流份额的厂家。这是欧拉的发展目标。

在工业场景，这次我们发布了欧拉21.09创新版，明年3月份还将发布LTS版本。我们现在跟一部分OSV在合作，面向工业场景推出相适配的商业发行版，把工业场景现有的复杂的操作系统通过欧拉实现统一。

Q：欧拉操作系统资金以及研发人力投入的情况能否透露？具体是哪个团队在牵头做？

A：我们做欧拉操作系统有超过十几年的历史，并把过去十几年研发的成果，向产业界开放。之前徐总也提到，这并不是一个新东西。

在具体投入方面，华为内部有中软的内核开发团队，也有计算产品线的产品和生态团队，在不同的通信产品领域、云的产品领域都有面向欧拉做相应的产品开发的团队。总数有几千人的研发投入。未来，在华为我们会持续加强面向欧拉的投入。

现在华为内部启动了欧拉会战，加上我们过去面向鸿蒙的松山湖会战，我们就是要解决操作系统“缺芯少魂”的“少魂”的问题。欧拉开源之后，华为的投入不会减少，我们还会持续加大。同时更重要的是，未来通过开源社区，就不仅仅是华为的投入，整个产业链的投入都会加大。

目前在欧拉社区里面直接做代码贡献的总共有6500人，其中90%是非华为的直接代码贡献者。整个产业链都在为欧拉社区做贡献。我相信这次欧拉全新发布之后，整个产业链的投入会进一步加大，通过汇聚全产业链力量，共同繁荣生态。

Q：未来鸿蒙与我们现在的欧拉之间的分工是什么？比如哪些设备可能比较适合用鸿蒙，因为我们底层是通的，然后哪些设备可能更适合用欧拉？

A：鸿蒙跟欧拉操作系统是相互互补的，加在一起，可以覆盖数字全场景。它们之间的区别就在于，鸿蒙是面向万物互联的智能终端操作系统，是面向智能终端，面向端侧的操作系统。欧拉是面向数字基础设施，是面向数字基础设施的操作系统。所以面向ICT的设备都是基于欧拉覆盖的全场景，然后面向消费者终端或者各种行业终端、物联网终端类的都是鸿蒙覆盖的场景。

在工业场景，就是OT场景，原则上也是基于这样的分工，就是面向设备类是基于欧拉来覆盖，面向端侧，有各种工业场景的物联网的终端是基于鸿蒙来覆盖。可能在一部分边缘的场景，边缘设备到底是属于端侧还是属于边缘设备，存在一定的模糊地带，所以两种操作系统都存在一定的交叠，就是在工业场景，这个就根据不同的应用场景，比如对可靠性要求更高、更符合网络设备要求的，那我们就用欧拉系统；需要更灵活适配终端、多样性的，那就基于鸿蒙。所以为什么说欧拉和鸿蒙进一步打通，也更有价值，就是它既有各自独立的定位，又有一定的交叉地带，同时还需要这两个生态的协同对接。

Q：演讲中您提到现在整个鲲鹏生态已经能够用得上，但下一步是要做到用得好，那么鲲鹏从“用得上”到“用得好”还有多远？

A：从用上鲲鹏到用好鲲鹏，事实上这个转变是已经在部分行业、部分场景在做转移了。因为本身来说它并没有可量化的说多少就算好用、多少是可用。

从应用迁移的角度，从不同计算平台的应用迁移的角度，从原来的一个计算平台迁移到鲲鹏之后，它带来的用户体验、带来的性能能够进一步提升，这就是好用。如果性能基本持平，那算是可用的。如果说迁移上来，比原来性能还差，那算不太可用或者基本可用。所以我们现在梳理出来的八个主力场景，我们现在已经逐步地做到了从原有的计算平台迁移到鲲鹏之后，不仅可用，还能好用，就是性能还能提升。这是从迁移的角度。

从原生开发的角度，怎么算好用？应该是基于鲲鹏来做原生开发，对开发者来说，更方便、更便捷、极简开发，要么带来更好的性能，要么带来更多的功能、更多的增值的业务或者更好的用户体验，这是我们在后一步要努力的方向。未来我们希望从使能应用迁移到使能基于鲲鹏的原生开发，让更多的应用不要说再在原有的平台上开发一遍再迁移过来，而是从一开始就在鲲鹏的平台上做原生的应用开发。

这次我们推出的DevKit 2.0，就是让更多的行业应用就从一开始在鲲鹏上面开发，这样开发者也不用二次迁移。这样随着我们鲲鹏的生态进一步在各个行业的发展，整个生态发展、市场规模的扩大，各个应用就自然得到了规模的应用。

Q：鸿蒙和欧拉可能在某一些设备上可能会存在交叉，那这两个系统后面再去向更多的用户场景拓展的时候，会不会很容易打架？这块华为内部是怎么定义这两个东西的边界或者怎么去平衡这个事情？

A：操作系统本身就是在一个场景上是存在多种选择的。就像现在面向智能手机，现在有iOS操作系统、Android操作系统、有鸿蒙操作系统，用户可以做选择、上层的应用也可以做选择。在服务器操作系统这个场景，现在也有不同的操作系统的厂家都在做商业发行版。所以上层的应用软件可以选择其集成的操作系统厂家，然后用户单位也可以针对操作系统来单独招标。所以在不同的场景下，操作系统都不是唯一选择，其本身就存在多个选择。

从这一点来说，对于工业场景，如果说存在一定的重叠的地带，那也有一个用户可选择的过程。所以这本身来说并不存在冲突，应该是给用户提供了多种选择。因为如果一个场景只有唯一的选择，那反而不一定是最理想的方式。所以首先不存在冲突。

但是我们也是希望让客户多个选择，也能够实现一定程度的共享，而不是在多个选择之间相互互斥。如果不同的选择有不同的商业发行版，它是完全不同的两个体系，那就存在客户选择的这个操作系统，我基于这个操作系统开发了上层的应用。当我要转换到另一个操作系统时，我上层的应用要全部开发一遍，不管是对用户还是生态中的软件企业来说，都存在工作量的浪费。

所以我们也希望把底层能够进一步打通，让不同的操作系统的商用产品或者商用发行版，它们相互之间既有差异化的部分，又有共性、可共享的部分。它的基础部分能通过我们构建的统一的开源社区来构建一个开共享的基础部分，包括欧拉开源社区，在基础开源部分可以实现能力的共享。但是不同的技术软件企业基于开源社区，又可以推出各自的商用发行版面向客户。

商用发行版在基础的平台基础上，再增加差异化的部分，发挥各自他们的优势，比如在场景化适配性、在可靠性、在更多的增值功能各个方面，可以鼓励大家差异化。这样面向最终的场景、最终的客户，有多个选择，但是这多个选择之间又能够实现最有效的基础的共享。这就是我们希望的一种模式，应该也是用户所希望的一种模式。