当前位置：首页 > article >正文

AI算法与应用全栈开发前端开发后端开发测试开发运维开发

article 2025/3/15 3:26:10

AI算法与应用 & 全栈开发 & 前端开发 & 后端开发 & 测试开发 & 运维开发

前言
1.AI算法与应用
- 1.1. 12 days of OpenAI
- 1.2. AI Developer Studio
- 1.3. Transformer
- 1.4. AI Agent & RAG
- 1.5. LangChain
- 1.6. Ollama
- 1.7. LLM应用落地方法论
- 1.8. 从技术创新到场景落地（讲座）
2. 全栈开发
- 2.1. 系统建设方法论及具体方法
- 2.2. Course: IBM Full Stack Software Developer
- - 2.2.1. Introduction to Software Engineering
  - 2.2.2. Introduction to Cloud Computing
- 2.3. 低代码 Low-code
- 2.4. Node.js
3.前端开发
- 3.1. 前端开发注意事项和规范点
- 3.2. 普通基于Vue前端项目框架
- 3.3. 微前端
- 3.4. 案例：前端优化
- 3.5. 案例：PC端-登录/上传文件
- 3.6. 数字孪生（web端）/ XR
- - 3.6.1 Three.js
4.后端开发
- 4.1. 依赖注入（Dependency Injection, DI）
- 4.2. 业务逻辑事务落库和发送邮件提醒
- 4.3. 经典web前后端（Java味）代码结构
- 4.4. 结构化数据、非结构化数据、半结构化数据
- 4.5. NoSQL: MongoDB
- 4.6. 案例：MySQL库表设计
- 4.7. EDA, Event-Driven Architecture 事件驱动架构
- - 4.7.1 幂等性问题
  - - 4.7.1.1 解决方案一：数据库表唯一约束
    - 4.7.1.2 解决方案二：Token + Redis
    - 4.7.1.3 解决方案三：乐观锁
    - 4.7.1.4 解决方案四：Redis分布式锁
  - 4.7.2 最终一致性问题
  - 4.7.3 事件顺序性问题
  - 4.7.4 监控问题
5.测试开发
6.运维开发
- 6.1. 数据库
- 6.2. Server (Based on windows)

前言

本文不记录基础性问题和详细解决方案，只记录key idea，相对比较零散。
AI会改变开发模式甚至行业岗位

1.AI算法与应用

1.1. 12 days of OpenAI

day1: o1解决理工科问题（含数学、工程、代码等），具备较强能力，比o1 preview表现好。o1能很专业的解决工程问题，且接受多模态输入。
day2: Reinforcement fine-tuning for your own use cases. Use o1-mini with reinforcement your own data to solve.
day3: Sora. For Video Generation and a a series of video makeing functional. End to end product, a tool.
day4: Canvas. Wirting & Coding. 我觉得像是把gpt对话框扩展成了一个编辑器+，在canvas里写作和写代码，可以直接给你反馈，而且针对代码，他不仅是能给你建议，而且能直接run你的代码，所以甚至不是编辑器+，是一个和gpt高度融合的通用IDE。
day5: Apple mobile devices. ChatGPT in mobile devices.
day6: Senta. ChatGPT in audio. Advanced voice. 在手机上，直接与GPT对话，并share摄像头/share屏幕，然后咨询问题处理方式，他做出指导。真正的多模态嵌入到移动设备当中。
day7: ChatGPT in project. 读项目代码不会被卡脖子了。但我认为需要具备基础代码能力。
Tips: 前端好好的。后端也好好的。Not over.
day8: Search. You can search web information in chatgpt.
day9: Developer. Building on top of Open AI API. One, like normal, use JSON Schema. Two, real time API in video/audio, so crazy. 只需要12行代码，你就创建了和open ai api的语言实时对话关联。视频中介绍了一种商业场景，在玩具中放上miccontroller模块，与玩具实时对话。让人惊讶点在于，你不需要设置很多硬件设备，不需要制造很多硬件设备，只需要有一个带wifi的，能语言输入输出mic，能充电的小小处理器，然后连上chatgpt，就能实现。Three, fine tuning customization. 除了给精确的输入输出的监督微调，还能给输入，输出给perfer和non-perfer的perfering微调。
day10: 直接打电话给chatgpt，不通过network，降低使用门槛。
day11: Desktop App. Interact with terminal. Interact with code in an IDE. 直接监控屏幕实时变化。
day12: Next frontier model. O3 and O3 mini. AGI. AGI测试集。Interesting, AI里找规律的问题，和行测题很像。Think deeper please.

1.2. AI Developer Studio

开发平台/工具一般包含多种先进的LLM，并开放了很多定制化设置，供用户开发。相比于纯ChatGPT这种使用工具，AI Developer Studio是基于AI的工作平台。
一般来说，满血的账号费用都较高，免费使用的阉割了很多功能，仅开放一小部分数据训练、参数调整以及少量LLM供选择。

1.Vertex AI (Geogle)

Vertex AI Studio：Multimodal、Language(text/tasks/code…)、Vision(video/image…)、Speech(audio…)
LLM (Large Language Model) prompt: Zero-shot prompting / One-shot prompting / Few-shot prompting
Prompt design:
1.freedom:大模型直接问答
2.structured(Context给出背景，Example给出想要的input和output，以规训重点，最后Test)：大模型根据你的偏好，save一个特定大模型，回答你的问题
How to design Prompt（Prompt工程师）:
Be concise
Specific and clearly-defined
ask one task at once
ask to classify instead of generate(要选择题最好不要发散式)
include examples
temperature(概率分布): 对回答的随机程度进行调优， 0-1, 0是确定, 1是随机, 即越靠近0概率越大
top K: 对回答的概率最高的一部分答案进行随机
top P: 对回答的概率最高的答案进行累加，直到累加值达到top P，即对回答的概率最高的答案进行随机
模型调优(Model tuning):
How to customize and tune a gen AI model:
越来越偏技术：
1.Prompt design: Input(required) Context(optional) Example(optional)
2.Adapter tuning(Parameters-efficient tuning): Fine-tuning a model on a specific task or dataset.监督，给出一小部分样本调优参数
3.Reinforcement tuning(Parameters-efficient tuning): Fine-tuning a model on a specific task or dataset.非监督调优
4.Distilling(Student model weight updates): 在Geogle cloud可以做, 可以更加生成特定模型。我理解就是迁移学习。
Difference between AI and Machine Learning:
输出确定的、“旧的”东西，用学术的话，输出的是Number、Discrete、Class、Probability的，叫ML。
能输出“新的”东西，用学术的话，输出的是Natural language、Image、Audio（即所谓的非结构化数据），叫GEN AI。
举个例子，如果输入猫狗图片，且每张图片label是文字“猫”、文字“狗”。训练后模型最后能预测猫狗，这叫ML。
如果输入大量的猫狗图片，且按照你想要的方式进行训练（这里涉及到模型了，具体需不需要lable或者怎么lable有疑惑）。训练后模型最后能生成新的猫狗图片，这叫Gen AI。
AI Develop
Data Security，开源的模型，私有化部署local AI(teacher student…)

2.Azure AI Foundry (Microsoft)

1.3. Transformer

1.绝大多数先进的多模态大模型（如 GPT-4o、DeepSeek、Qwen2.5 等）的底层架构均基于 Transformer，但会根据多模态需求进行扩展和优化。Transformer 的核心优势在于其自注意力机制（Self-Attention），能够高效建模长距离依赖关系，并天然支持并行计算。对于多模态任务（文本、图像、音频等），模型会通过以下方式扩展：

多模态输入编码：将不同模态数据（如文本、图像、音频）统一编码为向量序列。例如：图像被切分为小块并通过视觉编码器（如 ViT）转换为嵌入向量；音频通过语谱图、波形编码、短时傅里叶变换等预处理方式，预处理为向量序列（my work）。
跨模态注意力机制：允许不同模态的嵌入向量在注意力层中交互。

2.Transformer 模型的训练方式
核心训练范式：自监督预训练 + 有监督微调

