- 微信的浏览器之战,让操作系统变成了一个管道
- 冯诺依曼计算机体系
- 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)