后端从单体切到微服务之后，很多团队会发现一件尴尬的事：业务代码分得清清楚楚，服务边界画得明明白白，可那份被所有服务共同引用的 .proto 文件，却成了没人说得清该归谁管的东西。「Proto 代码到底放哪里？」是社区里反复出现的经典讨论，也是一个存在已久的老问题。各方答案大致归成五类，每一轮讨论都吵得不可开交——有说放业务仓库里的，有说必须独立仓库的，还有说干脆搞个集中仓库一劳永逸的。争论多年，答案并没有收敛，但问题的外延却悄悄变大了：存放位置只是 proto 管理的一个切面

源代码托管平台看起来都差不多：建仓库、提变更、跑流水线、开 Issue。于是选型很容易变成截图对比：谁的功能更多、界面更新、免费额度更大。等真正迁移，才发现 Git 仓库只是最容易搬走的那一层，代码审查记录、流水线、权限、制品、机器人和团队习惯早已长在平台里面。Gerrit、GitLab、GitHub 和 Gitea 的根本区别，不是四套网页皮肤，而是四种协作模型：Gerrit 把严格审查当作提交代码的入口，GitLab 把仓库放进一体化 DevSecOps 平台，GitHu

一个系统有 30 个服务，它就比一个单体先进吗？未必。它也可能只是把原来一次函数调用能完成的事情，改成了 30 个进程互相发请求，再配上一套 Kubernetes、一条消息队列、三种数据库和一群半夜被告警叫醒的人。服务数量确实上去了，业务价值却不会因此自动上涨。微服务最容易被误解成一种代码组织方式：文件多了就拆仓库，类多了就拆服务，团队大了就上容器。其实它首先是部署边界、数据所有权和团队责任的重新划分。一刀切下去，切开的不只是代码，还包括事务、故障、版本、监控与值班责任。边界

打开浏览器，输入一个网址，页面很快出现在眼前。这件事熟悉得近乎无聊，但若继续追问，问题马上就多了起来：电脑怎么知道服务器在哪？数据为什么没有走错门？跨过 Wi-Fi、光猫、运营商和海底光缆之后，对方又如何确认内容没有缺斤少两？很多回答会祭出一张 OSI 七层模型图，再从物理层一路背到应用层。图当然没错，只是背完之后，人仍然可能解释不了一个更实在的问题：当网络会丢包、乱序、重复、限速甚至中断时，TCP/IP 到底替应用做了什么，又故意没做什么？先给出一个不太严谨但好用的答案：I

程序是怎么运行的？这个问题听上去像是计算机组成原理课的第一道题，答案通常也很像课本：编译器把源代码翻译成机器码，操作系统把程序加载到内存，CPU 执行它。没错，但这句话把最有意思的部分全部压扁了。操作系统为什么能同时运行浏览器、音乐播放器和终端？CPU 明明一次只能执行一条指令，所谓「同时」是怎么来的？一个普通程序为什么不能随便读取别的程序的内存？printf 最后又是怎么把字符送到屏幕上的？当我们在终端输入 ./hello 时，操作系统究竟做了什么？说到底，计算机并没有我们

八月秋高风怒号，卷我屋上三重茅。茅飞渡江洒江郊，高者挂罥长林梢，下者飘转沉塘坳。南村群童欺我老无力，忍能对面为盗贼。公然抱茅入竹去，唇焦口燥呼不得，归来倚杖自叹息。俄顷风定云墨色，秋天漠漠向昏黑。布衾多年冷似铁，娇儿恶卧踏里裂。床头屋漏无干处，雨脚如麻未断绝。自经丧乱少睡眠，长夜沾湿何由彻！安得广厦千万间，大庇天下寒士俱欢颜，风雨不动安如山。呜呼！何时眼前突兀见此屋，吾庐独破受冻死亦足！