一个故事，把大厂互联网架构 70+ 概念串完

首先得对这个行业里的基础概念，有个了解。

其实，这些东西，不像英语单词一样，孤立的突然出现了，而是每个都是解决某一个问题而出现。

后端进大厂，面试造火箭必须得懂的。而且很多概念是学校根本不教的，工作了又需要这些技术，真的很糟心。但也没办法，这些是前沿技术，前沿技术是不断发展的。（不过好几年了一直是这套架构，架构基本已经到头了，毕竟地球上也就 80 亿人，目前全球关键服务基本能抗住）

整个 IT 的系统架构发展，就是【面多加水，水多加面】8 个字，计算机科学领域的任何问题,都可以通过增加一个间接的中间层来解决，如果解决不了，再加一层 ！有问题就拆，拆多了就打包！

所谓架构师，其实日常就是，遇到难题，加机器，加中间件解耦，数据查不动，给我上数仓哈哈 ~

今天简单的把绝大部分名词，串一串！这基本就全了，一共 70+ 个概念。。。

这是 4 年前我做的笔记，稍微整理一下，按照先后顺序，笑纳：

单体和集群

我们创立了一个互联网应用，最简单的就是【单机架构】，但是在本地，没人看，于是放到【应用服务器】。

用户多了一点，单机开始扛不住了。应用和数据库经常抢 CPU、内存、磁盘 IO，怎么办？把应用和数据库拆开，有了【数据库服务器】。这叫【应用与数据库分离】。

之后在【应用服务器】上，解决单台机器扛不住，就多台跑，跑同一个服务，就是【集群】。同时有【负载均衡】措施，均匀分发流量。

但是性能上又不能限制的太死，加机器、加实例、加节点，这个叫【水平扩展】。为了防止单台机器宕机，让站挂了，所以能及时把流量调到好机器，这叫【高可用】。

缓存

为了解决每次查数据库都太慢，于是有了【缓存】，为了解决优先缓存谁的问题，有了【热点数据】这个概念，里面都是被频繁访问的数据。

可是单层缓存压力可能也大，于是产生了【多级缓存】的概念。同时，很多内容用户也没必要反复请求服务器去下载，于是有了【浏览器缓存】。如果服务器离离应用近，可以把内容缓存到应用服务器，这叫【本地缓存】。但是本地缓存不够用，就多个机器共享缓存，叫【分布式缓存】。

在应用层面上，有很多业务，会重复计算，于是业务结构可以缓存起来，这个叫【业务缓存】。

数据库

我们一般用的那种类似于 Excel 的数据库，叫【关系型数据库】，数据库的读，一般都很慢，读请求多了以后，主库压力会变大，于是有了【读写分离】，【主库】是负责写入的数据库，【从库】是主要负责读取的数据库。【主从复制】是把主库的数据，同步到从库，而【主从延迟】则说明从库的数据落后了，旧了，没跟上，明白吧。

在数据库里，单库单表太大了，就拆库拆表分散压力，叫【垂直分库】，而数据库里，一张表可能会越来越宽，于是按照规则拆分同一张表，叫做【水平分表】。

上面各种拆拆拆，太复杂了，于是【数据库中间件】这个概念出来了，它就是个中间人，它负责合并结果等等，反正从它角度看，数据库还是原来一样简单。

分布式

单个节点，它储存容量有限，于是多个节点都存（可以是分片，也可以是多副本。不是每个节点都完整存一份。），叫【分布式存储】。有的在上海，有的在广州，离用户近，就谁的服务器发，叫【CDN】，为了解决用户去哪个节点，有了【DNS调度】。但是总是有个节点是最权威的原始内容节点，这个叫【源站】。

流量

后端直接暴露，肯定危险，于是有了【反向代理】承接公网请求。但是别忘了有 SSL ，HTTPS 这种，如果让后端反复解密，也不行，就有了【HTTPS 终止】直接让代理层解密加密，省劲儿不少。有些内容不是谁都能访问，需要【权限校验】，为了防止流量大了，那就【限流】。为了解决常见的 Web 攻击，就有了【WAF（Web 应用防火墙）】。

搜索

数据库本身搜索其实还是慢，就有了【搜索引擎】，为了加速文本搜索，有了词到文档的反向映射，这叫【倒排索引】。在大量文本中搜索内容，叫【全文搜索】。

很多数据，它的数据结构是不固定的，就叫【NoSQL 非关系型数据库】。

大量请求同时读写，叫【高并发读写】，数据库查询，我们知道，很多查询语句很复杂，这种叫【复杂检索】，有些表它又改动很频繁，于是为了适配不固定的数据结构，有了【灵活存储】。

微服务

有些应用，它所有功能都挤在同一个应用里，叫【巨石应用】（貌似也是一个名词），也叫比较大的单体应用。

每个业务模块之间的边界，叫做【业务边界】，多个系统协作完成业务，叫做【分布式架构】。

为了解决服务拆开后怎么通信，于是有了【RPC 远程调用】，让我们能像本地方法一样调用远端服务器。

可是服务地址不好找，于是有了【服务注册与发现中心】，帮助我们记录和查找服务地址。

有时候我们架构设计的不够好，或者流量太大、设备故障等，于是可能局部故障不断的放大。这个叫【雪崩】哈哈。

比如我们做商场应用，大促，短时间内流量猛击，于是有了【削峰填谷】概念把流量排队消化：

服务和服务，之间就好像独立的部门，你不能在传输数据时，相互等吧，于是有了【消息队列】，每个部门只管接收和发送。为了防止某服务宕机，其他能不被拖累，就有了【服务解耦】和【故障隔离】的概念。为了不等结果出来，拖累时间，就有了【异步处理】。把系统给分细，每个部分就是只负责一个小业务，这种叫【微服务架构】。

云原生，部署和运维

我们运维，在追 bug 时，为了找出核心问题点，就追踪一次完整路径，这个叫【全链路追踪】。为了防止某个坏服务继续当累赘，就有了【熔断】这个概念，来停止某个坏服务。还有【降级】，额，，， 这个怎么解释，就是比如购物 APP 卡顿，就关掉商品推荐、弹窗动画，只保留下单、付款基础功能。

服务多了，如果不管理，就会失控，这个叫【服务治理】，比如集中观察系统的状态，叫【统一监控】，以及集中记录日志的【日志系统】来保留证据。以及访问权限、权限管理的【权限体系】。

可是那么多细碎的服务，部署很麻烦，于是就打包一下，把应用环境都打包，随时用随时部署，这叫【容器化】，以及常用的【Docker】工具。但是容器那么多，怎么管理，于是有了【Kubernetes/K8s】这个管理容器、集群的平台。

为了解决容器放哪台机器的问题，有了一个自动工具，能自动安排容器的运行位置，叫【容器编排】。还有资源的分配，也自动化一下，叫【资源调度】。

以前，为了分配资源，人工去搞真的很慢，于是有了【自动扩缩容】的概念，让负载自动根据访问情况加减实例。

服务宕机了有【故障自愈】措施，自动恢复服务。为了解决自己买服务器太昂贵，于是有了【云平台】可以按需购买配置。为了解决资源闲置浪费的情况，有了【资源池】，让我们可以随时申请释放资源。

通过日志、指标、链路追踪等手段，把线上的各个系统都直观展示，叫做【可观测性】。

上面提到的这些，专门为云计算而设计的架构，就叫做【云原生】。