阶段 1：预训练（自监督学习）：让模型从海量无标注数据中学习通用表示（如语言规律、跨模态关联）。输入和标签均来自同一数据，无需人工标注。典型的方法有掩码语言建模、自回归预测、多模态对齐等
阶段 2：微调（有监督学习）：针对特定任务（如问答、图像描述生成）优化模型。需要人工标注的输入-输出对。指令微调、强化学习等
阶段 3：推理（部署后）。训练时需标签（显式或隐式），推理时仅需输入。

references：
Attention is all you need
十分钟理解Transformer

1.4. AI Agent & RAG

AI Agent

能够基于任务目标执行(行动，动作，action)多步骤动作的系统，它能通过调用工具、API 、知识库、插件、代码库等等，动态规划并完成复杂任务。Agent 具备一定程度的自主决策能力。
核心组成：
Brain: 处理/计算/记忆/计划/决策
Perception: 多模态输入
Action: 调用工具、SDK、API 、知识库、插件、代码库等等，完成交互

RAG, Retrieval Augmented Generation

LLM应用方案。将大模型应用于实际业务场景遇到几个问题：1.无法具备全部知识（包括实时数据、非公开数据、私有数据、私有专家知识等） 2.幻觉（无法具备全部知识）3.数据安全
核心思想：检索增强生成。检索体现在：私有数据/数据存储到向量数据库（因为结合了transformer训练时数据处理word embedding）后高效的检索能力，召回目标知识。生成体现在：大模型+Prompt工程，将召回的知识合理利用，融入到Prompt里，大模型更根据目前的提问+能够参考相应的知识（上下文），生成目标答案。

Tips:
Prompt工程：一般包括任务描述、背景知识（检索得到）、任务指令（一般是用户提问）

1.5. LangChain

LangChain is a framework for developing applications powered by language models.
python version & JS/TS version
Components / Off-the-shelf chains: Off-the-shelf chains make it easy to get started. Components make it easy to customize existing chains and build new ones. Components fall into the following modules: Model I/O(prompt)、Retrieval(RAG)、Agents
胶水层

1.6. Ollama

Get up and running with large language models.
本地部署（非常方便的）多种LLMs
支持模型微调
支持命令行运行与直接交互、Ollama 的 Python SDK使用、API交互、WebUI

1.7. LLM应用落地方法论

概念验证：确定使用场景、案例、数据。初步测试LLM是否符合预期
评估LLMs: 测试并选择出最合适的LLM模型
部署、监控和安全：Local VS Cloud-Based deploy
持续性和可靠性：CI/CD
模型迭代/管理
经典场景与方向：RAG & Agent

1.8. 从技术创新到场景落地（讲座）

通义千问与DeepSeek的技术突破及企业应用前瞻

大语言模型：通用模型(基础模型能力/Agent两条线，我理解就是算法和工程两条路)(语料,T级数据) / 推理模型
多模态模型：多模态理解 / 多模态生成

DeepSeek：真实能力 / 算法 / 工程 / 其他工作 - > 爆

deepseek V3 突破性技术与应用

MoE / 671B / excellent / low cost

Architecture Opti:
MLA(Multi-Head Latent Attention，空间换时间->reduce KV cache压缩->损耗？->细节处理，不同压缩方式)
MoE(Mixture-of-Experts, router选Experts。多个Experts -> load balancing ->打分选不同Experts)
MTP（预测下一个token->预测下两个token->预测下n个token）

Infrastructure Opti:
Train Framework(并行，硬件？)
DualPipe(bid pipeline scheduling，减少了last one和中间的waiting(空泡)，硬件？)
FP8 training(浮点数)

deepseek R1 突破性技术与应用

RL auto / few shot prompting / Distillation / 规则奖励reward / better reasoning

pretrain -> SFT (labelled) -> RL

deepseek-r1-zero: Training Template (Prompt Engineering) / Rule-based Reward Models (Accuracy reward: Math and Coding. Format reward: < think >) / GRPO (Group Relative Policy Optimization)

deepseek-r1 (solves issues of deepseek-r1-zero): deepseek-v3-base +SFT(poor readability)+RL(reasoning + language mixing)+SFT(reasoning + general)+RL(human preference alignment)

Distillation (base-model ability is important)

2. 全栈开发

2.1. 系统建设方法论及具体方法

一、方案调研：

网络搜索、AI、同学同事圈，确定解决方案：

选择一：外采
根据调研结果，联系供应商，明确需求，明确报价，明确时间点，明确数据安全问题。

若采用此方案，后续工作只需要作为业务方和供应商的中间媒介和监督者的角色即可，即将业务需求尽量翻译为计算机实现方式（也可以让供应商提供该人员）给到供应商，同时对供应商的开发进度、产品质量等方面做总体把关，不需要了解技术细节。

即，此时计算机从业人员为产品经理 & 项目经理 & 甲方经理（类似于土建行业的甲方）角色，因此后续工作也将不再涉及。

选择二：自研
通过需求，抽象出我们想要的功能，可以借助AI工具帮我们做抽象。然后根据相关关键词，通过网络搜索、AI、同学圈、同事圈四个方向进行调研，形成框架思路。如是简单的增删改查系统，我们可以直接进行实现，如涉及到核心逻辑/业务逻辑，则需更进一步思考大概的技术解决方案。

与此同时，我们需要考虑基础设施的问题，即我们的系统是部署到自有物理服务器上还是部署到云上，亦或是混合的方式，亦或是我们只需要一个微信小程序，一般来说系统级应用微信小程序搞不定。

对于大型互联网公司，往往有自己的物理机房，甚至有自己的云集群，且基础设置较为完备，因此不需要考虑此问题。

对于一些敏感性企业（银行/国企），由于数据的敏感性，也需要部署到自己的物理服务器上，或是本地&云混合的方案。

对于中小型企业，往往可以直接上云，公有云相对私有云价格更合适，若想保护数据安全也可以采用私有云部署。

上云的一个很大的好处是即租即用即部署即调整。举个例子，你有一个系统，如果想要部署到自己的服务器上，首先你需要采购物理服务器，然后要布线网络，然后要对服务器环境进行初始化，如安装一些基本的系统运行环境，并在一个相对不友好的界面监控。与此同时，你的服务器资源也不是百分百利用，甚至你还要考虑网络安全、设备安全等等一系列的运维问题。如果采用市场上常用的Iaas、PaaS等云服务，那么将极大的节省前期建设成本、中期运维/管理/监控成本、后期回收成本以及一系列的安全问题、法律问题(IP、DNS备案等等)。

最后，在敲定解决方案后，形成第一次汇报报告。

注意事项：对于百分之80的情况，我们需要用敏捷开发的思想来构建系统，即step by step完成最终目标。当然，如果你的+1/+2允许你更完善，那便可以多想一些技术实现。总而言之：沟通出平衡点。老板关注的是时间成本和金钱成本，以及回报，用英语说就是Tell Me Your Story。最后才可能感兴趣实现。兄弟们，哈哈

二、系统架构设计：系统包含哪些平台、宏观上具备哪些功能

根据市场常见手段或自己的业务人员拉会头脑风暴，明确高优先级需求，抽象出架构图，一定要明确包含哪些平台、包含哪些核心功能。

与此同时，明确技术方案。即采用全栈一把梭方案（常见的如python Dj框架），还是采用前后端分离方案（常见如国内公司后端Java配spring、国外公司后端c#配.net等等，前端vue、react等），数据库一般国内用MySQL，国外MS SQL。对于进阶级别的系统，需要考虑Nginx做前端服务器做反向代理，后端部署服务器若考虑分布式服务还需要经典的spring cloud配合服务注册、服务发现等，再进一步，需不需要redis缓存、需不需要kafka消息队列对并发性做一些优化，这些都要根据具体需求考虑，亦或是前期留下相关接口，后期迭代时再考虑接入。

此时有许多细节需要注意，比如orcal jdk和open jdk的区别，MySQl企业版和MySQL Community Server的区别。许多国外工具讲究租的概念，即可能你可以下载下来使用，一段时间后你无法使用或提示会有账单，且作为企业级应用具有很多安全风险、法律风险。因此，需要具备对开源工具和闭源工具的识别。

