再见， localhost！

CodingNET 2021-01-12 20:03:39 +08:00 3260 次点击

这是一个创建于 1782 天前的主题，其中的信息可能已经有所发展或是发生改变。

本文作者：张海龙
CODING 创始人兼 CEO 。技术创业者，十多年来一直在技术圈、开发工具领域耕耘，2014 年创办 CODING，给企业用户全套 DevOps 研发管理工具，包括项目管理、代码托管、持续集成、制品管理、持续部署，让整个开发过程都可以在浏览器中实现。

这应该是我脑海中构思时间最长的一篇文章，大概半年时间，一直没有动手。前一阵子，我们的新产品 Nocalhost 发布了，再也不能拖了。其实也不是我懒，确实有些关于“云原生”的问题没有想透，怕写不出东西。有很多新概念成熟的过程其实都不是一开始就想的特别清楚的，都是有了个萌芽以后开始逐步实践，慢慢的就成了事实。云计算，物联网，无不如是。

什么是云原生？

“云原生 Cloud Native”这个概念其实提了好几年了，但是一直没被重视，直到今年终于开始爆发了，几乎所有大厂都在忙着发布云原生的白皮书和路线图，生怕被时代落下。

我真正理解 Cloud Native 是从了解它的反义词开始的。对于不理解的东西尝试去看它的反面往往会豁然开朗。那 Cloud Native 的反面是啥呢？不是 Cloud in-Native 也不是 Non-Cloud Native，而是 Machine Native （这里顺便推荐一本书《反脆弱》，脆弱的反面不是坚强，而是反脆弱，很有意思的观点，值得一读）。这是一个巨大的概念飞跃。从计算机诞生以来，一直都是有个机器的概念，是一个具象的，物理的机器。云的出现第一次把这个具象打破了，你所依赖的计算资源再也不是一台 /多台机器，而是一朵云。不是说把一坨机器放一起就是云。云包含了大量对于硬件的抽象，以及服务能力的抽象，使得上层应用可以完全脱离对于物理硬件的依赖。过去我们写程序的时候，必须要考虑的三大件有“内存，硬盘，CPU”，这也是冯诺依曼架构的核心。从某种意义上讲，云的出现使得计算机行业变相的突破了冯诺依曼架构，或者说也是应对摩尔定律到头了的解决方案。现在 Cloud Native/云原生的应用，已经完全摆脱了对于三大件的依赖，所有需要的资源都是通过云 API 获取。

冯诺依曼计算机结构

最近流行的 Serverless 技术，也是这一理念的延伸。这里的最终效果就是往云上扔一个应用，就能顺畅的跑起来，至于怎么调度计算资源，用哪里的计算资源，那是云的事情。正如你把电风扇的插头插到墙上就应该能转，至于这个电怎么来的，电网怎么运行的，风力还是火力，你关心吗？

上云三步曲

把云比作电是一个对于美好未来的想象。时代的变迁是个漫长的过程，涉及到对于现有系统的大量改造。我们把 Machine Native 时代的应用叫做传统应用，Cloud Native 时代的应用叫做云应用。传统应用和云应用的差别一点都不比汽油车和电动车的差别小。所以要实现真正的“上云”必须要对传统应用做改造，这是一个巨大的工程，也是巨大的产业机会，我称之为数字化的城中村旧改。这个世界上确实没啥新鲜事，都是换了个模式换了个技术把做过的事情一遍一遍的重复。类似的事情还有从 PC 转向移动互联网的时候，大量的 PC 应用再造了一遍。

现在很多企业喊上云，云厂商也帮着企业上云。十多年云计算的发展，还没有接触过云的企业可以说是绝无仅有。但是到目前为止绝大部分企业完成的只是上云 1.0，也就是把传统应用搬到了云上。对于企业来讲，这样的上云相当于把云厂商当成了高级的 IDC 机房。这当然是不能体现云最终价值的。

于是云原生概念出现了，你不光要上云还得云原生，这叫上云 2.0 。也就是把传统应用改造成云应用。这里涉及到的点大概有，把应用拆成微服务，容器化，数据库也别自己装 MySQL 了，直接用云数据库，还有其他比如缓存，监控，日志啥的，云统统给你搞定，你管好应用的业务逻辑就好了。改造完了以后你会发现，这个应用大量依赖云的能力，从某种意义上讲你的应用再也不能在你自己的机器上跑起来了。所以我给云原生下了一个定义“离开云活不了，叫做云原生”。这个时代早晚要来的，我们现在离开了电也活不了。

云原生架构

当你的应用云原生以后，你会发现另外一个问题，开发这些应用变得非常困难，因为你的开发工具都是为开发传统应用准备的，为了开发云应用，你必须调整自己的开发工具和开发方式。这里就需要上云三步曲的最后一步，开发云原生，也就是上云 3.0 。

有时候想想云厂商也挺坏的，一步一步的让客户上套，美其名曰推动时代发展，数字化新基建。

Nocalhost

我们公司一直是坚定的云计算实践者，有啥新东西就用啥。我们大概在一年前就已经基本完成了上云 2.0，但随之而来很多开发的问题：

开发没有办法拥有自己的开发环境，无法在自己的机器上跑起来整个 CODING，150 个微服务。
共享的测试环境经常被搞坏，更新维护困难。
开发测试环境无法使用云的 PaaS 服务（云数据库，缓存等等）跟生产环境不一致。

每次我跟新同事交流的时候，都会提到开发环境的问题，效率低下。这使得我不得不深入调查这里的问题根源在哪里。2020 年上半年我们也找了不少已经深入使用微服务和容器的团队交流，大家普遍都会遇到上面的问题，通常的解决方案是搭建共享的开发测试环境，但这是一个治标不治本的 workaround 。这里的本质问题就是云应用和传统应用的架构差别，导致开发工具和开发方式必须做出改变。国外也有一些项目在尝试解决这个问题，但这确实是一个新领域。

云给我们带来便利的时候，也给我们带来了各种开发的不便。有时候怀念，做一个单机应用是多么的纯粹，多么的简单快乐。我想写过程序的都会熟悉下面的画面：

在笔记本上装一个 LAMP，然后就跑起来了。调试的时候改完代码，保存，刷新页面就能看到效果，行云流水。而现在云原生的体系结构使得开发的调试变得非常困难，你改个代码要等 10 分钟才能看到效果，甚至更长时间，这种感受堪比打王者荣耀的时候卡顿，想把手机砸了。这个时候开发往往会去泡杯咖啡，被迫摸鱼……

我们产品团队在调研了各种技术以后，认为有可能做一个产品解决云原生开发的问题，使得云应用的开发体验接近传统应用的开发体验。以前看 Localhost 感觉它就是个代号，最近研究云才越来越觉得这个名字的深切含义，甚至感到一丝惭愧，相见恨晚。这个词的表述也很达意：“Local”“Host”本地的机器。然而在云原生时代，开发环境搬到了云上，从某种意义上讲 local 没有 host 了，或者说没有 local 了，这个机制也就不再能解决开发的问题。那 localhost 的反面是啥，no localhost ？合并一下取名 Nocalhost （ https://nocalhost.dev ）。