前言

分布式系统涵盖的知识面非常广，all in one本篇我会介绍下我所了解的知识点，预计完稿后的知识密度较高，本篇只点到为止，每个点都有很多值得深挖和学习的内容，后续逐渐会有相关系列文章来具体阐述。

挑战

1990年，浏览器诞生。1994年底，万维网联盟（World Wide Web Consortium，简称3W）成立，这标志着万维网的正式诞生。此时的网页以HTML为主，是纯静态的网页，信息流只能通过服务器到客户端单向流通，由此世界进入Web1.0时代，至今三十年过去了，互联网已经进入web3.0。随之而来遇到的挑战非常多，包括但不局限于下面几点

• 高并发，大流量：用户常用的应用往往集中在头部的那几个，参考Google日均PV35亿，日IP访问数3亿。另一方面，特殊时期节点，用户对平台访问和使用集中度非常高，导致的瞬时qps也非常高。典型的如12306节假日抢票，淘宝双11，春节红包会场等等，流量的波峰波谷明显，非常考验整体的系统架构设计，同时对系统的可升缩性也提出了要求。
• 全球化，用户分布广：全球化的公司比如谷歌，meta，国内典型的如字节跳动等在全球化发展过程中遇到非常多的挑战，包括网络、语言、文化等，技术上也会带来诸多挑战，比如，如何让不同区域用户的使用体验趋同，不同机房之间的流量调度和数据隔离问题，用户隐私数据的合规问题等等。
• 大数据：需要存储、管理海量数据，需要使用大量服务器。Facebook每周上传的照片数量接近10亿，百度收录的网页数目有数百亿，Google有近百万台服务器为全球用户提供服务。
• 需求迭代快：和传统软件的版本发布频率不同，互联网产品为快速适应市场，满足用户需求，其产品发布频率极高。一般大型网站的产品每周都有新版本发布上线，中小型网站的发布更频繁，有时候一天会发布多次。

先来简单说下笔者的经历，笔者的研究生专业是电磁场与微波技术，毕业后跨专业选择进入看了一家互联网OTA公司，从事前端开发岗位，19年底加入到字节后又逐渐从前端、全栈转成了全职后端开发，这其中伴随着业务的转变带来的转型需要，也有一部分是自己有强烈的学习意愿，有成长的诉求。虽然我并不推荐你经常这样去做，因为这会让你之前的知识积累、积攒的经验以及所带来的竞争力有所削弱。但于我而言，每一次的转变都非常具有挑战性，我也顺利完成了角色的过渡和转变，这种成长是潜移默化的，我也试着写下我自己的经验之谈，希望能给大家后续发展带来一些借鉴。当然了，这里很多的点虽然只适用于互联网工程师，不过对各行各业的技术类工程师，其中很多基本素养和成长路径究也大抵如此。

在说LLM之前，我们先来了解下AI到底是什么，先从AIGC开始说起。

AIGC

当AIGC这个词在国内火爆的同时，海外更流行的是另外一个词：Generative AI，即生成式AI。 从字面上来看，生成式AI和AIGC之间关系是：生成式AI所生成的内容就是AIGC。

AIGC 又称生成式 AI (Generative AI)，是继专业生产内容（PGC， Professional-generated Content）、用户生产内容（UGC， User-generated Content）之后的新型内容创作方式，可以在对话、故事、图像、视频和音乐制作等方面，打造新的数字内容生成与交互形式。

ChatGPT、GitHub Copilot、Midjourney等都属于生成式AI。

内存模型

内存模型描述了程序执行的规范。在golang中，这些规范由 goroutine 执行组成，而 goroutine 的执行又由一系列内存操作构成。golang的内存模型规定了多个goroutine读取变量时候，变量的可见性情况。

内存操作可以从以下四个方面进行详细描述：

• 类型：包括普通数据读取、普通数据写入、同步操作、原子数据读取、互斥操作或通道操作等。
• 代码中的位置：即操作在程序代码中的具体位置，通常用行号或函数名标识。
• 内存位置：指正在访问的内存地址或变量。
• 值：指正在读取或写入的具体数据值。

为了确保多核、多线程环境下的正确性和一致性，内存模型确保了以下几点：

• 顺序一致性：在单线程情况下，操作的执行顺序与程序代码中出现的顺序一致。这是最简单的模型，假设所有的读写操作按代码中的顺序执行，但实际上现代处理器和编译器都会进行优化，例如乱序执行（Out-of-Order Execution）和指令重排（Instruction Reordering），这使得顺序一致性变得复杂。
• 可见性：一个线程对变量的修改对于其他线程是可见的。
• 原子性：保证某些操作（如读写）是不可分割的，即要么完全执行，要么完全不执行。

比较有意思的是，Golang Memory Model 文章作者并不希望读者通过 Memory Model 来理解自己程序的运行方式，如果必须要这样做的话，很可能是程序的编写方式有问题，很可能意味着高昂的维护成本）

软件架构是什么？

软件架构到底是什么？每个人的理解可能不尽相同，下面举几个例子 维基百科的解释

软件架构是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。

IEEE结构定义：架构=系统宏观结构+系统组件关系+系统设计原则

the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution --ANSI/IEEE

在我的理解里，我们可以将架构理解为对一个系统内部各部分及其相互作用的高度概括。这不仅包括了物理和信息的属性及其相互之间的配对，也涵盖了组成部分之间以及它们与环境之间关系的界定。通过遵循特定的原则对系统进行细分，架构使得不同参与者能够同时在各自的领域内高效工作，从而证明了有组织的创造过程远胜于无序的努力。软件架构的核心目的在于管理和降低系统的复杂性，实现业务逻辑与技术实现之间的清晰分离和解耦。

架构的不同视角

你所认知的架构和别人所说的架构可能是两码事。

不同职位对架构的视角是不一样的。比如，对老板来说，他看到的是企业架构；对产品同学，他看到的是产品业务架构；对于销售同学，他看到的是市场渠道架构；对开发人员，他看到的是服务技术架构；对于运维人员，他看到的是运维架构；而对于技术支持，他看到的是网络和物理架构。