注意事项：AI辅助加速设计进程

三、用户界面设计：统一UI风格，用户友好，不学即用

根据需求敲定UI页面，确定包含哪些交互及展示方式，与业务方碰头，进一步明确需求。（该部分要控制好时间，根据情况决定方向。如果时间不乐观警惕业务人员陷入页面细节优化）
注意事项：AI辅助加速设计进程

四、数据模型设计：数据库表设计

范式、索引。具体设计思路可以按上面的想法，同时注意对业务场景的实体抽象要尽可能合理，符合人类社会对事物的认知。注意事项：AI辅助加速设计进程，且可以辅助出UML图，帮助开发实现。

五、逻辑功能设计：明确核心逻辑所采用的算法实现。比如某些核心系统在状态转移的逻辑怎么实现。
六、敏捷开发人力计划：明确方案。

明确阶段目标、明确需求表达、明确接口定义（对于前后端分离项目来说，接口就是前后端工作集成的协议，必须尽可能今早敲定），合理根据开发量、难度设定人力。

七、代码开发

代码开发中的一些最基本的规则：

1.后端代码逻辑中，运用回溯等算法时，注意边界条件，尽量逻辑完备。注意算法的时间和空间复杂度，善用各类数据结构，最简单的一遍Map可以替代N遍循环。
2.注意代码的保护。加try catch保护系统稳定。
3.数据的增删改注意并发性和完整性，考虑事务。数据库的查考虑效率。
4.代码善用设计模式可以提高可维护性。
5.前端代码考虑数据为空的展示，考虑页面布局大小的flex展示，考虑渲染压力，考虑表单的校验，考虑用户的输入不规范处理、考虑数据初始化等等。

注意事项：AI辅助可以大大加速开发速度或是代码阅读debug速度。具体开发中还有很多实际问题和技术细节，之前的博客中均有记录。目前也在这个方向上继续深入。

八、测试
测试相当于传统制造业中的质量部门，从更专业的角度保证我们的产品更加完备。

单元测试：开发人员自测，自己保证功能的可用与完善。

集成测试：前后端链接，将软件的不同部分组合在一起。作为整体保证整个系统的可用与完善。

产品测试：从功能完备性的角度和复杂情况的角度，设计测试案例，保证整个系统的功能完备，符合需求。

安全测试：通过拦截包修改参数、身份验证等专业方式，测试系统的安全性。

性能测试：响应时间、吞吐量、资源利用率，有QPS指标等等。

用户测试/验收测试：由客户或用户对软件进行测试，以验证软件是否满足他们的需求

九、部署及运维：

部署窗口期、是否灰度、部署方案、回滚机制等等。监控软件运行状态。

十、用户支持：

分析用户问题属于系统BUG还是使用问题，耐心解答。一定不能告诉用户不能解决、不知道等拱火回答。

十一、成果展示与结束：Power Point Presentation，论文 / 专利 / 软著，成果落地结束

2.2. Course: IBM Full Stack Software Developer

很多全栈知识来源于这里，包括把前后端开发类比装修。

2.2.1. Introduction to Software Engineering

Software Development Life Cycle, SDLC: planning (including requirements), design, development, testing, deployment, and maintenance.
Requirements Documents
在软件开发生命周期（SDLC）中，SRS、URS和SysRS是用于描述软件需求的文档。它们分别代表软件需求规格说明书（Software Requirements Specification）、用户需求说明书（User Requirements Specification）和系统需求规格说明书（System Requirements Specification）。下面是它们的详细解释：
软件需求规格说明书（SRS）：
- SRS是一个详细的技术文档，它描述了软件系统必须做什么，以及如何满足用户的需求。
- 它包括功能需求、非功能需求（如性能、安全性和可用性）、接口需求、设计约束和假设条件等。
- SRS是开发团队、测试团队和项目管理人员的重要参考资料，它为软件的设计、开发和测试提供了依据。
用户需求说明书（URS）：
- URS是由项目团队与用户和利益相关者合作制定的文档，它以用户的角度描述软件系统的需求。
- 它通常包括用户的目标、期望的功能、操作流程、用户界面需求等。
- URS是需求分析阶段的重要输出，它为SRS的编写提供了基础。
系统需求规格说明书（SysRS）：
- SysRS是一个综合性的需求文档，它描述了整个系统的需求，包括硬件、软件、人员和过程等方面。
- 它不仅包括软件的需求，还可能包括网络、数据库、安全和其他系统组件的需求。
- SysRS通常在系统层面进行制定，它为系统的设计、开发和集成提供了指导。
这些文档之间的关系通常是这样的：URS是用户视角的需求描述，SRS是基于URS进一步细化和技术化的软件需求描述，而SysRS则涵盖了整个系统的需求，包括但不限于软件需求。
在编写这些文档时，应该确保需求的完整性、一致性和可验证性，以便为软件的开发和测试提供清晰的方向。同时，这些文档应该随着项目进展而不断更新和细化，以确保它们始终保持最新和准确。
method of SDLC

a.type

Waterfall model: compliance. These methodologies made it very difficult to adapt to change because by the time testing started, not all requirements were relevant anymore. This often resulted in software products that did not meet expectations because they couldn’t change fast enough along with new requirements.
V-shape model
Agile: Responding to change over following a plan. (Feedback, Modularization, hard to schedule). Scrum methodology

b.testing

In my situtation: unit testing, sit, 安全/性能测试，fat，uat
In course situtation: Unit testing, Integration testing, System testing, Acceptance testing

c.doucmentation
d.different job roles

Front-end developer

To create a website, web developers usually use HTML, CSS (SASS, LESS), JavaScript.
JS framework: Angular, React.js (JS library, routing is not of this), Vue
multiple browsers, multiple operating system, multiple devices.

Back-end developer
JavaScript (Framework: Node.js and Express)
Python (Framework: Django and Flask)
别把眼睛就放在Java、C++、Go、C#！！！！！
随着AI发展，开发成本下降，我认为将来一定不会用语言来区分岗位
agile & team work & pair programming
Tools of Development (include all): Version Control & Libraries & Frameworks (框架决定了代码工作流程，it call 控制反转) & CI/CD (DevOps) & Build tools & Packages & Package Manager
technology stack (more bigger then software stack) & software stack：技术栈。
some interesting stack:

MEAN: MongoDB / Express.js / Angular.js / Node.js
MEVN: MongoDB / Express.js / Vue.js / Node.js
LAMP: 感觉前后端分离，后端用java / c++ / go等，前端用vue php 原生等，都是该的变体

Type of Languages

Interpreted (programming) languages (also called script language, go through an interpreter in the OS or Browser): Python, JavaScript, Lua(game), HTML
Compiled (programming) languages (Executable files on device): C/C++/C#, Java
Query languages: SQL
Assembly languages

Pseudocode & Flowcharts
object-oriented programming & procedural programming
Software Design and Architecture

UML, Unified Model Language. System Design & Architecture.
Component-Based & Service-Based Architectures: Object -> Component -> Service
Distributed system architecture: client-server (bs) / peer-to-peer / three-tier / Microservices(HTTP/HTTPS、gRPC) / …
详解事件驱动 / 微服务

Application environments
Application environments: dev / test / staging / prod
Cloud deployment types: Public / Private / Hybrid
Skills of Software Engineer
Hard Skills of Software Engineer: Design, Build, Maintain, Repair
Soft Skills of Software Engineer: Team work, Stakeholders
Job titles
Front-end engineer
Back-end engineer
Full-stack engineer
DevOps engineer
Software quality assurance engineer
Software integration engineer
Software security engineer
Mobile app developer
Games developer

2.2.2. Introduction to Cloud Computing

Cloud technology: On demand. Self-serving.
Alibaba Cloud: Aliyun
A cloud strategy: core component of any business strategy today. eg.弹性资源/敏捷部署/高速计算/全球化/AI…
AI / Big Data / IoT / Blockchain
Blockchain: An immutable network allowing members to view only those transactions that are relevant to them.
IaaS (System Admin)-> PaaS(Dev) -> SaaS(Users)

