许式伟的架构课
许式伟
七牛云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 | 接口设计的准则
许式伟的架构课
登录|注册
40 | 服务端的业务架构建议
许式伟 2019-09-10
你好，我是七牛云许式伟。
相比桌面程序而言，服务端程序依赖的基础软件不只是操作系统和编程语言，还多了两类：
负载均衡（Load Balance）；
数据库或其他形式的存储（DB/Storage）。
我们前面几讲已经介绍了负载均衡和常见的存储中间件。今天，让我们就把焦点放在上图中的业务架构上。
大方向来说，业务架构必然是领域性的，与你所从事的行业息息相关。但就如同桌面程序会有自己的架构体系的套路一样，服务端的业务架构也会有自己的套路。
在图中，我们把服务端分成了两层。底层是 Multi-User Model 层，一般情况下它对外提供了一套 RESTful API 接口。上层是 Web 层，对外提供 Web API。Web 层又分为 Session-based Model 层和 Session-based ViewModel 层。
一般来说，Session-based Model 是一个非常简单的转译层。而在胖前端的模式下，Session-based ViewModel 层也几乎没有任何后端的代码，就是一些托管的资源文件，包含一些 HTML + CSS + JavaScript 文件。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《许式伟的架构课》，如需阅读全部文章，
请订阅文章所属专栏。
请订阅文章所属专栏。
立即订阅
登录 后留言
精选留言(9)
leslie许老师对存储和架构的理解确实不一样：开始学时还有些诧异为何只有此门功课的课程之间间隔相对较大；一路学来一路梳理，每次学完都会觉得有些疏漏需要自己去补；最终发现其实讲的太快根本无法理解所学的知识。
最初的学习目的是因为当下的数据系统和中间件有问题：之前自己在其它电商和金融业的经验无法移植，虽然系统放在云上，可是还是有性能问题，刚好老师的课开课，就带着求知欲来学习；课程开课到现在5个月了，学习老师的课程之余带着困惑把相关的知识顺带把相关知识梳理了一遍，前几天刘超老师的操作系统跟完了；自己把部分最关心的知识再看第二遍时才理解老师的讲解。最终发现某些困惑是因为自己的理解不够深度和广度，深度和广度铺开了且研究了有些东西就明白了；还有就是其实业界一直有个问题，对于某些知识/系统的标准划分其实蛮混乱的，这同样造就了典型问题本质相同的东西会因为包装不同而被叫成2种东西，不知道老师是否有这种体会？我自己作为一个一直混迹于中小企业近10年的DBA兼OPS对此深有体会。
关于存储中间层：其实这个定义老师应当是从物理层去划分的吧？其实关于这块选型我一直在研究存储中间层的选型：最近更是用了1个多月完全钻在里面，翻阅了不少书籍和看了一些极客时间里面其它老师的课，其实从设计层而已我们可以称为"数据系统"-这个概念其实是源自蔡超老师推荐的一本书籍中看到的;这个名词学生觉得更贴切-至少是设计层，无论是RMDB、NOSQL DB、MQ核心都是以数据为中心，他们的发展历程其实完全依赖的是硬件的发展-尤其是MQ。
根据发展历史其实关系型和非关系型的概念其实是同时提出：不过由于历史原因以及硬件原因，RMDB首先发展起来了，NOSQL DB的发展源自内存的代价不再那么庞大，随着服务端的模式的改变以及分布式设计的出现MQ开始彻底出现；故而现在其实三者是相辅相成，老师今天提出API，其实差的系统都有一点共性：API写的很差，RMDB、NOSQL DB、MQ的读写比例、调度机制设计的再合理扛不住一个烂的API的一个操作，前段时间公司某套系统内测时就碰到过接口程序写的太烂直接把数据库和操作系统资源跑崩的情况。
其实我现在非常好奇的是一件事情不知道许老师是否有所关注：其实现在很多的瓶颈已经从过去我们设计数据系统/存储中间件时硬盘、内存变成了CPU，AI 的聚焦其实一定程度上同样在CPU上：毕竟它有20年没有真正提升了，内存的廉价化其实已经让过去的数据库+数据仓库变成了NOSQL DB+ RMDB，CPU未来的提升会给现在的系统再次带来怎样的变化？
今天是教师节：谢谢老师一路来的辛勤付出，祝愿老师节日快乐。作者回复: 这本书没法承担太多职能，我们的讨论重心始终会在架构，包括基础架构和业务架构。从架构角度来说，系统的瓶颈永远是存储中间件。但是从数据分析角度来说，CPU的确是我们的智能能够走得有多远的瓶颈。
2019-09-10 13
Aaron Cheung楼上大佬留言很有分量 我就啥也不说了 老师教师节快乐2019-09-10 3
Quincy老师，我想请教下老师一个建议，Devops想选一门专精的话，是专go语言还是Python比较有前或"钱"途作者回复: 都有前途
2019-09-20 1
TryTs许老师您好，我现在有个很天真的想法，不知道是否正确，在没有进入公司的情况下，在计算机行业里面如果实力真的足够（或者就是把所以硕士要求的课都学好），可否打破那种（要求硕士）的门槛的要求，还是说现状是不管怎样，必须先有那个硕士文凭在？作者回复: 文凭重要但又没有那么重要。硕士要求的课都“学好”和有实力也不完全等同，有实力可以有很多证明方式，用文凭可能是最没有说服力的证明方式之一。
2019-09-17 1- Sam老师，麻烦问下Session-base model作为web api，是否他是融合多个后端业务系统的RESTful api后，提供给前端使用的web api接口吗？
作者回复: 是的
2019-09-15 1 
八哥还有很多前端工程师不知道在同域下，浏览器默认携带cookie，很多工程师理不清单点登录。认证这块可以多讲讲作者回复: 实战有一篇专门是认证篇
2019-09-12
睡觉💤如果一个服务需要c端用户为登录状态进行操作，例如淘宝或者京东，那么这个服务必然要维护session ，所以这个服务就不符合Rest规则了吗？Rest仅仅是数据接口？作者回复: 登录的session一般通过cookie来记录session id，在服务端记录session信息，这的确不那么无状态。不过authorization很特殊，通常不作为rest与否的判断依据。
2019-09-11- Geek_88604f但是从状态转化角度来说，桌面程序和服务端程序很不一样。桌面程序的状态转化往往存在中间的 “临时状态”，这其实也是 Controller 层的价值所在。关于这段描述有如下疑问，望解答:
一，理论上应该存在四种选择:桌面程序有临时状态、桌面程序无临时状态、服务端程序有临时状态、服务端程序无临时状态，而实际上只有桌面程序有临时状态、服务端程序无临时状态两种。究竟是什么样的需求或技术发展背景导致只有这两种情况？
二，服务端对外暴露的api在内部也可能涉及到对多个其他服务的调用，在这个过程中也有可能产生临时状态。这个和老师的描述似乎不太一致，是否是我理解有误？作者回复: 内部有临死状态那是内部的事，从交互接口来说没有临时状态。另外服务端内部临时状态一般通过事务来完成原子化，以避免出现不一致的状态。
2019-09-11 - Caffeine现在物联网这么火 不知道有没有针对嵌入式软件或单片机软件开发的架构设计呢
作者回复: 和桌面开发差不多，由于交互少，整个体系只会比桌面简单。
2019-09-10
收起评论