许式伟的架构课
许式伟
七牛云CEO
立即订阅
19913 人已学习
课程目录
已更新 71 讲 / 共 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 | 服务治理篇：回顾与总结
架构思维篇 (8讲)
57 | 心性：架构师的修炼之道
用户故事 | 站在更高的视角看架构
58 | 如何判断架构设计的优劣？
59 | 少谈点框架，多谈点业务
60 | 架构分解：边界，不断重新审视边界
加餐 | 实战：“画图程序” 的整体架构
61 | 全局性功能的架构设计
62 | 重新认识开闭原则 (OCP)
许式伟的架构课
登录|注册
42 | 实战（二）：“画图”程序后端实战
许式伟 2019-09-17
你好，我是七牛云许式伟。
在上一章，我们实现了一个 mock 版本的服务端，代码如下：
接下来我们将一步步迭代，把它变成一个产品级的服务端程序。
我们之前已经提到，服务端程序的业务逻辑被分为两层：底层是业务逻辑的实现层，通常我们有意识地把它组织为一颗 DOM 树。上层则是 RESTful API 层，它负责接收用户的网络请求，并转为对底层 DOM 树的方法调用。
这一讲我们关注的是底层的业务逻辑实现层。
使用界面（接口）
我们先看下这一层的使用界面（接口）。从 DOM 树的角度来说，在这一讲之前，它的逻辑结构如下：
<Drawing1>
<Shape11>
...
<Shape1M>
...
<DrawingN>
从大的层次结构来说只有三层：
Document => Drawing => Shape
那么，在引入多租户（即多用户，每个用户有自己的 uid）之后的 DOM 树，会发生什么样的变化？
比如我们是否应该把它变成四层：
Document => User => Drawing => Shape
<User1>
<Drawing11>
<Shape111>
...
<Shape11M>
...
<Drawing1N>
...
<UserK>
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《许式伟的架构课》，如需阅读全部文章，
请订阅文章所属专栏。
请订阅文章所属专栏。
立即订阅
登录 后留言
精选留言(7)
- 侯永强这个专栏看到现在的体会:
1.作者是大神。神一样的思考和行为。
2.体会了看懂后的快乐，无价之宝。
3.必须磕头才能表达敬意。2019-09-17 5 
Aaron Cheung读了好几遍文章 很有收获 打卡2019-09-17 1
Dimple看后端实战，没有动GO语言，还得回去稍微了解下GO2019-11-20
Bachue Zhou从工程的角度看，不推荐用这种难以理解的缩写，dgid 乍看之下非常难以让人联想到 drawingId作者回复: 这种简写一般在团队内有统一的缩写表，否则建议全称
2019-10-23- Geek_88604f关于Sharp的约束我试着理解一下，语言方面的约束老师已经说了两点:一是Drawing类通过接口来引用Sharp类以增加通用性；二是考虑到 Drawing 类的 List 和 Get 返回的 Shape 实例，会被直接作为 RESTful API 的结果返回。所以，Shape 的 json.Marshal 结果必须符合 API 层的预期。
除了语言方面的约束外还存在语意方面的约束，一方面RESTful要求对资源的操作只能是POST、GET、PUT、DELETE；另一方面考虑到网络可能出现的故障，接口实现要幂等，支持错误或超时的重试。作者回复: Shape对象的约束和网络并没有关系
2019-09-22 - Geek_88604f多租户共用一颗 DOM 树，会不会存在性能瓶颈？在后续用户数增多，高并发的情况下无法满足要求，存在拆分的诉求？
作者回复: 不是共享dom树，这里和共享没什么关系。你可以认为uid和任何普通的变量一样，只是一个普通数据而已。
2019-09-22 
吴有深度2019-09-17
收起评论