IaaS: is a form of cloud computing that delivers fundamental compute, network, storage to consumers on-demand, over in internet, on a pay-as-you basis.
Test, Development, Deploy faster / Business Continuity and Disaster Recovery / Scalability / High performance Computing / Economically Balance
PaaS: is a cloud computing model that provides a complete application platform to Develop, Deploy, Manage.
High Abstraction (eg网页点击就能部署) / focus on application develop

mPaaS（mobile Platform-as-a-Service），起源蚂蚁金服。
具体能力见：

mPaaS能力介绍1
mPaaS能力介绍2
实时发布服务能力MDS
离线包
小程序

SaaS: a cloud offering that provides access to a cloud-based software.

交付模型：SaaS、PaaS、IaaS

部署模型：私有云private cloud、社区云Community cloud、公有云public cloud(省钱，然而concern Security and Data)、混合云Hybrid cloud

商业优势：省去软硬件成本/构建成本/运营成本等等多种成本，且成本控制监控灵活可变，可快速敏捷部署，用户友好等等多种优势

云计算（cloud computing）中讨论的服务包括基础设施即服务（IaaS, Infrastructure-As-A-Service），平台即服务（PaaS, Platform-As-A-Service）和软件即服务（SaaS, Software-As-A-Service）三个层次的服务。（理解：IaaS如买的阿里云买的服务器、PaaS如mPaas提供了移动平台、SaaS如钉钉，三个层次层层递进）

怎么选择？如果有应用，且没时间重新构建cloud native application，则选择IaaS. 如果有应用，有时间，则可以考虑re-platform，如果没应用，但有时间也可以基于PaaS开发cloud native. 如果没应用，没时间，直接买SaaS，因为SaaS很多时候也不是定死的，可以定制化一些东西，当然supply提供support定制更多

Virtualization / Hypervisor: cost saving, agility speed, backup…
Cybersecurity
Containers: Executable Unit of Software. Package Application Code, Libraries, Dependencies. Run anywhere, include desktop, Traditional IT, cloud.
eg. k8s, docker.
容器化在规模、灵活性、可拓展性(cloud native思想，弹性伸缩复制服务)、统一性等方面超过VM
cloud storage

Direct Attached
File Storage
Block Storage
Object Storage

2.3. 低代码 Low-code

（低代码行业市场崛起：预计2025年市场规模将达到131.0亿元-中金企信发布低代码行业市场崛起：预计2025年市场规模将达到131.0亿元-中金企信发布。美国在低代码领域研究的时间较长，在经历了萌芽期、探索期等阶段后，已经进入到巨头的整合阶段。相较而言，国内对于低代码的研究较晚，目前仍然处于探索阶段。国内低代码产品的应用路径从早期的数据库交付、数据集结构搭建逐渐抽象出各种流程引擎、可视化界面等，而应用也从BPM延伸到更复杂的应用场景如ERP、CRM等应用系统的搭建。同时，低代码开发平台的使用门槛也在降低，主要使用群体由专业开发人员和业务人员共同构成。）

国内外低代码厂商：钉钉宜搭、简道云、氚云（BPM起家）、金蝶云苍穹、炎黄盈动（BPM专家/流程数字孪生）、Mendix…

Node-RED: Low-code programming for event-driven applications. The easiest way to collect, transform and visualize real-time data. Node-RED is built on Node.js, taking full advantage of its event-driven, non-blocking model. 可以直接通过NPM安装，通用IoT编程工具，关键概念：Node节点、Flow流，用户拖拽建立流程。

2.4. Node.js

Node.js is a free, open-source, cross-platform JavaScript runtime environment that lets developers create servers, web apps, command line tools and scripts.

Node.js 是单线程、事件驱动、非阻塞 I/O 模型

单线程：Node.js 在一个单独的线程中运行 JavaScript 代码，这意味着它一次只能执行一个任务。这种设计避免了多线程编程中的复杂问题，如线程同步、死锁和竞态条件，使得代码更加简洁、易于理解和维护
（之前Java/spring boot的线程池那一套）
事件驱动：Node.js 使用事件循环来处理并发请求。事件循环是一个无限循环，它不断地检查任务队列中的任务，并在任务完成后执行相应的回调函数。这种机制使得 Node.js 能够在一个线程内同时处理多个请求，而不需要为每个请求创建一个新的线程
（联想到架构范式EDA，事件驱动架构，又联想到消息队列Kafka，又记录联想到什么场景需要？高内聚低耦合，交易处理链路较长的准实时或非实时场景，或是广播类型场景，例如移动商城抢购后需要跟进的一系列动作短信通知、发货申请、更新订单状态等。又发现有什么典型需要处理的错误？重复处理/消费等，所以要考虑幂等。查询类操作还好，变更类操作，一定要考虑幂等设计，联想深入终止。）
非阻塞 I/O：在 Node.js 中，I/O 操作（如文件读写、数据库查询、网络通信等）不会阻塞主线程。当执行这些 I/O 操作时，Node.js 会将这些操作委托给底层的线程池，主线程可以继续处理其他请求。一旦 I/O 操作完成，事件循环会将相应的回调函数放入任务队列中，等待主线程执行
（之前Java/spring boot的线程池那一套）

Node.js 不适合处理 CPU 密集型任务。
Java 的多线程模型使其能够更有效地处理 CPU 密集型任务。

Node.js：适用于实时应用（如聊天应用、直播流、协作工具等）、微服务架构、流媒体应用、物联网应用等。
Java/Spring Boot/JVM，适用于大型企业级应用、科学计算

3.前端开发

3.1. 前端开发注意事项和规范点

eslint代码规范
接口async/await语法糖trycatch
无数据避免空白页（用户友好）
移动端盒模型border-box和flex
ts为java风的js等等
vue表单项交互数据挂载注意更新与初始化

3.2. 普通基于Vue前端项目框架

基于Vue框架的前端：webpack or vue-cli，将.vue文件及各类配置文件等文件，打包编译成浏览器认识的html/css/js（尤其是js）

package.json ：项目的 package.json 是配置和描述如何与程序交互和运行的中心。 npm CLI（和 yarn）用它来识别你的项目并了解如何处理项目的依赖关系。package.json 文件使 npm 可以启动你的项目、运行脚本、安装依赖项、发布到 NPM 注册表以及许多其他有用的任务。 npm CLI 也是管理 package.json 的最佳方法，因为它有助于在项目的整个生命周期内生成和更新 package.json 文件。

移动端页面适配（vue中实现移动端页面样式自适应）：
lib-flexible插件配合postcss-px2rem插件（阿里解决方案，配合了vant组件库）
方案流程：

npm i lib-flexible --save，在main.js里import ‘lib-flexible’，设置or注释掉标签< meta >
flexible会为页面根据屏幕尺寸自动添加标签，动态控制initial-scale，maximum-scale，minimum-scale等属性的值。同时flexible.js文件中封装这refreshRem方法,与页面监听事件绑定,可以动态设置根元素的font-size。体现在页面上就是html根上的style="font-size"会根据机型屏幕尺寸变。
举个例子：如iphone6的尺寸是375px，它的页面上就是html根上的自动被依赖设置为style=“font-size: 37.5px”
在lib-flexible里的flexible.js源码里的refreshRam()体现了这一核心操作，他的rem也是 var rem = (width / 10) + ‘px’。
该公式的物理含义为 1rem=1根元素字体大小
在做rem布局方案中，一般推荐是将我们的网页划为十等份，我们的HTML标签的字号为视口宽度的1/10（和上面公式也对上了）。
举个例子：375尺寸的设计图，1rem=37.5px，即1rem十等分了设计图尺寸。
只用该插件我们可以在样式文件中直接以 rem 作为单位编写样式，而无需手动计算不同屏幕下元素的具体尺寸。
npm install px2rem-loader，配置px2rem-loader，在build文件中找到util.js，将px2rem-loader添加到cssLoaders中，设置remUnit: 设计图尺寸 / 10
postcss-px2rem会将你写的px值转换为对应的rem，rem单位用于适配不同宽度的屏幕，它是根据标签的font-size值来计算出结果的。设置完remUnit我们就可以直接根据设计图上的px值进行正常开发了。
举个例子：如果设计图尺寸是375的，此时remUnit就要设置成37.5。此时在该设计图尺寸下16px就是16 / 37.5 = 0.426667rem（rem是个比例单位）。当机型变成其他尺寸，如414，此时16px字体尺寸肯定要等比例放大。此时lib-flexible已经帮我们把根元素的font-size变化更新了出来，postcss-px2rem帮我们转换px尺寸。在设计图375px下是根元素fontsize是37.5，此时更新成了41.4，代表的物理含义是1rem = 41.4px，最后该375下的16px字体就变成了414屏幕尺寸 41.4 * 0.426667 = 17.6px。

