极客时间专栏：许式伟的架构课

• 微信的浏览器之战，让操作系统变成了一个管道
• 冯诺依曼计算机体系
• CPU 存储（大脑） IO（四肢）
• IO是黑箱的，可以是不同架构的东西
• 计算机的能力（CPU指令集） ROM（BIOS）主板的程序
• 内存页缺失的中断处理
• 解决一切可以用计算来解决的问题
• 计算机的程序可以保存在计算机主板 ROM上，也叫启动程序，也可以保存在外置存储设备上（硬盘）， 在合适的时机加载执行
• 指令的可能无穷性，程序的无穷性
• 用变量名来表达一段内存中的数据，不用关注物理地址，而是放在程序的逻辑表达上
• 语言和编程语言的革命性是一样的，软件就是书籍，比书籍表现力更加丰富
• 结构体 面向过程 函数式 对过程的约束 面向对象（接口和多态）
• Go放弃了继承用组合，Go是面向连接的
• 用消息传递代替共享内存
• 一个典型的网络应用程序角度来说，完整的图是什么样的？

• 对象存储服务是http，数据库等是TCP
• Nginx和Apache都可以作为应用层网关
• NAT处在第四层
• 如果限定了数据包一定是某种协议，就会出现应用层网关，工作在第七层
• ip协议不保证数据时候到达
• 音视频的传输，在网络环境比较差的情况下，往往希望丢掉一些帧，但是由于TCP从传的机制，反而会加剧了网络的拥堵。这种情况UDP就比较理想
• ip和UDP区别非常小，都是无连接协议，唯一的区别就是增加了一个端口
• 网络安全：IOS系统相对来说就比较好（安全）
• 原来是不一张www 而是企业的局域网
• 对象存储的一种新型的存储系统，由于互联网的兴起，数据不在i存在本机，数据只需要关联账号
• 对于操作系统厂商如果把你数据弄丢了不会责怪，但是云存储给你数据弄丢了就会罪责
• 文件系统对于大规模存储有什么问题？ 文件系统是一棵树，对于单个文件除了需要锁住文件外，对于树节点的修改操作都是一次事务，需要锁住整棵树
• 对于并法吞吐能力都是伤害，从规模来说实现分布式事务也比较难（这也是分布式数据库难做的原因），做出来性能往往也好不到哪里去，从并发吞吐能力来说，如果系统存在大锁，即锁在里面执行废时操作，就会大幅度降低并发吞吐能力
• 从本质来说，服务端和桌面软件的场景是不同的，文件系统是桌面软件下的产物，桌面系统是单用户场景，没有高并发的需求
• 服务端一上来就面临着并发访问的问题，所以很早就出现了数据库这样的存储中间件，数据库的出现，其实证明文件系统不适合服务端。
• 互联网的发展极大的加速了文件型存储的发展，互联网增加的90%以上的数据，都是非结构化的数据，包括图片 音频 视频 日志
• 对象存储能够支撑的文件数量规模上非常非常大。比如七牛云存储，我们已经支持万亿级别的文件。
• 大数据的Hadoop，HDFS这种日志型存储是对象存储的一个特例，大数据会逐步过渡到以对象存储的基石
• 存储网关将对象存储包装成NAS
• 冯·诺依曼体系结构，我们把它抽象为“中央处理器（CPU）+ 存储 + 一系列的输入输出设备”
• 为什么要引入栈，CPU起什么作用？

• 操作系统的5个子系统：设备管理（存储设备，输入输出设备，网络设备），进程管理，安全管理

• 桌面操作系统和服务端操作系统的演进方向非常不一样。桌面操作系统的演进方向主要是交互范式的迭代，在向着越来越自然、越来越智能的交互前进。
• 无论什么操作系统都有一个全局事件队列

• 站在高的角度去理解MVC：M是放在最底层的，C是最上层，M越厚越好，C应该设计成注释一行代码就能取消一个接口，View监听Model的事件。view局部更新的优化

• 基于浏览器的软件：软件服务化，随时发布，跨平台

• PWA+Libra

