许式伟的架构课
许式伟
七牛云CEO
立即订阅
20092 人已学习
课程目录
已更新 72 讲 / 共 77 讲
0/4登录后，你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 怎样成长为优秀的软件架构师？
免费
基础平台篇 (21讲)
01 | 架构设计的宏观视角
02 | 大厦基石：无生有，有生万物
03 | 汇编：编程语言的诞生
04 | 编程语言的进化
05 | 思考题解读：如何实现可自我迭代的计算机？
06 | 操作系统进场
07 | 软件运行机制及内存管理
08 | 操作系统内核与编程接口
09 | 外存管理与文件系统
10 | 输入和输出设备：交互的演进
11 | 多任务：进程、线程与协程
12 | 进程内协同：同步、互斥与通讯
13 | 进程间的同步互斥、资源共享与通讯
14 | IP 网络：连接世界的桥梁
15 | 可编程的互联网世界
16 | 安全管理：数字世界的守护
17 | 架构：需求分析 (上)
18 | 架构：需求分析 (下) · 实战案例
19 | 基础平台篇：回顾与总结
加餐 | 我看Facebook发币（上）：区块链、比特币与Libra币
加餐 | 我看Facebook发币（下）：深入浅出理解 Libra 币
桌面开发篇 (16讲)
20 | 桌面开发的宏观视角
21 | 图形界面程序的框架
22 | 桌面程序的架构建议
23 | Web开发：浏览器、小程序与PWA
24 | 跨平台与 Web 开发的建议
25 | 桌面开发的未来
26 | 实战（一）：怎么设计一个“画图”程序？
27 | 实战（二）：怎么设计一个“画图”程序？
28 | 实战（三）：怎么设计一个“画图”程序？
29 | 实战（四）：怎么设计一个“画图”程序？
30 | 实战（五）：怎么设计一个“画图”程序？
31 | 辅助界面元素的架构设计
课外阅读 | 从《孙子兵法》看底层的自然法则
加餐 | 想当架构师，我需要成为“全才”吗？
32 | 架构：系统的概要设计
33 | 桌面开发篇：回顾与总结
服务端开发篇 (14讲)
34 | 服务端开发的宏观视角
35 | 流量调度与负载均衡
36 | 业务状态与存储中间件
37 | 键值存储与数据库
38 | 文件系统与对象存储
39 | 存储与缓存
40 | 服务端的业务架构建议
41 | 实战（一）：“画图”程序后端实战
42 | 实战（二）：“画图”程序后端实战
43 | 实战（三）：“画图”程序后端实战
44 | 实战（四）：“画图”程序后端实战
45 | 架构：怎么做详细设计？
46 | 服务端开发篇：回顾与总结
加餐 | 如何做HTTP服务的测试？
服务治理篇 (11讲)
47 | 服务治理的宏观视角
48 | 事务与工程：什么是工程师思维？
49 | 发布、升级与版本管理
50 | 日志、监控与报警
加餐 | 怎么保障发布的效率与质量？
51 | 故障域与故障预案
52 | 故障排查与根因分析
53 | 过载保护与容量规划
54 | 业务的可支持性与持续运营
55 | 云计算、容器革命与服务端的未来
56 | 服务治理篇：回顾与总结
架构思维篇 (9讲)
57 | 心性：架构师的修炼之道
用户故事 | 站在更高的视角看架构
58 | 如何判断架构设计的优劣？
59 | 少谈点框架，多谈点业务
60 | 架构分解：边界，不断重新审视边界
加餐 | 实战：“画图程序” 的整体架构
61 | 全局性功能的架构设计
62 | 重新认识开闭原则 (OCP)
63 | 接口设计的准则
许式伟的架构课
登录|注册
36 | 业务状态与存储中间件
许式伟 2019-08-27
你好，我是七牛云许式伟。
相比桌面程序而言，服务端程序依赖的基础软件不只是操作系统和编程语言，还多了两类：
负载均衡（Load Balance）；
数据库或其他形式的存储（DB/Storage）。
存储在服务端开发中是什么样的一个地位？今天我们就聊一下有关于存储中间件的那些事情。
业务状态
让我们从头开始。
首先我们思考一个问题：桌面程序和服务端程序的相似之处在哪里，不同之处又在哪里？对于这样一个开放性的问题，我们不同人可能有非常不同的答案。
今天让我们从数据的视角来看这个问题。
我们知道，一个桌面程序基本上是由一系列的 “用户交互事件” 所驱动。你可以把它理解为一个状态机：假设在 i 时刻，该桌面程序的状态为业务状态i ，它收到用户交互事件i后，状态变化为业务状态i+1 。这个过程示意如下：
业务状态i+1= F( 用户交互事件i，业务状态i)
用状态转换图表示如下：
那么，服务端呢？
仔细考虑你会发现，其实服务端程序可以用一模一样的模型来看待。只不过它不是由 “用户交互事件” 来驱动，而是由 “网络 API 请求” 所驱动。
你同样可以把它理解为一个状态机：假设在 i 时刻，该服务端程序的状态为业务状态i ，它收到网络 API 请求i后，状态变化为业务状态i+1。这个过程示意如下：
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《许式伟的架构课》，如需阅读全部文章，
请订阅文章所属专栏。
请订阅文章所属专栏。
立即订阅
登录 后留言
精选留言(17)
- 有铭补充一下：第一个数据库的头衔并不能戴在IBM System R上，它只是第一个广为人知的关系数据库模型。在关系模型之前，也会有其他的模型。1966年IBM就开启了一个数据库项目：IBM Information Management System，简称IMS。IMS用的是一个层次模型。和关系模型里面完全摊平的表结构不一样，层次模型里面的数据有层次的概念。某种程度上来说，你可以理解为比较像类似今天MongoDB这样的文档数据库，或者某种形态的图数据库。这个简称为IMS的系统1968年发行了第一个版本。大企业蜂拥而至。卖的不是一般的好。而且奇迹一般的，到今天还有很多的客户跑在IMS上，这个古董堪称生命力顽强。
然后此时要提到一个关键人物：Edgar Frank Codd，英格兰人，早年学习数学和化学。二战时候是飞行员。二战后来到美国给IBM服务。后来因为美国麦卡锡风潮辗转去了加拿大。之后又回美国IBM工作，顺便去密西根大学拿了一个PhD。Edgar Codd的PhD做的是冯诺依曼架构计算模型的扩展，非常的理论。1970年在加州圣何塞硅谷实验室里工作的他公开发表了一篇论文：A Relational Model of Data for Large Shared Data Banks。翻译成中文就是一个为大容量共享数据银行设计的数据的关系模型，提出了数据的关系模型，也就是著名的关系代数。
Edgar Codd最初提出关系模型的时候，他以为好日子很快就要到来了。但是IBM并不是很愿意去实现这个模型，IBM对Edgar Frank Codd的关系模型的态度很暧昧：不拒绝，不反对，但是也不给钱做系统。现在回头去看究其原因是怕影响了自己已经有的IMS这个层次模型数据库的钱。
但是，Codd也是一个非常顽强的人，他就去找IBM的大客户，给大客户们洗脑说关系数据库才是未来，层次是过去。大客户们被洗的都信了关系代数神教以后就回头找IBM，说赶紧给爸爸们做一个关系数据库出来。IBM不怕Codd，但是经不住客户金主爸爸们反复要求，就在自己的Future System里加了一个新的研究对象：System R。Future System项目是IBM1970年前后开展的一个大型研究项目，为的是开发出革命性的新软件和硬件——从名字就可以看出这东西本质是想做一个“系统”，而不是现在意义上的“数据库软件”。当时如日中天的IBM可谓浩浩荡荡的撒钱。System R团队成立于1973年。里面包括了后来很多在数据库圈里声名显赫的人，包括后来的图灵奖获得者Jim Gray。当然，也不知道IBM怎么想的，IBM把System R团队和Codd给隔离开来了。
可以看出直到现在IBM还是看关系模型不顺眼，但是很快的，加州伯克利大学的Ingres（这就是后来著名的PostgreSQL的前身），以及甲骨文在1978年开始入场。IBM这才发现大势所(不)趋(妙)，加快研发速度搞出了DB2，随后Ingres商业化，甲骨文发布oracle加入竞争。关系数据库至此广泛的出现在大众视野面前作者回复: 多谢补充
2019-08-27 2 9 
诗泽老师今天讲的存储即数据结构可以这样理解：类比于桌面程序，服务端的系统状态也是存储于某些数据结构中，通过持久化这些数据结构来持久化服务的状态，这样服务重启或者扩容的时候可以利用这些数据来恢复服务状态，而存放持久化数据的存储系统即可被认为是内存外的数据结构。内存类型的数据结构有list map set 等，对应的内存外的数据结构类型有kv数据库，关系型数据库，对象储存，倒排索引等即“元数据结构”作者回复: 👍
2019-08-27 2
williamcai老师，消息队列不是消息中间件里么，为啥属于存储中间件作者回复: 消息中间件是从功能来说的，存储中间件是从分类来说。
2019-08-29 1
靠人品去赢老师，这个把存储中间件看成一个元数据结构，举个例子：数据库是不是我可以看成是一个B+树结构的元数据结构，是不是这意思？作者回复: 不需要看实现，我们看使用界面（接口）。接口是什么数据结构，就认为是什么数据结构。
2019-08-27 1
文龙流计算（flik，storm），也可以认为是中间件吗？作者回复: 嗯
2019-11-22
Eternal存储中间件是抽象的存储接口，是稳定点；
同的存储元数据是具体的实现，是变化点；
比如：MYSQL的元数据是一棵 B+树，MongDB的元数据是一个Docment文档，Redis的元数据是 key-value
分布式场景下，最大的瓶颈是存储中间件的压力，因为服务端程序依赖存储中间件来持久化多用户的的状态变化数据，
当用户量非常大的时候，服务实例可以容易伸缩，但是数据的伸缩却不是那么容易，老师讲的这个点印象很深2019-11-10
skye老师,为啥数据库叫中间件？数据最后才存数据库里的呀作者回复: 我自己是习惯把所有操作系统之上应用程序之下的都叫中间件。
2019-10-26- A2讲的内容都好抽象，真的是到了一定的境界才看的懂
作者回复: 学架构有如学内功，需要不停反复琢磨
2019-10-17 
逆流的鱼不明白服务端为什么比桌面程序实现kv更难，我理解桌面端能在内存那是因为服务端帮他实现了吧，区别不应该在一个是单用户的数据量级和全量数据的区别吗？作者回复: 是质量要求的差别
2019-09-05
Aaron Cheung比较全面的文章 打卡362019-08-31
何用服务端程序的业务状态并不简单。这是一个多租户的持久化状态。就算一个用户的业务状态数据只有 100K，有个 100 万用户，那么需要持久化的数据也有 100G。
—————
老师，为何这句话前面用“多租户”，后面又用“用户”来表达呢？作者回复: 嗯，多租户是受到云计算的影响，其实就是多用户
2019-08-30
qpm老师对抽象架构的讲解真是让人醍醐灌顶！2019-08-29
humor文中说的分布式数据库是什么概念呢？我理解的数据库应该是有状态的，不能像业务服务器一样任意伸缩，如果数据库要伸缩的话，肯定是需要手工迁移数据的作者回复: 分布式数据库是自动迁移的
2019-08-28 1
leslie老师今天的课回答了之前的之前上堂课问老师的问题：其实均衡是各个存储中间件的平衡；老师提到了持久化，可是目前业界大量的不落地或者为了数据的一致性定期落地。
存储中间件对于硬件所在的位置不同：MQ主要是基于PageCache、内存库主要其实访问的是内存、传统数据库其实不少时候还是在硬盘；几者之间的平衡性把握如何把握。
目前就是生产碰到困惑：关系型数据库无法满足现状，追加了内存库可是效果不是很好，目前在极客时间学习《消息队列高手课》，希望跟着老师学完后能找到一些思路；希望老师在下节课讲数据库时能把消息队列、内存库、关系型数据库同时结合分享一下老师的经验。
作者回复: 多谢建议
2019-08-27
勇闯天涯“存储中间件”从名字看来，我的理解是对数据库读写的公共层API封装，为何是 “元数据结构”不是很了解作者回复: 数据库只是一种存储中间件
2019-08-27- d关于元数据结构，有哪些，老师能讲下吗
作者回复: 文章中有举例，比如kv，比如mq，比如倒排索引
2019-08-27 
业余爱好者每个程序都要访问外部资源，如磁盘，网络等基础服务，所以有了操作系统。每个服务端程序都需要存储，所以有了数据库。2019-08-27
收起评论