mpaas框架下移动端h5调用native的能力：引入alipayjsapi

3.3. 微前端

微前端概念和微服务一样，解耦前端页面框架。可以做到vue、react、原生混合开发，互相解耦。典型框架是qiankun

3.4. 案例：前端优化

问题：把一个word文档内容（分不同章节）展示在一个竖直大长页中，包含多个echarts/表格/页面数据、多个接口请求。除上拉滑动查看外，还可以大纲直接点击章节查看。如何实现并优化？
解决方案：章节锚点（定位） + 上拉滚动监听（优化按需渲染压力、按需发送请求压力）+ 节流（优化滚动监听频率）+ 异步组件懒加载（优化按需渲染压力、按需发送请求压力）+ 章节锚点flag数组（避免重复发送请求）
echarts / g2plot 画图：1.id重复画图问题。2.g2plot更新数据要调用更新数据的方法，echarts更新数据要重置配置里的data。3.实时更新数据用watch就行。
数据制作成展示结构（包括页面直接展示、表展示、柱状图、饼图、折线图展示，类似于仪表大盘实现）：
大概：由于该需求特殊性，前端整理组织全部数据。故利用工厂设计模式整理数据。页面多个模块显示内容是调用不同接口得到数据，且包含列表、echarts、直接显示等多种展示方式，给每个某块设计一个独立的vue data属性，即独立的数据结构对象（其实有点typescript的感觉）。实时性可采用定时器发请求。
具体：.map方法数组筛选出数组、三个点…拆装箱、固定自定义数据结构。注意let temp = { a:[] }初始化列表。直接属性temp.b = 3可以，列表temp.a.push()必须初始化了a才行。
webworker：该需求js数据计算的量级不大，单次处理不到100条数据，所以没用webworker
总结：章节锚点（定位） + 上拉滚动监听（优化按需渲染压力、按需发送请求压力）+ 节流（优化滚动监听频率）+ 异步组件懒加载（优化按需渲染压力、按需发送请求压力；非v-if不完全懒加载，webpack打包后文件验证）+ 章节锚点flag数组（避免重复发送请求） + 其他优化考虑（由于是mpaas离线包方案，故没采用gzip压缩；由于计算量不大，没采用并发webworker） + 图表（多表头固定首列原生tr/td实现，饼图/柱状图等统计图用echars/g2plot框架实现，实时变化加定时watch，多张图不能混id） + 表单联动规则（map数据结构编码联系;事件冒泡阻止） + 每章节同一组数据文字/表/图三种展示方式（工厂设计模式整理数据，On处理出一个章节的数据结构，类ts思想）

3.5. 案例：PC端-登录/上传文件

1.针对上传文件功能：

element-ui的上传文件组件。前端默认发的是post请求，Content-Type为multipart/form-data，即通过常见的FormData编码（一般二进制文件上传都要用这个）类型把File类型（继承Blob，二进制，其type属性为为该文件具体的MIME类型）文件直接传上去了。后端Spring框架的MultipartFile类来处理上传的文件（它通常用于处理multipart/form-data类型的请求），通过get等方法获取文件信息、文件流内容等，处理文件。该流程也是比较常见常规的上传文件流程。
针对OSS场景，可通过阿里OSS给前端/客户端/后端暴露的oss.put()调用上传文件。前端/客户端发的是put请求（后端没验证，但感觉大概率是。PUT请求用于向指定URL传输文件或数据，在文件上传场景中，可以使用PUT请求直接将File从客户端发到服务器，和前面post传文件涉及到了restful风格接口设计问题），Content-Type为application/msword或其他类型或干脆没有Content-Type字段，通过该编码类型把File类型（继承Blob，二进制，其type属性为该文件具体的MIME类型）文件传上去了。可以看出来和element-ui的上传文件组件及后端处理文件方式这一条龙相比，没用multipart/form-data对文件进行编码，而是直接甩File上去。再次，针对大文件上传。blob切片上传。这里文件包含音视频文件、文本文件等全部，都是处理二进制文件流/blob，然后针对所有场景加上各种编解码规则。最后，为了防篡改可以加验签环节。
断点续传：可以使用 localStorage 或 sessionStorage 来存储已上传的切片信息，包括已上传的切片索引、切片大小等。采用文件唯一标识符或用户会话标识符进行区分。

2.针对登录功能（PC页面；基于mpaas hybird方案移动端一般由客户端控制登录）：

1.区分二维码登录和账户登录
基于账户登录：
2.登录（登录验证、登录保持、登录退出）：

localstorage获取缓存的用户名等其他信息做展示
用户名和密码校验（特殊字符校验、长度校验等定制化校验，即表单校验）
上锁（防止重复登录）
client发请求获取公钥（服务端生成），拿到返回结果后，通过SM2加密算法和公钥，加密密码
clinet将用户名和加密后的密码发请求*
server返回的header里Set-Cookie加密token、加密sessionId（涉及redis会话保持），并在body里放了加密token和用户uuid
解锁，到此步已经登录成功，后续均为具体需求场景
client拿用户uuid和token发请求，拿到用户全部信息
client清除之前的localstorage、sessionstorage中无用缓存信息，并set新的用户信息（可用做下次登录用户名头像签名等信息的展示等等），并格式化用户信息数据，并vuex中保存信息。（总结：清除/初始化localstorage、sessionstorage、vuex中保存的用户信息，vuex/localstorage等保存这些可以用来做登陆保持）
获取菜单信息，动态调整页面路由，千人千面
退出。清除信息、状态，返回登录页。

基于二维码登录：
3.登录（登录验证、登录保持、登录退出）：

拿到qrcode的string，通过组件生成qr码
二维码定时器发检查登录状态，再来个计数器刷新码
检查成功，发请求拿token后边都一样

tips细节：

为了更安全，可以在3.client发请求*时候再来个公私钥密码对发给server，这样server发来的sessionId和token也能加密）
登录过程中有许多信息需要共享使用，借助vuex可以在代码中共享
sessionId和token一般会set在cookie里。（cookie localstorage sessionstorage区别在前文）
token放在cookie无法跨域，可以放在HTTP请求的头信息Authorization字段或者代码里存一下；sessionId遇上分布式场景，可以存在redis里来识别。
加密/解密（防泄露）和签名/验签（防篡改）
加密/解密过程：密码原理上安全，但可以抓到公钥，而且可以篡改信息
a -> b ：a请求登录，需要加密密码，向b请求获取公钥
b -> a：b配合加密算法生成公/私钥对，自留私钥，给a发公钥
a -> b：a拿到公钥，配合加密算法，加密密码，发给b，b用私钥解密

签名/验签过程：保证信息不会篡改，就算抓到报文和公钥，因为不知道私钥也没法改信息
a -> b：a配合加密算法生成公/私钥对，自己对信息做签名，把签名（即加密后信息）+原文信息发给b
b -> a：b收到消息后，向a发请求获取公钥验签
a -> b：a给b发公钥
b：b验签

加密配合签名，可以保证防泄漏和防篡改。整个报文加密，需要通过https进行网络传输层面加密。

3.6. 数字孪生（web端）/ XR

层层递进：

OpenGL：跨平台的原生图形渲染 API，适用于桌面/移动端原生应用开发。在原生操作系统运行，提供直接操作 GPU 的底层接口。
WebGL：基于 OpenGL ES 2.0 标准的浏览器 JavaScript API，是 OpenGL 在 Web 环境的实现，可在浏览器中呈现3d图形。
Three.js：通过 JavaScript 简化 WebGL 操作的高级 3D 库。将 WebGL 的底层调用封装为易用的对象。
A-Frame: 面向 WebXR/VR 的 HTML 标签化框架，底层依赖 Three.js。用类似 HTML 的标签定义 3D 物体（如 < a-box >、< a-entity >）。默认集成 VR 设备支持。（Tips: VR, Virtual Reality. AR, Augmented Reality. MR, Mixed Reality. XR, __Reality. ）

