许式伟的架构课
许式伟
七牛云CEO
立即订阅
20217 人已学习
课程目录
已更新 74 讲 / 共 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 | 服务治理篇：回顾与总结
架构思维篇 (11讲)
57 | 心性：架构师的修炼之道
用户故事 | 站在更高的视角看架构
58 | 如何判断架构设计的优劣？
59 | 少谈点框架，多谈点业务
60 | 架构分解：边界，不断重新审视边界
加餐 | 实战：“画图程序” 的整体架构
61 | 全局性功能的架构设计
62 | 重新认识开闭原则 (OCP)
63 | 接口设计的准则
64 | 不断完善的架构范式
65 | 架构范式：文本处理
许式伟的架构课
登录|注册
59 | 少谈点框架，多谈点业务
许式伟 2019-11-22
你好，我是七牛云许式伟。
架构是共识确认的过程
理需求的能力；
读代码的能力；
抽象系统的能力。
这里面除了 “读代码” 这件事可能允许没有什么显性的产出外（其实也应该有，去读代码通常意味着缺架构设计文档，所以按理应该去补文档），其他两类事情要做好都不容易。
就理需求的能力而言，很多架构师一不知道要做需求分析，二不知道需求分析的产出到底应该是什么样的。需求分析可以说是架构师最没有概念的一个环节，尽管它至关重要。这一块领域特征比较明显，课堂上讲师授课的方式，很难有好的成效，更适合以实训的方式来强化。
就抽象系统的能力而言，很多架构师爱画架构图。画完了架构图，他就认为架构做完了，下一步该去编码。
这有什么问题？
首先，架构过程是团队共识形成与确认的过程。共识是需要精确的、无歧义的。而架构图显然并不精确。
团队没有精确的共识很可怕，它可能导致不同模块的工作牛头不对马嘴，完全无法连接起来，但是这个风险没有被暴露，直到最后一刻里程碑时间要到了，要出版本了，大家才匆匆忙忙联调，临时解决因为架构不到位产生的“锅”。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《许式伟的架构课》，如需阅读全部文章，
请订阅文章所属专栏。
请订阅文章所属专栏。
立即订阅
登录 后留言
精选留言(10)
tt“框架，提现的是需求泛化的能力”。
体现需求泛化的能力，就是架构可以适应需求的变化。需求的变化就是接口的变化，因为本文说了，接口代表需求。
接口代表了要做什么，需求就是一个要做什么的集合，是目的。接口是需求的流程分解，即可以体现用户地图。
程序分为算法和数据结构，业务分为接口和业务数据，业务数据是业务的沉淀，是比框架更稳定的东西，而接口是在数据之上的动作，所以位置最高。作者回复: 赞
2019-11-22 7
Fs定义了数据结构，但是不抽象数据的业务逻辑，直接让使用方操作成员变量，或者定义一堆成员变量的 get/set 接口。
这句话含义是DDD中的贫血模型了。比如我需要判断某个实体是否是合格的，需要通过a,b 字段来判断。这个实现没有定义在数据结构里，却把a,b字段通过get暴露出去，让调用方去判断了作者回复: 是的
2019-11-24 4
Jxin目前来看，架构设计套路有限，但业务领域无限。如何应用有限的套路做出无限的架构设计，难点应是在业务上。没有足够的业务背景积累和业务需求洞察，架构设计就会出现知易行难的窘境。但是想要架构师一步到位具有健全的业务领域知识也是不现实的。所以，横竖都不好，那么就落地灵活的设计，动态去演变，也就所谓的演进式架构。而代码变动是高成本的，所以要想办法降低成本。首先代码可读要高。接着，单模块内各层，以及模块间的耦合要低。最后，代码的实现要采用合适的设计模式，以便易于扩展。但这三点不取决于架构师，具体业务开发个人素养的影响更大。所以，感觉约往后，业务开发的个人素养要求会越高。至少领域设计（战略规划）和架构分层、设计模式（战术应用）的诉求怕是少不了的。2019-11-22 1
leslie老师今天课程中提到了一个很关键的现状：框架绑架开发。这其实是许多程序过程中经常碰到的问题：某种框架不错大家去用，可是随着业务的复杂度和需求的复杂度的增加我们会发现被框架绑架了-实现不了，然后就开始调整需求或者实现方式。
这些年更多基于内核或者核心去改/写框架的：稍微有点特色就火了；其实我们去看本质会发现，只是降低了对某些框架的绑定能力而已，当程序中一大堆框架时其实我们就被一大堆事物绑架了。框架使用的度确实是个问题：用的越深绑架越深，故而其实都是在努力的做解绑-最小需求使用。
以上是个人的一点切身体会和薄见：一路听老师的课一路学习修正；期待老师的后续分享。2019-11-22 1
Aaron Cheung理清楚需求 列出验收标准 让一线开发理解做成啥样OK 有一些感触👍🏻2019-11-22 1
苟范儿“追求的不再是架构设计的好坏，而是打补丁，怎么把里程碑的目标实现了，别影响了团队绩效“ 。绩效真是把双刃剑，也许在做架构的时候也要充分将这些管理、协作因素考虑进去。
“代码即文档。代码是理解一致性更强的文档。“ 现在小孩子都开始抓编程，编程语言也真正变成一种语言，与计算机沟通、与 IT 人员沟通的语言。2019-12-09
小喵喵数据结构是指的是表结构或者是实体吗？还是什么链表，栈，树之类的数据结构呢？作者回复: 都是
2019-11-29
丁丁历险记本身也应该按module 来切分代码模块，最好让模块多具备正交性。2019-11-26
沫沫（美丽人生）许老师好，现在有些SaaS 企业PaaS化，请问从SaaS 向PaaS 过度的关键技术是什么呢？在系统架构上两者有什么本质区别吗？望不吝赐教。作者回复: 没本质区别。不过很多saas公司可能刚开始没有考虑接口开放的重要性，所以在这一层会遇到一些坑。
2019-11-25
睡觉💤定好边界，提前抽象出各个子模块对接时的接口与数据，然后是各个子模块的结构。架构师之路，道阻且长2019-11-22
收起评论