许式伟的架构课
许式伟
七牛云CEO
立即订阅
20237 人已学习
课程目录
已更新 75 讲 / 共 87 讲
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 | 服务治理篇：回顾与总结
架构思维篇 (12讲)
57 | 心性：架构师的修炼之道
用户故事 | 站在更高的视角看架构
58 | 如何判断架构设计的优劣？
59 | 少谈点框架，多谈点业务
60 | 架构分解：边界，不断重新审视边界
加餐 | 实战：“画图程序” 的整体架构
61 | 全局性功能的架构设计
62 | 重新认识开闭原则 (OCP)
63 | 接口设计的准则
64 | 不断完善的架构范式
65 | 架构范式：文本处理
66 | 架构老化与重构
许式伟的架构课
登录|注册
61 | 全局性功能的架构设计
许式伟 2019-12-03
你好，我是七牛云许式伟。
在架构设计中，我们会有一些难啃的骨头。其中最为典型的，就是全局性功能。全局性功能的特征是很难被剥离出来成为独立模块的。我们仍然以大家熟悉的 Office 软件作为例子：
读盘 / 存盘：每增加一个功能，都需要考虑这个功能的数据如何存储到磁盘，如何从磁盘中恢复。
Undo/Redo：每增加一个功能，都需要考虑这个功能如何回滚 / 重做，很难剥离。
宏录制：每增加一个功能，都需要考虑这个功能执行的结果如何用 API 表达，并且得支持将界面操作翻译成 API 语句。
……
也有一些功能看似比较全局，但实际上很容易做正交分解，比如服务端的所有 API 都需要鉴权，都需要记录日志。它们似乎有全局性的影响，但一方面，通常可以在 API 入口统一处理，另一方面就算只是提供辅助函数，具体的鉴权和记录日志都由每个 API 自行处理，心智负担不算太高。所以对于这类功能，我们可以不把它归为全局性功能。
正因为需求交织在一起，全局性功能往往难以彻底进行正交分解。但对于架构师来说，难不代表应该轻易就放弃对正交分解的追求。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《许式伟的架构课》，如需阅读全部文章，
请订阅文章所属专栏。
请订阅文章所属专栏。
立即订阅
登录 后留言
精选留言(13)
leslie"任何功能都是可以正交分解的，如果没有，那是因为没有透彻理解需求"。数据库多年，上次和池老师见面时-他描述他的人生轨迹时，自己得到了一个反思-全栈去看待梳理，然后换位思考去沟通。
大概万事万物离不开数据：数据部门有时反而成了中间点。站在中间点的角度和产品、销售、开发、运维之间做了不少需求的协调和梳理，在不断的换位思考中能理解可能的问题，这大概是最难的事情，不断的沟通去梳理探索当前真正的核心然后才能把握住当下。
老师的课程首先从各个方面去梳理了各个点的问题，又从业务/产品的角度去思考了，最后站在中间的地方去拎起来整体。明显的感受到老师在传递一种思想：好的架构一定是对架构相关的都明白且通过沟通去梳理出真正的核心需求/架构；就像计算机的核心是CPU，然后一步步扩展出整台PC。
感谢老师的教诲和付出：全局性的核心首先是不断抓住核心，然后扩展出周边，不能因为周边反而绑住/束缚了核心。期待老师下节课的分享。2019-12-03 4
Aaron Cheung任何功能都是可以正交分解的，即使我目前还没有找到方法，那也是因为我还没有透彻理解需求。
醍醐灌顶作者回复: 👍
2019-12-03 4
tt“业务分解就是最小化的核心系统，加上多个正交分解的周边系统。核心系统一定要最小化，要稳定。坚持不要往核心系统中增加新功能，这样你的业务架构就不可能有臭味。”
我觉得这句话就是下节课的引子，核心是最小化的，就可以容易做到对修改封闭，因为它是业务的本质，除非业务变了，或者是我们没有彻底理解业务，否则它不会剧烈变化。
多个正交分解的周边系统，所以可以容易的扩展，因为互相不耦合，而只是依赖核心。
核心就是坐标系原点，定位了一个业务，周边就是各个象限，扩充了整个系统。作者回复: 说得很赞👍
2019-12-08 2
诗泽当一个新需求来了或者要开始一个新项目的时候架构师在做需求分析和架构设计的时候其他工程师们在做什么？作者回复: 在做老项目
2019-12-05 2
清歌核心功能最小话，保持稳定；外围功能正交分解，这个总结太厉害了2019-12-04 1
Tao许老师你好，最近在做一个前端图标编辑的 web 应用，遇到了undo/redo 需求，项目之前是针对部分 commander （涉及对画布的增删），将整个画布数据拷贝一份存入，没有持久化在内存中，undo/redo 将数据取出来重绘。性能非常差，数据量上去之后，直接卡死。现在这部分在重构，想要实现你文中表述的样子，只是对修改的部分存储，我们画布元素分为节点（node) 和边（edges)，修改只针对这两种，包括修改样式、增加边或者节点，删除边或者节点，我想这增加修改我会将对应的数据存下(有元素id)，redo/undo 的时候，与 base 数据合并，提供给场景，但是删除怎么增量保存呢？
另外数据保存到浏览器的 localStrorage 好还是 indexedDB 中较好呢作者回复: 1、删除可以看作parent的items属性修改，也可以看作自身deleted属性的修改。
2、localStorage 比较通用、易用，indexedDB 更加强大。2019-12-16
吴老大，一般浏览日志，操作日志怎么规划？谢谢2019-12-09- CoderLim老师一直在强调业务正交分解，不理解，能否说一下如何做
作者回复: 这块和具体业务相关，关键做好需求分析。
2019-12-06 
Fs有点抽象，需要更多慢慢咀嚼消化2019-12-04
阿火正在反复阅读当中，正交分解2019-12-04
K战神大道至简，
把事情做明白想明白还得千锤百炼，
还得深刻思考中千锤百炼地做明白想明白，
回头再看，大道至简。
顿悟。2019-12-04
睡觉💤任何功能都是可以正交分解的，即使我目前还没有找到方法。2019-12-03
梦醒十分干货满满呀！2019-12-03
收起评论