（物理引擎: Cannon.js（专注于刚体物理模拟的 JavaScript 库）等等）

+-------------------------------+
|  Renderer Process (JavaScript) |
|   - Three.js 逻辑              |
|   - WebGL API 调用             |
+-------------------------------+
              ↓ IPC
+-------------------------------+
|  GPU Process                  |
|   - 转换 WebGL 为原生图形 API    |
|   - 管理显存资源                |
+-------------------------------+
              ↓ 系统调用
+-------------------------------+
|  OS Graphic Driver           |
|   - Direct3D/OpenGL/Vulkan    |
+-------------------------------+
              ↓ 硬件指令
+-------------------------------+
|  Physical GPU                 |
+-------------------------------+

3.6.1 Three.js

Three.js 应用都必须包含这三个核心对象：

场景（Scene）
scene = new THREE.Scene();
相当于一个3D舞台，所有要显示的对象（模型、灯光、相机）都必须添加到场景中
相机（Camera）
camera = new THREE.PerspectiveCamera(75, aspect, 0.1, 1000);
决定用户能看到场景中的哪些部分，类似人眼的视角。
Three.js 使用右手坐标系。
渲染器（Renderer）
renderer = new THREE.WebGLRenderer({ antialias: true, alpha: true });
作用：将场景和相机的内容绘制到网页上（生成图像）

几何体（Geometry）与材质（Material）:

高性能几何体BufferGeometry与普通 Geometry：定义物体的形状，包含顶点坐标、颜色、法线等数据。
材质Material：定义外观特性
将几何体和材质结合，创建一个可渲染的系统

光照系统：环境光（AmbientLight），提供均匀的基础照明，没有方向性。点光源（PointLight）：从一个点向所有方向发射光线，类似灯泡。
动画与更新机制：如requestAnimationFrame 以显示器刷新率（通常60Hz）循环调用函数。每次循环中更新粒子位置并重新渲染。
相机控制器（OrbitControls）：允许用户通过鼠标拖拽旋转、缩放、平移场景。监听鼠标事件，修改相机的位置和朝向。
Three.js 创建的 WebGL 资源不会自动释放，必须手动清理

4.后端开发

4.1. 依赖注入（Dependency Injection, DI）

依赖注入（Dependency Injection，简称DI）是一种设计模式，用于实现控制反转（Inversion of Control，简称IoC）。在依赖注入中，对象的依赖关系不是在代码中直接创建的，而是通过外部容器（如Spring、ASP.NET Core等）来管理的。

在传统的编程中，对象的依赖关系通常在代码中直接创建。例如，在一个类中，你可能直接创建另一个类的实例，或者使用构造函数或方法参数来获取另一个类的实例。这种方式可能会导致代码的耦合度增加，使得代码难以测试和维护。
依赖注入通过将对象的依赖关系从代码中分离出来，由外部容器来管理，从而降低了代码的耦合度。在依赖注入中，对象的依赖关系是通过构造函数参数、方法参数或属性来注入的。
举个例子：C++需要自己释放对象管理内存，Java有JVM帮你管理对象释放内存，如果没有mybatis这些框架，那么你需要自己写连接与释放mysql连接，如果有，他会自动管理数据库连接的生命周期，包括创建连接、使用连接和关闭连接，在MyBatis中，连接池是通过SqlSessionFactory类来管理的。如果我们要用该方法，可以通过依赖注入的方式引入，即依赖注入通过将对象的依赖关系从代码中分离出来，由外部容器来管理，从而降低了代码的耦合度。（这段话其实解决了两个问题，1谁来管理数据库连接资源，2如何用到代码中即注入到代码框架中）

4.2. 业务逻辑事务落库和发送邮件提醒

复杂业务逻辑涉及到多张表的增删改，需要用事务来保证一致性。最后发送邮件，最好送到消息队列里（Kafka），因为邮件发送服务器往往具有有时间长、异步的特点，且有网路延迟问题，放到kafka里可以应对并发场景，并提高用户前端感知响应速度，且信息丢失可能性降低。

4.3. 经典web前后端（Java味）代码结构

PO（Persistent Object）/ DO (Domain Object) :PO/DO通常用于表示数据库中的表结构，每个PO都对应一个数据库表，其中包含了该表的属性和方法等信息。
(bean、entity、model)
DAO（Data Access Object）：DAO通常用于封装数据访问逻辑，以便在业务逻辑中使用。
（mapper）
BO（Business Object）：BO通常用于封装业务逻辑，使得业务逻辑与其他模块解耦。
(service、manager、business)
DTO（Data Transfer Object）：DTO通常用于封装数据传输逻辑，主要用于不同模块之间的数据传输。
VO（View Object）:VO通常用于封装界面显示所需的数据，使得界面与后端服务解耦。

下方为流转关系
View < -------VO------- > Controller < ----DTO— > Service(BO) < -----PO------ > DAO < ------ > database

4.4. 结构化数据、非结构化数据、半结构化数据

结构化数据是指具有固定格式和长度，并且数据元素之间存在明确关系的数据。它通常以表格形式存储，如关系型数据库中的行和列。
非结构化数据是指没有固定格式或长度，数据元素之间没有明确关系的数据。它通常以文本、图像、音频、视频等形式存在。
半结构化数据介于结构化数据和非结构化数据之间，它具有一定的结构，但不是严格意义上的表格形式。常见的半结构化数据包括XML和JSON等。

4.5. NoSQL: MongoDB

SQL database < ---- > MongoDB database
SQL table < ---- > MongoDB collection
SQL row < ---- > MongoDB document
SQL column < ---- > MongoDB field

MongoDB Docs：
MongoDB CRUD Operations
MongoDB 文档
MongoDB Docs

eg.
const cursor = db.collection(‘inventory’).find({ status: ‘D’ });

SELECT * FROM inventory WHERE status = “D”

也有增删改查，也有事务，也有索引等等，也有自己特色比如时间序列…也有各种查询手段，比如聚合管道配合着各种系统关键字$match等类似于sql里各种join group by等等复杂的查询方式

简单想法记录：容易或可以高度抽象表结构、高价值、复杂事务/强一致性的数据的还是用传统SQL。快速迭代/变更/灵活、实时数据流、AI交互的数据可以MongoDB。具体场景具体分析。

4.6. 案例：MySQL库表设计

机构、角色、用户MySQL库表设计：
基础概念：

主键Primary Key：主键是一种特殊的唯一索引，它要求表中的每一行记录都必须有一个唯一的主键值。特点：唯一性、非空性、唯一索引。主键可以是一个字段，也可以是多个字段的组合。如果是一个字段，则称为单字段主键；如果是多个字段，则称为联合主键。
联合主键Composite Key：联合主键是指由两个或多个字段组成的键，这些字段共同唯一标识表中的每一行记录。联合主键通常用于需要多个字段共同唯一标识的情况，例如，在一个订单表中，订单号和客户ID可以共同作为联合主键，因为一个客户可以下多个订单，但每个订单号和客户ID的组合是唯一的。
ID：在MySQL中，id通常是一个自增的整数，用于唯一标识表中的每一行记录。由于MySQL的底层实现
UUID, Universally Unique Identifier：是一种128位的全局唯一标识符，通常用于数据库和分布式系统中，以生成唯一的标识符。其特点是全局唯一。
外键Foreign Key：外键用来引用其他表，通过子表的一个或多个字段对应父表的主键或唯一键值，将子表和父表建立关联关系。它确保了数据的完整性和一致性。外键确保了引用的表中的数据不会因为被引用的数据被删除或更改而丢失。例如，如果你有一个订单表和一个客户表，订单表中的客户ID必须是客户表中的有效ID，否则订单表中的数据将无法插入或更新。外键强制执行引用完整性，这意味着在删除或更新引用表中的数据时，必须考虑被引用表中的数据。例如，如果你试图删除一个客户，而该客户有相关的订单，MySQL将阻止删除操作，除非你先删除或更新这些订单。

