我时常被问到，我们为什么不能把本地服务注册到环境上，以便于快速地debug呢？尤其是刚刚接触kubernetes部署微服务的开发同学，尤其不适应无法在环境上调试自己的代码。

为什么会有这种心理呢？在业界里早有广泛的讨论，有个常见的Inner Loop vs Outer Loop说法，如下图：

也大概搜了几篇文章提到这个的：

http://jorgemoral.es/posts/2020_03_17-develop_apps_in_k8s_and_not_die_trying-inner_loop_outer_loop/

https://web.archive.org/web/20201107102000/https://mitchdenny.com/the-inner-loop/

https://container-registry.com/posts/productivity-lift-buildkit-cli-for-kubectl/

确实从工程效率上来说，引入了outer loop需要耗费额外的大量的时间，而且如果参与的人多，还容易出乱子，需要有各种各样的工具来管理，这些东西会提升系统复杂度，需要研发人员额外的学习成本，还有项目经理这么一个人来协调周旋。在越是大型的项目里越容易遇到这样的问题，这也是为什么存在的一个课题，叫做研发效能提升，有专门的工程师在围绕这个课题开发各种各样的工具，有很多业界大佬针对这个事情写各种各样的论文。

另外从心理层面上来说，只有coding这个部分，是程序员最爽的过程，因为它有直观的产出的，是最有意思有挑战性的设计过程。而其他的像build，test都是给反馈说你的code有没有写对，算是一种辅助，还有更讨厌的是本地启动、外部的ci/cd这种部署纯粹就是tax给你收时间税的，完全就是在浪费时间，而且还贼慢，有时候同时提交的人多，cicd甚至要排队，任务重又抓不到bug的时候人基本要疯了。

机器都还好说了，涉及到人的更加痛苦，前后端联调跨团队联调等来等去、测试给你报bug你复现不了、有的团队测试环境还不给开发随便发版、上预生产还得找leader审批，简直崩溃。

而inner loop的话，就是你完全不需要依赖外部，自己一个人在本地机器上开发调试debug就完事，loop转得很快，而且完全自己控制，只要自己电脑配置足够高，几乎不能再爽。

扯远了，在环境上debug当然有好处，我自己也经常会有这样的冲动，也曾试着找各种办法来实现，其实是有很多方法的。比如jvm的remote debug模式，在环境上通过配置jvm启动参数暴露debug端口，再用IDEA把本地代码绑定上去。如果熟悉k8s，并且有权限的话，甚至也可以把集群上的service和endpoint直接修改掉，把服务指向自己pc上的ip和端口。相当于把本地服务变相注册到集群了。当然上面两个方法的前提都是网络需要完全打通。集群和本地的网络需要互相能够访问才行。另外也还有很多工具，比如这篇文章里写的三种：telepresence、KT-Connect、Nocalhost，配置起来稍微复杂，但是跑起来之后就会很顺畅，功能丰富，使用体验看起来也不错。

原文：https://www.modb.pro/db/612073

但其实，在环境上debug，从某些角度上来看，是存在弊端的。

积累技术债务：debug这事容易上瘾，并产生依赖，结果就是写代码偷懒不认真设计，不注意代码整洁，无所谓可读性，反正能debug就好了。那结果代码就不好好写，单元测试也不好好写，日志不打算了还费存储反正也不看，code review不好好做反正崩了修就行。这些都是直接导致技术债务快速积累的重要原因。

故障解决能力低：生产的问题处理效率低，上线一旦有问题会非常不适应，生产环境总不能让你debug吧，需要掌握的检索日志、jvm工具比如arthas的使用、看监控、写埋点，这些都缺乏实战机会，而且也没动力去了解应用是怎么部署起来的。可能团队里资深一点的开发能行，但是那段代码不是他写的，看起来也费劲，还得拉着具体研发甚至大家一起。

容易环境冲突：如果别的开发也涉及到这个服务，就会发生版本冲突，不一定是他也在开发这个服务，可能只是依赖到有调用，他就会调到这个服务并且被block住，或者是返回了snapshot状态的未定稿的响应，而且可能还不知道是谁干的得到处问。并且很难追踪code变化，因为都没提交代码。团队越多人，改动越频繁，越容易发生这个问题。

破坏测试环境：如果把debug中的代码发到测试环境，高概率会产生脏数据，对环境造成日积月累的破坏。亦或者是在测试人员不知情的情况下，产生诡异的现象误导测试。因为测试很难知道有开发在这么干，他只会懵掉，就像面对被智子锁住了的对撞机一样崩溃。

助长闭门造车风气：从协作角度上讲，研发人员习惯了高效率的inner loop之后，容易倾向于不合作，因为少了很多跟别人打交道的环节，甚至排查历史遗留问题的时候也变得容易很多。结果就是不知道别人在干什么，缺乏交流的机会和动力。更不会去写文档和要求别人写文档了。

我自认为是一个十分自律而且非常注重代码整洁的开发者，但从自己过往的经历来看，这些事在忙起来的时候，来自外部的压力，来自自己心理上的诱惑，都是非常难以抗拒的。

以上问题其实发散地看，其实就是怎么去压缩outer loop环节，属于研发效能提升的范畴。除了用工具提升效率之外还有很多，甚至比如缩减测试资源或者让开发自己测试，也是可以提升效率的。但如果团队的价值导向变成只求业务代码产出而不顾长远的技术债务，这些问题将会日益凸显，要么系统做不大，要么整天崩盘CTO疯掉只能想着怎么样把研发人员换掉。

当然，最后话说回来，也不能一概而论，对于一个复杂系统来说，还是适当的保留outer loop会好一点，但是紧要时刻也别硬刚，不得已还是要debug的，别滥用就好了。而简单系统最好别整那么复杂，快速的迭代才能适应和生存。说到底，还是程度的拿捏，那就是架构的艺术了。

PS: 这篇文章我写了一下午，希望大家在转载的时候记得提一下是谁写的。喜欢的朋友不妨点赞关注。