许式伟的架构课
许式伟
七牛云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
    比较全面的文章 打卡36
    2019-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
收起评论
17
返回
顶部