由于分布式架构的普及，以及随着数据量增大数据库迁移、同步、分库分表等操作，往往自增的id无法满足全局唯一性，所以引入UUID来保证全局唯一。然而，由于UUID是字符串且无序，如果把UUID作为主键，对于MySQL底层索引实现的B+树（数据结构知识）来说，这样很影响查询速度。所以，为了兼顾数据唯一性和查询速度的问题，通常把id作为物理主键，来保证查询速度，把uuid作为逻辑主键和外键，来保证数据唯一性以及和其他表的关系。

范式（Normalization）：在（关系型）数据库设计中，范式（Normalization）是一种规范化的过程，用于消除数据冗余和依赖性，提高数据的一致性和完整性。

第一范式（1NF）：第一范式是最基本的范式，要求表中的每个字段都是原子性的，即每个字段不能再分割。实践过程中一般常识性满足。
第二范式（2NF）：第二范式是在第一范式的基础上，要求表中的所有非主键字段必须完全依赖于主键。换句话说，第二范式要求表中的所有非主键字段必须依赖于整个主键，而不是主键的一部分。实践过程中，遇到两张表是多对多关系，拆出来第三张表做链接表（设置外键、联合主键等），解决了数据的冗余问题。
反规范化：在某些情况下，为了提高查询性能，可能需要进行反规范化，即在表中添加冗余字段。但是，反规范化会增加数据冗余，降低数据的一致性和完整性，因此需要谨慎使用。对于上面的具体事件，就是把A表的id加到B表的字段中，由于是多对多，导致B表出现很多冗余数据，但是提高了查询效率，剩去了去第三张链接表找数的时间。
因此，需要根据实际场景判断用满足范式还是反范式。
第三范式（3NF）：第三范式是在第二范式的基础上，要求表中的所有非主键字段必须直接依赖于主键，而不是通过其他非主键字段间接依赖于主键。换句话说，第三范式要求表中的所有非主键字段必须依赖于主键，而不是依赖于其他非主键字段。实践过程中，解决的是数据添加、数据删除即数据修改的问题。

编码（character set & encode）：

字符集用unicode。unicode定义了世界上几乎所有的书写系统中的每个字符一个唯一的数字编码，包括中文和Emoji
编码方式（将字符集编码为计算机可以存储和处理的二进制数据）用utf8mb4
该方式设置避免了数据库中文数据乱码
需要注意的是，不同数据库需要额外关心该事件。比如mysql的varchar可以存储Unicode字符，但MS sql server的varchar存储的是非Unicode数据，它只能存储ASCII字符。MS sql server需要用NVARCHAR来存储Unicode字符，且插入数据的时候，需要加N标识才能识别Unicode（如中文）。

数据迁移与数据备份问题：

迁移：1.完全推到重来（数据丢失）。2.全量迁移（跨系统数据库迁移工作量大，且容易对现有运行功能产生较大影响）。3.增量迁移，逐步清理（折中方案）。4.不迁移，通过trick连接系统。（影响最小，工作量最小）。

备份：1.数据库备份。2.数据库异地/云备份/灾难备份。3.数据库操作权限管理。主库不能给过大权限。4.操作生产环境一定要有落在纸面上的明确的回滚机制与指导方案，且具备一定的技术水平。5.对于过于重要的数据，又必须做一些操作，学习银行，在一个时间窗口内关闭系统，避免增量数据的产生。

MySQL表创建命令

机构表（Organizations）
机构表存储了机构的信息，包括机构ID、UUID和机构名称。机构ID是自增的主键，UUID是唯一标识，机构名称是必填字段。

CREATE TABLE organizations (
id INT AUTO_INCREMENT PRIMARY KEY,
uuid CHAR(36) UNIQUE NOT NULL,
org_name VARCHAR(100) NOT NULL
);

角色表（Roles）
角色表存储了角色的信息，包括角色ID、UUID和角色名称。角色ID是自增的主键，UUID是唯一标识，角色名称是必填字段。

CREATE TABLE roles (
id INT AUTO_INCREMENT PRIMARY KEY,
uuid CHAR(36) UNIQUE NOT NULL,
role_name VARCHAR(100) NOT NULL
);

职位表（Positions）
职位表存储了职位的信息，包括职位ID、UUID、机构UUID、角色UUID、职位名称和职位有效日期。职位ID是自增的主键，UUID是唯一标识，职位名称是必填字段。机构UUID和角色UUID分别是外键，分别引用机构表和角色表的逻辑主键。

CREATE TABLE positions (
id INT AUTO_INCREMENT PRIMARY KEY,
uuid CHAR(36) UNIQUE NOT NULL,
org_uuid CHAR(36),
role_uuid CHAR(36),
pos_name VARCHAR(100) NOT NULL,
valid_to DATE,
FOREIGN KEY (org_uuid) REFERENCES organizations(uuid),
FOREIGN KEY (role_uuid) REFERENCES roles(uuid)
);

用户表（Users）
用户表存储了用户的信息，包括用户ID、UUID和用户名称。用户ID是自增的主键，UUID是唯一标识，用户名称是必填字段。

CREATE TABLE users (
id INT AUTO_INCREMENT PRIMARY KEY,
uuid CHAR(36) UNIQUE NOT NULL,
user_name VARCHAR(100) NOT NULL
......
);

链接表（UserPositions）
链接表存储了用户和职位之间的关联关系，包括链接ID、用户UUID和职位UUID。链接ID是自增的主键，用户UUID和职位UUID分别是外键，分别引用用户表和职位表的主键。

CREATE TABLE user_positions (
id INT AUTO_INCREMENT PRIMARY KEY,
user_uuid CHAR(36),
position_uuid CHAR(36),
FOREIGN KEY (user_uuid) REFERENCES users(uuid),
FOREIGN KEY (position_uuid) REFERENCES positions(uuid)
);

优化

索引：在经常查询的字段上创建索引，以提高查询性能。例如，可以在org_name、role_name、pos_name和user_name字段上创建索引。

索引进阶：
A. where/join/group by/order by等语句使用的列创建索引
B. 利用最左前缀复用索引
C. 区分度大的列优先搞索引（如name，sex，用name建索引快）
D. 宽度小的列优先搞索引（宽度指这个列的的大小，因为索引树中一个节点能存的key值就越多）

分析查询执行计划优化索引：explain + SQL语句，查看性能，调优时用。优化思路：查询是否用了索引即key是否非空 -> 索引连接类型type（range往上） -> extra是否违反（Using where往上） -> 索引设计是否合理。

分库分表：把原本存储于一个库的数据分块存储到多个库上或把原本存储于一个表的数据分块存储到多张表上。单库资源有限，会影响应用性能，阻碍业务发展，单表数据过大，同样影响增删改查性能。垂直拆分：将表按照功能模块、关系密切程度进行划分，部署到不同的库上。水平拆分：当一个表中的数据量过大时，可将该表的数据按照某种规则分散到多张表上。

client → 查询缓存 → 解析器 → 预处理器 → 查询优化器 → 查询执行计划 → 执行引擎 → 存储引擎(InnoDB, MyISAM) → 执行引擎 → （缓存） client

字段长度：根据实际需求调整字段长度，避免浪费存储空间。例如，如果org_name和role_name字段的最大长度不超过50个字符，可以将它们的长度设置为VARCHAR(50)。
范式：根据实际需求，可以进一步规范化表结构。例如，如果positions表中的org_uuid和role_uuid字段经常一起查询，可以考虑将它们合并为一个字段，以提高查询性能。
冗余字段：根据实际需求，可以添加一些冗余字段，以提高查询性能。例如，如果经常需要查询某个职位所属的机构名称和角色名称，可以考虑在positions表中添加org_name和role_name字段。
数据类型：根据实际需求，选择合适的数据类型。例如，如果valid_to字段只需要存储日期，可以考虑使用DATE类型，而不是DATETIME类型，以节省存储空间。

