Nocalhost - 重新定义云原生开发环境

前言

随着业务的快速发展，技术部门的组织架构在横向及纵向不断扩大和调整，与此同时，企业的生产资料：应用系统，也变得越来越庞大。为了让应用系统适配企业组织架构的调整，梳理组织架构对于应用权责的边界，大部分组织会选择使用“微服务”架构来对应用系统进行横向拆分，使得应用系统的维护边界适配组织架构的权责边界。

一般来说，越庞大的组织架构，应用系统会被拆分地越来越细，“微服务”的数量也变得越来越多。而在“微服务”的拆分的实践中，很容易出现将组织架构的权责边界一股脑地对标到“微服务”的拆分粒度中，这可能导致“微服务”拆分粒度过细，数量进一步剧增的问题。最终，“微服务”之间的调用关系就像跨部门协作，也变得越来越复杂，问题在想要新增需求时尤为突出。

“微服务”带来便利的同时，对开发人员而言，还带来了额外的挑战：如何快速启动完整的开发环境？开发的需求依赖于其他同事怎么联调？如何快速调试这些微服务？

而对于管理人员来说，也同样带来了一系列的挑战：如何管理开发人员的开发环境？如何让新入职的同事快速进行开发？

试想一下，要开发由 200 个“微服务”组成的云原生应用，会遇到哪些困难呢？

Localhost 时代

在单体应用的时代，对于开发者来说是极为友好的，开发者使用本机运行应用，修改代码后实时生效，通过浏览器访问 Localhost 实时查看代码效果。

单体应用和“微服务”应用不同，单体应用是 “ALL-IN-ONE” 组织方式，所有的调用关系仅限于在自身的类和函数，应用对硬件的要求一般也不会太高。

而开发“微服务”应用则大不相同，由于相互间的依赖关系，当需要开发某一个功能或微服务时，不得不将所有依赖的服务都启动起来。随着微服务数量的增加，开发应用所需要的本地资源越来越多，最终导致本地无法满足开发的配置需求。

云原生解放了部署和运维，开发呢？

云原生和 Kubernetes 的普及，进一步屏蔽了“微服务”应用的复杂度，这主要体现在部署和运维阶段。

为了解决微服务应用在开发、测试和生产阶段环境一致性的问题，现代的微服务应用开发，都会将每一个组件打包成 Docker 镜像，并以工作负载的形式对其进行部署。利用 DevOps 流水线中的持续集成和持续部署，配合 Kubernetes 探针、HPA、应用自愈的能力，彻底解放了微服务应用的部署和运维环节。

但我们忽略了一个关键节点：开发阶段

微服务应用使用 Kubernetes 工作负载封装后，解决了开发过程应用的快速启动问题，开发人员只需要在本地安装单节点的 Kubernetes 集群，例如 Minikube、Kind 等即可快速启动微服务应用。

但对于开发人员来说，原来单体应用的开发体验变得不复存在，由于应用很难在 Docker 容器之外运行，所以每次代码修改，都需要经历以下步骤：