• Web 的 B/S 架构意味着编写软件有了更高的复杂性。这主要表现在以下几个方面。

• 其一，多用户。有了 Server 端，意味着用户的数据不再是保存在 Client（Browser）端，而是存储在 Server 端。

• 其二，更高的数据可靠性要求。数据在 Client 端，客户自己对数据的可靠性负责。硬盘坏了，数据丢了，用户会后悔没有对数据进行备份。但是一旦数据在 Server 端，数据可靠性的责任方就到了软件厂商这边。如果厂商不小心把数据搞丢了，用户就会跳起来。

• 其三，更多可能的分工安排。详细来说，Web 应用从流派来说，分为两大类：胖前端与胖后端。

所谓胖前端，是指把尽可能多的业务逻辑放在前端。极端情况下，整个网站就是一个单页的应用。胖前端无论开发体验还是用户体验，都更接近于本地应用（Native App）。

所谓胖后端，是指主要逻辑都在后端，包括界面交互的事件响应，也通过网络调用交给了后端来实现。

• 这个时候我们重新看 MVC 框架在浏览器下的样子，你会发现它变成了 MVMP 模式，全称为 “Model-ViewModel-Presenter”。
• 所以解决思路自然是让 Controlller 层来做，这样就变成了 MVP 模式。 但是我们又不是标准的 MVP，因为 Presenter 层更新界面（Update View）并不是操作 View，而是 ViewModel。
• 今天的跨平台，重点是要跨 Android、iOS、Web、小程序和 PWA。如果精力顾不上，PC 桌面操作系统的优先级反而可以缓一缓，毕竟 Web 也能够顶一下。
• 今天随着桌面平台的多元化，跨平台工具的需求达到了历史最高点。
• 那么，通用的跨平台怎么做到？
  Google Flutter 给了一条路，它把对操作系统的要求最小化，整个界面系统完全自己在用户态构建。
  这个思路和 Go 语言有点像。Go 语言其实是在用户态完全重写了操作系统的进程管理和 IO 子系统。
• 方法和函数之间的差别：方法多了一个概念叫接受者，go中叫this或self

文件系统和对象存储

• 从单机时代的文件系统，后来数据库兴起，到后来对象存储云存储
• 存储加计算就构成了朴素的计算机模型，存储就是维持了计算系统的单元
• 服务器做到高可用：存储中间件
• 对于大部分程序而言，只需要重点关注业务的分支流程，对于出乎意料的情况，只需要抛出一个错误，告诉用户不应该这么玩。
• 在服务端开发过程中应用到多媒体等，几乎不会存储到数据库中，更多放到文件系统里，单机时代诞生的文件系统真的适合多媒体数据吗。
• 不，文件系统需要改变：第一是伸缩性问题，第二是性能瓶颈，第三是可靠性（数据需要冗余）
• 非结构化会有大规模的存储
• 把物理世界映射到数字世界
• HDFS的block大小为64M，依然用文件系统的API
• 存储非结构化最好是对象存储：键值存储
• 对象存储根本就是要去关系

授权模式

• 最后，客户端（Client）通过 Token 向服务提供商的资源服务（Resource Server）发起资源访问请求。

• 整个过程的具体流程如下：

（A）终端用户打开客户端以后，客户端要求终端用户给予授权。
（B）终端用户同意给予客户端授权。
（C）客户端使用上一步获得的授权，向认证服务器申请令牌（Token）。
（D）认证服务器对客户端进行认证以后，确认无误，同意发放令牌。
（E）客户端使用令牌，向资源服务器申请获取资源。
（F）资源服务器确认令牌无误，同意向客户端开放资源。

• 这个图体现了 OAuth 2.0 的核心思想。但不同场景下，具体的授权流程有一定的差异。常见的授权模式有如下几种：

• 授权码模式（Authorization Code）；

• 简化模式（Implicit）；

• 用户名+密码模式（Resource Owner Password Credentials）；

• 客户端模式（Client Credentials）；

• 访问令牌（Access Token）；

• 更新令牌（Refresh Token）