更深入的分析：组织和角色是多对多的关系，职位表示两张表的链接表。然而，物理世界中真的存在职位，且就是机构与角色的组合，所以他叫“职位表”更合适。而用户和职位的多对多关系所抽象出的链接表，没有任何物理含义，纯属是为了解决二范式（解决数据冗余）出来的抽象链接表。我们可以把角色uuid字段抽出来，放在职位表里吗？当然可以，这样减少了连表查询，加快了速度，然而会造成数据冗余，即职位表里有许多相同的数，这就叫反范式。

归根结底，到了计算机空间和时间取舍的经典问题，需要根据实际场景进行设计。

AI能帮助我们？当然，根据经验可以明晰需求，并输入一个有上下文的Prompt

4.7. EDA, Event-Driven Architecture 事件驱动架构

是一种以事件为核心的系统设计模式，系统中的组件通过事件的产生、传递和响应实现松耦合的协作。事件代表系统中发生的状态变化或动作（如“用户下单”“传感器数据更新”），组件之间不直接调用接口，而是通过发布/订阅事件进行异步通信。

实时性（高实时性体现在异步不阻塞，低实时性体现在下游服务time-tolerance）、松耦合、可扩展（如突发流量时增加消费者实例）、异步、灵活（新增一个数据分析服务无需修改原有代码）

事件（Event）：系统中发生的任何有意义的状态变化或动作，通常包含上下文数据（如时间、来源、类型、负载）。
事件生产者（Producer）：检测或触发事件的组件（如用户下单时，订单服务生成“订单创建”事件）。
事件消费者（Consumer）：订阅并处理事件的组件（如库存服务监听“订单创建”事件，扣减库存）。
事件通道（Event Channel）：传输事件的媒介，如消息队列（Kafka、RabbitMQ）或事件总线（AWS EventBridge）。
事件处理器（Event Processor）：可能对事件进行过滤、转换、路由或聚合（如将原始日志事件转换为告警事件）。

事件生产者发布事件 → 2. 事件通过通道传递 → 3. 消费者订阅并处理事件 → 4. 处理结果可能触发新事件。

案例：

电商订单系统

事件流：
订单服务 → 发布“订单创建”事件（含商品ID、数量）。

消费者：
库存服务 → 扣减库存，发布“库存已扣减”事件。
支付服务 → 发起支付，发布“支付成功”事件。
物流服务 → 订阅“支付成功”事件，生成运单。

优势：支付失败时，库存服务可通过“支付失败”事件回滚库存。

物联网（IoT）监控

事件流：
温度传感器 → 每秒发布“温度更新”事件。

消费者：
告警服务 → 温度超阈值时触发告警。
数据分析服务 → 存储数据并生成报表。
可视化服务 → 实时更新仪表盘。

优势：新增一个机器学习服务分析温度趋势，无需修改传感器代码。

技术栈：消息队列Apache Kafka（还有其他消息队列、还有事件总线）

容易面临的问题：在事件驱动架构（EDA）中，组件通过异步事件通信，天然面临分布式系统的复杂性。事件可能重复传递、处理顺序不确定、消费者可能失败。

4.7.1 幂等性问题

定义：一个操作执行多次的效果与执行一次相同（无论操作执行一次还是多次，系统的最终状态一致）。
例如：多次调用“设置用户名为Alice”的接口，结果始终是“Alice”（幂等）；但“给账户加100元”操作如果多次执行，结果会错误（非幂等）。

主流消息队列（如 Kafka）的“至少一次投递”（at-least-once delivery）机制可能导致消费者多次收到同一事件。例子：网络超时导致生产者重试，或消费者处理成功但未及时确认消息。

4.7.1.1 解决方案一：数据库表唯一约束

在数据库表中为事件添加全局唯一索引UUID，若插入失败（唯一键冲突），则判定为重复请求。适用低频请求场景。

（toB中经常还配一个状态字段，因为不太考虑并发，也可以来判断幂等是否处理）

4.7.1.2 解决方案二：Token + Redis

1.客户端申请Token → 2.服务端生成 Token 并存储到 Redis（设置超时时间） → 3.客户端携带 Token 调用业务接口，服务端尝试删除 Redis 中的 Token：删除成功 → 处理业务。删除失败 → 判定为重复请求。

4.7.1.3 解决方案三：乐观锁

哲学思想/起名艺术：

乐观锁

假设冲突很少发生，在数据操作过程中不主动加锁，仅在提交修改时检查数据是否被其他事务修改过。后验解决。

实现：
版本号机制：在数据表中增加一个版本号字段version，每次更新时校验版本号。

-- 乐观锁流程（无需显式事务）
-- 更新前检查版本号
UPDATE products 
SET stock = stock - 1, version = version + 1 
WHERE id = 1001 AND version = 5;  -- 关键：提交时校验版本号

-- 不加物理锁，仅在提交时检查版本号是否变化。

若更新成功：版本号递增，其他事务的旧版本更新会失败。
若更新失败（affected_rows = 0）：说明数据已被修改，需重试或抛异常。

（实现方式CAS（操作系统里学过））

读多写少、冲突概率低（如商品浏览计数、点赞）、高并发（如电商秒杀，吞吐量高，但部分用户需重试）

案例：电商秒杀（悲观锁 vs 乐观锁）
悲观锁流程：
用户A查询商品库存并加锁 → 其他用户无法查询或修改。
用户A扣减库存 → 提交事务释放锁。
用户B才能继续操作。
结果：强一致性，但高并发下用户体验差（排队等待）。

乐观锁流程：
用户A查询商品库存（version=5）。
用户B查询商品库存（version=5）。
用户A发起更新：WHERE id=1001 AND version=5 → 成功（version变为6）。
用户B发起更新：WHERE id=1001 AND version=5 → 失败（version已变）。
用户B重新查询库存（version=6）并重试。
结果：高并发下吞吐量高，但部分用户需重试。

悲观锁

假设冲突经常发生，在操作数据前直接加锁，阻止其他事务修改，直到当前事务完成。先验防御。

实现：
行级锁（SELECT … FOR UPDATE）：锁定单行数据（如 MySQL 的 InnoDB，支持事务）

-- 悲观锁流程（以 MySQL 为例）
BEGIN;
-- 步骤1：显式加行锁（阻塞其他事务）
SELECT * FROM products WHERE id = 1001 FOR UPDATE; 
-- 步骤2：更新数据（此时数据已被锁定）
UPDATE products SET stock = stock - 1 WHERE id = 1001;
COMMIT;
-- 其他事务若尝试修改 id=1001 的数据，会被阻塞直到当前事务提交或回滚。

表级锁：锁定整张表（如 MySQL 的 MyISAM，不支持事务）。

写多读少、强一致性（如金融交易）

4.7.1.4 解决方案四：Redis分布式锁

在分布式系统中，为了确保多个节点对共享资源的访问互斥，防止并发修改造成数据错误。

Redis 的 SETNX，生成锁 Key，确保同一请求在锁持有期间仅被处理一次。并配合EXPIRE命令为锁设置一个过期时间，防止因故障导致锁无法释放。

生成锁 Key（如按订单 ID 加锁）
获取锁成功 → 处理业务 → 释放锁
取锁失败 → 判定为重复请求

4.7.2 最终一致性问题

4.7.3 事件顺序性问题

场景：事件可能乱序到达，导致状态错误。例子：先收到“订单取消”事件，再收到“订单创建”事件。

解决方案：使用 Kafka 的分区机制，将同一业务键（如 order_id）的事件发送到同一分区，保证分区内有序。

4.7.4 监控问题

场景：事件跨多个服务，难以追踪完整链路。

解决方案：为每个事件附加唯一 trace_id；记录事件的完整生命周期（生产、传输、消费时间戳）。

5.测试开发

6.运维开发

6.1. 数据库

MySQL Workbench 操作 MySQL Server
数据库备份与迁移（即数据导入和数据导出）：data import/restore和export
Users and Privileges：配置用户权限
SQL script：写SQL语句
mysqldump: MySQL备份工具。编写脚本前，需添加环境变量，不然无法识别到命令。比如在windows里编写.bat脚本