- 课程目录
- 课程介绍
-
在线阅读：开篇词 | 怎样成长为优秀的软件架构师？
让我们来想象一下，如果把信息世界看成一座大厦，把程序员看成这个世界的建筑师，那么，现在的你在负责什么样的工作呢？
-
01 | 架构设计的宏观视角
不管今天的你是不是团队里的一位架构师，对于任何一位程序员来说，具备架构思维将会成为让你脱颖而出的关键。
-
02 | 大厦基石：无生有，有生万物
冯·诺依曼体系结构的不凡之处在于，它想“解决一切可以用‘计算’来解决的问题”。
-
03 | 汇编：编程语言的诞生
为了不再用“0101”表达自己的思想，人们创造了汇编语言，这一步让编程成为一个纯软件行为，程序员这一个分工也由此诞生。
-
04 | 编程语言的进化
今天我们抛开具体的语言发展史，从编程范式演进的角度来谈编程语言的进化。
-
05 | 思考题解读：如何实现可自我迭代的计算机？
第一台以键盘+显示器为标准输入输出的现代计算机出现后，一个最小功能集，但计算能力可自我迭代的计算机应该是什么样的？
-
06 | 操作系统进场
从商业价值说，操作系统是刚性需求，核心的流量入口，兵家必争之地。所以，围绕它的核心能力，操作系统必然会不断演化出新形态。
-
07 | 软件运行机制及内存管理
操作系统的核心职能是软件治理，软件治理的一个很重要的部分，就是让多个软件可以共同合理使用计算机的资源，不出现争抢的局面。
-
08 | 操作系统内核与编程接口
通过系统调用这个机制，我们很好地实现了操作系统和应用软件的隔离性和安全性，同时仍然保证了极好的执行性能。
-
09 | 外存管理与文件系统
整体来说，外存管理从架构角度来说比较简单，复杂性主要集中在外存数据格式，也就是文件系统的设计上。
-
10 | 输入和输出设备：交互的演进
交互在朝着自然和智能的方向发展。每一个软件不能自己去做输入意图的理解。在未来，必然由操作系统来实现智能交互的基础架构。
-
11 | 多任务：进程、线程与协程
今天我们重点介绍了多任务，以及多任务带来的复杂需求，由此介绍了进程、线程和协程等三套执行体的设计。
-
12 | 进程内协同：同步、互斥与通讯
锁在一些人心中是有误解的，但实际上锁在服务端编程中的比重并不低，我们可能经常需要和它打交道，建议多花精力理解它们。
-
13 | 进程间的同步互斥、资源共享与通讯
通过对比不同操作系统，我们会发现以 “剧烈变动” 来形容进程间协同的需求演进一点也不过分。
-
14 | IP 网络：连接世界的桥梁
互联网背后的世界，和互联网一样精彩。精妙之处，值得细细体会。
-
15 | 可编程的互联网世界
这一讲我们希望给大家呈现的是应用程序的全貌。当然，我们现在看到的仍然是非常高维的样子。
-
16 | 安全管理：数字世界的守护
从最早的病毒和木马，演化到今天敏感信息如通讯录等内容的窃取，正常软件与恶意软件的判断边界越来越模糊。
-
17 | 架构：需求分析 (上)
需求分析的目标和最终结果，都是要形成清晰的产品定义。产品定义将明确产品元素，明确产品边界，与产业上下游、合作伙伴的分工。
-
18 | 架构：需求分析 (下) · 实战案例
今天我们选了两个实战案例：打造“互联网”和存储新兵“对象存储”，来继续“需求分析的讨论”。
-
19 | 基础平台篇：回顾与总结
我们日常所依赖的基础平台，随处可见的架构之美，看到了，悟到了，就学到了。
-
20 | 桌面开发的宏观视角
交互范式的演进是非常剧烈的。交互体验却越来越自然，但从编程的角度来说，如果没有操作系统支持，实现难度也将越来越高。
-
21 | 图形界面程序的框架
在操作系统的所有子系统中，交互相关的子系统是毫无疑问的差异性最大的子系统。
-
22 | 桌面程序的架构建议
一千个人眼中有一千个哈姆雷特，虽然都在谈 MVC，但是大家眼中的 MVC 各有不同。
-
23 | Web开发：浏览器、小程序与PWA
为什么微信小程序必然会成功？因为，有 7 亿人同时使用的操作系统，很少。
-
24 | 跨平台与 Web 开发的建议
今天我们要聊一聊 Web 带来的两个重要改变。一个是跨平台，一个是 Web 开发。
-
25 | 桌面开发的未来
桌面开发的未来是什么？从终局的视角来看，桌面开发的终极目标，是让儿童可以轻松编写出生产级的应用。
-
26 | 实战（一）：怎么设计一个“画图”程序？
今天我们结合一个实际的应用案例，来回顾一下前面我们介绍的内容。
-
27 | 实战（二）：怎么设计一个“画图”程序？
我今天把服务端对接往后延后一讲，增加一篇。一方面把“上”篇没有交代清楚的补一下，也对 “画图” 程序做一次需求的迭代。
-
28 | 实战（三）：怎么设计一个“画图”程序？
我们开始考虑 “画图” 程序的服务端连接。今天这一讲我们先做画图程序的本地浏览器存储的持久化，以便拥有更好的离线。
-
29 | 实战（四）：怎么设计一个“画图”程序？
今天我们重点讨论了 “画图” 程序的网络协议，给出了常规网络协议设计上的一些考量点。
-
30 | 实战（五）：怎么设计一个“画图”程序？
今天我们完成了画图程序前后端 paintdom、paintweb 的对接。
-
31 | 辅助界面元素的架构设计
我们不见得什么桌面应用程序都要把它控件化。但是我们花一些精力去思考控件化的话，会有助于你对架构设计中的一些决策提供帮助。
-
32 | 架构：系统的概要设计
学架构，我个人强调的理念是 “做中学”。首先还是要勤动手。然后配合本专栏去思考和梳理背后的道理，如此方能快速进步。
-
33 | 桌面开发篇：回顾与总结
学业务架构最好的方式是“做中学”。做是最重要的，然后要有做后的反思，去思考并完善自己的理论体系。
-
34 | 服务端开发的宏观视角
今天我们从服务端的发展历程、服务端开发的需求谈起，以此方便你理解服务端开发的生态会怎么演化，技术迭代会走向何方。
-
35 | 流量调度与负载均衡
负载均衡的价值并不只是做流量的均衡调度，它也让我们的业务服务器优雅升级成为可能。
-
36 | 业务状态与存储中间件
对于服务端来说，存储中间件至关重要。它不只是极大地解放了生产效率，也是服务端的性能瓶颈所在。
-
37 | 键值存储与数据库
数据库是非常专业并且复杂的领域，今天我们就聊一下应用最为广泛的存储中间件：数据库。
-
38 | 文件系统与对象存储
对象存储的出现，是服务端体系架构和桌面操作系统分道扬镳的开始。
-
39 | 存储与缓存
缓存是一个存储系统在服务器性能上的补丁，这个补丁并不是那么完美。
-
40 | 服务端的业务架构建议
服务端业务架构，主要是怎么做一个多租户的 Model 层。
-
41 | 实战（一）：“画图”程序后端实战
从今天开始我们会一步步将之前写的 mock 服务端改造为真实的服务端程序。
-
42 | 实战（二）：“画图”程序后端实战
多租户不会导致 DOM 层级变化，但是它会导致接口方法的变化。
-
43 | 实战（三）：“画图”程序后端实战
一旦我们希望授权第三方应用程序来调用我们的服务，最好的选择是 OAuth 2.0。
-
44 | 实战（四）：“画图”程序后端实战
基于 OpenID Connect 协议来提供帐号系统，基于 OAuth 2.0 协议来实现 Open API 体系。
-
45 | 架构：怎么做详细设计？
详细设计并不是只谈实现就完事，更不是一个架构图。
-
46 | 服务端开发篇：回顾与总结
服务端开发致力于设计合适的业务架构来满足用户需求，而服务治理则致力于让服务端程序健康地为客户提供不间断的服务。
-
加餐 | 如何做HTTP服务的测试？
测试是软件质量保障至关重要的一环。一个好的测试工具对提高开发效率的作用巨大。
-
47 | 服务治理的宏观视角
服务治理不是纯理论，没有简洁的抽象问题模型，我们面对的是现实世界的复杂性。
-
48 | 事务与工程：什么是工程师思维？
真正的工程师会系统化地考虑方案的有效性。他们追求的是用最小化的编码工作来解决更大范围的问题。
-
49 | 发布、升级与版本管理
无论是从市场竞争还是工程质量管理的角度，我们都鼓励这样的版本发布哲学：少量发布、频繁发布。
-
50 | 日志、监控与报警
一个很牛的监控 SRE，他要干的绝对不是不停地添加新的监控项以 “完善某个业务的监控”。
-
加餐 | 怎么保障发布的效率与质量？
LCE 的技术要求与其他的 SRE 成员一样，但这个岗位打交道的外部团队很多，需要有很强的沟通和领导能力。
-
51 | 故障域与故障预案
发布过程引发的故障实际上有别于另外两种故障类型，它源于我们主动对系统作出变更，属于过程型的故障。
-
52 | 故障排查与根因分析
为了有效排查故障，日志系统在里面起到了关键作用。
-
53 | 过载保护与容量规划
所谓过载，最直白的理解，当然就是因为活跃的用户超过了资源的承载能力范围，导致某类资源耗尽，进而体现出系统过载。
-
54 | 业务的可支持性与持续运营
除了产品的功能外，实际上为了产品能够更好地服务好客户，我们需要关注售前、售后支持能力的构建。
-
55 | 云计算、容器革命与服务端的未来
云计算和容器革命将服务端的基础设施化推向了高潮。未来，也许我们并不需要专门的服务端开发工程师来做业务开发。
-
56 | 服务治理篇：回顾与总结
到此为止，我们 “基础平台”、“桌面开发”、“服务端开发”、“服务治理” 这四大模块就结束了。
-
57 | 心性：架构师的修炼之道
架构之道，是虚实结合之道，理论与实践相结合。
-
58 | 如何判断架构设计的优劣？
不增加无谓的复杂性，正确理解系统的需求之后才进行设计。
-
59 | 少谈点框架，多谈点业务
架构就是业务的正交分解。每个模块都有它自己的业务。
-
60 | 架构分解：边界，不断重新审视边界
我们通过一个实际的例子，来剖析架构设计过程中我们如何在思考模块边界。
-
加餐 | 实战：“画图程序” 的整体架构
对于复杂系统，一定要理清核心系统和周边系统的边界，让整个程序的内核最小化。
-
61 | 全局性功能的架构设计
我们需要坚持作为一名架构师的信仰：“任何功能都是可以正交分解的，即使我目前还没有找到方法。”
-
62 | 重新认识开闭原则 (OCP)
如果我们把整个信息科技看作最大的一个业务系统，我们有无数人在为之努力奋进，迭代它的架构。
-
63 | 接口设计的准则
对于模块的使用界面，我们推崇 KISS 原则，简单自然，符合业务表达的惯例。
-
64 | 不断完善的架构范式
我们需要意识到的一点是，熟读架构思维并不足以让我们成为优秀的架构师。
-
65 | 架构范式：文本处理
文本处理是一个非常庞大的课题，本文详细解剖了我个人在这个领域下的经验总结。相信这些经验对你面对相关场景时会有帮助。
-
66 | 架构老化与重构
架构的功夫全在平常。
-
67 | 架构思维篇：回顾与总结
架构设计，设计为先，架构为魂。
-
68 | 软件工程的宏观视角
架构师的确是一个技术岗，但是架构师干的事情，并不是那么纯技术。
-
69 | 团队的共识管理
共识有非常多的层次。不同层次的共识处于完全不同的维度。它们都极其重要，且相互不可替代。
-
70 | 怎么写设计文档？
对于系统的概要设计来说，核心是交代清楚不同模块的配合关系。
-
71 | 如何阅读别人的代码？
代码即文档，代码是理解一致性更强的文档。
-
72 | 发布单元与版本管理
一个复杂的软件，总可以被分割为若干个独立迭代的发布单元，以便分而治之。
-
73 | 软件质量管理：单元测试、持续构建与发布
整体来说，软件工程与传统工程在质量管理上的理念是迥异的，甚至往往是反其道而行之的。
-
74 | 开源、云服务与外包管理
从形态来说，商业软件很接近传统外包，但是从它的边界来说，因为商业软件往往有明确的业务边界，所以在品质上会远高于外包。
-
75 | 软件版本迭代的规划
在不同阶段，版本迭代的侧重点会有极大的不同。
-
76 | 软件工程的未来
软件工程极大成熟的标志，是一体化的软件工程支撑系统，和高效的人才培养体系。
-
77 | 软件工程篇：回顾与总结
我们首先需要尊重团队协同的科学，在尊重的基础上去探索新的更高效的协同方法论。
-
在线阅读：结束语 | 放下技术人的身段，用极限思维提升架构能力
在架构能力上，没有最好，只有更好。
-
结课问卷获奖用户名单
我们挑选出反馈信息最具体、丰富、有实际价值的5位用户，送出奖品。
-
课程迭代 | 84讲音频重新交付
那些能持之以恒学完这门课的同学，他们在努力迭代升级自己，这要比我们迭代课程难的多。
-
热点观察 | 我看Facebook发币（上）：区块链、比特币与Libra币
站在未来看现在，Facebook 发布的Libra 币将会是极其重大的一个历史节点。
-
热点观察 | 我看Facebook发币（下）：深入浅出理解 Libra 币
货币有着巨大的网络效应，留给后来者的时间窗口极短。我想，我们都应该思考怎么去面对这件事情了。
-
课外阅读 | 从《孙子兵法》看底层的自然法则
我们作为架构师，需要做到对世界的认知可宏观、可微观。从对宏观的理解来说，背后所依赖的正是我们对这些底层自然法则的体悟。
-
答疑解惑 | 想当架构师，我需要成为“全才”吗？
架构在于创造，如果你总是重复别人，那有何价值？即使有所参考，也应该有自己的精气神，这个精气神是需要架构师把它干出来的。
-
用户故事 | 站在更高的视角看架构
学习没什么捷径，不存在什么一蹴而就的高超技术，要真的能稳得住啃那些基础，能沉下心坚持再坚持。
课程介绍
特别推荐 你将获得 许式伟首次完整架构经验分享 从0开始，构建信息世界全貌 常见业务场景的架构范式解读 9大必备架构思想精讲 讲师介绍 首席架构师口传心授，带你重新理解架构设计，一起成为信息世界的创造者。 课程介绍...特别推荐
你将获得
- 许式伟首次完整架构经验分享
- 从0开始，构建信息世界全貌
- 常见业务场景的架构范式解读
- 9大必备架构思想精讲
讲师介绍
首席架构师口传心授，带你重新理解架构设计，一起成为信息世界的创造者。
课程介绍
每一位程序员都有一颗成为架构师的心。
但是，很多人对于“架构”的理解，还停留在产品经理出需求，架构师依据产品设计给出实现，也就是所谓的架构设计方案这一阶段。
这一点恐怕是个误解。架构关乎整个工程，以及实现它的人，又因团队的能力而异。
同时，架构也关乎用户需求，作为架构师，我们不仅要知道当前用户的需求是什么，还要对需求未来可能出现的变化做出合理预判。
预判什么会发生，而什么一定不会发生。其中，后者更为重要，只有做到这一点，才能真正防止架构的过度设计，把简单的事情复杂化。
所以，想要成长为优秀的软件架构师，关键在于四个字：掌控全局。
掌控全局，就是要对系统的全貌了然于胸，在自己心中重新构建出整个世界。而不是一上来就沉浸在某个技术的实现细节中，除非它影响了你对这个世界构建过程的理解。
当你了解了世界的脉络和骨骼，你的感觉将完全不同，因为，你已经成为了世界的构建者。
而架构的本质，不正是构建和创造么？
这种透过层层代码的业务层级，窥见整个信息世界的来龙去脉的能力，才是架构师的终极能力。
我们现在所在包罗万象的信息世界，正是在最底层的冯·诺依曼的基础体系上搭建而成，我们熟知的架构，则是最上层的业务架构。
对于架构师来说，不只需要想清楚业务应该怎么做分解，实际上，整个应用从底层的操作系统、编程语言到顶层的业务架构，每一层都需要进行各种决策。
模块介绍
本课程从基础架构开始讲起，然后逐步过渡到业务架构，到最终完成一个完整应用程序的设计过程。这其中包括基础平台、桌面端平台、服务端开发、服务治理、架构思维、软件工程六大话题。
1.基础平台
如果把应用程序比作一座大厦，那大厦的架构师就需要把大厦的结构搭建好，让程序员可以把砖填充进去。而一个大厦的结构建得是否稳固，与其地基密不可分。基础平台模块就是介绍与应用程序相关的“地基”，这其中包括冯·诺依曼体系结构、操作系统、计算机体系结构等。
2.桌面端与服务端平台
对于架构师来说，不是只需要想清楚业务应该怎么做分解。实际上，整个应用从底层的操作系统、编程语言到顶层的业务架构，每一层都需要进行各种决策。这几个模块会开启全局视角，帮你理解桌面端应用和服务端应用体系结构以及核心逻辑。
3.架构思维
思维方式对于一个人来说至关重要，同样，具备架构思维也是让你脱颖而出的关键。这一模块将会介绍架构师必须掌握的架构思维方法论，每一个架构师都应该把这些架构思维内化为自己的基本功，比如架构和业务的关系、架构的边界、重构、接口设计的准则等等。
4.软件工程
架构师的关键目标是交付结果，所以架构师的着眼点一定不只是技术、业务这些内容，还应该包括团队协同、过程管理等等。这一模块将会重点介绍软件工程和架构的关系。
课程目录
特别放送
免费领取福利
限时活动推荐
