这篇是我学 Linux 和 Docker 时的学习笔记,时间大约在 2021 年前后。 起因是项目做到一定程度后发现自己不会部署,只写了代码不知道怎么让它跑起来。开始是在云服务器上捣鼓,后来把一台闲置笔记本装了 CentOS7 做自己的”测试服务器”,顺便把 Linux 和 Docker 的基础一起补了。 文章内容比较杂,更像是操作记录,不是系统化的教程。留在这里主要方便自己翻阅。 Linux 常用命令速查 以下是日常最常用的那些,完整的 man page 还是要靠查文档。 文件操作ls -la # 列出含隐藏文件的详细列表pwd # 显示当前目录cd ~ # 回到家目录mkdir -p a/b/c # 创建多级目录cp -r src/ dst/ # 递归拷贝目录rm -rf dir/ # 强制递归删除(危险,确认后再执行)mv old new # 移动或重命名find . -name "*.log" -size +100M ...
Arthas 线上排查 Java 问题实录Arthas 是阿里开源的 Java 诊断工具,核心能力是 attach 到运行中的 JVM 进程,不停机、不改代码,直接查线程状态、监听方法入参/返回值、分析调用链耗时。 安装与启动curl -O https://arthas.aliyun.com/arthas-boot.jarjava -jar arthas-boot.jar# 启动后会列出当前机器上的 Java 进程,输入编号选择要 attach 的进程 四个核心命令dashboard — 整体概览,快速定位问题线程 dashboard 进入 Arthas 后第一步通常先跑 dashboard,能看到所有线程状态、堆内存使用、GC 频率。CPU 飙高时,这里能直接看到哪个线程在占 CPU。 thread — 查看线程状态,找出 CPU 占用最高的线程 thread -n 3 # 显示 CPU 占用最高的 3 个线程的栈信息thread -b # 查找处于 BLOCKED 状态的线程(排查死锁)thread <线程ID> ...
低代码平台:技术人应该认真对待的事一、那时行业的声音2021 年是低代码话题的密集期。 钉钉发布宜搭,阿里云推出低代码引擎,各类平台的营销材料里都有一句类似的话:”让不懂编程的人也能搭建业务应用”。公众号上类似《低代码会替代程序员吗》的文章每隔一段时间就会出一篇,评论区里总有一批人在激烈争论。 有一次在公司的技术讨论群里,有人丢了一篇文章进来,说某大厂内部用低代码把一个部门的 CRUD 系统开发工期缩短了 80%。接下来大家的反应分成两类:一类人觉得这是在扯,一类人觉得这件事值得认真对待。 我当时属于第三类:不太确定,但觉得应该真的试一试再说。 二、我的第一反应说实话,最开始听到”低代码”这个词,我的第一反应是带着一点防御性的——这是给不懂技术的人用的,和我有什么关系? 这种想法来得挺自然,也来得挺快。大概是某种职业性的本能:我学了好几年写代码,现在你说拖拖拽拽就能搞定,那我这些年算什么? 但这个想法撑不住仔细想。我见过太多”绕过工程师”的工具最后还是得靠工程师才能用起来。我更好奇的是:低代码的边界在哪里?它真正擅长解决什么问题? 于是我专门花了一周时间,把宜搭和某开源低代码平台(AM ...
技术学习
未读猫咪版 Git 命令图解这套图来自国外创作者 Lynn Skursky 的”Git Purr”系列,用猫咪的行为类比 Git 核心命令,画风幽默但讲得挺准确。第一次看到时感觉比很多文字教程直观,收藏下来,顺手加了一些自己的理解注释。 图里的角色说明:猫咪对应本地仓库,云端/猫咪聚集地对应远程仓库,毛球/玩具对应 commit。 git purr(git pull) git pull = git fetch + git merge。从远端把最新的 commit 抓下来,直接合到当前分支。 日常用得最多,但多人协作时容易产生一堆多余的 merge commit,让提交历史看起来乱。如果想保持线性历史,可以改用 git pull --rebase。 git meowge(git merge & git rebase) merge:把两个分支的历史合并,保留所有提交记录,会产生一个 merge commit。历史真实,但图形复杂。 rebase:把当前分支的提交”搬”到目标分支的末端,历史是线性的,看起来干净。代价是改写了 commit 的 hash, ...
焦虑的旋涡已经焦虑好长一段时间了,陷入了一个很负能量的思维漩涡。 大事小事,各种事情都会产生焦虑,很不应该这样。 卖掉二手笔记本电脑,全程非常顺利,买家话少,事少,我却很担心中间会有什么其他纠纷问题,甚至担心有套路,很不应该这样啊。 今早坐地铁上班,旁边一个中年男子在用 Kindle 看纯英文的书籍,一个我曾经想冲动消费的电子设备,一个我一直以来最羡慕的语言技能,他拥有这些,却依然通着勤上班。我不喜欢。 我是不喜欢上班么?还是不喜欢把太多精力放在工作上? 我想不清楚我到底向往什么样的生活,目光所及范围内,下一阶段的岗位并不感兴趣。 现阶段的焦虑,到底是因为压力,还是因为没有压力?
Docker Compose:用一个 yml 文件搞定本地开发环境以前本地跑项目,要先开 MySQL,再开 Redis,偶尔还有 RabbitMQ——每次开机都要挨个确认哪个没起来,换台电脑还得重新装一遍。有了 Docker Compose 之后,一条命令全搞定。 一个真实的 docker-compose.ymlMySQL + Redis + RabbitMQ 三件套,大多数 Java 后端项目够用: version: '3.8'services: mysql: image: mysql:8.0 container_name: dev-mysql environment: MYSQL_ROOT_PASSWORD: root123 MYSQL_DATABASE: myapp ports: - "3306:3306" volumes: - mysql_data:/var/lib/mysql networks: - dev-net redis: image: ...
我第一次把项目跑在 Docker 里2020 年下半年,我开始认真研究 Docker。不是主动学的,是被逼的。 项目要迁到新服务器,运维说你们自己搞部署,给你们 Docker 环境。我当时 Docker 基本等于没用过,只知道是”跑容器的东西”。 那两周折腾下来,算是真正理解了容器化到底解决了什么问题。 一、之前的部署方式容器化之前,我们的部署流程大概是这样的: 本地打好 jar 包 用 FTP 或 scp 传到服务器 手动备份旧包,停掉旧进程 启动新包:nohup java -jar app.jar > app.log 2>&1 & 等个一两分钟,curl 一下接口看是否正常 每次上线都在走这几步。环境多了就是噩梦——开发环境、测试环境、生产环境,配置文件不一样,JDK 版本要核对,端口要确认,有时候某台机器上依赖的某个 so 库版本不对,就各种奇怪的问题。 “在我机器上能跑”这个问题我是真的遇到过,不是网上才有的梗。测试环境跑好好的,上了生产就报错,排查半天发现是两台服务器的 JDK 小版本不一样。 二、第一次接触 Docker 的契机就是上面说 ...
被讨厌的勇气刚听了一章《被讨厌的勇气》的解读,内容讲了两件事:目的论,和改变的勇气。 目的论的意思大概是——你以为自己是因为某件事”导致”了现在的状态,但阿德勒说不对,你其实是先有了”想维持现状”的目的,才反过去找了那个理由来撑腰。 听到这里有点不舒服,因为对号入座了。 大概从上周开始,我打算每天健身、练字,给自己定了个很简单的计划。前两三天还算顺利,到了第四天就开始松动了。晚上没去健身的时候,脑子里会自动冒出一个理由——身体有点不舒服,或者饭吃得晚了不适合运动。 说得挺有道理。但书里那句话一下把我钉住了:你不是因为身体不舒服才没去,而是你已经决定不去了,才找到了”身体不舒服”这个理由。 仔细想想确实是这样。那个理由从来不是我主动想出来的,它就那么自然地出现,像是我的大脑帮我提前准备好的一样。如果我真的想去,身体稍微有点不适大概不会是障碍。 这让我觉得,所谓的”执行力不够”,其实很多时候是个假问题。真正的问题是:你没那么想做这件事,但又不好意思直接承认,所以大脑帮你找了个体面的出口。 改变的勇气这部分我理解得更简单一些:改变会带来不确定性,现状哪怕不好,至少是熟悉的。所以很多时候”没时 ...
疫情居家的两个月,我重新审视了自己写的代码2020 年春节,原本只打算在家待一周,结果一待就是两个多月。 最开始几天还在刷新闻,后来慢慢定了下来,打开电脑,开始工作。居家远程那段时间,反而有了一些在公司里很久没有过的感受——第一次有空回头看自己写的代码了。 一、上班时的状态在公司里的日子,需求排着队来。今天这个功能要上线,明天那个 bug 要修,周报要写,评审要参加。 我们团队的 sprint 大概是两周一个迭代,每次排进来的卡基本都是满的。写代码的时候其实没怎么想”这样写对不对”,想的更多是”这样能跑起来吗””接口文档对上了吗””测试那边什么时候开始联调”。 代码 review 是有的,但很多时候都是走形式——互相看一眼,没有明显的 bug 就过了。确实没精力深究,也没人有时间纠结”这个方法是不是太长了”这种问题。 就这样日复一日,代码在赶节奏里写,很少有机会回头看它长什么样。 二、居家后的意外收获有一天,我在修一个线上小问题,改完了顺手往上翻,看了一眼那个模块周边的代码。这一看,就停不下来了。 那是一个做数据导入的模块,我大概一年前写的。我记得当时赶着上线,代码写得比较糙,心里 ...
我从未见过懒惰的人我从未见过懒惰的人; 我见过 有个人有时在下午睡觉, 在雨天不出门, 但他不是个懒惰的人。 请在我胡言乱语之前, 想一想,他是个懒惰的人,还是 他的行为被我们称为”懒惰”? 我从未见过愚蠢的孩子; 我见过有个孩子有时做的事 我不理解 或不按我的吩咐做事情; 但他不是愚蠢的孩子。 请在你说他愚蠢之前, 想一想,他是个愚蠢的孩子,还是, 他懂的事情与你不一样? 我使劲看了又看 但从未看到厨师; 我看到有个人把食物 调配在一起, 打起了火, 看着炒菜的炉子—— 我看到这些但没有看到厨师。 告诉我,当你看的时候, 你看到的是厨师,还是有个人 做的事情被我们称为烹饪? 我们说有的人懒惰 另一些人说他们与世无争, 我们说有的人愚蠢 另一些人说他学习方法有区别。 因此,我得出结论, 如果不把事实 和意见混为一谈, 我们将不再困惑。 因为你可能无所谓,我也想说: 这只是我的意见。 ——鲁思·贝本梅尔



