我们看一个新的技术栈博客很多时候并不理解这个技术栈是干啥的里面提到的很多信息看不懂不理解为什么呢我们用全景视角来解释一下我们拆分两个点1.对于一个技术栈符合人的认识学习是啥样的2.我们现实里遇到的情况是直接怼技术栈提供的机制概念符合人认识的第一层要理解的东西基础概念的本质我这里列举出一些1.关系型数据库这个实际上就是存数据的一种思路解决的是数据存的问题衍生除了表结构字段类型主键2.工程化springboot这个实际上是一个web服务器用户接收和请求来自浏览器的请求衍生出了工程目录结构来实现数据流转的路径第二层要理解的东西写这个博客总结这个技术栈的人的信息环境1.潜在的工程架构信息是在一个工程里架构部署好了工程架子比方说springboot这些都已经弄好了2.潜在的业务需求背景技术栈背后的需求是什么。实际情况写技术或者官网文档的人在做什么他完全在博客中不说完整这些东西他在说什么技术栈内部的拓扑结构这个技术栈里面创造出来的技术概念和名词是什么注意这里完全没有操作对象需求直接说明这个技术概念的内涵是什么第三层要理解的这个技术栈为了全域深刻的解决这个领域遇到的问题发明了哪些概念和机制现象我们读技术博客经常被一堆新名词分区、副本、IoC、AOP砸懵。本质原因写博客的人站在“已经搭好的舞台”上向你描述“舞台内部的机械结构”而初学者连这个“舞台是搭给什么演员、演什么戏”都不知道。结论看技术栈必须反过来从需求场景倒推机制设计。第一层基础概念的本质——它替代了现实中的什么笨办法博客喜欢直接给定义比如“关系型数据库是一种基于关系模型的数据存储系统”。你写博客时可以这样给读者补这一刀关系型数据库本质为了解决“数据如何有条理地存放并且能快速跨表格查找”的问题。现实笨办法Excel表格。一张表放用户一张表放订单用“用户ID”把两张表粘起来。衍生物的由来既然要存得像Excel就必须规定每一列叫什么字段、是什么类型字段类型、用什么来唯一标识这一行主键。SpringBootWeb服务器本质为了解决“如何接收远处浏览器发来的网络消息并给出回复”的问题。现实笨办法你写一个Java程序死循环监听8080端口拿到字符串后自己手动解析HTTP协议。衍生物的逻辑既然要接收请求就要有专门的门卫Controller既然要处理业务就得有专门的车间Service既然要操作数据库就得有仓库管理员Mapper/DAO。这就是工程目录结构的本质——不同人干不同的活代码才不会乱。第二层博客隐藏的信息环境——他们省略了什么写技术博客的人脑子里其实装着一个默认前提但他没写出来。你可以这样向读者拆解隐藏的工程架构博主假设这套代码已经跑在公司的服务器上了Maven/Gradle依赖已经下载好了数据库连接密码已经配置在application.yml里了。他谈论的是这个既定系统内部怎么流转而不是这个系统怎么从零搭建出来。隐藏的业务需求这才是源动力没有“双十一秒杀”这个需求就不会有缓存Redis和消息队列MQ。没有“几十个人同时改同一份代码”这个麻烦就不会有Git分支和Spring的IoC控制反转。读者看不懂的根本原因是因为博主直接说了“IoC是为了解耦”但没告诉读者“解耦”的本质是因为老板老改需求A业务改了不能影响B业务。第三层内部概念与机制——他们在造什么“轮子”这是博客最常写、也是读者最头疼的地方。你可以告诉读者一个通用公式任何一个复杂的技术概念都是为了解决该领域里一个“极其顽固的核心矛盾”而造出来的“妥协方案”。你可以用这两个例子把读者点醒以Redis为例核心矛盾内存速度快太小硬盘速度慢太大。为了解决这个矛盾它造出了过期策略内存不够了必须把不常用的踢出去LRU/LFU。持久化RDB/AOF既然内存会丢那我把内存里的数据定时拍个照RDB或者记个操作日志AOF存到硬盘上重启时再读回来。以Spring事务Transactional为例核心矛盾数据库要求多条SQL要么全成功要么全回滚但Java代码是一行一行执行的。为了解决这个矛盾它造出了事务传播机制如果当前没有事务就新建一个REQUIRED如果当前有事务就加入进去REQUIRED。本质就是决定这个方法是当大哥新建还是当小弟加入。第一步先找“土办法”拿到新框架先问自己如果没有它我用最原始的文件读写、Socket通信、或Excel手工操作该怎么干找到这个答案你就抓住了本质。第二步找“规模压迫”什么情况下土办法会崩溃是数据量太大了还是并发请求太多了还是代码改不动了这就是这个技术栈诞生的业务原点。第三步再翻开内部原理只有走完前两步当你看到“分区”、“副本”、“屏障”这些词时你才能自动翻译成——“哦原来是在解决机器宕机时数据怎么不丢的问题”。
