阿里云SLB-ECS-OSS-RDS架构详解：用餐厅比喻搞懂云计算四大件

简介一份系统梳理阿里云SLB、ECS、OSS、RDS四大核心服务及系统数据迁移方法的技术文档面向云计算运维、架构设计与开发人员适合需要掌握阿里云常用组件并规划数据迁移方案的读者。文档以单个docx文件交付压缩包大小约1.78MB目录结构清晰依次覆盖对象存储OSS的相关概念、存储类型与管理手段关系型数据库RDS的实例、备份恢复与数据库迁移服务以及负载均衡SLB的监听器、后端服务器、健康检查等关键机制同时结合ECS云服务器讨论系统迁移中的基础资源配合并配有各服务的使用方式、管理工具与常见功能说明。内容不仅介绍各服务的基础用法还通过典型应用场景说明如何在数据迁移中组合使用OSS承担非结构化存储、RDS管理结构化数据、SLB分发业务流量从而提升整体架构的可用性与扩展性。从概念到功能再到运维要点逐层展开适合当作云上架构入门与迁移实践的参考资料。该资源目前已有778人学习浏览具有较好的参考热度。1. 到底什么是阿里云SLB-ECS-OSS-RDS四个缩写一场开店生意经你有没有过这种瞬间业务要上云同事丢过来一张架构图图上写着“SLB-ECS-OSS-RDS”四个缩写排成一排你盯着看了半天每个字母都似曾相识但连起来就不知道它们各自负责什么、为什么非要凑在一起。别慌用开餐厅来类比一分钟就能建立认知。一家餐厅要正常运转至少要有四样东西一个地方放食材和半成品一个厨房负责炒菜一本账本记录每一笔收支再有一个门口迎宾的人负责把客人安排到不同的桌子。阿里云SLB-ECS-OSS-RDS对应的正是这四件事OSS是仓库ECS是后厨RDS是账本SLB是迎宾。通俗地说这是一套把“存储、计算、数据库、流量分发”拆开、各自独立又互相配合的云端架构组合。搞懂这套组合你就搞懂了大多数中型网站和App是怎么跑起来的也就能看懂后续系统迁移到底在迁什么。2. ECS和OSS一台能登录的云电脑和一个“没有文件夹”的仓库先看这套组合里最容易上手的两兄弟ECS和OSS。它们一个管计算一个管存储名字里都带“云”但性格完全不同。2.1 ECS到底是一台什么样的“电脑”ECS的中文全称是弹性云服务器英文是Elastic Compute Service。你可以把它理解为“一台永远开着机的电脑”只不过这台电脑不在你的办公桌上而是在某个数据中心里。这台“电脑”能干什么能登录、能装软件、能跑程序。你可以在上面安装JDK、Nginx、Redis、Tomcat也可以随便跑一个Python脚本。它和你手边的笔记本没有本质区别只是配置可以按需选要几核CPU、几GB内存、多大带宽选好就能开通性能不够时还能在几分钟内升配。正因为可以随时扩大或缩小它才叫“弹性”云服务器。在实际架构里ECS通常是“干活的人”。比如一个Web网站的后端服务、一个App的消息推送进程、一个定时任务调度器这些都需要CPU和内存去算、去跑它们就住在ECS里。文档里常见的“系统应用服务迁移ECS”说的就是把原本跑在自建服务器上的业务程序搬到云上的ECS里去继续跑。需要注意ECS本身也有系统盘和数据盘但这和下面要说的OSS完全是两码事。ECS的系统盘是一块“云硬盘”它跟着ECS走你登录进去看到的C盘D盘就是它而OSS是独立存在的存储服务不依附于任何一台服务器。2.2 OSS为什么是“仓库”而不是“网盘”OSS的全称是Object Storage Service对象存储服务。官方定位是“海量、安全、低成本、高可靠的云存储服务”。它最适合存放的是图片、视频、文档、安装包这类非结构化文件。为了讲清楚它这里值得多花一点笔墨。OSS的“对象”是什么你可以把每个文件看作一个“对象”每个对象由三部分组成文件名Key、用户数据Data、元信息Object Meta。其中元信息是描述文件的一组键值对比如最后修改时间、文件大小甚至你自己塞进去的自定义标签。那“Bucket”又是什么Bucket翻译过来叫“存储空间”是装对象的容器。所有对象都必须属于某个Bucket就像仓库里有若干排货架每件货物必须放在某个货架上。Bucket有几个硬性规则名称在OSS范围内全局唯一创建后不能改只能包含小写字母、数字和短横线-必须以小写字母或数字开头和结尾长度限制在3到63字节之间。也就是说“my-app-logs”合法“My-App-Logs”不合法“-my-app”不合法。下面这个示意代码能帮你一眼看出哪些名字能过审# Bucket 名称命名规则检查 # 合法示例my-app-logs、app-2024、data-bucket-01 # 非法示例MyApp - 包含大写字母 # 非法示例app_2023 - 下划线不允许 # 非法示例-app - 不能以短横线开头对象Object也有命名限制使用UTF-8编码长度1到1023字节不能以正斜线/或反斜线\开头。这里有个很多初学者理解不了的细节你在OSS上看到“test1/test.jpg”这种名字很容易以为它存在“test1”这个文件夹里但OSS里根本没有文件夹的概念。“test1/test.jpg”只是这个对象的一个完整Key它和“a.jpg”在本质上没有任何区别都是平铺在存储空间里的一个字符串。正因为这个设计OSS可以支撑海量并发访问——它不需要一层层去翻目录拿到Key就能直接定位文件。也正因为这个设计如果你想把“test1”这个“目录”改成“test2”OSS的真实操作是把所有以test1/开头的对象全部复制一遍改成新前缀代价极高。2.3 对象存储与传统文件系统的本质区别很多人第一次接触OSS时都会不自觉地把它当成一个“无限大的网盘”想在上面做重命名目录、修改文件某一段内容的操作。这正是最容易踩坑的地方原文里有一张非常直观的对比表我把最关键的差异整理如下对比项对象存储 OSS传统文件系统数据模型扁平的Key-Value结构没有目录层级树状索引结构有目录获取数据根据对象Key直接获取先访问目录再逐层查找文件修改文件不支持修改只能整文件重新上传可以修改指定偏移位置内容重命名目录极其昂贵需复制大量对象很轻量一条命令完成并发访问海量并发无压力受限于单设备性能典型优势海量、低成本、高可靠支持随机写、目录操作方便看到区别了吗OSS的设计哲学是“存进去、读出来”它不鼓励你做修改和目录搬家。如果你要改一个1GB文件的1个字节OSS的做法是重新上传整个对象。因此把OSS直接当文件系统挂载是非常低效的官方也明确不推荐如果一定要挂载也只建议做写新文件、删除文件、读取文件这三种操作。另一点值得记住的是OSS的强一致性你上传PUT一个对象成功后它立刻就能被读到不存在“写了一半”的中间状态你删除一个对象成功后它立刻就不存在了。底层数据还会做冗余存储数据持久性号称不低于99.9999999999%也就是传说中的“12个9”。通俗地说数据存进OSS后即使某个存储设施出问题OSS也会自动用冗余数据把损坏部分重建出来。2.4 Bucket、Object、Endpoint、AccessKey四个词串起OSS的骨架要真正在项目里用OSS绕不开四个概念Bucket、Object、Endpoint、AccessKey。前两个刚才讲过这里补上后两个。Endpoint是OSS对外服务的访问域名不同地域的Endpoint不一样内网访问和外网访问也不一样。比如杭州地域的外网Endpoint是oss-cn-hangzhou.aliyuncs.com内网Endpoint是oss-cn-hangzhou-internal.aliyuncs.com。这个区别在实际迁移时非常重要如果你的ECS也在杭州地域ECS内网访问OSS就不收流量费速度还更快如果走公网访问就要支付外网流出流量费用。AccessKey简称AK相当于你的“身份证加家门钥匙”包含AccessKeyId和AccessKeySecret两部分。AccessKeyId用来标识你是谁AccessKeySecret用来加密验证请求的签名必须严格保密。它一旦泄露别人就能用你的身份往OSS上传文件、删文件相当于是仓库大门钥匙被人复制了。所以生产环境的AK要开最小权限能用临时凭证STS授权就尽量别用主账号AK。OSS还提供了三种存储类型标准存储、低频访问存储、归档存储。标准存储适合频繁访问的数据比如网站首页图片低频访问存储适合每个月只访问一两次的数据价格更低归档存储适合要放半年以上的冷数据价格最低。选错类型会怎样该用低成本归档的用了标准存储账单会明显偏高该用标准存储的用了低频访问每次读取都要额外付数据取回费。存储类型这件事本质上是用“访问频率”换“存储成本”。3. RDS把数据库从“自建”换成“托管”省下的不只是买机器的钱讲完存储再看这套组合里最需要“稳重”的角色——RDS。它的全称是Relational Database Service关系型数据库服务。简而言之RDS就是“你出钱云厂商帮你养数据库”。3.1 以前是自己抱数据库现在是请专业团队看管在RDS出现之前团队要跑一个MySQL数据库典型的做法是买一台服务器装好Linux手动安装MySQL配置数据目录设置密码再自己写脚本做定时备份。听起来不难但真正上线后问题会接连冒出来磁盘满了要自己扩主从同步断了要自己修半夜机器宕机要爬起来手动切换版本升级要先在测试环境演练半天。RDS把这一整套脏活累活接走了。你创建RDS实例后拿到的是一个数据库连接地址直接就能用。备份是自动的高可用是内置的监控告警是现成的扩容也只需要在控制台点按钮。打个比方以前你是自己雇了个账房先生账房先生生病了你得亲自去替他记账现在你外包给了一个专业的记账团队他们有备用人员、有值班制度、有保险柜你只需要每天看报表。RDS支持的引擎很常见比如MySQL、PostgreSQL、SQL Server。文档里提到的迁移场景主要就是“MySQL数据迁移RDS”。3.2 实例、数据库、账号是什么关系很多第一次用RDS的人会卡在“实例、数据库、账号”这三个词的关系上。其实一句话就能理清实例是一台独立的数据库服务器实例下面可以创建多个数据库账号则是用来连接和操作这些数据库的“通行证”。类比一下实例是一栋写字楼数据库是楼里的不同公司办公室账号是门禁卡。一张门禁卡可以只允许进A办公室也可以同时进A、B两个办公室全看管理员怎么授权。实际使用中建议一个业务用一个账号权限给到最小比如只读账号就坚决不给写权限。RDS实例本身具备高可用架构主备两个节点数据实时同步。主节点出故障时备节点会自动顶上应用几乎感知不到切换过程这就是“产品高可用”带来的价值。对业务来说数据库连接地址不变但背后已经完成了一次故障转移。来看一个前后对比的连接串示例。自建MySQL时连接地址通常长这样jdbc:mysql://192.168.1.10:3306/order_db使用RDS后连接地址变成-- 自建 MySQL 连接串需要自己维护主从、备份、监控 jdbc:mysql://192.168.1.10:3306/order_db -- RDS 连接串高可用、备份、监控全部托管 jdbc:mysql://rm-xxxxxx.mysql.rds.aliyuncs.com:3306/order_db注意看RDS给的是一个带域名的地址而不是裸IP。这是因为RDS实例背后有VIP虚拟IP和主备节点如果给你一个物理IP主备切换后IP可能就变了域名地址则始终不变应用不用改配置。3.3 从MySQL迁移到RDS时最容易忽略的三件事把本地或ECS上的MySQL数据迁到RDS听起来无非是“导出再导入”但实际操作中容易忽略三件事如果处理不当迁移完成后才会发现业务悄悄出错。第一是字符集。很多老数据库表用的是latin1或其他字符集RDS默认可能是utf8mb4。迁移前不统一字符集中文数据导入后直接变成乱码而且这种乱码很难通过简单修改恢复。迁移前先查一遍所有表的字符集能和目标端保持一致就尽量一致。第二是账号权限。迁移完成后原系统的数据库账号密码可能和RDS不一致。文档里特别强调迁移对数据库账号的权限有要求比如源库账号需要具备读取权限目标库账号需要具备写入权限。如果权限不够传输过程中会出现“读不出来”或“写不进去”的情况。第三是白名单。RDS实例默认有访问白名单只有白名单内的IP才能连接数据库。很多人在迁移后遇到“连接超时”排查半天才发现是ECS的IP不在RDS白名单里。安全起见白名单应该精确到ECS的私网IP而不是图省事放行0.0.0.0/0否则数据库等于裸奔在公网上。3.4 RDS为什么不替代OSS这里需要提前埋一个引子因为后面专门有一章讲易混概念RDS存的是结构化数据OSS存的是非结构化文件。用户在OSS上看到的是图片、视频、文档在RDS里看到的是订单表、用户表、商品表。两者的查询方式也完全不同——RDS用SQL去筛选、排序、关联多张表OSS则是给你一个URL你把整个文件拿走它不管文件里面是什么。所以一个典型的电商系统里商品图片放在OSS商品名称、价格、库存数量放在RDS。前端页面先通过接口从RDS查出商品信息其中图片地址指向OSS再由浏览器去OSS加载图片。两者各司其职谁也替代不了谁。4. SLB流量入口的交通警察凭什么让多台ECS不吵架这套组合里最有“存在感”的通常是SLB因为用户请求第一个遇到的就是它。SLB全称Server Load Balancer负载均衡服务。一句话定义它站在所有后端服务器前面负责把进来的请求均匀地分发给多台服务器。4.1 为什么多台ECS不能直接暴露给用户假设你的系统有两台ECS都跑着同一个网站服务。如果不引入SLB最原始的做法是把两台ECS的公网IP都解析到域名里让用户随机访问其中一台。这就是所谓的DNS轮询。但DNS轮询有个致命问题它不知道某台服务器是不是还活着。如果其中一台ECS宕机了DNS照样会把一部分用户引导到那台宕机的机器上结果就是这些用户看到“网站打不开”而另外一半用户却一切正常。更麻烦的是重启、发版、扩容这些日常操作需要频繁修改DNS解析记录而DNS解析有缓存生效要等很久。SLB解决的就是这个问题。它是所有流量的统一入口后端挂几台ECS都行。SLB会持续对后端服务器做健康检查发现某台ECS不响应了就自动把它从分发列表里摘掉剩下的请求全部转发给健康节点等到这台ECS恢复后又自动加回来。这一切都是实时发生的不需要人工干预。用餐厅来类比SLB就是门口那个拿对讲机的迎宾。客人来了迎宾看看哪个桌子空着、哪个桌刚收拾好就把人往那边带某个区域暂时不能接待迎宾就自动跳过它。如果没有迎宾客人自己往里冲就可能出现一边挤爆、一边空着的局面。4.2 监听器、后端服务器、健康检查是怎么配合的SLB的核心由三部分组成监听器Listener、后端服务器Backend Server和健康检查。监听器负责“听什么、怎么转发”。你需要告诉SLB监听哪个端口比如80或443、用什么协议HTTP、HTTPS、TCP、把流量转发给哪组后端服务器。一个SLB实例可以配置多个监听器比如一个监听80端口处理HTTP一个监听443端口处理HTTPS流量互不干扰。后端服务器就是真正处理请求的ECS。你可以把多台ECS加入同一个后端服务器组SLB会按权重分发流量。权重越高分到的请求越多这个参数在灰度发版时特别有用——新版本先挂一台低权重ECS观察没问题后再把权重调高。健康检查是SLB的“体检医生”。常见配置是让SLB每隔几秒向后端服务器发起一次探活请求比如访问一个固定的健康检查路径/healthz如果连续几次没收到健康响应就把这台服务器标记为异常不再转发新请求。下面是一份简化的配置示意方便你理解监听器和后端服务器的关系{ listener: { protocol: HTTPS, port: 443, backendGroup: web-servers, healthCheck: { path: /healthz, interval: 5, unhealthyThreshold: 3 } } }这里的含义是SLB监听443端口的HTTPS请求转发给名为web-servers的后端服务器组每5秒检查一次/healthz路径连续3次失败就判定后端服务器不健康。健康检查这条路看起来简单却在生产环境里救过无数次命——它把故障机器从流量中摘除让用户始终访问到健康的服务器。4.3 会话保持和证书管理两个容易被忽视的细节流量平均分配给多台服务器后会带来一个新问题用户登录状态怎么办假设用户第一次请求被分到了ECS-A登录信息写在了ECS-A上刷新页面后SLB把第二次请求分到了ECS-BECS-B没有这个用户的登录信息用户就以为自己“被登出了”。这就是为什么SLB提供“会话保持”功能也叫会话保持或粘性会话。开启后SLB会给同一个来源的用户尽量转发到同一台后端服务器从而保证登录状态不丢。不过要注意会话保持也是一把双刃剑。如果某台ECS流量特别大而大量用户都被粘在这台机器上就可能出现这台机器过热、其他机器闲着的情况。所以更现代的做法是让应用层把会话状态存到Redis这类集中式缓存里这样任何一台ECS都能处理任何用户的请求SLB就可以纯粹按负载分发不必依赖会话保持。证书管理则对应HTTPS。传统方案里每台ECS都要部署一份SSL证书换证书时要挨个登上去更新。SLB可以把证书统一管理在SLB这一层完成HTTPS解密再把明文HTTP请求转给后端ECS这就是常说的“SSL卸载”。后端服务器因此省去了加解密开销证书也只需要在SLB上维护一份。4.4 SLB在实际架构中的位置回到整套架构来看SLB永远站在最前面。用户访问域名时DNS把域名解析到SLB的公网IPSLB收到请求后根据监听规则将请求转发给后端的ECSECS处理完业务逻辑需要图片时去OSS取需要数据时去RDS查。整套链路是“用户→SLB→ECS→OSS/RDS”请求入口只有一个后端却可以有多台ECS数据库和存储则稳定地待在后方。这种设计带来的直接好处是扩容变得非常简单活动流量涨了新开两台ECS加入后端服务器组SLB自动开始分发流量全程不需要改用户访问的域名也不需要动数据库。这也就是“弹性伸缩”在日常架构中的真实落地。5. 易混概念存储、计算、数据库、流量这四件事别混成一锅粥前面把四个服务分别讲了一遍但真正让初学者头疼的是它们之间的边界。这一章专门说说最容易被搞混的四个误区每个都按“哪里容易混、为什么混、怎么区分”来讲。5.1 误区一OSS和云硬盘都能存文件用哪个都行这是最常见的问题。OSS和ECS的系统盘/数据盘确实都能存文件甚至都可以在上面放图片但两者的本质完全不同。为什么混因为从使用者角度看都是“往一个空间里放文件再把文件读出来”。怎么区分ECS的云硬盘是给ECS做本地存储用的它必须挂载到一台ECS上才能访问你登录到ECS里看到的路径是/dev/vda1或者C盘。云硬盘适合存操作系统、应用程序、临时文件它强调低延迟和随机读写。OSS则是独立存储服务不跟随任何一台ECS通过HTTP RESTful API访问任何设备只要能联网就能读写。OSS适合存海量图片、视频、备份文件强调海量、低成本、高可靠。简单记云硬盘是“电脑里的硬盘”OSS是“网上的仓库”。如果你访问一个文件还需要走公网URL那多半用OSS如果你只是让某台ECS上的程序快速读写本地文件那用云硬盘。5.2 误区二RDS和自己装的MySQL不都是MySQL吗这也是高频误解。看到RDS的引擎是MySQL就以为RDS和自己ECS里装的MySQL是一回事甚至觉得没必要为此付费。为什么混两者用起来确实很像都支持SQL语句都监听3306端口连接方式都是JDBC串。怎么区分自建MySQL是一套需要“你全权负责”的数据库系统装在哪里、磁盘多大、怎么备份、怎么做主从全部自己操心RDS则是一套“托管数据库服务”底层的主从架构、自动备份、故障切换、监控告警都是云厂商负责的。自建MySQL好比你自己买了个保险柜钥匙自己保管保险柜坏了自己修RDS是银行保险箱服务银行负责安保、消防、维修你只管把值钱的东西放进去。更进一步说RDS的实例本身是主备高可用架构你拿到的永远是一个稳定的域名地址自建MySQL想达到同样的可用性至少得自己搭一主一从再写一套切换脚本运维成本不可同日而语。5.3 误区三SLB和DNS轮询都能分流有SLB就不用理解DNSSLB和DNS轮询都能把用户请求分散到多台服务器上但它们的健壮性有天壤之别。为什么混因为它们做的事情表面上都是“把流量分给多台机器”名字里也都带“负载均衡”的影子。怎么区分DNS轮询发生在“域名解析”阶段它只负责让不同用户解析到不同IP一旦IP对应的服务器宕机了它不知道也不会处理用户访问就会失败。SLB发生在“请求转发”阶段所有请求先到SLB再由SLB实时分发给后端服务器并且带有健康检查能自动剔除故障节点。打个比方DNS轮询像是小区门口贴了个告示“送水的请去1栋、2栋、3栋”不问哪栋楼今天没人SLB则是门卫亲自看监控发现2栋没人就只往1栋和3栋带路。在实际架构里DNS一般只解析到SLB的IPSLB再负责后端多台ECS的分发两层各司其职。5.4 误区四OSS的标准存储、低频访问、归档存储只是“套餐不同”这种理解不算全错但容易忽略一个关键差异——数据取回的代价。为什么混因为对用户来说上传和下载的方式完全一样都是通过API只是控制台里选的存储类型不同。怎么区分标准存储适合频繁访问的数据随时取用没有取回费用低频访问存储适合每月访问一两次的数据存储单价便宜但每次取回数据要额外支付取回费归档存储单价最低但取回数据需要等待解冻可能要等几分钟甚至更久并不适合做在线访问。简单判断标准是这份数据下次访问会在什么时候如果下一秒就要用用标准一个月后用一次用低频半年后才可能用且能接受等待用归档。选错存储类型不会丢数据但账单会让你留下深刻印象。5.5 误区五ECS上可以跑数据库所以RDS没必要买这个误区通常是“省钱党”的思维既然ECS能干所有事为什么还要单独买RDS为什么混ECS确实能安装MySQL并稳定运行小型项目的确可以这样做。怎么区分关键在于可用性和运维成本的权衡。自建数据库在ECS上遇到磁盘满、主从延迟、数据损坏、实例宕机等问题都要自己处理处理时间通常是小时级别RDS把这些问题包装成“自动处理”的托管能力故障切换时间是秒级。对核心业务来说宕机一小时的损失往往远超一年RDS的费用。什么时候可以不用RDS后面一章会专门说。这里只需要记住ECS上的MySQL适合开发测试、低并发场景RDS适合业务数据不能丢、不能长时间中断的生产系统。6. 这一套组合拳什么时候该用从一次系统迁移看边界理解了四个服务的职责最后一个问题是我到底该不该用这一整套不是所有系统都需要SLB-ECS-OSS-RDS全家桶过早引入只会增加复杂度和成本。先看一个典型的适用场景。某公司原来有一套自建系统跑在一台物理服务器上图片文件存在本地磁盘数据库是服务器上的MySQLWeb应用也跑在同一台机器上用户直接通过服务器IP访问。刚开始人少没问题后来用户量上来磁盘快满了数据库查询开始变慢更尴尬的是一旦服务器重启整个系统全部不可用。系统迁移时就可以按这套组合拳来做第一步系统文件资源迁移到OSS。把原来挂在HTTP服务下的图片、文档等非结构化文件批量上传到OSS的Bucket里应用代码中把文件访问地址改为OSS的URL同时开启图片处理服务用缩略图和水印功能替代原来自己写的图片处理逻辑。第二步MySQL数据迁移到RDS。通过数据传输工具把原服务器的数据库迁移到RDS实例应用连接串从原来的IP改为RDS提供的域名地址账号权限、字符集、白名单都提前检查一遍。第三步系统应用服务迁移到ECS。在ECS上安装JDK、Nginx、Redis等运行环境把Web后台、移动端服务等应用部署上去数据库地址指向RDS文件路径改为调用OSS。第四步部署SLB。把多台ECS加入SLB后端配置监听器和健康检查域名解析到SLB原来的单点入口变成高可用入口。这套调整完成后每一层的职责都清晰了SLB负责引入流量ECS负责计算OSS负责文件RDS负责数据。反过来边界也很重要。如果只是个人学习、内部工具、日访问量不到几百的系统一台ECS加一个自建MySQL完全够用没必要上SLB和RDS。给一个小网站配三个SLB监听器、两组后端服务器、两套白名单运维复杂度反而会把人劝退。以下情况建议慎重使用全家桶系统几乎没有并发一台服务器常年CPU使用率不到10%数据量很小且不增长一个SQLite文件就能搞定团队没有专人负责云资源管理开通了一堆服务却没人知道怎么维护。那以后我形成了一个习惯任何一个系统要上云先在纸上画一张“四件套关系图”标清楚哪台机器跑计算、哪类文件进仓库、哪套数据进数据库、谁在门口分发流量。这张图画不明白迁移就一定会翻车画明白了后面每个步骤都只是按图施工。希望这篇能帮你建立起这套架构的基础认知下次看到架构图上的那串缩写不会再觉得它们是一团乱码。本文还有配套的精品资源点击获取