后端开发经验-阶段性总结思考
背景 做了大半年左右的后端开发后,总结下相关感受。 技术栈:Python/Nodejs + React 行业背景:LLM 应用, RAG, Agent 后端开发思路 后端关注面更广范,几乎要关注整个应用软件运行所需所有的环节: 运维,应用,业务,服务,UI 等。 其中核心工作流在于:充分理解需求,转换业务需求到系统的功能性设计及非功能指标设计。 功能设计上主要关注:数据结构,类包,业务模块,工作流等 非功能性关注:性能,并发,安全,稳定等 玩的是数据 数据算是核心中的核心了。所有的业务基础都是按照这个来的 关系型业务 mysql 或者 pg,选一个吧,这里我还没遇到两者特别大的差异的地方,因为我的业务场景里没那么复杂 这里主要考虑:表结构设计,索引设计。 如果到一定规模考虑 分区,分表,分库 实际业务中大多需要找一个 ORM 库来完成在应用里方便的操作。 如果有 Redis 或者其他异步复杂的事务处理,需要进一步考虑数据一致性。 非关系 Redis,Es,Mongodb,图数据库 日志相关的一般存放到 mongodb 或者es,由于他们在倒排索引的效果做的比较好,方便快速全文索引,海量存储。 Redis:内存数据库,来缓解在 mysql里不经常变动,又频繁查询的操作压力。当然他也可以做一些简单的消息中间件等 图数据库 在一些场景里需要做知识图谱,做关系,图数据库特别适合。这里核心是实体关系等三元组信息抽取,已有知识更新。得益于大模型这个第二大脑的配合,可以通过提示词让LLM帮我们去做实体抽取,三元组信息变得简单很多 小结 这块也是一个非常大的技术体系,往深走的话需要专题讨论。 我这边是入门不久,着重看了 Mysql 执行引擎的内容,B+ 索引的来由。练习了常用 SQL 语法(leetcode 50高频sql) 由于之前了解过大数据基础知识,所以对于我前端出身学习这块,难度不大。 一些中间件 消息中间件 几乎是必须的,做异步,服务结构等 任务队列 做性能,并发等 日志,错误处理等 微服务体系 很多公司其他基础模块都是基于微服务的方式提供的。系统扩充到一定程度肯定少不了微服务架构的梳理 得益于 Service Mesh 这种微服务2.0架构。做上层应用变得异常简单了。日志,监控,服务注册调用 等都在 SideCar里 我之前有过 Nodejs 接入微服务体系的经验,所以这块难度也不是特比大 计算机基础 计算机组成:cpu,gpu,硬盘,内存 操作系统:进程线程协程等,资源管理,IO管理:网络/文件 编译:前端:分词,语法分析,语法树,后端:机器平台生成 分布式-时间空间互换 这里我觉得是计算机性能上一个很重要的思路,在优先的单机资源下实现高复杂度计算的模式。大数据的基石 Hadoop也是这个核心思想。 ...