Xiaowu/20230214 (#766)
* update * update * update * update * Update 4.4 个人与团队的故事.md * Update 12.5 树形系统架构模式.md * Update 12.0 架构设计.md * update * Update 12.5 树形系统架构模式.md * update * update * update * Update 12.5 树形系统架构模式.md * update * Create 9.6 练习.md * Update 13.1 与架构相关的概念.md * update * update * Update 13.7 康威定律.md * update * update
This commit is contained in:
xiaowuhu
GitHub
Родитель
5c2e74baf7
Коммит
5f06420d59
|
|
@ -79,6 +79,7 @@
|
|||
|Milestone|里程碑|
|
||||
|Org (Orgnazation) | 微软内部划分的一个个大的组织，通常有上百人 |
|
||||
|Papera||
|
||||
|Pipeline||
|
||||
|PM（Program Manager）|微软的过程管理职位，过程经理或程序经理|
|
||||
|Power Platform||
|
||||
|Promotion||
|
||||
|
|
|
|||
|
|
@ -37,7 +37,9 @@ Nobody is an island. 没有人是一座孤岛。
|
|||
|
||||
图 3.1.2 沟通的最佳实践
|
||||
|
||||
#### 1. 表达深思熟虑后的观点
|
||||
#### 1. 基于观点的沟通
|
||||
|
||||
**（1）表达深思熟虑后的观点**
|
||||
|
||||
表达观点时，要有理有据（虽然不能保证合情合理），不能道听途说地只说个结论，没有推理过程或者解释说明。
|
||||
|
||||
|
|
@ -57,7 +59,7 @@ Nobody is an island. 没有人是一座孤岛。
|
|||
|
||||
乐队里有一位 C，自认为自己多弹了几年吉他，有一些演出经验，经常会长篇大论地写一些东西，搬出来一些不明觉厉的名词，最后总不忘加一句“这些都是我上学时就玩儿剩下的”。木头只好说：“大家看看老 C 的文字，观点完整、有理有据，请大家学习。” 确实，在“观点完整”上，C 确实做到了，但是**观点完整并不代表观点正确，有理有据并不代表合情合理。**
|
||||
|
||||
#### 2. 谨慎使用反问句
|
||||
**（2）谨慎使用反问句**
|
||||
|
||||
完整地表达观点，是一种成熟思考、具有知识体系的表现。微信的出现其实是为了普通大众服务的，往往是三言两语说完就走，因为不具备完整表达观点的能力。
|
||||
|
||||
|
|
@ -67,7 +69,7 @@ Nobody is an island. 没有人是一座孤岛。
|
|||
|
||||
但是，完整地表达观点经常会吃亏，因为言多必失，大概率会有漏洞。有些人就会抓住其中一个小漏洞，或者是一个语病、一个词汇来反驳。乐队里就有这么一个家伙，总是不好好说话，阴阳怪气的总用反问句，比如“这怎么会是性别问题？”、“你觉得这样做就是公平的吗？”，这些看似普通的反问句在上下文里的伤害极大，使得大家不能正常交流，最后被木头踢出了乐队群。
|
||||
|
||||
#### 3. 认清“角度”与“高度”
|
||||
**（3）观点的“角度”与“高度”**
|
||||
|
||||
在人类所在的三维空间中，当然会有“角度”的概念，同样是看一个巨大的物理实体，有的人只能看到它的左侧，有的人只能看到右侧。由此引申到对待一个问题的看法，不同的人会有不同的“角度”。但是，当有人和你沟通时用了“角度”这个词，尤其是领导，大概率是在说你的思考层次“高度”不够，而不是“角度”。为什么呢？
|
||||
|
||||
|
|
@ -77,9 +79,9 @@ Nobody is an island. 没有人是一座孤岛。
|
|||
|
||||
你自认为从 360 度观察到了事务的本质，但是领导却是从 720 度（包括上下两个维度）做了更多的思考。所以，说“角度不同”只是给你一个面子，其实是“高度”的差别。
|
||||
|
||||
#### 4. 基于事实的讨论，而非立场
|
||||
**（4）基于事实的讨论，而非立场**
|
||||
|
||||
先看三个概念：
|
||||
观点的形成是由三个概念决定的：利益$\rightarrow$立场$\rightarrow$行为。
|
||||
|
||||
- 利益：隐藏起来的真正的需求。
|
||||
|
||||
|
|
@ -89,6 +91,8 @@ Nobody is an island. 没有人是一座孤岛。
|
|||
|
||||
利益决定了立场，两个人具有共同利益时，就会很容易达成共识，形成相似的观点或态度。
|
||||
|
||||
立场也可以叫做观点，其细微差别是：立场尚未表现出来，而观点是已经通过下面所说的行为表现出来了。
|
||||
|
||||
- 行为：表达出来的具体形式。
|
||||
|
||||
行为可以是具体的动作，也可以是语言/言论。
|
||||
|
|
@ -97,7 +101,7 @@ Nobody is an island. 没有人是一座孤岛。
|
|||
|
||||
很典型的情况是，面对一个关键技术问题，两个人各持己见互不相让，其背后的原因很可能是采用了谁的建议，谁就会在 promotion 的路上向前迈进了一步。有个实际的例子，木头在 Windows 组时，常听到很远的隔壁的两个同事 A 和 B 因为在 Edge 浏览器上做银行插件时究竟应该采用哪种技术方案而进行讨论，A 是一个 Senior Dev，B 是一个 SDE II。后来 B 得到了 promotion 到了 Senior 级别，在邮件通告中的罗列的一条理由就是：B 在该项目上贡献突出，在技术方案的选择上与同组的一名 Senior 级别的员工竞争而胜出。
|
||||
|
||||
#### 5. 简洁不发散
|
||||
**（5）简洁不发散**
|
||||
|
||||
沟通时，每个观点完整是必须的，但是在其它方面要简洁，不要过于发散。
|
||||
|
||||
|
|
@ -105,7 +109,9 @@ Nobody is an island. 没有人是一座孤岛。
|
|||
|
||||
但是有一些人又过于简洁，茶壶煮饺子，心里有话但是倒不出来。笔者听说有个同事在 Machine Learning 上很有功底，就跑去请教，结果对方说了一些不是关键点的信息，听得云里雾里的。可能在对方看来，“有些基本的信息我都不用说你自然应该明白”，于是直接进入了细枝末节。
|
||||
|
||||
#### 6. 婉转表达否定
|
||||
#### 2. 注意沟通方式
|
||||
|
||||
**（1）婉转表达否定**
|
||||
|
||||
假设你和领导进行 1:1 的年终总结谈话，领导说：“你在这个项目里承担了一些重要的工作，技术能力很不错，但是在与同事进行技术讨论时，在说话技巧上还有一些进步的空间。”
|
||||
|
||||
|
|
@ -113,7 +119,7 @@ Nobody is an island. 没有人是一座孤岛。
|
|||
|
||||
在《星际迷航》电影里，经常会看到这样的对话：船长说“把动力系统全部移到船头形成能量保护网”，操作员可能会说“Negative（不行），我们需要至少10%的能量储备用于随时做光速跃迁逃逸。” 此时用 Positive/Negative 就会比较客观婉转，给船长留了面子。
|
||||
|
||||
#### 7. 注意语气语调
|
||||
**（2）注意语气语调**
|
||||
|
||||
俗话说“有理不在声高”。有些人说话的音量很大，像是在吵架；有些人语速特别快，通常需要听者在脑子里把话在重复一遍才能明白；还有些人语气比较强硬，不太会用词。
|
||||
|
||||
|
|
@ -123,13 +129,13 @@ Nobody is an island. 没有人是一座孤岛。
|
|||
2. 速度慢，还稍微有些结巴（当然这不是优点），不过反而能让人明白他在说什么。
|
||||
3. 不和别人争吵，有不同意见时，他表达完自己的观点后，如果对方不同意，他就会说“行，那再回去研究研究吧”，这样不管最终谁对谁错，都给双方留了余地。
|
||||
|
||||
#### 8. “一会儿回复您”
|
||||
**（3）及时回复**
|
||||
|
||||
如果需要较长时间的思考，也可以回复说“让我先想想，一会儿回复您”。
|
||||
|
||||
曾经有一位朋友（微软中国 ARD 的韦青老师）请笔者去给一个合资公司讲讲“微软的工程师文化”，因为笔者当时很忙，一时不能确定能不能讲好，或者是需要多长时间的准备，所以就在第一时间回复说“让我想想”。两个小时后，给予了对方肯定的答复，然后就在业余时间开始准备演讲内容（即本书中的内容），最后的演讲效果非常好，这才启发、激励笔者继续写完这本书，相信会得到很好的读者反馈。
|
||||
|
||||
#### 9. 面对面的讨论更加有效，慵懒的文字会产生误解
|
||||
**（4）面对面的讨论更加有效，慵懒的文字会产生误解**
|
||||
|
||||
以前在办公室里听到某人打字速度很快（而且还大胆地使用了机械键盘）时，就知道这个家伙一定在用电脑微信聊天，因为写代码的速度不可能那么快。现在面对疫情，大家都采用了线上办公，每天进行大量的文字交流。有的人文字表达能力非常差，而且懒，自己头脑中是有上下文信息的，但是不在文字中表达出来，往往造成对方误会。
|
||||
|
||||
|
|
@ -137,7 +143,7 @@ Nobody is an island. 没有人是一座孤岛。
|
|||
|
||||
还有一个特点是，一般的实习生在写字时都会带上一个“啊”字，比如：“是啊”、“我也不知道啊”、“就是那样啊”，听上去像吵架。因为“啊”字本身在说出来时是一个轻声的后缀，没有实际含义，但是写出来就变成了一个强调的重语气词，看上去很不舒服。
|
||||
|
||||
#### 10. 少用对抗思维，多用平行思维
|
||||
**（5）少用对抗思维，多用平行思维**
|
||||
|
||||
同事之间，如果没有上述的立场问题作怪，就尽量“先扬后抑”，或者“少抑多扬”。
|
||||
|
||||
|
|
@ -147,7 +153,9 @@ Nobody is an island. 没有人是一座孤岛。
|
|||
|
||||
这种技巧，是 B 先给了 A 一个较强的心理暗示：咱俩是一个阵营的。这样 A 就会表现出合作的态度。
|
||||
|
||||
#### 11. 说话不要绕弯子
|
||||
#### 3. 沟通的误区
|
||||
|
||||
**（1）说话不要绕弯子**
|
||||
|
||||
比如，有个同事建议：“快到年底了，美国那边要休圣诞节假期，所以我们不如等他们都休假回来后再一起讨论后续的安排。” 其实是这个同事的年假没用完，他想在 12 月底休两周的假，他不直说，却把美国人搬出来当挡箭牌。
|
||||
|
||||
|
|
@ -155,7 +163,7 @@ Nobody is an island. 没有人是一座孤岛。
|
|||
|
||||
这听上去就是很为演出效果考虑的感觉，但是春节后再开音乐会的话，排练不好安排，大家过完春节刚刚来上班，不论是观众和乐手，心气儿都差远了。木头看出来了是因为他们的乐手凑不齐才会提这个要求，所以拒绝了这个小队长的请求，说：“你如果缺乐手可以向别的乐队借，没必要把自己小乐队的困难绕个弯子转嫁到整个演出上。”
|
||||
|
||||
#### 12. 相同的话不要重复说
|
||||
**（2）相同的话不要重复说**
|
||||
|
||||
在工程师层面的沟通，不需要像在大街上聊天似的，为了增加亲密程度和聊天长度而说“车轱辘话”。车轱辘话出现的原因是：
|
||||
|
||||
|
|
@ -164,7 +172,7 @@ Nobody is an island. 没有人是一座孤岛。
|
|||
|
||||
一旦出现车轱辘话，在说者看来好像是强调了刚才的观点，但是在听者看来会得到两个结论：这个人固执；他没别的理由了。这与说者想达到的目的正好相反。
|
||||
|
||||
#### 13. 不要乱用“沉默”的权力
|
||||
**（3）不要乱用“沉默”的权力**
|
||||
|
||||
笔者在写本书的“用户与需求”部分时，曾经想要求一位以前共过事的 PM 一起写，就发了一封邀请邮件，但是却石沉大海。笔者也不好意思再追问，干脆自己写。笔者感到很不可思议的是，曾经和那位 PM 在项目最艰难的时刻共同努力，最终令项目得到了总部的认可，相当于一起“扛过枪、负过伤”的交情，为什么对方会沉默呢？
|
||||
|
||||
|
|
@ -172,7 +180,7 @@ Nobody is an island. 没有人是一座孤岛。
|
|||
|
||||
同样的问题经常发生在同事或朋友之间的微信通信上，有的时候甚至一句“新年快乐”发过去却得不到半点儿回音。对于笔者来说，当对对方的行为或言语极为反感时，才会采用“沉默”这种“极端”手段。比如，笔者的一个同学出家当尼姑了，想让笔者捐钱给她所在的寺庙，笔者是无神论者，所以选择了沉默。所以奉劝那些容易忘记回复消息的读者们，要真正地把对方放在心上，在方便的时候第一时间回复对方，这样对方才能把你也放在心上。
|
||||
|
||||
#### 14. 不抱怨结果，要分析原因
|
||||
**（4）不抱怨结果，要分析原因**
|
||||
|
||||
无效的沟通往往是从对糟糕的结果的抱怨开始的。
|
||||
|
||||
|
|
@ -180,7 +188,7 @@ Nobody is an island. 没有人是一座孤岛。
|
|||
|
||||
家长在家庭中处于强势地位，不太注重沟通的方式。但是一般的公司领导会很注意这些细节，在上面这种情况下一般会说：“这次项目结果不太理想，应该还可以做得更好，你有没有自己分析过是什么原因造成的呢？” 这样拉开话匣子，会让对方可以接受。
|
||||
|
||||
#### 15. 不挑战别人的决定，而是提出建设性意见
|
||||
**（5）不挑战别人的决定，而是提出建设性意见**
|
||||
|
||||
有一些对话经常会出现这个问题：“为什么这样做？”
|
||||
|
||||
|
|
|
|||
|
|
@ -67,6 +67,14 @@ A 人很好，总会安慰木头说“下次估计希望很大”，但下次 B
|
|||
|
||||
- 经过了这 4 年多的辗转，木头的积累又回到了零，在新的团队中必须重新积累才有可能获得 promotion。但是一个朋友告诉木头：“看上弯曲的路也许能通向更远的地方。” 确实，木头在 MSRA 自学了很多 ML/AI 相关的知识，对以后的 career path 有很大的帮助。
|
||||
|
||||
- 如何决定应该离开一个团队？有三点可以参考：
|
||||
1. 是否有成就感？
|
||||
2. 是否收入与付出成比例？
|
||||
3. 人际关系如何？
|
||||
|
||||
如果这三点中有两点是否定的答案的话，立刻拍屁股走人；如果只有一点不满足，那就尝试着适应一下，或者改变自己的心理预期。
|
||||
|
||||
|
||||
### 4.4.2 个人在团队中如何做
|
||||
|
||||
<img src="img/Slide11.SVG"/>
|
||||
|
|
@ -161,26 +169,26 @@ A 人很好，总会安慰木头说“下次估计希望很大”，但下次 B
|
|||
|
||||
图 4.4.2 乐队就是典型的团队合作
|
||||
|
||||
乐队里有个民乐组，组长 M 是一位女生，琵琶弹得非常好。有一天，M 忽然说她不继续带队了，还出了一个视频，内容是《这两年我在微软乐队做了什么》，讲得很好，分析了民乐和流行乐的区别，以及自己为什么不再继续带队的原因。木头总结如下：
|
||||
乐队里有个民乐组，组长 D 是一位女生，琵琶弹得非常好。有一天，D 忽然说她不继续带队了，还出了一个视频，内容是《这两年我在微软乐队做了什么》，讲得很好，分析了民乐和流行乐的区别，以及自己为什么不再继续带队的原因。木头总结如下：
|
||||
|
||||
1. 为什么不继续带队了
|
||||
|
||||
M 第一年编了一个《十面埋伏》，叫做武曲；第二年编了一个《春江花月夜》，叫做文曲。非常有代表性。后来又参与了《元神》的创作和演出，以及其它几支民乐曲目。她认为该玩儿的项目都玩儿遍了，可以离开游乐场了。可惜的是民乐组没有人原意站出来接班当组长的。
|
||||
D 第一年编了一个《十面埋伏》，叫做“武曲”；第二年编了一个《春江花月夜》，叫做“文曲”。非常有代表性。后来又参与了《元神》的创作和演出，以及其它几支民乐曲目。她认为该玩儿的项目都玩儿遍了，可以离开游乐场了。可惜的是民乐组没有人原意站出来接班当组长的。
|
||||
|
||||
还曾经有一次木头问 M：“为何上次那个曲目不拿出来在另一个场合（不同的听众）再演一回？挺好听的。” M 回答说：“演过一遍的曲目我就不想再演了。” 木头就明白了：她演出是为了纯娱乐，自己高兴就行，不考虑观众。这在微软乐队这种非商业化的民间组织中是可以理解的。
|
||||
还曾经有一次木头问 D：“为何上次那个曲目不拿出来在另一个场合（不同的听众）再演一回？挺好听的。” D 回答说：“演过一遍的曲目我就不想再演了。” 木头就明白了：她演出是为了纯娱乐，自己高兴就行，不考虑观众。这在微软乐队这种非商业化的民间组织中是可以理解的。
|
||||
|
||||
2. 民乐和流行乐的区别
|
||||
|
||||
M 从小练琵琶，据说老师也很有名。琵琶独奏，讲究得是演奏者的自我情感表达，忽快忽慢，所以谈不上固定的节奏。在《十面埋伏》中，为了增强效果而配了鼓手，但是鼓手是要看琵琶的手部动作来打鼓，这与鼓手在流行乐队中的统治地位恰巧相反。
|
||||
D 从小练琵琶，据说老师也很有名。琵琶独奏，讲究得是演奏者的自我情感表达，忽快忽慢，所以谈不上固定的节奏。在《十面埋伏》中，为了增强效果而配了鼓手，但是鼓手是要看琵琶的手部动作来打鼓，这与鼓手在流行乐队中的统治地位恰巧相反。
|
||||
|
||||
流行乐中的旋律、和声（准确地说和弦）、节奏、音色，到了 M 这里就只剩下了旋律，因为琵琶和吉他一样，可以自带和声（当然 M 认为那是旋律的一部分）；节奏自己掌握，不需要跟着其它乐器跑；音色更没得说了，只有琵琶的声音才是好的。
|
||||
流行乐中的旋律、和声（准确地说和弦）、节奏、音色，到了 D 这里就只剩下了旋律，因为琵琶和吉他一样，可以自带和声（当然 D 认为那是旋律的一部分）；节奏自己掌握，不需要跟着其它乐器跑；音色更没得说了，只有琵琶的声音才是好的。
|
||||
|
||||
M 认为：在琵琶与流行乐的配合中，琵琶与歌手不能同时发声，否则就二者冲突了，所以琵琶不能是 C 位，那也就找不到自己的位置了。而且一旦要跟随节奏与其它乐器合奏时，琵琶就丧失了其自由性，而只是展示乐手的专业性了，毫无乐趣。
|
||||
D 认为：在琵琶与流行乐的配合中，琵琶与歌手不能同时发声，否则就二者冲突了，所以琵琶不能是 C 位，那也就找不到自己的位置了。而且一旦要跟随节奏与其它乐器合奏时，琵琶就丧失了其自由性，而只是展示乐手的专业性了，毫无乐趣。
|
||||
|
||||
|
||||
可以总结为：
|
||||
|
||||
1. M 认为所有的民乐风格都玩儿了一遍，够了；
|
||||
1. D 认为所有的民乐风格都玩儿了一遍，够了；
|
||||
2. 演出是为了自己高兴，与听众无关，所以不愿意重复；
|
||||
3. 玩儿琵琶玩儿独了，不愿意受多人合作时的节奏限制；
|
||||
4. 不能接受自己不在 C 位的待遇，所以感觉无法和流行乐合作。
|
||||
|
|
|
|||
|
|
@ -169,19 +169,24 @@ Qlib - Quantitative Library 量化交易平台。命名为一个 Library，意
|
|||
|
||||
图 5.3.3 研究员与工程师对软件系统的不同理解
|
||||
|
||||
#### 目标不同
|
||||
#### 1. 目标不同
|
||||
|
||||
在强化学习项目中，研究员的目标是做一个能让大家使用的做多智能体强化学习研究的平台，但是它的泛化能力太差，以至于无人问津。而工程师在这个项目中处于辅助位置，在领域知识上处于劣势，基本上要听从研究员的安排。这种项目，成功的概率很小。
|
||||
|
||||
在量化交易项目中，研究员的目标是让工程师使用 Qlib，而工程师的目标是要切实完成用户的需求。如果使用 Qlib 的过程遇到什么问题而不能完成需求，那么要承担责任的是工程师，而不是研究员。况且学习 Qlib 还需要时间，而距离下一次模型切换只有 60 个交易日。
|
||||
|
||||
#### 背景不同
|
||||
#### 2. 背景不同
|
||||
|
||||
在量化交易项目中，第一次开会时，研究员提出了上述任务，要求两个工程师 + 两个实习生来完成这些任务。木头心里估算了任务量后，当时就提出：你们的资源要少了！第一，我们工程师和你们研究员不一样，research 领域中主要是实习生写 code，而工程领域中实习生是不能写 production code 的。第二，这些任务的实际工程工作量远超出你们的想象，两个人是不可能完成的，至少需要五个人。
|
||||
在量化交易项目中，第一次开会时，研究员提出了上述任务，要求两个工程师 + 两个实习生来完成这些任务。木头心里估算了任务量后，当时就提出：你们的资源要少了！
|
||||
|
||||
- 第一，我们工程师和你们研究员不一样，研究领域中主要是实习生写代码，研究员出主意；，而工程领域中实习生是不能写产品代码的，但可以写原型代码。
|
||||
- 第二，这些任务的实际工程工作量远超出你们的想象，两个人是不可能完成的，至少需要五个人。
|
||||
|
||||
研究员什么时候有能力估算工程师的工作量了？
|
||||
|
||||
#### 做法不同
|
||||
而且，研究员还会用一些不知道哪里听来的词汇和工程师交流。比如，Qlib 的研究员想让工程师使用 Qlib 框架来为某基金公司的线上产品服务，研究员是这么说的：“这个任务很简单，就是把线上的那套东西和 Qlib 的接口对齐。” 木头当时就一愣，什么叫做“接口对齐”？按工程师的术语应该是：适配 Qlib 框架。而且这不是一件“很简单”的事情，至少是几人月的工作量。
|
||||
|
||||
#### 3. 做法不同
|
||||
|
||||
在量化交易项目中，用户买了 100 万的 Azure 订阅，用于训练模型。但是以前的研究员并没有充分使用，而是使用公司内部的 GPU 平台来训练模型。导致用户认为根本不需要购买很多的订阅额。
|
||||
|
||||
|
|
@ -191,7 +196,7 @@ Qlib - Quantitative Library 量化交易平台。命名为一个 Library，意
|
|||
|
||||
木头在工程化过程中，专门指派了一个 dev 复制了这台计算机，包括环境和代码，然后在副本计算机上做各种探索，终于搞清楚了每一步的输入输出和整个流程，让黑盒变成了白盒，为后期使用 Qlib 成为可能。
|
||||
|
||||
#### 最佳实践
|
||||
#### 【最佳实践】
|
||||
|
||||
- 如果是一个项目处于刚开始的研究阶段，研究员和工程师需要积极配合，研究员是 R 的角色（负责），工程师是 S 的角色（支持），以研究为导向。
|
||||
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
## 6.1 木头与 MSN 的故事
|
||||
|
||||
其实木头与 MSN 的陨落没有什么直接关系，只是恰巧亲眼目睹而已。下面的这些真实历史事件$^{[1]}$，可以让大家清醒地看到，无论软件公司或软件产品有多么的牛，不符合用户需求的话，仍然会失败，即使它曾经成功过。以此为鉴，让读者充分认识软件产品的需求挖掘与分析。
|
||||
其实木头与 MSN 的陨落没有什么直接关系，只是恰巧亲眼目睹而已。下面的这些真实历史事件$^{[1]}$，可以让大家清醒地看到，无论软件公司或软件产品有多么的牛，不符合用户需求的话，最终仍然会失败，即使它曾经成功过。以此为鉴，让读者充分认识到软件产品的需求挖掘与分析是多么的重要。
|
||||
|
||||
我们先给读者一个时间线，如图 6.1.1 所示，可以在后面的阅读时大概计算一下各个阶段所经历的时长。
|
||||
我们先给读者一个时间线，如图 6.1.1 所示，可以在后面阅读时大概计算一下各个阶段所经历的时长。
|
||||
|
||||
<img src="img/Slide3.JPG"/>
|
||||
|
||||
|
|
@ -10,23 +10,23 @@
|
|||
|
||||
### 6.1.1 上线
|
||||
|
||||
二十世纪的最后几年发生了很多事，其中移动通信和互联网的崛起，让整个世界收获了第三次工业革命的硕果。
|
||||
二十世纪的最后几年发生了很多事，其中移动通信和互联网的崛起，让整个世界经历了第三次工业革命。
|
||||
|
||||
互联网的兴起是在1998年的前后5年内，在那之前，木头想找朋友聊天的话，只能通过电话或者寻呼：
|
||||
互联网的兴起是在 1998 年的前后 5 年内，在那之前，木头想找朋友聊天的话，只能通过电话或者寻呼：
|
||||
|
||||
- 电话是指固定电话，那时移动电话还非常贵，只有大老板才能消费得起，俗称大哥大。很多电影里还能看到这样的场景：一个粗脖子男人带着小手指般粗的金项链，手里捧着一个黑色带天线的大砖头喊话。
|
||||
- 电话是指固定电话，那时移动电话还非常贵，只有大老板才能消费得起，俗称大哥大。很多电影里还能看到这样的场景：一个粗脖子男人带着小手指般粗的金项链，手里捧着一个黑色带天线的大砖头粗鲁地喊话。
|
||||
|
||||
- 寻呼机（Pager）是人们带在身上的一种电子设备，单向接收无线信号。有人想找木头，就给寻呼台打电话：“你好！请呼叫9048，让机主回电话到59175433”。
|
||||
- 寻呼机（Pager）是人们带在身上的一种电子设备，单向接收无线信号。有人想找木头，就给寻呼台打电话：“你好！请呼叫 9048，让机主回电话到 59175120”。
|
||||
|
||||
在IM（Instant Messaging，即时通信）领域，发生了几件大事：
|
||||
与此同时，在 IM（Instant Messaging，即时通信）领域，发生了几件大事：
|
||||
|
||||
1. ICQ（I seek you 的谐音，我找你）是整个互联网聊天工具的鼻祖，是三个以色列人在1996年推出的一个软件，即在互联网上可以随时随地找到你。
|
||||
|
||||
2. 1998年，AOL（American Online，美国在线）收购了ICQ。1999年，AOL推出了他们收购ICQ后的第一个版本：ICQ 99a，准备让自己原本就排名全美第一的网上寻呼业务来一把“烈火烹油”。
|
||||
2. 1998年，AOL（American Online，美国在线）收购了ICQ。1999年，AOL 推出了他们收购 ICQ 后的第一个版本：ICQ 99a，准备让自己原本就排名全美第一的网上寻呼业务来一把“烈火烹油”。
|
||||
|
||||
3. 同年，马化腾在深圳科技园一个小厂房里，模仿 ICQ 推出了一款中文的即时通讯工具，取名 OICQ（Opening ICQ，开放的ICQ），后来由于和 ICQ 有同名嫌疑，与AOL的官司败诉，改名为 QQ。
|
||||
3. 同年，马化腾在深圳科技园一个小厂房里，模仿 ICQ 推出了一款中文的即时通讯工具，取名 OICQ（Opening ICQ，开放的ICQ），后来由于和 ICQ 有同名嫌疑，与 AOL 的官司败诉，改名为 QQ。
|
||||
|
||||
4. 同年7月日，微软公司（Microsoft）正式上线了 MSN Messenger，在它服务开通的6天内，就获得了70万注册用户。
|
||||
4. 同年 7 月日，微软公司（Microsoft）正式上线了 MSN Messenger，在它服务开通的 6 天内，就获得了 70 万注册用户。
|
||||
|
||||
5. 木头开始使用 MSN，并对微软产生了强烈的好奇心。
|
||||
|
||||
|
|
@ -34,13 +34,13 @@
|
|||
|
||||
MSN 与 QQ 的用户增长的对比：
|
||||
|
||||
- 到了2000年7月17日的时候，微软方面宣布，MSN已经拥有了2.1亿独立用户，成为了全世界排名第一的网站，而借这股东风，2001年3月16日，MSN Messenger 在全世界范围内拥有了3000万在线用户。
|
||||
- 到了 2000 年 7 月 17 日的时候，微软方面宣布，MSN已经拥有了 2.1 亿独立用户，成为了全世界排名第一的网站，而借这股东风，2001 年 3 月 16 日，MSN Messenger 在全世界范围内拥有了 3000 万在线用户。
|
||||
|
||||
- QQ 上线后，花了整整9个月的时间，到1999年11月，注册用户数才达到6万。
|
||||
- QQ 上线后，花了整整 9 个月的时间，到 1999 年 11 月，注册用户数才达到 6 万。
|
||||
|
||||
MSN 与 QQ 的用户构成对比：
|
||||
|
||||
- 在当时拥有 qq.com 邮箱，会在招聘会上或面试中（尤其是外企或500强企业），被面试官认为没有眼界。
|
||||
- 在当时拥有 qq.com 邮箱，在招聘会上或面试中（尤其是外企或 500 强企业），会被面试官认为没有眼界。
|
||||
|
||||
- 而如果你留的是“xxx@hotmail.com”，至少证明了你是追随互联网潮流的。木头就是那时申请的 hotmail.com 邮箱，而且一直使用到现在。
|
||||
|
||||
|
|
@ -81,7 +81,7 @@ MSN Messenger 身上各种毛病，也都找到了根源：
|
|||
|
||||
### 6.1.5 沉沦
|
||||
|
||||
2007年末，MSN Messenger 在中国的各项数据开始掉头向下。除了 MSN 本身臃肿和效率低下的决策体系之外，外部的竞争环境也开始发生了巨大的变化：
|
||||
2007 年末，MSN Messenger 在中国的各项数据开始掉头向下。除了 MSN 本身臃肿和效率低下的决策体系之外，外部的竞争环境也开始发生了巨大的变化：
|
||||
|
||||
- 从国际方面来看，Google、Facebook、Twitter 等巨头迅速崛起，“同步聊天”的人群渐渐被分流到了“异步聊天”乃至互联网社区；
|
||||
|
||||
|
|
@ -91,13 +91,13 @@ MSN Messenger 身上各种毛病，也都找到了根源：
|
|||
|
||||
在国际和国内各种力量的夹击之下，原本就已经反应迟钝，船大难调头的 MSN 不可避免地开始沉沦。
|
||||
|
||||
到了2012年， MSN Messenger 在中国的用户数跌到了4500万，而与之相比的是，QQ 的用户数超过了6亿。
|
||||
到了 2012 年， MSN Messenger 在中国的用户数跌到了 4500 万，而与之相比的是，QQ 的用户数超过了 6 亿。
|
||||
|
||||
### 6.1.6 隐退
|
||||
|
||||
2013年3月15日，微软正式宣布：关闭全球范围内 MSN，除了中国。这个时候，中国市场反而成了MSN仅剩的独苗。
|
||||
2013 年 3 月 15 日，微软正式宣布：关闭全球范围内 MSN，除了中国。这个时候，中国市场反而成了MSN仅剩的独苗。
|
||||
|
||||
但是，“独苗”也不能存活多久。2014年8月28日，每一个中国 MSN Messenger 的用户收到了来自微软的一封邮件：中国的 MSN Messenger 将于 2014 年 10 月 31 日正式关闭，所有人可以转向早先微软收购的 Skype。
|
||||
但是，“独苗”也不能存活多久。2014 年 8 月 28 日，每一个中国 MSN Messenger 的用户收到了来自微软的一封邮件：中国的 MSN Messenger 将于 2014 年 10 月 31 日正式关闭，所有人可以转向早先微软收购的 Skype。
|
||||
|
||||
木头当时还郁闷了一阵，因为不用 QQ，MSN 又关闭了，没法通信了。用了一阵 Skype，没有熟人，但是在微软内部通信还是可以的。所以就变成了工作时用 Skype，下班后用微信。
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
## 6.2 故事分析-用户与需求
|
||||
## 6.2 故事分析-需求的重要性
|
||||
|
||||
|
||||
<img src="img/Slide4.JPG"/>
|
||||
|
|
@ -96,4 +96,4 @@ MSN 的崛起，是缘于当时国内对外企潮流的跟随行为。但是国
|
|||
|
||||
而国内的软件公司却对用户需求把握得非常到位，尤其是一些大体量的应用，以已经具有觉得的优势，但仍然努力变得更好。以微信为例，作为一个月活已经超过10亿的即时通讯工具，微信还在努力地进行变化，时不常地推出一些新功能，比如为了抗衡抖音而发布的视频号功能，在新冠疫情期间突飞猛进。
|
||||
|
||||
在这个充满变化的时代，唯变不变，拥抱变化、快速更新，是软件从业者唯一的选择。
|
||||
在这个充满变化的时代，唯变不变，拥抱变化、快速更新，**跟踪并尊重用户需求**，是软件从业者唯一的选择。
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
## 6.3 木头与需求调研的故事
|
||||
## 6.3 需求调研的故事
|
||||
|
||||
### 6.3.1 需求调研方法
|
||||
|
||||
|
|
@ -95,9 +95,9 @@ MSRA 有很多的实习生，招聘、管理实习生是一个很重要的工作
|
|||
|
||||
### 6.3.3 访谈法
|
||||
|
||||
微软在北京中关村有两座大厦，南北相望，南侧的是1号楼，北侧的是2号楼。每个楼都有12部电梯，位于大堂东西两侧，各6部。
|
||||
微软在北京中关村有两座大厦，南北相望，南侧的是 1 号楼，北侧的是 2 号楼。每个楼都有 12 部电梯，位于大堂东西两侧，各 6 部。
|
||||
|
||||
出于部门安排的一些考虑，1号楼的电梯是分层配置的，1-10层乘坐东侧电梯，11-17层乘坐西侧电梯。而2号楼的电梯就是普通的配置，即可以达到任意楼层。
|
||||
出于部门安排的一些考虑，1号楼的电梯是分层配置的，1-10 层乘坐东侧电梯，11-17 层乘坐西侧电梯。而2号楼的电梯就是普通的配置，即可以达到任意楼层。
|
||||
|
||||
木头在2号楼工作，感觉平时乘坐电梯时有个痛点：
|
||||
|
||||
|
|
@ -105,11 +105,11 @@ MSRA 有很多的实习生，招聘、管理实习生是一个很重要的工作
|
|||
|
||||
木头想：应该有“满员”运行的策略呀？于是木头找到了电梯公司的人，进行了面对面的深入访谈。
|
||||
|
||||
经了解，电梯的满载质量是1350千克，18人满员，这是按平均每人75公斤计算的。但是，电梯又不是城铁，里面的人不会挤得满满的。为了保证舒适度，木头建议10~12人就算做满员，也就是900公斤左右。
|
||||
经了解，电梯的满载质量是 1350 千克，18 人满员，这是按平均每人 75 公斤计算的。但是，电梯又不是城铁，里面的人不会挤得满满的。为了保证舒适度，木头建议 10~12 人就算做满员，也就是 900 公斤左右。
|
||||
|
||||
原本以为就是一个软件设置问题，没想到电梯公司的人这样答复：
|
||||
|
||||
1. 降低到900公斤，需要减少电梯的配重块重量。
|
||||
1. 降低到 900 公斤，需要减少电梯的配重块重量。
|
||||
|
||||
*注：为了让电梯平稳运行，电梯轿厢和配重块是悬挂在一个定滑轮的两侧的，当两侧的重量越接近时，电梯就运行得越平稳，不会忽悠忽悠的。*
|
||||
|
||||
|
|
@ -123,7 +123,7 @@ MSRA 有很多的实习生，招聘、管理实习生是一个很重要的工作
|
|||
|
||||
木头听完后也傻了，原来这是一个工程问题，而不是简单地动动鼠标把1350改成900就行！
|
||||
|
||||
木头的另外一个痛点是，早晨上班时乘坐电梯，电梯里6个人，其它5个人分别在6、7、8、9、10层下了电梯，木头在11层，只能目送同志们一个一个下了电梯，本来10秒能到达11层，现在变成了30秒，因为电梯的启动和停止需要很长的缓冲时间，同时也会更费电，增加开关门的损耗。
|
||||
木头的另外一个痛点是，早晨上班时乘坐电梯，电梯里 6 个人，其它 5 个人分别在 6、7、8、9、10 层下了电梯，木头在 11 层，只能目送同志们一个一个下了电梯，本来 10 秒能到达 11 层，现在变成了 30 秒，因为电梯的启动和停止需要很长的缓冲时间，同时也会更费电，增加开关门的损耗。
|
||||
|
||||
木头的实习生毛毛提出：如果在大堂里放一个楼层选择器，在同一时间段内相同楼层的人就会被分配到同一部电梯；并且，调度系统会知道一共有几个人等候，就会放下足够的电梯数到一层。
|
||||
|
||||
|
|
@ -133,7 +133,7 @@ MSRA 有很多的实习生，招聘、管理实习生是一个很重要的工作
|
|||
|
||||
负责楼宇管理的大哥急了：“那赶紧给我装上呀！”
|
||||
|
||||
电梯公司：“这个系统需要100万人民币。”
|
||||
电梯公司：“这个系统需要 100 万人民币。”
|
||||
|
||||
大哥：“......这个投入太大了......”
|
||||
|
||||
|
|
@ -164,13 +164,13 @@ MSRA 有很多的实习生，招聘、管理实习生是一个很重要的工作
|
|||
图 6.3.2 - 调查问卷的样式
|
||||
|
||||
|
||||
- 问题1：一共10颗星代表满意度，用户选择了满意度为7颗星，那么前7颗星高亮。
|
||||
- 问题1：一共 10 颗星代表满意度，用户选择了满意度为7颗星，那么前7颗星高亮。
|
||||
- 问题2：是一个单项选择。
|
||||
- 问题3，4：略。
|
||||
- 问题5：类似满意度，但是选择7后，7会高亮，其它不变。
|
||||
- 问题5：类似满意度，但是选择 7 后，7 会高亮，其它不变。
|
||||
- 问题6：用户自由填写文字。
|
||||
|
||||
用户提交后，后台会自动统计所有问卷结果，对于纯文本型的回答，如问题6，还可以有 NLP 模型进行语义、情感分析。
|
||||
用户提交后，后台会自动统计所有问卷结果，对于纯文本型的回答，如问题 6，还可以有 NLP 模型进行语义、情感分析。
|
||||
|
||||
### 6.3.5 A/B测试法
|
||||
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
## 6.4 木头与研究员的故事
|
||||
## 6.4 研究员的故事
|
||||
|
||||
7月份到了，微软一年一度的 Hackathon（黑客马拉松）又要开始了！虽然前几年做的项目一个奖都没拿到，但是木头还是跃跃欲试地琢磨今年要做什么有趣的项目了。
|
||||
7 月份到了，微软一年一度的 Hackathon（黑客马拉松）又要开始了！虽然前几年做的项目一个奖都没拿到，但是木头还是跃跃欲试地琢磨今年要做什么有趣的项目了。
|
||||
|
||||
MSRA 的研究员很多，木头经常看到有人打印了一些已经发表的论文在纸上，边阅读边用笔在上面写写画画做标记。在很多情况下，写一篇论文要阅读十几篇论文。研究员们是如何做这些论文管理的呢？能否做一个工具帮助到大家呢？
|
||||
|
||||
|
|
@ -52,7 +52,7 @@ MSRA 的研究员很多，木头经常看到有人打印了一些已经发表的
|
|||
|
||||
### 6.4.3 研究员小雨
|
||||
|
||||
小雨，上海人，五官小巧，说话声音很好听。兼顾的项目很多，所以经常会丢三落四，有时候也会因为早晨找不到袜子而穿凉鞋出门，但仍然从骨子里透出一股优雅的气质。
|
||||
小雨，江浙人，五官小巧，说话声音很好听。兼顾的项目很多，所以经常会丢三落四，有时候也会因为早晨找不到袜子而穿凉鞋出门，但仍然从骨子里透出一股优雅的气质。
|
||||
|
||||
木头：我要做个阅读论文的辅助工具，你希望做成什么样子？
|
||||
|
||||
|
|
@ -96,7 +96,7 @@ MSRA 的研究员很多，木头经常看到有人打印了一些已经发表的
|
|||
|
||||
### 6.4.5 主管级研究员张大姐
|
||||
|
||||
张大姐是老炮儿了，在机器学习领域十多年耕耘，硕果累累，如今带了十几个研究员工作。张大姐语速超快，木头只得全神贯注地倾听，不敢落下节奏，否则就跟不上了。
|
||||
张大姐是老炮儿了，在机器学习领域十多年耕耘，硕果累累，如今带了五十几个研究员工作。张大姐语速超快，木头只得全神贯注地倾听，不敢落下节奏，否则就跟不上了。
|
||||
|
||||
木头：张大姐，我想做一个读论文的辅助工具，您阅“文”无数，是否可以提供一些经验技巧，能分享给大家的？
|
||||
|
||||
|
|
@ -120,7 +120,7 @@ MSRA 的研究员很多，木头经常看到有人打印了一些已经发表的
|
|||
|
||||
### 6.4.6 大佬沈向洋
|
||||
|
||||
最不可思议的是，木头还得到了和大佬 Harry Shum（沈向洋）1:1（读做one on one，二人面对面谈话）的机会。
|
||||
最不可思议的是，木头还得到了和大佬 Harry Shum（沈向洋）1:1（读做 one on one，二人面对面谈话）的机会。
|
||||
|
||||
Harry：“听说你要做个工具，很好呀！先说几点自己读论文的现状吧：
|
||||
|
||||
|
|
@ -19,14 +19,14 @@ Persona 用户画像，古希腊罗马戏剧中的面具。
|
|||
图 6.5.1 示意性地展示了用户画像的概念，比如：
|
||||
|
||||
- 第一个人像旅行者；
|
||||
- 第二、三两个人看上去像是老师；
|
||||
- 第二个人像职员；
|
||||
- 第三个人看上去像是老师；
|
||||
- 第四个人像是运动员；
|
||||
- 第五个人是年轻都市青年；
|
||||
- 第六个人像家庭主妇。
|
||||
- 第五、六个人是年轻都市青年。
|
||||
|
||||
我们知道了用户群的分类，才能有针对性地为不同群体提供不同的功能。
|
||||
|
||||
在用户界面设计领域，Alan Cooper 提出来的一种通过调研和问卷获得的典型用户模型，用于产品需求挖掘与交互设计的方法。把这个词分解为7个单词的词头，如图 6.5.2 所示，虽然略为勉强，但也起到了帮助人们记忆的作用$^{[6]}$。
|
||||
在用户界面设计领域，Alan Cooper 提出来的一种通过调研和问卷获得的典型用户模型，用于产品需求挖掘与交互设计的方法。把这个词分解为 7 个单词的词头，如图 6.5.2 所示，虽然略为勉强，但也起到了帮助人们记忆的作用$^{[6]}$。
|
||||
|
||||
|
||||
<img src="img/Slide10.JPG"/>
|
||||
|
|
@ -79,7 +79,7 @@ Persona 用户画像，古希腊罗马戏剧中的面具。
|
|||
图 6.5.3 - 研究员的用户画像
|
||||
|
||||
|
||||
对比一下图 5.4.1 和图 6.5.3，可以看到后者的一些变化：
|
||||
对比一下图 6.4.1 和图 6.5.3，可以看到后者的一些变化：
|
||||
|
||||
1. 形象地用一个卡通头像来表示用户；
|
||||
2. 给出了该类用户的分类名称；
|
||||
|
|
@ -87,7 +87,7 @@ Persona 用户画像，古希腊罗马戏剧中的面具。
|
|||
|
||||
下面具体分析一下各类用户的需求差别。
|
||||
|
||||
### 工程师军儿哥
|
||||
#### 0. 工程师军儿哥
|
||||
|
||||
军儿哥根本不是我们这个软件的使用对象，所以就不要费力气了，和他聊聊天气就可以了。
|
||||
|
||||
|
|
@ -95,7 +95,7 @@ Persona 用户画像，古希腊罗马戏剧中的面具。
|
|||
|
||||
所以，对于软件设计者来说，在照顾到已有用户的同时，不要放弃对“局外人”的吸纳，因为其潜力巨大。
|
||||
|
||||
### 实习生小皮
|
||||
#### 1. 实习生小皮
|
||||
|
||||
小皮的关注点在：
|
||||
|
||||
|
|
@ -111,7 +111,7 @@ Persona 用户画像，古希腊罗马戏剧中的面具。
|
|||
2. 观察这个图中的引用路径，看看它们是不是会追溯到一个或几个原始论文（即所谓的开山之作）；
|
||||
3. 建议小皮先阅读原始论文，再根据需要阅读“二代”论文，这样会非常有条理，学习路径清晰。
|
||||
|
||||
### 研究员小雨
|
||||
#### 2. 研究员小雨
|
||||
|
||||
小雨的关注点在于：
|
||||
|
||||
|
|
@ -123,7 +123,7 @@ Persona 用户画像，古希腊罗马戏剧中的面具。
|
|||
|
||||
多页阅读模式是一个很好的建议。想象一下我们平时读纸质书时，由于书有厚度，我们知道自己读了多少，还有多少没读；而且我们在读左侧时，右侧的书页会给人一种莫名其妙的“安全感”。所以，在计算机上，虽然没有厚度的概念，但是左右页的排版方式会是一种很好的“用户体验”。
|
||||
|
||||
### 高级研究员大陈
|
||||
#### 3. 高级研究员大陈
|
||||
|
||||
大陈的关注点是：
|
||||
|
||||
|
|
@ -133,7 +133,7 @@ Persona 用户画像，古希腊罗马戏剧中的面具。
|
|||
|
||||
大陈的主要目标是利用工具的帮助把个人的能力发挥到极致，同时，上升到了一定的层次，也开始关注交流问题了。但是大陈的需求并不会与小雨的需求产生矛盾，而是一种递进的关系。
|
||||
|
||||
### 主管级研究员老张
|
||||
#### 4. 主管级研究员老张
|
||||
|
||||
张老师的关注点是：
|
||||
|
||||
|
|
@ -143,7 +143,7 @@ Persona 用户画像，古希腊罗马戏剧中的面具。
|
|||
|
||||
张老师更多地关注团队的成长、合作、效率等问题，所以会从这方面给与建议。
|
||||
|
||||
### 大佬沈向洋
|
||||
#### 5. 大佬沈向洋
|
||||
|
||||
Harry 大佬的关注点是：
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,51 @@
|
|||
## 6.6 AI 课堂教学的故事
|
||||
|
||||
从上一节的内容我们知道，典型用户是需要应用场景故事来具体描述的，这一节我们就举例说明什么是应用场景故事。
|
||||
|
||||
人物：
|
||||
- 毛毛作为一个大三的学生，正在学习深度学习的相关知识。
|
||||
- 木头是一名老师，讲授神经网络基本原理课程。
|
||||
|
||||
|
||||
<img src="img/Slide12.JPG"/>
|
||||
|
||||
图 6.6.1 - 真实的 AI 教学场景
|
||||
|
||||
|
||||
图 6.6.1 展示了微软在上海仪电做的真实的 AI 教学场景。
|
||||
|
||||
### 6.6.1 老师和学生预习的场景
|
||||
|
||||
2020/10/13 晚。
|
||||
|
||||
毛毛已经上了 10 节关于神经网络入门的课程，明天该进入卷积网络的学习了。
|
||||
|
||||
在前面的深度学习基础中，循序渐进的课程设置，让毛毛感觉学习起来很轻松，似乎学习曲线没有那么陡峭。而示例代码和课后作业，由于代码的高度优化，他用自己的笔记本完全可以跑起来，很快地就跑出了实验数据。他打开了课程网站，用自己的学号和密码登录后，进入提交作业的页面，填写了自己的实验数据，点击“提交”按钮，看到“提交成功”的信息后，毛毛猜想着自己的作业成绩，会不会像以往那样名列前茅。
|
||||
|
||||
果真，一会儿毛毛的微信收到了作业系统通知消息，自动评分系统已经统计了全班同学的作业成绩，由于毛毛的模型预测数据的准确率为 98.1%，名列第二名，仅比第一名低 0.1 个百分点。毛毛不满意地摇摇头，暗下决心一定要在卷积网络这一部分的成绩超过那个名叫金二的但总得第一的家伙。
|
||||
|
||||
毛毛想预习一下卷积网络的知识，打开了课件。看了 20 分钟后，毛毛的觉得很沮丧，什么单入单核，多入单核，单入多核，多入多核……一大堆卷积类型，越看越晕。算了，明天上课好好听木头老师讲吧。
|
||||
|
||||
而木头老师此时也还没有休息，他先浏览了一下全班同学的作业成绩，在讨论区里回答了几个问题后，调出卷积神经网络的PPT课件，开始备课。在PPT 的 note 中标记了几处需要重点说明的环节后，Office 365 已经替他把文档自动保存到服务器上，这样其它老师也可以看到他的分享。
|
||||
|
||||
然后，木头又用教师账号在Azure上申请了两台带 GPU 卡的计算 VM，选择了 OpenPAI 的镜像，5 分钟后，两台服务器正常启动，他便关闭了服务器，避免在没人使用时发生不必要的费用。
|
||||
|
||||
### 6.6.2 老师和学生上课的场景
|
||||
|
||||
2020/10/14 上午。
|
||||
|
||||
第二天，木头准时来到电教室，同学们已经都到齐了，毛毛像往常一样坐在第一排，他想仔细听听老师如何讲解复杂的卷积神经网络。
|
||||
|
||||
木头没有带电脑，因为电教室的 Surface Hub S2 所连接的主机，早已经连接到了 Azure 上。他打开 Edge 浏览器，输入http://openaiedu.azure.microsoft.com网址，输入了自己的教职员工号码登录，电教系统已经自动开始录音录像他的讲课内容了。
|
||||
|
||||
木头打开了 PPT，放在屏幕左侧，而右侧则是书写区，便于注释与重点讲解。45 分钟之内，4种卷积类型在左侧依次一个个地被讲解，并最终做了比较，而右侧的白板区则写满了木头的 Ink 笔记，使得毛毛清晰地理解了它们的原理。木头把Ink笔记保存为文件后，上传到了服务器，便于同学们复习。
|
||||
|
||||
课间休息，木头在 Azure 上激活了昨天准备好的两台虚拟机，准备给同学在课堂上跑卷积神经网络的训练过程示例。此时 OpenPAI 已经严阵以待，就等 Job 的提交了。
|
||||
|
||||
木头先用交互式图形界面，在屏幕上妥妥拽拽，只用了 5 分钟就生成了一个神经网络，包括两层卷积、两层池化和两层全连接，最后又选择了 Softmax 分类函数和交叉熵损失函数后，把准备好的 MNIST 数据集输入，并点击“提交Job”按钮，OpenPAI 瞬间活跃起来，数据流在 K80 GPU 中疯狂运转，10 分钟后，50 个 epoch 跑完了。与此同时，同学们也分组搭建自己的神经网络，在图形界面上设置了自己想试验的超参，然后点击“提交Job”按钮。
|
||||
|
||||
OpenPAI 管理的两块 GPU 现在满负荷运行了，在任务区中有 10 组同学的排队请求，每隔 1 分钟，会有一个任务状态信息反馈到用户界面上。20 分钟后，同学们的手机依次收到了任务结束通知，纷纷去看结果，有的高兴有的沉思，毛毛似乎又不太顺利，琢磨着为什么 4 个卷积核只能得到89% 的准确率呢？
|
||||
|
||||
正踌躇间，下课的铃声响了，木头老师提醒同学们保存好自己的模型，便关闭了 GPU 服务器，看看 Azure 上的账单，一共只花费了 2 美元！（美国西 2 区当前价每小时 0.9 美元每台单卡 K80 服务器）
|
||||
|
||||
故事讲完了，但毛毛还在郁闷中。
|
||||
|
|
@ -1,51 +0,0 @@
|
|||
## 6.6 木头与 AI 教学的故事
|
||||
|
||||
从上一节的内容我们知道，典型用户是需要应用场景故事来具体描述的，这一节我们就举例说明什么是应用场景故事。
|
||||
|
||||
人物：
|
||||
- 毛毛作为一个大三的学生，正在学习深度学习的相关知识。
|
||||
- 木头是一名老师，讲授神经网络基本原理课程。
|
||||
|
||||
|
||||
<img src="img/Slide12.JPG"/>
|
||||
|
||||
图 6.6.1 - 真实的 AI 教学场景
|
||||
|
||||
|
||||
图 6.6.1 展示了微软在上海仪电做的真实的 AI 教学场景。
|
||||
|
||||
### 6.6.1 老师和学生预习的场景
|
||||
|
||||
2020/10/13 晚。
|
||||
|
||||
毛毛已经上了10节关于神经网络入门的课程，明天该进入卷积网络的学习了。
|
||||
|
||||
在前面的深度学习基础中，循序渐进的课程设置，让毛毛感觉学习起来很轻松，似乎学习曲线没有那么陡峭。而示例代码和课后作业，由于代码的高度优化，他用自己的笔记本完全可以跑起来，很快地就跑出了实验数据。他打开了课程网站，用自己的学号和密码登录后，进入提交作业的页面，填写了自己的实验数据，点击“提交”按钮，看到“提交成功”的信息后，毛毛猜想着自己的作业成绩，会不会像以往那样名列前茅。
|
||||
|
||||
果真，一会儿毛毛的微信收到了作业系统通知消息，自动评分系统已经统计了全班同学的作业成绩，由于毛毛的模型预测数据的准确率为98.1%，名列第二名，仅比第一名低0.1个百分点。毛毛不满意地摇摇头，暗下决心一定要在卷积网络这一部分的成绩超过那个名叫金二的但总得第一的家伙。
|
||||
|
||||
毛毛想预习一下卷积网络的知识，打开了课件。看了20分钟后，毛毛的觉得很沮丧，什么单入单核，多入单核，单入多核，多入多核……一大堆卷积类型，越看越晕。算了，明天上课好好听木头老师讲吧。
|
||||
|
||||
而木头老师此时也还没有休息，他先浏览了一下全班同学的作业成绩，在讨论区里回答了几个问题后，调出卷积神经网络的PPT课件，开始备课。在PPT的note中标记了几处需要重点说明的环节后，Office 365已经替他把文档自动保存到服务器上，这样其它老师也可以看到他的分享。
|
||||
|
||||
然后，木头又用教师账号在Azure上申请了两台带GPU卡的计算VM，选择了OpenPAI的镜像，5分钟后，两台服务器正常启动，他便关闭了服务器，避免在没人使用时发生不必要的费用。
|
||||
|
||||
### 6.6.2 老师和学生上课的场景
|
||||
|
||||
2020/10/14 上午。
|
||||
|
||||
第二天，木头准时来到电教室，同学们已经都到齐了，毛毛像往常一样坐在第一排，他想仔细听听老师如何讲解复杂的卷积神经网络。
|
||||
|
||||
木头没有带电脑，因为电教室的Surface Hub S2所连接的主机，早已经连接到了Azure上。他打开Edge浏览器，输入http://openaiedu.azure.microsoft.com网址，输入了自己的教职员工号码登录，电教系统已经自动开始录音录像他的讲课内容了。
|
||||
|
||||
木头打开了PPT，放在屏幕左侧，而右侧则是书写区，便于注释与重点讲解。45分钟之内，4种卷积类型在左侧依次一个个地被讲解，并最终做了比较，而右侧的白板区则写满了木头的Ink笔记，使得毛毛清晰地理解了它们的原理。木头把Ink笔记保存为文件后，上传到了服务器，便于同学们复习。
|
||||
|
||||
课间休息，木头在Azure上激活了昨天准备好的两台虚拟机，准备给同学在课堂上跑卷积神经网络的训练过程示例。此时OpenPAI已经严阵以待，就等Job的提交了。
|
||||
|
||||
木头先用交互式图形界面，在屏幕上妥妥拽拽，只用了5分钟就生成了一个神经网络，包括两层卷积、两层池化和两层全连接，最后又选择了Softmax分类函数和交叉熵损失函数后，把准备好的MNIST数据集输入，并点击“提交Job”按钮，OpenPAI瞬间活跃起来，数据流在K80 GPU中疯狂运转，10分钟后，50个epoch跑完了。与此同时，同学们也分组搭建自己的神经网络，在图形界面上设置了自己想试验的超参，然后点击“提交Job”按钮。
|
||||
|
||||
OpenPAI管理的两块GPU现在满负荷运行了，在任务区中有10组同学的排队请求，每隔1分钟，会有一个任务状态信息反馈到用户界面上。20分钟后，同学们的手机依次收到了任务结束通知，纷纷去看结果，有的高兴有的沉思，毛毛似乎又不太顺利，琢磨着为什么4个卷积核只能得到89%的准确率呢？
|
||||
|
||||
正踌躇间，下课的铃声响了，木头老师提醒同学们保存好自己的model，便关闭了GPU服务器，看看Azure上的账单，一共只花费了2美元！（美国西2区当前价每小时0.9美元每台单卡K80服务器）
|
||||
|
||||
故事讲完了，但毛毛还在郁闷中。
|
||||
|
|
@ -10,7 +10,7 @@
|
|||
|
||||
“对于我们 MSRA 的**研究员**们，他/她们想**解决论文管理的问题**。我们要做的这个叫做 **Papera** 的产品，是一个**客户端软件工具**，它可以通过**本地存储、检索、智能搜索**等功能，为用户提供**论文阅读平台**。它不同于市场上的只能做标记工作**普通 PDF 阅读器**，它可以帮助研究员**很方便地从上百篇已经读过的论文中快速准确地找到曾经做过标记的最有价值的那篇论文，提高阅读论文的效率及与它人分享心得**。”
|
||||
|
||||
大家可以尝试着以正常语速念出上面的文字，大概只需要30秒的时间，但是这段文字基本上清晰扼要地把 Papera 这个产品的特点全方位地表述了出来。
|
||||
大家可以尝试着以正常语速念出上面的文字，大概只需要 30 秒的时间，但是这段文字基本上清晰扼要地把 Papera 这个产品的特点全方位地表述了出来。
|
||||
|
||||
|
||||
<img src="img/Slide16.JPG"/>
|
||||
|
|
@ -18,7 +18,7 @@
|
|||
图 6.8.1 - 电梯演讲
|
||||
|
||||
|
||||
图 6.8.1 中的一列向下的箭头，可以想象成电梯从30层楼开始向下运行，每5秒钟就要说出一句话来。其中的关键信息（Key）标在箭头的位置上，可以用程序员熟悉的 Key/Value Pair（键/值对）来表示，见表 6.8.1：
|
||||
图 6.8.1 中的一列向下的箭头，可以想象成电梯从 30 层楼开始向下运行，每 5 秒钟就要说出一句话来。其中的关键信息（Key）标在箭头的位置上，可以用程序员熟悉的 Key/Value Pair（键/值对）来表示，见表 6.8.1：
|
||||
|
||||
表 6.8.1 - 电梯演讲关键词
|
||||
|
||||
|
|
@ -106,30 +106,30 @@ Data 的问题是提醒软件产品要收集用户使用数据，通过分析来
|
|||
|
||||
1. N（need需求）
|
||||
|
||||
我们的产品解决了用户由于工作或者压力较大而得不到缓解的问题，近年来我国生活节奏快，如果有太多的压力得不到释放，对身心都会造成伤害，我们的产品可以来缓解这种情况。
|
||||
“我们的产品解决了用户由于工作或者压力较大而得不到缓解的问题，近年来我国生活节奏快，如果有太多的压力得不到释放，对身心都会造成伤害，我们的产品可以来缓解这种情况。”
|
||||
|
||||
*点评：这个说法可以接受，但是不够具体，比如具体到“听音乐”也可以是缓解手段。*
|
||||
**【最佳实践】可以接受。**
|
||||
|
||||
2. A（Approach做法）
|
||||
|
||||
人们的压力过大得不到释放，所以需要一些方法来转移注意力，来达到减压的目的，所以我们需要让人们在短时间里从工作中走出来，不再去想工作中的事。
|
||||
“人们的压力过大得不到释放，所以需要一些方法来转移注意力，来达到减压的目的，所以我们需要让人们在短时间里从工作中走出来，不再去想工作中的事。”
|
||||
|
||||
*点评：并没有描述具体的做法，比如“我们要制作一个游戏”，才算是做法。*
|
||||
**【最佳实践】并没有描述具体的做法，比如“我们要制作一个游戏”，才算是做法。**
|
||||
|
||||
3. B（Benefit好处）
|
||||
|
||||
我们制作的软件成本低，目前几乎所有类型的人群都可以使用，你只需要很短的时间就可以沉浸在里面，但又不会沉迷，是非常适合那些只有很少的空闲时间但是压力却很大的人群用来解压。
|
||||
“我们制作的软件成本低，目前几乎所有类型的人群都可以使用，你只需要很短的时间就可以沉浸在里面，但又不会沉迷，是非常适合那些只有很少的空闲时间但是压力却很大的人群用来解压。”
|
||||
|
||||
*点评：可以接受。*
|
||||
**【最佳实践】可以接受。**
|
||||
|
||||
4. C（Competitors竞争）
|
||||
|
||||
我们并不是第一个做这个的，但是这种类型的产品所适合的人很多，类型也很多，所以市场还是非常大的，只要自己有创意，可以在这个领域站稳脚步，做出自己的产品。
|
||||
“我们并不是第一个做这个的，但是这种类型的产品所适合的人很多，类型也很多，所以市场还是非常大的，只要自己有创意，可以在这个领域站稳脚步，做出自己的产品。”
|
||||
|
||||
*点评：没有说出“创意”是什么，太空洞，这样无法说服客户。*
|
||||
**【最佳实践】没有说出“创意”是什么，太空洞，这样无法说服客户。**
|
||||
|
||||
5. D（Delivery交付）
|
||||
|
||||
目前我们可以做小范围的推广，软件并不大只要几分钟就可以体验它的内容，随后在通过人群传播让更多的人可以了解到。
|
||||
“目前我们可以做小范围的推广，软件并不大只要几分钟就可以体验它的内容，随后在通过人群传播让更多的人可以了解到。”
|
||||
|
||||
*点评：并没有提及如何发布、宣传这个软件，甚至连是手机 App 还是桌面 App 都不知道。“通过人群传播”又是如何做到呢？软件又不是新冠病毒，况且现在大家都戴了口罩。*
|
||||
**【最佳实践】并没有提及如何发布、宣传这个软件，甚至连是手机 App 还是桌面 App 都不知道。“通过人群传播”又是如何做到呢？软件又不是新冠病毒，况且现在大家都戴了口罩。**
|
||||
|
|
|
|||
|
|
@ -1,28 +1,14 @@
|
|||
## 7.1 需求分析的重要性
|
||||
|
||||
需求分析是软件生命周期中相当重要的一个阶段。
|
||||
### 7.1.1 需求的故事
|
||||
|
||||
#### 国外故事：秋千图
|
||||
|
||||
<img src="img/Slide3.JPG"/>
|
||||
|
||||
图 7.1.1 - IT 项目成功率调查
|
||||
|
||||
|
||||
|
||||
1999年，美国专门从事跟踪 IT 项目成功或失败的权威机构 Standish Group，对23000个项目进行的研究结果表明，28%的项目彻底失败，46%的项目超出经费预算或者超出工期，只有约26%的项目获得成功。
|
||||
|
||||
而在这些高达74%（28% + 46%）的不算成功项目中，有约60%的失败是源于需求问题，也就是差不多有一半的项目都遇到了这个问题，这一可怕的现象引起人们对需求分析的高度重视。
|
||||
|
||||
需求分析阶段的主要任务是通过需求分析人员与用户之间的广泛交流，不断澄清一些模糊的概念，最终形成一个完整的、清晰的、一致的需求说明。
|
||||
|
||||
### 7.1.1 国外故事：秋千图的例子
|
||||
|
||||
我们先请出软件业界著名的秋千图，如图 7.1.2，表 7.1.1 中有解释。
|
||||
|
||||
我们先请出软件业界著名的秋千图，如图 7.1.1，表 7.1.1 中有解释。
|
||||
|
||||
<img src="img/Slide4.JPG"/>
|
||||
|
||||
图 7.1.2 - 秋千图
|
||||
图 7.1.1 - 秋千图
|
||||
|
||||
|
||||
表 7.1.1 - 秋千图的解释
|
||||
|
|
@ -62,17 +48,34 @@
|
|||
|
||||
10. 其实客户的真实需求只是一根绳索下面挂一个旧轮胎。
|
||||
|
||||
### 7.1.2 国产故事：烟囱和井的例子
|
||||
#### 国产故事：烟囱和深井
|
||||
|
||||
如图 7.1.2 所示。
|
||||
|
||||
<img src="img/Slide5.JPG"/>
|
||||
|
||||
图 7.1.3 - 烟囱和深井
|
||||
|
||||
|
||||
图 7.1.2 - 烟囱和深井
|
||||
|
||||
在郭德纲的相声《梦中婚》里，客户郭师傅需要挖一口井，但是工程人员把图纸拿反了，最后建了一个烟囱，一边干一边还纳闷儿：这个烟囱为什么设计的这么粗？
|
||||
|
||||
### 7.1.2 需求分析阶段
|
||||
|
||||
需求分析是软件生命周期中相当重要的一个阶段。
|
||||
|
||||
1999 年，美国专门从事跟踪 IT 项目成功或失败的权威机构 Standish Group，对 23000 个项目进行的研究结果表明，28% 的项目彻底失败，46%的项目超出经费预算或者超出工期，只有约 26% 的项目获得成功。见图 7.1.3。
|
||||
|
||||
<img src="img/Slide3.JPG"/>
|
||||
|
||||
图 7.1.3 - IT 项目成功率调查
|
||||
|
||||
|
||||
|
||||
而在这些高达 74%（28% + 46%）的不算成功项目中，有约 60% 的失败是源于需求问题，也就是多于一半的项目都遇到了需求问题，这一可怕的现象引起人们对需求分析的高度重视。
|
||||
|
||||
需求分析阶段的主要任务是通过需求分析人员与用户之间的广泛交流，不断澄清一些模糊的概念，最终形成一个完整的、清晰的、一致的需求说明。
|
||||
|
||||
### 7.1.3 避免错误
|
||||
|
||||
其实，有很多机会可以避免这个错误，而且可以轻易觉察。但是如果对应到软件开发上，就没有那么容易了，这要求在软件开发中有严格的流程管理和及时（通过scrum meeting）沟通。
|
||||
|
||||
|
||||
|
|
@ -80,9 +83,9 @@
|
|||
|
||||
图 7.1.4 - Scrum 的沟通作用
|
||||
|
||||
以烟囱和深井的故事为例：
|
||||
|
||||
|
||||
1. 包工头作为中间环节没有给上下游交代清楚。包工头在这里可以对应到需求分析人员，他如果拿着图纸（需求规格说明书）和客户确认一下需求，或者直接告诉施工方（开发人员）客户是要挖一口井，也不会出现这样的错误。
|
||||
1. 包工头作为中间环节没有给上下游交代清楚。包工头在这里可以对应到**需求人员**，他如果拿着图纸（需求规格说明书）和客户做一个**确认需求**，或者直接告诉施工方（**开发人员**）客户是要挖一口井，也不会出现这样的错误。
|
||||
|
||||
2. 文档不严格，不完整。如果在图的上方注明《郭师傅家的深井挖建工程图》，除非工人是文盲，否则也不会拿反图纸。
|
||||
|
||||
|
|
@ -92,17 +95,14 @@
|
|||
|
||||
5. 包工头经常来现场检查工程进展。需求分析人员在完成文档后，并非就完成工作了，而是要阶段性地和开发人员进行交流，监督、检查进度、质量以及需求满足情况。
|
||||
|
||||
### 7.1.3 需求分析的特点及难点
|
||||
|
||||
需求分析的特点及难点，主要体现在图 7.1.5 所示的几个方面。$^{[1]}$
|
||||
### 7.1.4 需求分析的特点及难点
|
||||
|
||||
尽管可以用一些手段避免需求分析阶段的错误，但是仍然存在很多陷阱，其特点及难点主要体现在图 7.1.5 所示的几个方面。$^{[1]}$
|
||||
|
||||
<img src="img/Slide7.JPG"/>
|
||||
|
||||
图 7.1.5 - 需求分析的特点与难点
|
||||
|
||||
|
||||
|
||||
1. 定位困难
|
||||
|
||||
主要原因一是应用领域的复杂性及业务变化，难以具体确定；二是用户需求所涉及的多因素引起的，比如运行环境和系统功能、性能、可靠性和接口等。
|
||||
|
|
|
|||
|
|
@ -2,70 +2,67 @@
|
|||
|
||||
需求逻辑分析，就是通过记录用户诉求（文字的或语言的），仔细领会用户的真实意图和工作流程。具体的方法可以有以下几种：
|
||||
|
||||
- 小组讨论，从语义上搞清需求。
|
||||
- 卡片分类，整理功能需求集合。
|
||||
- 单据分析，业务流程逻辑需求。
|
||||
- 报表分析，数据汇总统计需求。
|
||||
|
||||
见图 7.2.1。
|
||||
|
||||
<img src="img/Slide8.JPG"/>
|
||||
|
||||
图 7.2.1 - 需求逻辑分析
|
||||
|
||||
|
||||
|
||||
- 小组讨论，从语义上搞清需求；
|
||||
- 卡片分类，整理功能需求集合；
|
||||
- 单据分析，业务流程逻辑需求；
|
||||
- 报表分析，数据汇总统计需求。
|
||||
|
||||
### 7.2.1 小组讨论
|
||||
|
||||
|
||||
<img src="img/Slide9.JPG"/>
|
||||
|
||||
图 7.2.2 - 需求分析之小组讨论
|
||||
|
||||
|
||||
|
||||
项目小组成员通过任何形式获得用户需求，回来后自己内部开会，对需求进行讨论，目的如下：
|
||||
- 把抽象的需求具体化
|
||||
#### 1. 把抽象的需求具体化
|
||||
- 用户：“这么多论文乱七八糟的，根本没法找！”
|
||||
- 毛毛：“我觉得用户并不喜欢读很多论文。”
|
||||
- 木头：“需要论文分类管理功能，可能是根据类别、会议或者日期。”
|
||||
|
||||
*解释：用户的需求有时是用情绪化的语言形式表达出来的。*
|
||||
【最佳实践】用户的需求有时是用情绪化的语言形式表达出来的。
|
||||
|
||||
- 用计算机专业词汇描述需求
|
||||
#### 2. 用计算机专业词汇描述需求
|
||||
- 用户：“这个论文很有价值，以后还要再看。”
|
||||
- 毛毛：“给论文加一个类似豆瓣评分的级别。”
|
||||
- 木头：“按日期保存论文到系统指定的存储位置，并可以根据日期和名称检索。”
|
||||
|
||||
*解释：需求文档要明确指出存储、检索的功能。*
|
||||
【最佳实践】需求文档要明确指出存储、检索的功能。
|
||||
|
||||
- 避免需求理解偏差
|
||||
#### 3. 避免需求理解偏差
|
||||
- 用户：“这个游戏软件主要是面对儿童的，比如我，希望家里的三个分别为7岁、10岁、12岁的孩子都可以玩。”
|
||||
- 毛毛：“用户希望如果一个家庭有三个孩子的话，可以同时玩这个游戏。”
|
||||
- 木头：“别闹，用户是希望各个年龄段的孩子都可以玩。”
|
||||
|
||||
*解释：用户的举例通常带有实例化性质，需求文档需要泛化这些需求。比如该用户家的三个孩子恰巧都是男孩儿，或者该用户家的孩子的身高比同龄人的平均身高要高，这些都需要广泛调查后再确定目标用户。其实在著名的秋千图的例子里，用户的原始想法是用一个橡胶轮胎挂在树上做秋千，这样他的三个孩子都可以玩儿。但是需求分析人员把“三个孩子都可以玩儿”理解为“三个孩子可以同时玩儿”，于是设计了一个三层的木板结构。*
|
||||
【最佳实践】用户的举例通常带有实例化性质，需求文档需要泛化这些需求。比如该用户家的三个孩子恰巧都是男孩儿，或者该用户家的孩子的身高比同龄人的平均身高要高，这些都需要广泛调查后再确定目标用户。其实在著名的秋千图的例子里，用户的原始想法是用一个橡胶轮胎挂在树上做秋千，这样他的三个孩子都可以玩儿。但是需求分析人员把“三个孩子都可以玩儿”理解为“三个孩子可以同时玩儿”，于是设计了一个三层的木板结构。
|
||||
|
||||
- 确定需求边界
|
||||
#### 4. 确定需求边界
|
||||
- 用户：“能不能加两个人手，在这个月就把那个云端同步的功能也一起做了？”
|
||||
- 毛毛：“云端同步的功能，只是把客户端的注释标记上传到云端保存而已，好像没有很大的工作量。”
|
||||
- 木头：“对不起，我们本期的需求已经确定了‘论文注释’功能只在客户端保存，开发计划已经排满了。况且云端同步功能还需要购买 Azure 资源，这部分也不在预算内。”
|
||||
|
||||
*解释：用户总希望少花钱多办事，而市场人员往往为了订单随口承诺一些事情，需求文档需要明确这些边界。做计划外的功能，会影响计划内的软件的质量，和一些不可预估的如预算、设备、部署等方面的麻烦。*
|
||||
【最佳实践】用户总希望少花钱多办事，而市场人员往往为了订单随口承诺一些事情，需求文档需要明确这些边界。做计划外的功能，会影响计划内的软件的质量，和一些不可预估的如预算、设备、部署等方面的麻烦。
|
||||
|
||||
- 判别错误需求
|
||||
#### 5. 判别错误需求
|
||||
- 用户：“这个论文最好还能保存成 docx 格式，便于修改。”
|
||||
- 毛毛：“保存成 docx 功能还能用 Word 打开阅读，很方便。”
|
||||
- 木头：“你......我......人家发表的论文你改什么改？”
|
||||
|
||||
*解释：对用户的一些需求，需要分析它的背后的含义，再确定其正确性。*
|
||||
【最佳实践】对用户的一些需求，需要分析它的背后的含义，再确定其正确性。
|
||||
|
||||
- 识别潜在需求
|
||||
#### 6. 识别潜在需求
|
||||
|
||||
- 用户：“我批改了这篇论文，我想把我的意见通过电子邮件转达给其它人。”
|
||||
- 毛毛：“电子邮件是无纸办公的重要手段，倒是可以考虑增加这个功能。”
|
||||
- 木头：“用户实际上是想通过网络的方式把自己的意见快速准确地转达给其它人，那不如我们后期考虑在 Azure 上搭建一个服务器吧，这样大家都可以分享自己的见解。”
|
||||
|
||||
*解释：就如同亨利福特遇到的情况，用户希望有一匹快马，但其实用户需要的只是“快”，而不是“马”，“快”是真正的需求，“马”只是载体，所以福特开始造新的载体——汽车。理解用户的真实意图，用自己的专业知识提供解决方案。*
|
||||
【最佳实践】就如同亨利福特遇到的情况，用户希望有一匹快马，但其实用户需要的只是“快”，而不是“马”，“快”是真正的需求，“马”只是载体，所以福特开始造新的载体——汽车。理解用户的真实意图，用自己的专业知识提供解决方案。
|
||||
|
||||
### 7.2.2 卡片分类
|
||||
|
||||
|
|
@ -73,57 +70,72 @@
|
|||
|
||||
微软内部有一种做法类似于卡片分类，叫做 Backlog，就是使用软件把一些想法记录下来，在下一阶段的需求分析开始时，把这些想法拿出来分类整理，大家评估一下需求属性，再排一下优先级，成为真正的功能写到文档中等待开发。
|
||||
|
||||
|
||||
<img src="img/Slide10.JPG"/>
|
||||
|
||||
图 7.2.3 - 需求分析之卡片分类
|
||||
|
||||
|
||||
|
||||
木头在做 Edge Mobile Browser 的需求分析时，使用了卡片分类法来归纳总结一些浏览器上的功能的分类，这样做的好处是：
|
||||
|
||||
- 应用场景分类
|
||||
|
||||
- 从客户角度可以清楚这个软件可以提供什么类型的功能，而不是看到乱糟糟堆砌的一堆功能，这可以帮助客户建立对这个软件的质量方面的信心。
|
||||
|
||||
- 需求分析人员可以从已有分类中开拓思路，设计出一个惊喜型的功能。
|
||||
#### 1. 应用场景分类
|
||||
|
||||
分类设定，其实对人类的思维是一个双刃剑。木头的感觉是，很容易陷入已定类别中不能或者不敢突破。另一方面，也可以帮助需求分析人员仔细研究每个类别里的功能，找出缺失的部分，或者找出缺失的类别，来开发出惊喜型功能。
|
||||
【最佳实践】帮助客户理清思路。
|
||||
|
||||
- 开发人员可以快速学习领域知识，理解真正的需求。
|
||||
|
||||
木头自己就通过这次分类整理，真正地认识到了浏览器功能的全貌，一旦有了“上帝视角”，会不由自主地感叹到：“原来如此！那么浏览器那个组的几百号儿人，这些年都做了什么，为什么 Edge 浏览器口碑越来越差？”。话音未落，浏览器组先是换了一个大老板，紧接着决定用 Chromium 做引擎，重新写 Edge 浏览器的 Shell，而这个大老板，就是以前在 Windows Team 负责 Shell 的，这说明了一个问题 —— 上层已经决定用 Chromium 做引擎，让一个对 Shell 很有经验的人去领导 Edge 项目的开发，在 Chromium 的基础上做一个微软风格的 Shell，成为新的 Edge 浏览器。
|
||||
|
||||
- 模块功能整合
|
||||
|
||||
- 相近的功能可以共用底层模块，减少代码重复。
|
||||
- 从客户角度可以清楚这个软件可以提供什么类型的功能，而不是看到乱糟糟堆砌的一堆功能，这可以帮助客户建立对这个软件的质量方面的信心。
|
||||
|
||||
比如浏览器里常用的两个功能：网页收藏，浏览历史。从外观上看，很明显都是一个列表，里面存放一些网页记录。最起码，那个列表控件就是可以重用的部分。
|
||||
【最佳实践】发现新功能。
|
||||
|
||||
- 需求分析人员可以从已有分类中开拓思路，设计出一个惊喜型的功能。
|
||||
|
||||
分类设定，其实对人类的思维是一个双刃剑。木头的感觉是，很容易陷入已定类别中不能或者不敢突破。另一方面，也可以帮助需求分析人员仔细研究每个类别里的功能，找出缺失的部分，或者找出缺失的类别，来开发出惊喜型功能。
|
||||
|
||||
【最佳实践】学习领域知识。
|
||||
|
||||
- 开发人员可以快速学习领域知识，理解真正的需求。
|
||||
|
||||
木头自己就通过这次分类整理，真正地认识到了浏览器功能的全貌，一旦有了“上帝视角”，会不由自主地感叹到：“原来如此！那么浏览器那个组的几百号儿人，这些年都做了什么，为什么 Edge 浏览器口碑越来越差？”。话音未落，浏览器组先是换了一个大老板，紧接着决定用 Chromium 做引擎，重新写 Edge 浏览器的 Shell，而这个大老板，就是以前在 Windows Team 负责 Shell 的，这说明了一个问题 —— 上层已经决定用 Chromium 做引擎，让一个对 Shell 很有经验的人去领导 Edge 项目的开发，在 Chromium 的基础上做一个微软风格的 Shell，成为新的 Edge 浏览器。
|
||||
|
||||
- 合理地分配开发资源，让一个人或小组负责一类功能。
|
||||
#### 2. 模块功能整合
|
||||
|
||||
【最佳实践】底层模块规划。
|
||||
|
||||
- 相近的功能可以共用底层模块，减少代码重复。
|
||||
|
||||
比如浏览器里常用的两个功能：网页收藏，浏览历史。从外观上看，很明显都是一个列表，里面存放一些网页记录。最起码，那个列表控件就是可以重用的部分。
|
||||
|
||||
【最佳实践】合理分配任务。
|
||||
|
||||
- 合理地分配开发资源，让一个人或小组负责一类功能。
|
||||
|
||||
木头在 Edge Mobile Browser 项目中，担任的是质量管理任务，亲眼目睹了当时的 Dev Manager 是如何分配工作的：先给甲乙丙三个开发人员各分配一个任务模块 A、B、C，假设甲先做完了，就分配另外一个任务模块D，而 D 和 A 是两个不相关的模块。
|
||||
木头在 Edge Mobile Browser 项目中，担任的是质量管理任务，亲眼目睹了当时的 Dev Manager 是如何分配工作的：先给甲乙丙三个开发人员各分配一个任务模块 A、B、C，假设甲先做完了，就分配另外一个任务模块D，而 D 和 A 是两个不相关的模块。
|
||||
|
||||
上面只假设有三个开发人员，实际上当时有10几个人，每个人都是在功能类别之间跳来跳去，需要熟悉每一个功能模块的底层代码，造成资源上的浪费。
|
||||
上面只假设有三个开发人员，实际上当时有10几个人，每个人都是在功能类别之间跳来跳去，需要熟悉每一个功能模块的底层代码，造成资源上的浪费。
|
||||
|
||||
- 子系统划分
|
||||
#### 3. 子系统划分
|
||||
|
||||
相互之间有较强关系的模块聚合在一起，可以形成子系统。子系统划分其实不是设计阶段才开始的任务，而是在需求阶段就已经形成雏形了。
|
||||
【最佳实践】理清子系统边界。
|
||||
|
||||
用卡片分类法，在视觉上就可以直接形成功能聚类，理清子系统的边界，便于后面做接口设计。
|
||||
- 相互之间有较强关系的模块聚合在一起，可以形成子系统。子系统划分其实不是设计阶段才开始的任务，而是在需求阶段就已经形成雏形了。
|
||||
|
||||
- 界面设计指导
|
||||
【最佳实践】规划接口。
|
||||
|
||||
- 用卡片分类法，在视觉上就可以直接形成功能聚类，理清子系统的边界，便于后面做接口设计。
|
||||
|
||||
#### 4. 界面设计指导
|
||||
|
||||
- 同一类功能放在一个菜单入口里，用户容易找到。
|
||||
【最佳实践】统一菜单入口。
|
||||
|
||||
在京东、淘宝等软件里，作为软件从业人员的木头，可以明显感觉到界面菜单是经过精心设计的。但是在使用一些银行的手机软件时，就会觉得功能不容易找到，缺乏设计。
|
||||
- 同一类功能放在一个菜单入口里，用户容易找到。
|
||||
|
||||
- 不同使用率的菜单入口在屏幕上的位置不一样，体现了重要程度。
|
||||
在京东、淘宝等软件里，作为软件从业人员的木头，可以明显感觉到界面菜单是经过精心设计的。但是在使用一些银行的手机软件时，就会觉得功能不容易找到，缺乏设计。
|
||||
|
||||
尤其是在手机上，屏幕小，寸土寸金，所以按钮的位置需要非常精细的设计：
|
||||
- 是否需要在首页上显示
|
||||
- 如果需要显示，放在什么位置，方便用户单手操作
|
||||
- 按钮的尺寸多大，才能即明显，又不影响美观，又能很容易地点击
|
||||
【最佳实践】规划入口位置。
|
||||
|
||||
- 不同使用率的菜单入口在屏幕上的位置不一样，体现了重要程度。
|
||||
|
||||
尤其是在手机上，屏幕小，寸土寸金，所以按钮的位置需要非常精细的设计：
|
||||
- 是否需要在首页上显示
|
||||
- 如果需要显示，放在什么位置，方便用户单手操作
|
||||
- 按钮的尺寸多大，才能即明显，又不影响美观，又能很容易地点击
|
||||
|
||||
### 7.2.3 单据分析法
|
||||
|
||||
|
|
@ -165,18 +177,14 @@
|
|||
1. 还缺一个唯一的入库单号做主键，否则无法索引。
|
||||
2. 另外就是型号字段是个外键，需要设计另外一张表来描述 LG302 和 C104 的具体特性，如重量、体积、颜色、无线/有线、是否人体工程学设计等等。
|
||||
|
||||
|
||||
### 7.2.4 报表分析法
|
||||
|
||||
报表分析法，通过分析用户使用的报表获取需求。报表跟单据是有本质区别的。单据是在业务处理过程中用户填写的纸质文件，往往是一个信息采集、传递的过程，而报表则是根据一定的规则对批量数据进行检索、统计、汇总，是一个信息加工、分析的过程。
|
||||
|
||||
|
||||
<img src="img/Slide12.JPG"/>
|
||||
|
||||
图 7.2.5 - 需求分析之报表分析
|
||||
|
||||
|
||||
|
||||
生成报表的数据来源，是需求分析的重要手段，这些数据必须在需求链前端存在，不能到最后环节凭空产生。要做到“报表中需要展示什么，就去收集什么数据”，而不是“已经有什么数据，就在报表中展示什么”。
|
||||
|
||||
分析好现在使用的这些报表，可以深入到管理者的管理神经，弄清楚当前公司管理者感兴趣的信息，最终给各级管理者带来真正的价值。报表是一个信息系统的集大成者，提前做好报表分析，可以加深理解管理脉络，理解信息系统的最终需求。$^{[5]}$
|
||||
|
|
|
|||
|
|
@ -1,25 +1,22 @@
|
|||
## 7.3 木头与 AI 教学需求的故事
|
||||
## 7.3 AI 教学系统的故事
|
||||
|
||||
这一天，木头和几个微软的同事来到一所高校调研，受到了校长、老师和同学的热情接待。在一个可以容纳 10 几个人的会议室里，大家围坐在桌前，一边品着刚刚下来的毛尖茶，一边聊着 AI 教育。
|
||||
|
||||
|
||||
<img src="img/Slide13.JPG"/>
|
||||
|
||||
图 7.3.1 - AI 教学系统的需求层次
|
||||
|
||||
|
||||
|
||||
### 7.3.1 校长和教务处主任的发言
|
||||
|
||||
首先当然是请校长发言。
|
||||
|
||||
“首先感谢微软的相关同志来我校做调研，我们这边今天参会的有分管校长、教务处刘主任、机房赵主任、老师代表和学生代表。下面我先说说大形式（校长端起杯子喝了一口茶水）。
|
||||
|
||||
“国务院2017年印发了《新一代人工智能 发展规划》，标志着人工智能作为产业变革的核心驱动力和引领未来的战略技术，已上升为国家战略......构建包含智能学习、交互式学习的新型教育体系。
|
||||
“这个国务院啊，2017 年印发了《新一代人工智能 发展规划》，标志着人工智能作为产业变革的核心驱动力和引领未来的战略技术，已上升为国家战略......构建包含智能学习、交互式学习的新型教育体系。
|
||||
|
||||
“对于AI教育企业而言，去年的政策环境足够振奋人心。教育部发布的《高等学校人工智能创新行动计划》提出......人工智能+X的复合特色专业，解决AI的人才问题。
|
||||
“对于 AI 教育而言，去年的政策环境那是相当地振奋人心。教育部发布的《高等学校人工智能创新行动计划》提出......AI + X 的复合特色专业，解决 AI 的人才问题。
|
||||
|
||||
“近日，教育部网站发布了《教育部2019年工作要点》，提出......AI+教育和互联网教育注入一剂强心针。
|
||||
“近日呢，教育部网站发布了《教育部2019年工作要点》，提出......给 AI + 教育和互联网教育注入一剂强心针。
|
||||
|
||||
......（省略1000字）
|
||||
|
||||
|
|
@ -27,11 +24,11 @@
|
|||
|
||||
木头：“感谢您的信任！支持高校的教育一直是我们的宗旨。刚才校长先生的讲话已经给我们指明了方向，这次来其实还是想听听各位一线老师目前在 AI 教育上有什么需求和痛点。”
|
||||
|
||||
教务处主任：“那我先说说吧！现在市面上的教材很多，国内的国外的都有，最知名的就是周志华老师的“西瓜书”《机器学习》，李航老师的《统计学习方法》，还有一本国外翻译过来的“花书”《深度学习》。但是我总觉得这些书做为教材的话，难度有点儿大，老师首先要自己学习，做课件，然后再讲给学生听，但学生们往往反映听不懂。”
|
||||
教务处主任：“那我先说说吧！现在市面上的教材很多，国内的国外的都有，最知名的就是周志华老师的“西瓜书”《机器学习》，李航老师的《统计学习方法》，还有一本国外翻译过来的“花书”《深度学习》。这些书相当的好，但是我总觉得这些书做为教材的话，难度有点儿大，老师首先要自己学习，做课件，然后再讲给学生听，但学生们往往反映听不懂。”
|
||||
|
||||
### 7.3.2 老师的发言
|
||||
|
||||
木头：“那为什么学生听不懂呢？”
|
||||
木头：“我也觉得那几本书都很好，那为什么学生听不懂呢？”
|
||||
|
||||
张老师：“首先是这些书本身的内容难度偏大，教课的老师们也是刚刚接触这方面的知识，自己理解起来还需要时间，讲课时也做不到融会贯通。”
|
||||
|
||||
|
|
@ -6,12 +6,10 @@
|
|||
- 用户需求
|
||||
- 功能需求
|
||||
|
||||
|
||||
<img src="img/Slide14.JPG"/>
|
||||
|
||||
图 7.4.1 - 需求层次分析
|
||||
|
||||
|
||||
下面的故事虽然是面向学校教育系统软件的需求分析，而面向企业的软件需求层次也是大同小异，同样可以分为三个层次。但是面向大众的软件，比如我们常用的办公软件、手机软件，就不符合这三个层次特征，我们将在第七章讲述。
|
||||
|
||||
### 7.4.1 业务需求（Business Requirement）
|
||||
|
|
@ -23,12 +21,10 @@
|
|||
|
||||
我们把这种需求叫做业务需求（因为需求来自业务管理者）或客户需求（客户代表一个法人或者一个企业，并非指某个具体的人）。
|
||||
|
||||
|
||||
<img src="img/Slide15.JPG"/>
|
||||
|
||||
图 7.4.2 - 第一层次：业务需求
|
||||
|
||||
|
||||
- 来源：投资人、负责人、管理者等，非直接用户。
|
||||
- 内容：说明需求的背景原因、系统目标、战略理念。
|
||||
- 作用：指导系统构建的根本基础。
|
||||
|
|
@ -40,7 +36,6 @@
|
|||
|
||||
也有一些观点认为这一层叫做目标需求，下一层叫做业务需求$^{[3]}$。还有另外一种分类方法，把校长的宏观需求称作“组织级需求”，把教务处主任的需求称作“业务需求”。我们在这里按照大多数文献的命名方式，以便读者可以方便地相互对照。
|
||||
|
||||
|
||||
### 7.4.2 用户需求（User Requirement）
|
||||
|
||||
我们再来看看老师们和机房主任的需求。
|
||||
|
|
@ -51,12 +46,10 @@
|
|||
|
||||
我们把这种需求叫做用户需求（因为需求来自直接用户）。
|
||||
|
||||
|
||||
<img src="img/Slide16.JPG"/>
|
||||
|
||||
图 7.4.3 - 第二层次：用户需求
|
||||
|
||||
|
||||
它描述的是用户的目标，或用户要求系统必须能完成的任务。用例、场景描述、事件/响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。
|
||||
|
||||
- 来源：系统的实际操作、使用者。
|
||||
|
|
@ -68,12 +61,10 @@
|
|||
|
||||
第三层次的需求，有些直接来自用户，更多的来自需求分析人员的需求分析结果。
|
||||
|
||||
|
||||
<img src="img/Slide17.JPG"/>
|
||||
|
||||
图 7.4.4 - 第三层次：功能需求
|
||||
|
||||
|
||||
这些需求分析人员被称为系统分析员，在微软没有为这个角色专门设立岗位，而是由资深的开发人员担任。系统分析员一般被要求在领域和技术两个方面都有较深的理解，才能够架起从需求到设计的桥梁。需求分析的结果就是《需求规格说明书》。
|
||||
|
||||
功能需求描述开发人员需要实现什么，习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”，有时也被称作行为需求（behavioral requirement）。用户利用这些功能来完成任务，满足业务需求。
|
||||
|
|
@ -83,17 +74,14 @@
|
|||
- 作用：指导系统后续的设计和开发，是需求分析的完成标志。
|
||||
- 输出：通过对这一层次需求的分析，应该输出《需求规格说明书》，还有其它一些重要的图和模型，将会在下几节中详细说明。
|
||||
|
||||
|
||||
### 7.4.4 需求来源
|
||||
|
||||
从上面的故事中，虽然所有的“需求”都是从客户的语言文字描述中得到的，但其实是有背后的领域知识的。更进一步地，我们可以挖掘整理出真正的需求来源，如图 7.4.5 所示。
|
||||
|
||||
|
||||
<img src="img/Slide18.JPG"/>
|
||||
|
||||
图 7.4.5 - 需求的来源
|
||||
|
||||
|
||||
- 市场需求：最终用户、客户、产品人员
|
||||
- 监管需求：政府、行业、企业
|
||||
- 技术需求：软件开发团队、合作团队
|
||||
|
|
@ -111,4 +99,4 @@
|
|||
- 技术创新带来的新功能
|
||||
- 多个产品的融合
|
||||
|
||||
所以，需求的引导也一般是由产品团队来完成的。就如同前面的一个故事中讲到的，用户需要快马，福特就制造了汽车。在福特那个年代，养马当然比买车便宜，但是现在养马反而是件奢侈的事情了，养马的需求从快速通行的需要变成了财大气粗的任性。
|
||||
所以，需求的引导也一般是由产品团队来完成的。就如同前面的一个故事中讲到的，用户需要快马，福特就制造了汽车。在福特那个年代，养马当然比买车便宜，但是现在养马反而是件奢侈的事情了，养马的需求从快速通行的需要变成了财大气粗的任性。
|
||||
|
|
@ -140,7 +140,7 @@ $$
|
|||
\end{aligned}
|
||||
$$
|
||||
|
||||
#### 来自甲方 - 资源约束
|
||||
#### 1. 来自甲方 - 资源约束
|
||||
|
||||
客户总是会在下面几个问题上“斤斤计较”：
|
||||
|
||||
|
|
@ -154,7 +154,7 @@ $$
|
|||
|
||||
即开发软件、部署软件、后期宣传所需要的费用。
|
||||
|
||||
#### 来自乙方 - 开发约束
|
||||
#### 2. 来自乙方 - 开发约束
|
||||
|
||||
主要是乙方要考虑自己的开发团队的具体情况，比如：
|
||||
|
||||
|
|
@ -184,7 +184,7 @@ $$
|
|||
|
||||
- 成员地理分布，主要是指像微软这种跨国公司，经常有跨区域合作的情况。比如做手机上的 Edge 浏览器时，PM 主要在美国，开发人员主要在中国，但是分在北京和苏州两个地方，还有一些依赖模块在欧洲开发。这需要制定好接口，并协调多方的进度保持一致。
|
||||
|
||||
#### 来自环境 - 技术约束
|
||||
#### 3. 来自环境 - 技术约束
|
||||
|
||||
- 批准的技术清单
|
||||
|
||||
|
|
@ -204,7 +204,7 @@ $$
|
|||
|
||||
GPL（General Public License）协议规定，如果使用了它人的开源软件，那么自己的软件必须也开源。
|
||||
|
||||
#### 来自领域 - 业务约束
|
||||
#### 4. 来自领域 - 业务约束
|
||||
|
||||
- 行业标准
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,6 @@
|
|||
|
||||
|
||||
## 12.2 业务架构
|
||||
|
||||
数字化学校系统
|
||||
|
||||
|
|
@ -1,41 +1,23 @@
|
|||
|
||||
|
||||
<img src="img/Slide1.SVG"/>
|
||||
业务架构
|
||||
|
||||
逻辑架构
|
||||
|
||||
运行架构
|
||||
|
||||
开发架构
|
||||
|
||||
物理架构
|
||||
|
||||
数据架构
|
||||
|
||||
|
||||
概要设计、总体设计、架构设计，high level design
|
||||
|
||||
详细设计（design pattern，low level design）
|
||||
|
||||
|
||||
|
||||
架构，源于中国古代建筑术语。架 = 加 + 木，构 = 木 + 勾，把一堆木头加起来并互相勾住，以形成一个完整的、牢固的建筑。引申到软件产品概念上，就是：
|
||||
|
||||
1. 把一个软件项目整体切分成不同的部分；
|
||||
2. 定义不同的角色来完成这些部分的工作；
|
||||
3. 建立相互沟通的机制，使得这些部分能够有机的结合为一个整体，并完成这个整体所需要的所有功能。
|
||||
|
||||
有两种常用的架构方法：RUP（Rational Unified Process，统一开发过程），TOGAF（The Open Group Architecture Framework）
|
||||
|
||||
|
||||
|
||||
<img src="img/Slide2.SVG"/>
|
||||
|
||||
|
||||
https://blog.csdn.net/lfsf802/article/details/8487990
|
||||
|
||||
https://towardsdatascience.com/10-common-software-architectural-patterns-in-a-nutshell-a0b47a1e9013
|
||||
|
||||
https://zhuanlan.zhihu.com/p/41395345
|
||||
|
||||
https://blog.csdn.net/Jayphone17/article/details/103651076
|
||||
|
||||
https://zhuanlan.zhihu.com/p/41395345
|
||||
|
||||
https://www.ou.nl/documents/40554/791670/IM0203_03.pdf/30dae517-691e-b3c7-22ed-a55ad27726d6
|
||||
|
||||
https://towardsdatascience.com/10-common-software-architectural-patterns-in-a-nutshell-a0b47a1e9013
|
||||
|
||||
https://max.book118.com/html/2016/1115/63079375.shtm
|
||||
|
||||
https://blog.csdn.net/hguisu/article/details/78259898
|
||||
||RUP 4+1|UML|TOGAF|Other|$\rightarrow$|统一名称|
|
||||
|-|-|-|-|-|-|-|
|
||||
|1|场景视图|用户模型|业务架构|逻辑架构|$\rightarrow$|业务场景架构|
|
||||
|2|逻辑视图|结构模型|应用架构|逻辑架构|$\rightarrow$|逻辑结构架构|
|
||||
|3|过程视图|行为模型|应用架构|运行架构|$\rightarrow$|行为过程架构|
|
||||
|4|开发视图|实现模型|技术架构|开发架构|$\rightarrow$|开发架构|
|
||||
|5|物理视图|环境模型|技术架构|物理架构|$\rightarrow$|物理环境架构|
|
||||
|6|N/A|N/A|数据架构|数据架构|$\rightarrow$|数据存储架构|
|
||||
|
|
|
|||
|
|
@ -6,49 +6,48 @@
|
|||
|
||||
#### 1. 架构、架构师、构建、框架、结构
|
||||
|
||||
**架构师**（architect）使用**架构**模式**构建**（construct）了一个**框架**（framework），用于约束那些开放者们只能使用规定的**结构**（structure）来进行二次开发。
|
||||
**架构师**（architect）使用**架构**模式**构建**（construct）了一个**框架**（framework），用于约束那些开发者们只能使用规定的**结构**（structure）来进行二次开发。
|
||||
|
||||
#### 2. 架构设计、系统设计、概要设计、详细设计
|
||||
#### 2. 架构设计、总体设计、系统设计、概要设计、详细设计
|
||||
|
||||
- 在大型系统中，需求分析结束后，首先要做的是**架构设计**。由架构师来负责。**架构设计**比**概要设计**更高层、更抽象。
|
||||
- 对于中小型项目，架构设计可以不做，而是直接做**概要设计**，在概要设计里用**总体设计**这一名词来代表**架构设计**。由技术专家来负责。
|
||||
- **系统设计**如果是应用于软件领域，则其含义 = 架构设计 + 概要设计 + 详细设计。
|
||||
- 在小型项目中，可以用概要设计代替架构设计和详细设计，只不过要求概要设计写得稍微细一些，上可以涵盖架构设计的内容，下可以涵盖详细设计的内容。
|
||||
|
||||
架构设计比概要设计更抽象。
|
||||
所以，总的来说软件的系统设计顺序为：架构设计$\rightarrow$概要设计$\rightarrow$详细设计，总结为表 12.2.1。
|
||||
|
||||
概要设计主要要描述出系统分为哪些功能模块，每个模块又可以分为哪些子模块，每个模块的主要功能是什么等，
|
||||
表 12.2.1 几种“设计”概念的比较
|
||||
|
||||
而架构设计一般不需要详细描述到子模块，主要描述系统的层次结构、各层包含的重要的模块、各层之间的接口和通讯方式、大模块的物理部署等。
|
||||
||架构设计|概要设计|详细设计|
|
||||
|-|-|-|-|
|
||||
|负责人|架构师|技术专家|开发人员|
|
||||
|内容|描述系统层次结构、各<br>层包含的重要的模块、<br>各层之间的接口和通讯<br>方式、大模块的物理部<br>署等。|描述出系统分为哪些功<br>能模块，每个模块又可<br>以分为哪些子模块每个<br>模块的主要功能是什么。|针对各个模块进行的，<br>包括算法、流程、状<br>态、数据等等，必须符<br>合概要设计的约束，如<br>功能约定、接口约定。|
|
||||
|用途|确定轮廓，合理规划|理清脉络，层次分解|确定细节，编写代码|
|
||||
|输出文档|架构设计说明书|概要设计说明书|详细设计说明书|
|
||||
|
||||
一般大型项目都是在需求分析之后先做架构设计，再进行概要设计和详细设计，不过一般中小型的项目很多都没有架构设计，直接进行概要设计，在概要设计里阐述架构设计。
|
||||
|
||||
|
||||
- 架构
|
||||
- 功能
|
||||
- 数据
|
||||
|
||||
本着敏捷开发的原则，概要+详细设计比较臃肿，详细设计可以针对具体的模块、算法，由相应的开发人员完成。或者，把概要设计做得稍微详细一些，可以代替详细设计。
|
||||
无论那种级别的设计，都应该包含：结构、功能、数据三个要素。
|
||||
|
||||
#### 3. 架构、框架、设计模式
|
||||
|
||||
见图 12.2.1。
|
||||
|
||||
<img src="img/Slide7.SVG"/>
|
||||
|
||||
|
||||
从 12.1 节的架构进化的故事中，想必读者已经对“架构”有了一些基本的概念。本章中主要讨论架构设计，所以先澄清一下三个重要概念：
|
||||
图 12.2.1 架构、框架、设计模式之间的关系
|
||||
|
||||
**（1）架构**
|
||||
|
||||
简单的说架构就是一个蓝图，是一种设计方案，将客户的不同需求抽象成为抽象组件，并且能够描述这些抽象组件之间的通信和调用。
|
||||
软件架构指软件系统的顶层结构。简单的说架构就是一个蓝图，是一种设计方案，将客户的需求抽象成为组件，并且能够描述这些抽象组件之间的通信和调用。
|
||||
|
||||
比如，三层架构、事件总线架构等，这些架构代表的模式也可以叫做架构模式，它定义了系统的总体结构。
|
||||
比如，三层架构、事件总线架构等，它定义了系统的总体结构。
|
||||
|
||||
**（2）框架**
|
||||
|
||||
软件框架是项目软件开发过程中提取特定领域软件的共性部分形成的体系结构，不同领域的软件项目有着不同的框架类型。框架不是现成可用的应用系统。而是一个半成品，提供了诸多服务，开发人员进行二次开发，实现具体功能的应用系统。框架是代码，是工具，不是知识。
|
||||
软件框架是项目软件开发过程中提取特定领域软件的共性部分形成的体系结构，不同领域的软件项目有着不同的框架类型。框架不是现成可用的应用系统，而是一个半成品，提供了诸多服务，开发人员在框架内部进行二次开发，实现具体功能的应用系统。框架是代码，是工具，不是知识。
|
||||
|
||||
比如 .Net Framework 是开发框架，PyTorch 是深度学习框架。一旦使用了某个框架，就会有一定的粘性，想迁移到其它框架上会有困难。比如使用 PyTorch 搭建好神经网络模型后，如果想迁移到 Tensor Flow（另外一个深度学习框架）上，需要重新学习语法、重新搭建、重新训练。
|
||||
|
||||
框架有哪些？
|
||||
|
||||
C++语言的QT、MFC、gtk，Java语言的SSH 、SSI，php语言的 smarty(MVC模式)，python语言的django(MTV模式)等等
|
||||
|
||||
【最佳实践】
|
||||
|
||||
不要轻易地决定是否使用框架，一旦投入，就和框架绑定了，需要学习理解框架的底层逻辑，代码结构要遵守框架的约定，框架的 bug 也会让项目陷入泥潭。
|
||||
|
|
@ -57,18 +56,25 @@ C++语言的QT、MFC、gtk，Java语言的SSH 、SSI，php语言的 smarty(MVC
|
|||
|
||||
【最佳实践】
|
||||
|
||||
不要轻易决定自己写框架
|
||||
不要为了一个项目轻易决定自己写框架，原因如下：
|
||||
|
||||
- 与业务逻辑耦合
|
||||
|
||||
如果能够直接使用现有框架是最好的。但是如果项目有特殊需求，也不要轻易决定自己写框架，因为很难把具体的业务与框架分开，也就是说无法从一个特殊需求抽象出来一个框架。
|
||||
|
||||
- 没人用
|
||||
- 与业务逻辑耦合
|
||||
|
||||
写框架的目的是想以后重用，或者自己重用，或者让别人重用。但是大概率是没有人用的，除非这个框架可以解决通用问题。
|
||||
|
||||
在 5.3 节中讲到的强化学习资源优化平台（MARO），基本上没有可重用的可能，因为应用场景都有很大的差异；量化交易平台（Qlib）的应用场景相对比较明确，所以会有不少用户来尝试使用。
|
||||
|
||||
**（3）设计模式**
|
||||
|
||||
是一套被反复使用、广为人知的、经过分类的代码设计经验的总结，它强调的是一个设计问题的解决方法。设计模式是知识，是概念，不是代码。
|
||||
设计模式是一套被反复使用、广为人知的、经过分类的代码设计经验的总结，它强调的是一个设计问题的解决方法。设计模式是知识，是概念，不是代码。
|
||||
|
||||
稍微有些底层软件开发经验的读者，都知道有约 23 种软件设计模式，比如工厂模式、适配器模式、策略模式等等，目的是保证代码的可重用性、可读性、可靠性。而且还有 7 种设计原则，是上述的 23 种 设计模式要遵守的基本规则。
|
||||
|
||||
在上层的架构设计上，同样有设计原则和设计模式，一个合格的架构师就是根据这些原则和模式来工作的。
|
||||
在上层的架构设计上，同样有设计原则和设计模式，一个合格的架构师就是根据这些原则和模式来工作的。比如在设计模式中有观察者（订阅-发布）模式，在架构模式中有事件总线模式，其工作原理是相同的。
|
||||
|
||||
|
||||
**（4）三者的比较**
|
||||
|
|
@ -77,22 +83,22 @@ C++语言的QT、MFC、gtk，Java语言的SSH 、SSI，php语言的 smarty(MVC
|
|||
|
||||
- 首先架构应该是一个最大的概念，是最高层次的设计。所以在做一个项目的时候首先出来的应该是架构，是对整个问题的一个总体上的设计。可以根据已有架构模式衍生出具体的架构，或者自己设计出新的架构。一个架构设计中可能会用到多个框架和多个设计模式。
|
||||
|
||||
- 其次会考虑采用什么现有的框架或者自己实现框架来解决架构设计中的子系统、子任务。一个架构中，在不同的局部可能要采用不同框架，比如在靠近应用层的部分应该采用 MVC 框架，而靠近后台处理的部分应该采用 xx 框架。系统小的话，只使用一种框架也可以。框架是针对共性抽象出来的半成品，所以，如果开发者自己实现框架的话，基本上会和实例（实际的应用）代码混在一起，分不出哪个是框架，哪个是应用。
|
||||
- 其次会考虑采用什么现有的框架或者自己实现框架来解决架构设计中的子系统、子任务。一个架构中，在不同的局部可能要采用不同框架，比如在靠近应用层的部分应该采用 MVC 框架，而靠近后台处理的部分应该采用事件总线框架。系统小的话，只使用一种框架也可以。框架是针对共性抽象出来的半成品，所以，如果开发者自己实现框架的话，基本上会和实例（实际的应用）代码混在一起，分不出哪个是框架，哪个是应用。
|
||||
|
||||
- 最后，在具体的功能模块实现时就需要用到设计模式，所以设计模式就是解决单一问题的设计思路和解决方法。
|
||||
|
||||
这三者的共同点都是解决软件开发中的问题而出现的，而且都会表现出来的就是“高内聚，低耦合”的理念，就是让我们的设计更面向对象化。
|
||||
|
||||
所以我们要想做好一个好的项目，那么架构设计、框架选型、设计和使用、设计模式的使用是非常重要的。
|
||||
这三者的共同点都是解决软件开发中的问题而出现的，而且都会表现出来的就是“高内聚，低耦合”的理念，就是让我们的设计更面向对象化。所以我们要想做好一个项目，那么架构设计、框架选型、设计模式的使用，三者都是非常重要的。
|
||||
|
||||
简而言之：架构是大智慧，用来对软件设计进行分工；框架是半成品，加入代码来实现自己想要的功能；设计模式是小技巧，对具体问题提出解决方案，以提高代码复用率，降低耦合度。
|
||||
|
||||
|
||||
|
||||
### 12.2.2 架构设计方法
|
||||
|
||||
目前软件领域有几种主流的架构设计方法，见图 12.2.2。
|
||||
|
||||
<img src="img/Slide8.SVG"/>
|
||||
|
||||
图 12.2.2 主流的架构设计方法
|
||||
|
||||
#### 1. RUP 4+1
|
||||
|
||||
|
|
@ -100,6 +106,7 @@ RUP，Rational Unified Process，即统一开发过程。
|
|||
|
||||
<img src="img/Slide9.SVG"/>
|
||||
|
||||
图 12.2.3 RUP 4+1 视图
|
||||
|
||||
0. 场景视图（Scenario View）
|
||||
|
||||
|
|
@ -127,49 +134,43 @@ UML，即Unified Model Language，统一建模语言。
|
|||
|
||||
<img src="img/Slide10.SVG"/>
|
||||
|
||||
图 12.2.4 UML 分析模型
|
||||
|
||||
1. 用户模型（Use Case View）
|
||||
|
||||
强调从用户的角度看到的或需要的系统功能，是被称为参与者的外部用户所能观察到的系统功能的模型图。
|
||||
用用例图描述。
|
||||
强调从用户的角度看到的或需要的系统功能，是被称为参与者的外部用户所能观察到的系统功能的模型图。用用例图描述。
|
||||
|
||||
2. 结构模型（Logic View）
|
||||
|
||||
展现系统的静态或结构组成及特征，也称为结构模型视图(Structural Model View)或静态视图(Static View)。
|
||||
用类图和对象描述。
|
||||
展现系统的静态或结构组成及特征，也称为结构模型视图（Structural Model View）或静态视图（Static View）。用类图和对象描述。
|
||||
|
||||
3. 行为模型（Concurrent View）
|
||||
|
||||
体现了系统的动态或行为特征，也称为行为模型视图(Behavioral Model View)或动态视图(Dynamic View)。
|
||||
用状态图、时序图、协作图、活动图描述。
|
||||
体现了系统的动态或行为特征，也称为行为模型视图（Behavioral Model View）或动态视图（Dynamic View）。用状态图、时序图、协作图、活动图描述。
|
||||
|
||||
4. 实现模型（Component View）
|
||||
|
||||
体现了系统实现的结构和行为特征，也称为实现模型视图(Implementation Model View)。
|
||||
用组件图描述。
|
||||
体现了系统实现的结构和行为特征，也称为实现模型视图（Implementation Model View）。用组件图描述。
|
||||
|
||||
5. 环境模型（Deployment View）
|
||||
|
||||
体现了系统实现环境的结构和行为特征，也称为环境模型视图(Environment Model View)或物理视图(Physical View)。
|
||||
用配置图描述。
|
||||
体现了系统实现环境的结构和行为特征，也称为环境模型视图（Environment Model View）或物理视图（Physical View）。用配置图描述。
|
||||
|
||||
#### 3. TOGAF
|
||||
|
||||
TOGAF，即 The Open Group Architecture Framework，开放组织架构框架，是由 The Open Group 这个开放组织指定的企业发展架构的方法和工具（即框架）。
|
||||
|
||||
<img src="img/Slide11.SVG"/>
|
||||
|
||||
|
||||
0. 组织架构
|
||||
|
||||
在 TOGAF 中不存在（所以图中为灰色），但却是客观存在的，由人或部门组成的公司管理层，不属于架构设计范畴。
|
||||
|
||||
1. 业务架构（Business Architecture）
|
||||
|
||||
业务战略、组织和关键业务流程。
|
||||
业务战略、管理、组织和关键业务流程，也叫做俯视架构。
|
||||
|
||||
2. 应用架构（Application Architecture）
|
||||
|
||||
也叫做刨面架构、逻辑架构。
|
||||
也叫做剖面架构、逻辑架构。
|
||||
|
||||
3. 数据架构（Data Architecture）
|
||||
|
||||
|
|
@ -179,7 +180,15 @@ TOGAF，即 The Open Group Architecture Framework，开放组织架构框架，
|
|||
|
||||
支持上述架构的必要软硬件，包括基础设施、中间件、网络、部署。
|
||||
|
||||
#### 4. 其它
|
||||
如图 12.2.5 左侧所示。
|
||||
|
||||
<img src="img/Slide11.SVG"/>
|
||||
|
||||
图 12.2.5 TOGAF架构模型和其它流派
|
||||
|
||||
#### 4. 其它流派
|
||||
|
||||
如图 12.2.5 右侧所示。
|
||||
|
||||
1. 开发架构
|
||||
|
||||
|
|
@ -195,42 +204,51 @@ TOGAF，即 The Open Group Architecture Framework，开放组织架构框架，
|
|||
|
||||
4. 数据架构
|
||||
|
||||
数据架构，更关注的是数据持久化和存储层面的问题，也可能会包括数据的分布、复制、同步等问题。更贴切来讲，如何选择需要的关系型数据库、流行的NOSQL，如何保障数据存储层面的性能、高可用性、灾备等等。很多时候，和物理架构是有紧密联系的，但它更关注数据存储层面的，物理架构更关注整个基础设施部署层面。
|
||||
数据架构，更关注的是数据持久化和存储层面的问题，也可能会包括数据的分布、复制、同步等问题。更贴切来讲，如何选择需要的关系型数据库、流行的 NoSql，如何保障数据存储层面的性能、高可用性、灾备等等。很多时候，和物理架构是有紧密联系的，但它更关注数据存储层面的，物理架构更关注整个基础设施部署层面。
|
||||
|
||||
5. 物理架构
|
||||
|
||||
物理架构，更关注的系统、网络、服务器等基础设施。例如：如何通过服务器部署和配置网络环境，来实现应用程序的“可伸缩性、高可用性”。或者举一个实际的例子，如何通过设计基础设施的架构，来保障网站能支持同时10W人在线、7*24小时提供服务，当超过10W人或者低于10W人在线时，可以很方便的调整部署架构来支撑。
|
||||
物理架构，更关注的系统、网络、服务器等基础设施。例如：如何通过服务器部署和配置网络环境，来实现应用程序的“可伸缩性、高可用性”。或者举一个实际的例子，如何通过设计基础设施的架构，来保障网站能支持同时 10 万人在线、7*24 小时提供服务，当超过 10 万人或者低于 10 万人在线时，可以很方便的调整部署架构来支撑。
|
||||
|
||||
|
||||
表 四种架构体系的统一
|
||||
|
||||
||RUP 4+1|UML|TOGAF|Other|$\rightarrow$|统一名称|
|
||||
|-|-|-|-|-|-|-|
|
||||
|1|场景视图|用户模型|业务架构|逻辑架构|$\rightarrow$|业务架构|
|
||||
|2|逻辑视图|结构模型|应用架构|逻辑架构|$\rightarrow$|逻辑架构|
|
||||
|3|过程视图|行为模型|应用架构|运行架构|$\rightarrow$|运行架构|
|
||||
|4|开发视图|实现模型|技术架构|开发架构|$\rightarrow$|开发架构|
|
||||
|5|物理视图|环境模型|技术架构|物理架构|$\rightarrow$|物理架构|
|
||||
|6|N/A|N/A|数据架构|数据架构|$\rightarrow$|数据架构|
|
||||
|
||||
|
||||
### 架构设计方法
|
||||
|
||||
最开始只有逻辑架构和物理架构
|
||||
|
||||
|
||||
逻辑架构 = 模块划分 + 接口定义 + 领域模型
|
||||
|
||||
运行架构 = 技术选型 + 控制流划分 + 同步关系
|
||||
|
||||
开发架构 = 技术选型 + 文件划分 + 编译关系
|
||||
|
||||
物理架构 = 硬件分布 + 软件部署 + 方案优化
|
||||
|
||||
数据架构 = 技术选型 + 存储格式 + 数据分布
|
||||
|
||||
|
||||
|
||||
大型系统
|
||||
|
||||
架构设计
|
||||
子系统设计
|
||||
|
||||
中型系统
|
||||
|
||||
系统设计
|
||||
|
||||
|
||||
|
||||
|
||||
### 12.2.3 技术架构模式
|
||||
|
||||
架构模式是在给定上下文中对软件构建中常见问题的通用、可重用解决方案。架构模式类似于软件设计模式，但层次更高、范围更广。
|
||||
|
||||
串行模式
|
||||
|
||||
1. 分层模式 (Layered pattern)
|
||||
4. 管道-过滤器模式 (Pipe-filter pattern)
|
||||
|
||||
|
||||
星形模式
|
||||
|
||||
2. 客户端-服务器模式 (Client-server pattern)
|
||||
6. 对等模式 (Peer-to-peer pattern)
|
||||
3. 主-从模式 (Master-slave pattern)
|
||||
|
||||
|
||||
树形模式
|
||||
|
||||
5. 代理模式 (Broker pattern)
|
||||
7. 事件总线模式 (Event-bus pattern)
|
||||
|
||||
环形模式
|
||||
|
||||
8. 模型-视图-控制器 (MVC) 模式 (Model-view-controller pattern)
|
||||
9. 黑板模式 (Blackboard pattern)
|
||||
10. 解析器模式 (Interpreter pattern)
|
||||
|
||||
|
||||
|
||||
|
|
@ -1,59 +0,0 @@
|
|||
|
||||
## 12.4 树形系统架构模式
|
||||
|
||||
### 12.4.1 代理模式 (Broker pattern)
|
||||
#### 架构说明
|
||||
|
||||
代理模式用于在结构化系统中对组件解耦。系统内各组件间采用远过程调用（remote service invocations）的方式交互。代理（Broker）组件充当组件间通讯的协调角色。
|
||||
|
||||
提供服务的组件将其能力（服务以及特性）发布给代理，客户端均向代理请求服务，由代理将请求重定向到先前已发布过对应服务的组件进行处理。
|
||||
|
||||
使用场景
|
||||
消息中间件软件：Apache ActiveMQ，Apache Kafka，RabbitMQ 与 JBoss 等等
|
||||
|
||||
#### 优缺点
|
||||
|
||||
优点：
|
||||
- 通过一个代理对象完成一系列的处理，在将来的程序改动中，就会允许动态更改、添加、删除和重新定位对象，这使开发人员的发布变得透明，符合开闭原则。
|
||||
- 代理模式能够协调调用者和被调用者，在一定程度上降低了系统的耦合度。
|
||||
- 远程代理使得客户端可以访问在远程机器上的对象，远程机器可能具有更好的计算机性能与处理速度，可以快速响应并处理客户端请求。
|
||||
- 代理模式在架构中还可以让虚拟代理通过使用一个小对象来代表一个大对象，可以减少系统资源的消耗，对系统进行优化并提高运行速度
|
||||
|
||||
缺点：
|
||||
|
||||
- 要求对服务描述进行标准化，我们要使用代理模式时则需要考虑异步处理机制、协议创建流程和错误环境控制，比较的繁琐。
|
||||
- 由于在客户端和真实主题之间增加了代理对象，因此有些类型的代理模式可能会造成请求的处理速度变慢。
|
||||
- 实现代理模式需要额外的工作，有些代理模式的实现非常复杂。这些问题就造成了不易开发的弱点。
|
||||
|
||||
|
||||
#### 应用场景
|
||||
|
||||
- 当客户端对象需要访问远程主机中的对象时可以使用远程代理。
|
||||
- 当需要用一个消耗资源较少的对象来代表一个消耗资源较多的对象，从而降低系统开销、缩短运行时间时可以使用虚拟代理，例如一个对象需要很长时间才能完成加载时。
|
||||
- 当需要为某一个被频繁访问的操作结果提供一个临时存储空间，以供多个客户端共享访问这些结果时可以使用缓冲代理。通过使用缓冲代理，系统无须在客户端每一次访问时都重新执行操作，只需直接从临时缓冲区获取操作结果即可。
|
||||
- 当需要控制对一个对象的访问，为不同用户提供不同级别的访问权限时可以使用保护代理。
|
||||
- 当需要为一个对象的访问（引用）提供一些额外的操作时可以使用智能引用代理。
|
||||
|
||||
|
||||
#### 几种“代理”的区别
|
||||
|
||||
|英文|中文|解释|比喻|
|
||||
|-|-|-|-|
|
||||
|Agent|自主性代理|智能性较高，接收到 A 的请求，自主决定访问 B 还是访问 C，然后把 B 或 C 的返回结果告诉 A，但 A 并不知道 B 或 C 的存在||
|
||||
|Broker|中介性代理|A 通过本代理得知 B 的存在，但是不知道如何访问 B，发送请求给代理，代理把该请求变成 B 可以听懂的语言发送给 B 并获得结果返回给 A|股票经纪人代买卖股票|
|
||||
|Delegate|委托性代理|A 不知道怎么才能从 B 那里得到服务，甚至不知道 B 的存在，就把请求告诉代理，代理完成其它的任务|律师代理诉讼|
|
||||
|Proxy|透传性代理|无智能，在 A 不能合法/有效地访问B时，把 A 的请求拿过来原封不动地传给 B，再把 B 的响应原封不动地回传给 A|传声筒|
|
||||
|
||||
### 12.4.2 事件总线模式 (Event-bus pattern)
|
||||
|
||||
#### 架构说明
|
||||
|
||||
事件总线模式应用于事件处理，主要由四个组件构成：事件源（event source），事件侦听者（event listener），通道（Channel）以及总线（event bus）。 事件源将消息发布到总线的特定通道，侦听者订阅相应的通道，事件源所发布的消息经通道通告给订阅通道的侦听者。
|
||||
|
||||
使用场景
|
||||
Android 开发
|
||||
通告（Notification）服务
|
||||
|
||||
#### 优缺点
|
||||
|
||||
#### 应用场景
|
||||
|
|
@ -1,3 +1,9 @@
|
|||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
https://blog.csdn.net/hguisu/article/details/78259898
|
||||
|
||||
|
||||
|
|
@ -16,3 +22,31 @@ https://blog.csdn.net/hguisu/article/details/78259898
|
|||
|
||||
https://blog.csdn.net/danpu0978/article/details/107274524
|
||||
|
||||
|
||||
|
||||
Which architectural pattern is best for a given situation depends on
|
||||
which requirements have the highest priority, such as:
|
||||
– Maintainability: how easy or difficult is it to add an additional pro59
|
||||
Open Universiteit Software Architecture
|
||||
cessing component, for instance to filter certain words? How easy
|
||||
or difficult is it to change the input format, by adding line numbers,
|
||||
for example? In the Pipe-Filter pattern for instance, adding a filter is
|
||||
very easy, but changing the input format might be hard.
|
||||
– Reusability: can individual components be reused in other systems?
|
||||
In this case, the Pipe-and-Filter pattern enhances reusability because
|
||||
of the uniform data format that is used.
|
||||
– Performance: is the response time small enough? Is overall resource
|
||||
behaviour (memory usage in this example) acceptable? Patterns that
|
||||
make use of parallelism, such as the Pipe-Filter pattern and the EventBus pattern, will have better performance. On the other hand, starting a complex system like the Event Bus system, or transforming
|
||||
data in every filter using a different data structure, may lower performance.
|
||||
– Explicitness: is it possible to provide feedback to the user? Per stage?
|
||||
This is not possible in the Pipe-Filter pattern, for instance.
|
||||
– Fault tolerance: for the KWIC example, there is no difference between
|
||||
the different solutions, but fault-tolerance would have been enhanced
|
||||
if a Master-slave pattern been applied.
|
||||
The list of requirements and their priorities will vary for every system.
|
||||
No rigid guidelines are available to tell you which pattern will be the
|
||||
best in every case. Much also depends on the implementation of the
|
||||
pattern. Independent processes, for example, may be implemented using threads or using processes on different machines. The balance between communication and computation, the capacity of the processors
|
||||
involved and the speed of communication between machines, among
|
||||
other things, will decide which implementation will have the best performance
|
||||
Различия файлов скрыты, потому что одна или несколько строк слишком длинны
|
До Ширина: | Высота: | Размер: 144 KiB |
Различия файлов скрыты, потому что одна или несколько строк слишком длинны
|
До Ширина: | Высота: | Размер: 39 KiB |
Различия файлов скрыты, потому что одна или несколько строк слишком длинны
|
До Ширина: | Высота: | Размер: 99 KiB |
Различия файлов скрыты, потому что одна или несколько строк слишком длинны
|
До Ширина: | Высота: | Размер: 51 KiB |
Различия файлов скрыты, потому что одна или несколько строк слишком длинны
|
До Ширина: | Высота: | Размер: 94 KiB |
Различия файлов скрыты, потому что одна или несколько строк слишком длинны
|
До Ширина: | Высота: | Размер: 164 KiB |
Различия файлов скрыты, потому что одна или несколько строк слишком длинны
|
До Ширина: | Высота: | Размер: 48 KiB |
Различия файлов скрыты, потому что одна или несколько строк слишком длинны
|
До Ширина: | Высота: | Размер: 39 KiB |
Различия файлов скрыты, потому что одна или несколько строк слишком длинны
|
До Ширина: | Высота: | Размер: 50 KiB |
Различия файлов скрыты, потому что одна или несколько строк слишком длинны
|
До Ширина: | Высота: | Размер: 71 KiB |
Различия файлов скрыты, потому что одна или несколько строк слишком длинны
|
До Ширина: | Высота: | Размер: 56 KiB |
Различия файлов скрыты, потому что одна или несколько строк слишком длинны
|
До Ширина: | Высота: | Размер: 49 KiB |
Различия файлов скрыты, потому что одна или несколько строк слишком длинны
|
До Ширина: | Высота: | Размер: 58 KiB |
Различия файлов скрыты, потому что одна или несколько строк слишком длинны
|
До Ширина: | Высота: | Размер: 64 KiB |
Различия файлов скрыты, потому что одна или несколько строк слишком длинны
|
До Ширина: | Высота: | Размер: 63 KiB |
Различия файлов скрыты, потому что одна или несколько строк слишком длинны
|
До Ширина: | Высота: | Размер: 64 KiB |
Различия файлов скрыты, потому что одна или несколько строк слишком длинны
|
До Ширина: | Высота: | Размер: 458 KiB |
Различия файлов скрыты, потому что одна или несколько строк слишком длинны
|
До Ширина: | Высота: | Размер: 63 KiB |
|
|
@ -0,0 +1,45 @@
|
|||
设计三大原则
|
||||
|
||||
https://cloud.tencent.com/developer/article/1372372
|
||||
|
||||
|
||||
### 架构设计的三个原则
|
||||
分别是合适原则、简单原则、演化原则
|
||||
|
||||
4.1 合适原则
|
||||
“合适优于业界领先”
|
||||
|
||||
根据团队人数、团队人员的技术水平选用难度合适的技术
|
||||
|
||||
根据业务场景选择合适的技术
|
||||
|
||||
4.2 简单原则
|
||||
“简单优于复杂”
|
||||
|
||||
软件领域的复杂性体现在两个方面：
|
||||
|
||||
结构的复杂性
|
||||
结构复杂的系统的特点：组成复杂系统的组件数量更多，同时这些组件之间的关系也更加复杂。
|
||||
|
||||
2.逻辑的复杂性
|
||||
|
||||
如果想降低结构复杂性，可以降低组件数量，将功能和逻辑聚在一个组件上，但是这带来了新问题：某个组件的逻辑太复杂，一样会带来各种问题。
|
||||
|
||||
复杂的电路意味更强大的功能，而复杂的架构却有很多问题的根本原因在于电路一旦设计好后进入生产，就不会再变，复杂性只是在设计时带来影响；
|
||||
而一个软件系统在投入使用后，后续还有源源不断的需求要实现，因此要不断地修改系统，复杂性在整个系统生命周期中都有很大影响。
|
||||
|
||||
4.3 演化原则
|
||||
“演化优于一步到位”
|
||||
|
||||
建筑一旦完成（甚至一旦开建）就不可再变，而软件却需要根据业务的发展不断地变化，因此需要进行演化，一开始业务没那么复杂，性能要求没那么高，就没必要做得太复杂，建议如下：
|
||||
|
||||
首先，设计出来的架构要满足当时的业务需要。
|
||||
其次，架构要不断地在实际应用过程中迭代，保留优秀的设计，修复有缺陷的设计，改正错误的设计，去掉无用的设计，使得架构逐渐完善。
|
||||
第三，当业务发生变化时，架构要扩展、重构，甚至重写；代码也许会重写，但有价值的经验、教训、逻辑、设计等（类似生物体内的基因）却可以在新架构中延续。
|
||||
4.4 总结
|
||||
三个原则其实是一体的，核心就是因为软件系统的复杂就意味着问题，变化才是主题，因此”适当“才是最好地应对变化的方式，而不是“过度”
|
||||
|
||||
合适原则第一考虑，优先满足业务需求；
|
||||
简单原则第二考虑，挑选简单方案快速落地验证；
|
||||
演进原则第三考虑，适当预测业务发展，感觉预测不准就不预测，等真的出现问题的时候演进即可
|
||||
|
||||
|
|
@ -0,0 +1,43 @@
|
|||
|
||||
|
||||
<img src="img/Slide1.SVG"/>
|
||||
|
||||
架构，源于中国古代建筑术语。架 = 加 + 木，构 = 木 + 勾，把一堆木头加起来并互相勾住，以形成一个完整的、牢固的建筑。引申到软件产品概念上，就是：
|
||||
|
||||
1. 结构切分：把一个软件项目整体切分成不同的部分；
|
||||
2. 功能定义：定义这些部分各自完成的局部功能；
|
||||
3. 关系建立：建立这些部分相互沟通的机制，使之结合为一个整体，并完成这个整体所需要的所有功能。
|
||||
|
||||
有四种常用的架构方法：
|
||||
|
||||
- RUP（Rational Unified Process）统一开发过程
|
||||
- UML（Unified Model Language）统一建模语言
|
||||
- TOGAF（The Open Group Architecture Framework）开发组织定义的架构框架
|
||||
- 其它流派
|
||||
|
||||
在本章中，主要讨论技术架构。
|
||||
|
||||
|
||||
<img src="img/Slide2.SVG"/>
|
||||
|
||||
|
||||
https://blog.csdn.net/lfsf802/article/details/8487990
|
||||
|
||||
https://towardsdatascience.com/10-common-software-architectural-patterns-in-a-nutshell-a0b47a1e9013
|
||||
|
||||
https://zhuanlan.zhihu.com/p/41395345
|
||||
|
||||
https://blog.csdn.net/Jayphone17/article/details/103651076
|
||||
|
||||
https://zhuanlan.zhihu.com/p/41395345
|
||||
|
||||
https://www.ou.nl/documents/40554/791670/IM0203_03.pdf/30dae517-691e-b3c7-22ed-a55ad27726d6
|
||||
|
||||
https://towardsdatascience.com/10-common-software-architectural-patterns-in-a-nutshell-a0b47a1e9013
|
||||
|
||||
https://max.book118.com/html/2016/1115/63079375.shtm
|
||||
|
||||
https://blog.csdn.net/hguisu/article/details/78259898
|
||||
|
||||
|
||||
https://help.aliyun.com/document_detail/207135.html
|
||||
|
|
@ -1,6 +1,8 @@
|
|||
## 12.1 架构演化的故事
|
||||
## 12.1 架构模式演化的故事
|
||||
|
||||
还记得第一章中关于“木头与软件工程的故事”吧？这里有另外一个版本，是同样的应用场景，但是想说明的是软件**架构**演化的故事。
|
||||
还记得第一章中关于“木头与软件工程的故事”吧？这里有另外一个版本，是同样的应用场景，但是想说明的是软件**技术架构**演化的故事。**架构**这个词包含好几个子概念，本小节中只讲其中的**技术架构**。
|
||||
|
||||
注意，我们讲的是架构**演化**，而不是**进化**，意思是用户需求处于什么阶段，我们就使用什么样的技术架构。演化的各个阶段的具体架构没有好坏之分，只要最适合当前需求的就是最好的。每个后续的阶段都会比上一个阶段更复杂，开发、维护、部署的成本都更高，所以要谨慎选择。
|
||||
|
||||
### 12.1.1 单机架构
|
||||
|
||||
|
|
@ -16,7 +18,7 @@
|
|||
|
||||
<img src="img/Slide3.SVG"/>
|
||||
|
||||
图 12.1.1 架构计划-1
|
||||
图 12.1.1 技术架构演化的原始阶段
|
||||
|
||||
### 12.1.2 点对点架构
|
||||
|
||||
|
|
@ -54,7 +56,7 @@
|
|||
|
||||
<img src="img/Slide4.SVG"/>
|
||||
|
||||
图 12.1.2 架构演化-2
|
||||
图 12.1.2 技术架构演化的初级阶段
|
||||
|
||||
### 12.1.5 MVC 架构
|
||||
|
||||
|
|
@ -82,7 +84,7 @@
|
|||
|
||||
<img src="img/Slide5.SVG"/>
|
||||
|
||||
图 12.1.3 架构演化-3
|
||||
图 12.1.3 技术架构演化的中级阶段
|
||||
|
||||
|
||||
### 12.1.7 多层架构
|
||||
|
|
@ -120,7 +122,7 @@
|
|||
|
||||
<img src="img/Slide6.SVG"/>
|
||||
|
||||
图 12.1.4 架构演化-4
|
||||
图 12.1.4 技术架构演化的高级阶段
|
||||
|
||||
### 12.1.9 性能问题
|
||||
|
||||
|
|
@ -134,7 +136,3 @@
|
|||
针对第二个问题，开发团队在数据库写入前端加了消息队列，使得大量的并发写入都先进入消息队列进行削峰处理，然后在分批次地写到数据库路中，可以保证数据不丢失，这是由消息队列的特性来保证的。这也可以看作是用空间换时间的缓存机制。
|
||||
|
||||
见图 12.1.4 阶段9，由于细节太多而版面有限无法绘制出来，所以采用了框架图。
|
||||
|
||||
### 12.1.10 总结
|
||||
|
||||
注意，我们讲的是架构**演化**，而不是**进化**，意思是用户需求处于什么阶段，我们就使用什么样的架构。演化的各个阶段的具体架构没有好坏之分，只要最适合当前需求的就是最好的。每个后续的阶段都会比上一个阶段更复杂，开发、维护、部署的成本都更高，所以要谨慎选择。
|
||||
|
|
@ -0,0 +1,71 @@
|
|||
|
||||
|
||||
### 12.2 技术架构模式
|
||||
|
||||
**架构模式**是在给定上下文中对软件构建中常见问题的通用、可重用解决方案。架构模式类似于软件设计模式，但层次更高、范围更广。架构对应着架构模式；框架本身就是个模式，只不过包含基础功能代码；而设计对应着设计模式。
|
||||
|
||||
所谓技术架构模式，就是面向实现的架构设计，用于指导后面的概要设计。在本章中主要讨论这种架构模式，其它的如逻辑、过程、数据等等的架构，在后面的章节讨论。
|
||||
|
||||
一些基本的技术架构模式如下：
|
||||
|
||||
一个复杂系统的架构是由以上这些架构模式有机组合而成。
|
||||
|
||||
|
||||
|
||||
|
||||
#### 星形模式
|
||||
|
||||
- 客户端-服务器模式（Client-server pattern）
|
||||
- 浏览器-服务器模式
|
||||
- 对等模式（Peer-to-peer pattern）
|
||||
- 主-从模式（Master-slave pattern）
|
||||
|
||||
#### 串行模式
|
||||
|
||||
- 分层模式（Layered pattern）
|
||||
- 管道-过滤器模式（Pipe-filter pattern）
|
||||
|
||||
#### 树形模式
|
||||
|
||||
- 代理模式（Broker pattern）
|
||||
- 事件总线模式（Event-bus pattern）
|
||||
- 微服务模式
|
||||
- 插件模式
|
||||
|
||||
#### 环形模式
|
||||
|
||||
- 模型-视图-控制器模式（Model-view-controller pattern）
|
||||
- 反馈模式
|
||||
|
||||
|
||||
|
||||
#### 一览
|
||||
|
||||
表 12.2.1 技术架构模式一览表
|
||||
|
||||
|名称|描述|优点|缺点|综合|
|
||||
|-|-|-|-|-|
|
||||
|客户端-服务器模式||||灵活性：低<br>发布易用性：低<br>可测试性：高<br>性能：低<br>可扩展性：低<br>开发容易度：高|
|
||||
|浏览器-服务器模式|||||
|
||||
|对等模式|
|
||||
|主-从模式|
|
||||
|分层模式|
|
||||
|管道-过滤器模式|
|
||||
|代理模式|
|
||||
|事件驱动模式||||灵活性：高<br>发布易用性：高<br>可测试性：低<br>性能：高<br>可扩展性：高<br>开发容易度：低|
|
||||
|微服务模式||||灵活性：高<br>发布易用性：高<br>可测试性：高<br>性能：低<br>可扩展性：高<br>开发容易度：高|
|
||||
|插件模式||||灵活性：高<br>发布易用性：高<br>可测试性：高<br>性能：高<br>可扩展性：低<br>开发容易度：低|
|
||||
|MVC 模式|
|
||||
|反馈模式|
|
||||
|
||||
|
||||
#### 其它模式
|
||||
|
||||
|
||||
- 黑板模式（Black Board）
|
||||
|
||||
黑板模式是一种常用的架构模式，应用中的多种不同数据处理逻辑相互影响和协同来完成数据分析处理。黑板模式允许多个消息读写者同时存在，消息的生产者和消费者完全分开。这就像一个黑板，任何一个教授（消息的生产者）都可以在其上书写消息，任何一个学生（消息的消费者）都可以从黑板上读取消息，两者在空间和时间上可以解耦，并且互不干扰。这种模式对于没有确定解决方案策略的问题是有用的。
|
||||
|
||||
- 解析器模式（Interpreter）
|
||||
- 空间模式
|
||||
- 六边形模式
|
||||
|
|
@ -1,12 +1,12 @@
|
|||
## 12.2 星形系统的架构模式
|
||||
## 12.3 星形系统的架构模式
|
||||
|
||||
### 12.2.1 客户端-服务器模式（Client-Server）
|
||||
### 12.3.1 客户端-服务器模式（Client-Server）
|
||||
|
||||
这是一种最传统、最基本的模式，简称为 C/S，是其它一切模式的基础。见图 12.2.1。
|
||||
这是一种最传统、最基本的模式，简称为 C/S，是其它一切模式的基础。见图 12.3.1。
|
||||
|
||||
<img src='img/Slide10.svg'>
|
||||
<img src='img/Slide8.svg'>
|
||||
|
||||
图 12.2.1 客户端-服务器架构
|
||||
图 12.3.1 客户端-服务器模式
|
||||
|
||||
#### 架构说明
|
||||
|
||||
|
|
@ -14,16 +14,30 @@
|
|||
|
||||
后来出现了个人电脑 PC（Personal Computer），运算能力很强，并且有了局域网络。这两个技术突破让人们可以重新构建代码，把关键逻辑和数据放在主机（后称服务器）上，在终端（后称客户端）上运行本地逻辑（用户专用）和界面，并通过快速的局域网络与服务器进行通信。主动发起请求的叫客户端，响应的一方叫服务器。当然，相比之下服务器的运算能力更强，是专用的商业计算机。
|
||||
|
||||
客户端-服务器模式由两个部分构成：**一台**服务器与**多个**客户端，拓扑结构为星形。服务器组件同时为多个客户端组件提供服务。客户端向服务器发启服务请求，服务器将相应服务信息回应给客户端。此外，服务器持续监听来自其它客户端的请求。二者之间一般采用 TCP/IP 网络协议，传统的架构是局域网，但是现在互联网速度很快，所以可以扩展到广域网。
|
||||
客户端-服务器模式由两个部分构成：**一台服务器与多个客户端**，拓扑结构为星形。服务器组件同时为多个客户端组件提供服务。客户端向服务器发启服务请求，服务器将相应服务信息回应给客户端。此外，服务器持续监听来自其它客户端的请求。二者之间一般采用 TCP/IP 网络协议，传统的架构是局域网，但是现在互联网速度很快，所以可以扩展到广域网。
|
||||
|
||||
#### 扩展模式
|
||||
|
||||
如图 12.3.1 扩展模式所示。
|
||||
|
||||
- 有些时候一台服务器不能满足客户端的所有请求，比如：在档案管理系统中，服务器 1 只负责处理查询身份证号码的请求，而服务器 2 只负责处理更改个人信息的请求。那么在客户端 1 中，不同的用户请求会发送到不同的服务器上，这是在客户端代码中预先配置好的。而在服务器端，服务器 1 的内存可能会比较大，因为它可以缓存成千上万个身份证号码，便于快速得到查询结果；而服务器 2 的硬盘（存储设备）读写可能会比较快，因为它要快速地更新数据。
|
||||
|
||||
- 还有一种可能就是两个客户端的权限不一样，客户端 1 权限较高，可以提供所有功能；而客户端 2 权限较低，只能提供部分功能。这在银行系统中常见：有的机器只能自助取钱，而另外一些机器可以存钱和取钱。
|
||||
|
||||
- 有些负载均衡网络设备，可以把客户端请求均匀地分配给服务台集群中的每一台服务器。也可以在服务器端软件中实现简单的负载均衡，即每次用户请求时先返回本服务器的繁忙状态：如果很忙，则告诉客户端访问其它服务器；如果不忙，则继续请求/响应；如果所有服务器都忙，则在客户端显示系统繁忙信息。
|
||||
|
||||
#### 应用场景
|
||||
|
||||
当需要在个人电脑内下载、安装软件，并且必须有服务器端的支持才能工作时，这类的应用都属于客户端-服务器模式，比如：
|
||||
|
||||
- 公司内的电子邮件服务
|
||||
- 公司内的文件共享服务和打印服务
|
||||
- 银行窗口业务
|
||||
- 图书馆查询系统
|
||||
- 联网游戏
|
||||
|
||||
目前使用的手机类应用，比如微信、淘宝、微博、京东等等，也都可以算作是客户端-服务器模式，只不过它们是通过广域网联系到服务器的。
|
||||
|
||||
#### 优缺点
|
||||
|
||||
优点：
|
||||
|
|
@ -43,25 +57,13 @@
|
|||
- 当客户端较多时，升级客户端软件不方便。
|
||||
- 当客户端操作系统不同时，需要开发多个版本的客户端软件。
|
||||
|
||||
#### 应用场景
|
||||
### 12.3.2 浏览器-服务器模式（Browser-Server)
|
||||
|
||||
当需要在个人电脑内下载、安装软件，并且必须有服务器端的支持才能工作时，这类的应用都属于客户端-服务器模式，比如：
|
||||
此模式简称为 B/S，从 C/S 模式发展而来。见图 12.3.2。
|
||||
|
||||
- 公司内的电子邮件服务
|
||||
- 公司内的文件共享服务和打印服务
|
||||
- 银行窗口业务
|
||||
- 图书馆查询系统
|
||||
- 联网游戏
|
||||
<img src='img/Slide9.svg'>
|
||||
|
||||
目前使用的手机类应用，比如微信、淘宝、微博、京东等等，也都可以算作是客户端-服务器模式。
|
||||
|
||||
### 12.2.2 浏览器-服务器模式（Browser-Server)
|
||||
|
||||
此模式简称为 B/S，从 C/S 模式发展而来。见图 12.2.2。
|
||||
|
||||
<img src='img/Slide11.svg'>
|
||||
|
||||
图 12.2.2 浏览器-服务器架构
|
||||
图 12.3.2 浏览器-服务器模式
|
||||
|
||||
#### 架构说明
|
||||
|
||||
|
|
@ -69,13 +71,13 @@
|
|||
|
||||
- 广域网网络速度提升
|
||||
- 浏览器引擎性能提升
|
||||
- 浏览器开发框架成熟
|
||||
- 基于浏览器的开发框架成熟
|
||||
|
||||
这三点让人们意识到，如果把业务逻辑都挪到网页中，那么在客户端只要安装一个浏览器就行了，而无需为了 10 种应用安装 10 种客户端，这无疑对软件厂商和最终用户都有利。
|
||||
这三点让人们意识到，如果把业务逻辑都挪到网页中，那么在客户端只要安装一个浏览器就行了，而无需为了 10 种应用安装 10 种客户端，这无疑对软件厂商和最终用户都有利。这也是十几年前各大厂商竞相各自发展自己的浏览器的原因，虽然无法控制用户访问的页面地址，但是它毕竟是个客户端软件，可以做很多事情，比如推荐和广告。
|
||||
|
||||
#### 与 C/S 架构的比较
|
||||
|
||||
表 12.2.1 C/S 架构与 B/S 架构的比较
|
||||
表 12.3.1 C/S 架构与 B/S 架构的比较
|
||||
|
||||
||C/S|B/S|
|
||||
|-|-|-|
|
||||
|
|
@ -94,15 +96,15 @@
|
|||
|
||||
常见的是信息发布，但是由于浏览器技术的发展，几乎可以应用于任何应用场景。
|
||||
|
||||
从图 12.2.2 的组网实例可以看到，客户端可以使用任何操作系统上的任何浏览器。公司内部可以有自己的 Web 服务器，在局域网内直接访问内部的网页信息；通过路由器访问互联网上的外部 Web 服务器。
|
||||
从图 12.3.2 的组网实例可以看到，客户端可以使用任何操作系统上的任何浏览器。公司内部可以有自己的 Web 服务器，在局域网内直接访问内部的网页信息；通过路由器访问互联网上的外部 Web 服务器。
|
||||
|
||||
### 12.2.3 对等模式（Peer-to-peer）
|
||||
### 12.3.3 对等模式（Peer-to-Peer）
|
||||
|
||||
这是客户端-服务器模式的双向扩展。见图 12.2.3。
|
||||
这是客户端-服务器模式的双向扩展。见图 12.3.3。
|
||||
|
||||
<img src='img/Slide12.svg'>
|
||||
<img src='img/Slide10.svg'>
|
||||
|
||||
图 12.2.3 对等架构
|
||||
图 12.3.3 对等模式
|
||||
|
||||
#### 架构说明
|
||||
|
||||
|
|
@ -114,6 +116,12 @@
|
|||
|
||||
如果有多个节点，它们之间的两两互相连接也可以看作是对等模式。只从一个节点向外看，还是星形网络。
|
||||
|
||||
#### 应用场景
|
||||
|
||||
- 网络文件共享系统：Gnutella 目前是一个分布式文件共享协议的名称，主要用于分享音乐文件。此名称有时也用来指该网络本身以及原始的 Gnutella 软件。
|
||||
- 流媒体协议：P2PTV 与 PDTP，众多客户端访问媒体服务器所造成的压力是服务器所不能承受的，因此，当新的请求到达时，服务器会根据访问记录把请求转给刚刚访问了相关媒体数据的客户端，然后在两个客户端之间做媒体数据传输。
|
||||
- 区块链：区块链是一个去中心化的数据库，由很多独立的节点组成，分布在世界各地，通过互联网相互点对点连接，每个节点都具有数据层、网络层、共识层、激励层、合约层和应用层，集体维护一个可靠数据库，可用于智能合约、证券交易、电子商务、物联网、社交通讯、文件存储、存在性证明、身份验证、股权众筹、金融征信等领域。
|
||||
|
||||
#### 优缺点
|
||||
|
||||
优点：
|
||||
|
|
@ -131,27 +139,31 @@
|
|||
- 网络安全性差，资源分散，容易有薄弱环节
|
||||
- 当用户所在的节点做为服务器时，会影响用户本地的计算性能。
|
||||
|
||||
#### 应用场景
|
||||
### 12.3.4 主从模式（Master-Slave/Primary-Secondary）
|
||||
|
||||
- 网络文件共享系统：Gnutella 目前是一个分布式文件共享协议的名称，主要用于分享音乐文件。此名称有时也用来指该网络本身以及原始的 Gnutella 软件。
|
||||
- 流媒体协议：P2PTV 与 PDTP，众多客户端访问媒体服务器所造成的压力是服务器所不能承受的，因此，当新的请求到达时，服务器会根据访问记录把请求转给刚刚访问了相关媒体数据的客户端，然后在两个客户端之间做媒体数据传输。
|
||||
- 区块链：区块链是一个去中心化的数据库，由很多独立的节点组成，分布在世界各地，通过互联网相互点对点连接，每个节点都具有数据层、网络层、共识层、激励层、合约层和应用层，集体维护一个可靠数据库，可用于智能合约、证券交易、电子商务、物联网、社交通讯、文件存储、存在性证明、身份验证、股权众筹、金融征信等领域。
|
||||
因为 Slave 这个词比较敏感，因此英文中更多地使用 Primary-Secondary，我们只要知道 Slave 不是“奴隶”的意思就好。见图 12.3.4。
|
||||
|
||||
### 12.2.4 主从模式（Master-Slave/Primary-Secondary）
|
||||
<img src='img/Slide11.svg'>
|
||||
|
||||
因为 Slave 这个词比较敏感，因此英文中更多地使用 Primary-Secondary，我们只要知道 Slave 不是“奴隶”的意思就好。见图 12.2.4。
|
||||
|
||||
<img src='img/Slide13.svg'>
|
||||
|
||||
图 12.2.4 主从架构
|
||||
图 12.3.4 主从模式
|
||||
|
||||
#### 架构模式
|
||||
|
||||
这种模式由两部分组成：主节点和从节点。主节点将工作分配给不同的从节点，并根据从节点返回的结果计算最终结果。图 1.2.4 右侧显示了主从节点之间分配工作的顺序图，其中有一个硬性的要求：初始任务必须是可以**分割**的。
|
||||
这种模式由两部分组成：主节点和从节点。主节点将工作分配给不同的从节点，并根据从节点返回的结果计算最终结果。图 12.3.4 右侧显示了主从节点之间分配工作的顺序图，其中有一个硬性的要求：初始任务必须是可以**分割**的。
|
||||
|
||||
主从模式是分治（divide-and-conquer）原则的一个例子。每个从节点都是独立的，没有任何共享状态，因为它们是并行运行，或者是在同一个主机的不同进程中，或者是在不同的主机上，所以主从通信的延迟可能是一个问题。
|
||||
|
||||
### 优缺点
|
||||
#### 应用场景
|
||||
|
||||
那么什么叫做可以分割？注意“分割”这个词比较生硬，它并非智能地“分解”，也非理性地“分析”。有几种应用：
|
||||
|
||||
- 并行计算：把一批数据或任务整齐地拆分成 N 份儿，然后分配给 N 个从节点去处理。比如大规模的并行计算时，可以把多个矩阵的运算分配给多个从节点并行完成，再在主节点中合并。
|
||||
- 容错：主节点把同一个计算任务分配个多个从节点，然后从最快结束运算的从节点那里获得返回结果，并返回给调用者；或者是比较所有从节点的返回结果，取相似性最高的结果（三个结果是1.512，一个结果是1.511，则取1.512），返回给调用者。
|
||||
- 提供准确度：不同的从节点执行同一个任务，但是它们各自的实现方式不同，比如，一个是用神经网络推理，一个用线性回归做预测，还有一个用表格匹配法取近似值，最终在主节点上用一种策略来决定最佳结果，如平均值或最多相似值。
|
||||
- 数据库复制：主数据库被视为权威源数据库，从数据库与之同步。在有读取请求时，主数据库把请求转给从数据库，以提高并非读取的速度；在有写入请求时，只发生在主数据库上，然后再同步给从数据库。
|
||||
|
||||
|
||||
#### 优缺点
|
||||
|
||||
优点：
|
||||
|
||||
|
|
@ -165,13 +177,3 @@
|
|||
- 同步延迟问题，主从节点上的数据在某一时刻有可能不一致，不适合于要求一致性高的场合。
|
||||
- 如果有大量写操作，会集中在主节点上。
|
||||
- 主节点发生故障会比较麻烦，自动切换的复杂度高。
|
||||
|
||||
#### 应用场景
|
||||
|
||||
那么什么叫做可以分割？注意“分割”这个词比较生硬，它并非智能地“分解”，也非理性地“分析”。有几种应用：
|
||||
|
||||
- 并行计算：把一批数据或任务整齐地拆分成 N 份儿，然后分配给 N 个从节点去处理。比如大规模的并行计算时，可以把多个矩阵的运算分配给多个从节点并行完成，再在主节点中合并。
|
||||
- 容错：主节点把同一个计算任务分配个多个从节点，然后从最快结束运算的从节点那里获得返回结果，并返回给调用者；或者是比较所有从节点的返回结果，取相似性最高的结果（三个结果是1.512，一个结果是1.511，则取1.512），返回给调用者。
|
||||
- 提供准确度：不同的从节点执行同一个任务，但是它们各自的实现方式不同，比如，一个是用神经网络推理，一个用线性回归做预测，还有一个用表格匹配法取近似值，最终在主节点上用一种策略来决定最佳结果，如平均值或最多相似值。
|
||||
- 数据库复制：主数据库被视为权威源数据库，从数据库与之同步。在有读取请求时，主数据库把请求转给从数据库，以提高并非读取的速度；在有写入请求时，只发生在主数据库上，然后再同步给从数据库。
|
||||
|
||||
|
|
@ -1,14 +1,13 @@
|
|||
|
||||
## 12.3 串行系统架构模式
|
||||
## 12.4 串行系统架构模式
|
||||
|
||||
### 12.4.1 管道-过滤器模式 (Pipe-Filter)
|
||||
|
||||
### 12.3.1 管道-过滤器模式 (Pipe-filter pattern)
|
||||
见图 12.4.1。
|
||||
|
||||
见图 12.3.1。
|
||||
<img src='img/Slide12.svg'>
|
||||
|
||||
<img src='img/Slide15.svg'>
|
||||
|
||||
图 12.3.1 管道-过滤器架构
|
||||
图 12.4.1 管道-过滤器模式
|
||||
|
||||
#### 架构说明
|
||||
|
||||
|
|
@ -23,6 +22,21 @@
|
|||
|
||||
允许一个过滤器把数据分可后分别推送到不同的管道中，以便后续的不同逻辑的过滤器处理，甚至有可能进入不同的数据汇点。或者是在一开始，就有不同的数据源进入，但是共享某些过滤器（这种情况一般是分当作两个 pipeline 处理）。
|
||||
|
||||
#### 应用场景
|
||||
|
||||
在 Unix 系统中的 Shell，就是一个管道模式的例子，比如：
|
||||
|
||||
```
|
||||
cat a.txt | grep 'food' | sort | uniq > out
|
||||
```
|
||||
这个命令行首先用 cat 命令把 a.txt 中的文本行取出来，送给 grep 命令，把其中含有 'food' 的行取出来，送给 sort 命令，排序后把结果送给 uniq 命令去重，最后输出到 out。
|
||||
|
||||
管道过滤器模式的另外一个例子是编译器，如图 12.4.2 右侧所示。其中一个词法分析器分析源文件并将生成的符号序列发送到解析器，产生语法树，再由语义分析器产生增强语法树。然后由代码生成器用来生成字节代码，这些代码被优化后，并最终被翻译成机器代码（可能需要更多或更少的步骤）。
|
||||
|
||||
其实最常见的是我们经常所说的 Pipeline，可以应用于各种数据预处理中。比如：针对海量的原始数据，第一步可以先去掉字段不完整的记录，第二步删除无用字段以减小数据尺寸，第三步去重以避免后续逻辑混乱，第四步把纯文本格式变成二进制格式，等等。每一步都是过滤器，每两步之间的管道可以用临时文件，也可以用内存数据结构，或者是系统管道。
|
||||
|
||||
一种特殊的 Pipeline 是针对代码的，叫做 CI/CD Pipeline，经常用于团队合作开发流程中，主要功能是执行单元测试，当然也可以加入一些集成测试的单元。
|
||||
|
||||
#### 优缺点
|
||||
|
||||
优点：
|
||||
|
|
@ -36,26 +50,13 @@
|
|||
- 性能较低，一般用于非实时系统的后同数据处理流程中。
|
||||
- 数据传输和转换开销大，注意中间数据存储要及时清理。
|
||||
|
||||
#### 应用场景
|
||||
### 12.4.2 分层模式（Layer）
|
||||
|
||||
在 Unix 系统中的 Shell，就是一个管道模式的例子，比如：
|
||||
见图 12.4.2。
|
||||
|
||||
```
|
||||
cat a.txt | grep 'food' | sort | uniq > out
|
||||
```
|
||||
这个命令行首先用 cat 命令把 a.txt 中的文本行取出来，送给 grep 命令，把其中含有 'food' 的行取出来，送给 sort 命令，排序后把结果送给 uniq 命令去重，最后输出到 out。
|
||||
<img src='img/Slide13.svg'>
|
||||
|
||||
|
||||
管道过滤器模式的另外一个例子是编译器，如图 12.3.2 右侧所示。其中一个词法分析器分析源文件并将生成的符号序列发送到解析器，产生语法树，再由语义分析器产生增强语法树。然后由代码生成器用来生成字节代码，这些代码被优化后，并最终被翻译成机器代码（可能需要更多或更少的步骤）。
|
||||
|
||||
|
||||
### 12.3.2 分层模式
|
||||
|
||||
见图 12.3.2。
|
||||
|
||||
<img src='img/Slide14.svg'>
|
||||
|
||||
图 12.3.2 分层架构
|
||||
图 12.4.2 分层模式
|
||||
|
||||
#### 架构说明
|
||||
|
||||
|
|
@ -74,26 +75,9 @@ cat a.txt | grep 'food' | sort | uniq > out
|
|||
- 有些时候也可以跨层调用，比如从 第 3 层直接调用第 1 层的功能。
|
||||
- 同一层中有可能有两个独立的组，它们之间没有关系，只是根据上层业务逻辑提供不同的、独立的服务。
|
||||
|
||||
#### 优缺点
|
||||
|
||||
优点：
|
||||
|
||||
- 下层可以为所有的上层提供服务，调用灵活。一般不允许平级调用，否则被调用者就应该放在下一层。
|
||||
- 高内聚，低耦合，每一层都有标准化抽象。
|
||||
- 上下层之间指定好接口后，可以分组独立开发。
|
||||
- 测试、集成、排查错误、升级维护等都比较容易。
|
||||
|
||||
缺点：
|
||||
|
||||
- 逐层调用会降低系统性能，需要每一层都有相应的提高性能的措施。
|
||||
- 有时会导致级联的修改，这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。
|
||||
- 代码量变多，肯定比都聚合在一起的代码量大。
|
||||
|
||||
分层后代码量自然要比不分层多
|
||||
|
||||
#### 应用场景
|
||||
|
||||
一个复杂的应用系统通常被拆分为以下四个层次，如图 12.3.1 右侧所示：
|
||||
一个复杂的应用系统通常被拆分为以下四个层次，如图 12.4.1 右侧所示：
|
||||
|
||||
- 表示层（也称为 UI 层）
|
||||
- 应用层（也称为服务层）
|
||||
|
|
@ -112,3 +96,19 @@ cat a.txt | grep 'food' | sort | uniq > out
|
|||
- 表示层，加密解密、压缩解压缩。
|
||||
- 应用层，FTP、HTTP、POP3、SMTP 等重要协议都在这一层实现。
|
||||
|
||||
#### 优缺点
|
||||
|
||||
优点：
|
||||
|
||||
- 下层可以为所有的上层提供服务，调用灵活。一般不允许平级调用，否则被调用者就应该放在下一层。
|
||||
- 高内聚，低耦合，每一层都有标准化抽象。
|
||||
- 上下层之间指定好接口后，可以分组独立开发。
|
||||
- 测试、集成、排查错误、升级维护等都比较容易。
|
||||
|
||||
缺点：
|
||||
|
||||
- 逐层调用会降低系统性能，需要每一层都有相应的提高性能的措施。
|
||||
- 有时会导致级联的修改，这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。
|
||||
- 代码量变多，肯定比都聚合在一起的代码量大。
|
||||
|
||||
分层后代码量自然要比不分层多
|
||||
|
|
@ -0,0 +1,316 @@
|
|||
|
||||
## 12.5 树形系统架构模式
|
||||
|
||||
### 12.5.1 代理模式 (Broker)
|
||||
|
||||
#### 几种“代理”的区别
|
||||
|
||||
本小节中描述的代理都是具备 **A$\leftrightarrow$代理$\leftrightarrow$B 三个角色**的，其中，代理帮助 A 完成访问 B 的任务，但形式上有细微差别，见表 12.5.1 和图 12.5.1。
|
||||
|
||||
表 12.5.1 几种“代理”的区别
|
||||
|
||||
|英文|中文/性质|解释|比喻|
|
||||
|-|-|-|-|
|
||||
|Agent|自主性代理<br>独立主体<br>有独立决策能力|A 不知道 B 或 C 的存在。<br>代理接收到 A 的请求，自主决定访问 B 还是访问 C，然后把返回结果告诉 A。|各国驻联合国代表；<br>保险公司的代理代表<br>保险公司的利益|
|
||||
|Broker|中介性代理<br>独立主体<br>无自主决策<br>能力|B 在代理注册，A 通过代理得知 B 的存在，但不知道如何访问 B。<br>A 发送请求给代理，代理把该请求变成 B 可以听懂的语言发送给 B 并获得结果返回给 A|股票经纪人；<br>保险代理代表客户的<br>利益；<br>各类专卖店|
|
||||
|Proxy|透传性代理<br>非独立主体|A 知道 B 的存在，但不能直接访问 B。<br>代理把 A 的请求原封不动地传给 B，再把 B 的响应原封不动地回传给 A。|语言翻译；<br>代理服务器|
|
||||
|
||||
还有一种叫做 Delegate 即“委托性代理”的概念，它只涉及两个方面的角色，即委托人和被委托人，没有第三方，所以不符合本节中的“代理”概念。
|
||||
|
||||
<img src='img/Slide14.svg'>
|
||||
|
||||
图 12.5.1 代理模式
|
||||
|
||||
#### 架构说明
|
||||
|
||||
在复杂系统中经常遇到的情况是，服务器可能暂时不能用，或者是有比以前更多的服务器可用，但是客户端并不知道。所有有必要增加一个中间代理来解决这个问题。见图 12.5.1。
|
||||
|
||||
该模式由三部分组成：
|
||||
|
||||
- 服务器，提供服务，并向代理注册，以便让客户端知道自己的调用方法或者访问位置。
|
||||
- 代理，保持注册信息，当客户端的请求到达时，根据注册信息访问服务器，并把结果传回客户端。
|
||||
- 客户端，向代理发出服务请求。
|
||||
|
||||
代理模式用于在结构化系统中对组件解耦。系统内各组件间采用远过程调用（remote service invocations）的方式交互。代理（Broker）组件充当组件间通讯的协调角色。服务器将其能力（服务以及特性）发布（注册）给代理，客户端均向代理请求服务，由代理将请求重定向到先前已发布过对应服务的服务器进行处理。
|
||||
|
||||
以上是 Broker（中介性代理）的典型行为。对于 Agent 和 Proxy 代理有一些例外情况：服务器不需要向代理注册，代理预先知道服务器的能力和访问地址。
|
||||
|
||||
对于 Broker 模式，客户端很可能存在一个 proxy API，客户端软件在本地调用这个 proxy API 提供的方法，这个 proxy API 负责访问远程的 Broker 或服务器来完成服务请求。这就简化了客户端的开发复杂度，通信过程由 proxy API 来完成。
|
||||
|
||||
#### 应用场景
|
||||
|
||||
局域网中的计算机都没有公网的 IP 地址，所以必须通过代理服务器访问互联网上的任何主机。而通过代理即使能访问很多国内网站了，但是有些国外的网站无法访问，这样就必须通过一个特殊的网关去访问，也叫做代理。需要在客户端做配置，指明代理服务器的地址。
|
||||
|
||||
以上情况中，服务器只能知道代理的存在，而不知道真正的客户端是谁，这叫做正向代理。下面的情况正相反：请求来源很明确，但是不知道是哪个服务器来响应。比如 Nginx 服务器把客户端的请求按照一定的规则发送给后端的诸多服务器之一处理，而客户端不需要任何特殊配置。这叫做反向代理，它代理的是服务器端。负载均衡就是一种反向代理。
|
||||
|
||||
图 12.5.1 右侧的流程实例中，有两种方式：
|
||||
|
||||
初始化：
|
||||
|
||||
1. 服务器 1 向代理注册（也可能不需要注册，适用于 Agent 和 Proxy 模式）；
|
||||
2. 服务器 2 向代理注册（适用于 Broker 模式）。
|
||||
|
||||
|
||||
方式一（直连）：
|
||||
|
||||
1. 客户端发起请求 1；
|
||||
2. 代理告诉客户端服务器 1 的地址；
|
||||
3. 客户端直接发请求给服务器 1；
|
||||
4. 服务器 1 返回结果 1 给客户端。
|
||||
|
||||
DNS 就属于第一种方式，但是并不是典型的代理模式。
|
||||
|
||||
方式二（转发）：
|
||||
|
||||
1. 客户端发起服务请求 2；
|
||||
2. 代理把服务请求 2 转发给服务器 2；
|
||||
3. 服务器 2 返回结果 2 给代理；
|
||||
4. 代理把结果 2 转发给客户端。
|
||||
|
||||
这是典型的代理模式的行为。
|
||||
|
||||
#### 优缺点
|
||||
|
||||
优点：
|
||||
- 允许动态更改、添加、删除和重新定位服务，符合开闭原则。
|
||||
- 在一定程度上降低了系统的耦合度。
|
||||
- 可以增加额外的保护措施来做权限分级和保护服务器。
|
||||
|
||||
缺点：
|
||||
|
||||
- 要求对服务描述进行标准化，使用代理模式时则需要考虑异步处理机制、协议创建流程和错误环境控制，比较的繁琐。
|
||||
- 可能会造成请求的处理速度变慢，甚至带来通信瓶颈。
|
||||
- 实现代理模式需要额外的或重复的工作，不易开发。
|
||||
|
||||
|
||||
### 12.5.2 事件驱动模式 (Event-Driven)
|
||||
|
||||
#### 架构说明
|
||||
|
||||
事件驱动模式应用于事件处理，主要由四个组件构成：事件源（event source），事件侦听者（event listener），通道（Channel）以及事件总线（event bus）。 事件源将消息发布到总线的特定通道，侦听者订阅相应的通道，事件源所发布的消息经通道通告给订阅通道的侦听者。
|
||||
|
||||
见图 12.5.2 拓扑结构。
|
||||
|
||||
<img src='img/Slide15.svg'>
|
||||
|
||||
图 12.5.2 事件驱动模式
|
||||
|
||||
一个事件源一般只发送消息到一个通道中，该通道一般由消息队列实现。而监听者根据业务需求可以监听一个或多个通道内的消息，比如图 12.5.2 中的监听者 1 就同时监听通道 1 和通道 2 的消息，此时，事件源 2 要发送两个消息拷贝到通道 2 中。
|
||||
|
||||
发布-订阅模式是事件驱动模式的一个子集。
|
||||
|
||||
#### 应用场景
|
||||
|
||||
这里用一个网络购物的应用常见来说明事件驱动的应用方式，见图 12.5.2 右侧订单服务实力。
|
||||
|
||||
1. 一个网络购物的用户下了订单，应用程序会发送“订单事件”到事件总线；
|
||||
2. “订单处理”模块会得到“订单处理通知”，处理订单，比如核对存货量、配送地、付款信息等；
|
||||
3. 处理完毕后发送“订单确认事件”到事件总线；
|
||||
4. “订单确认”模块会得到“订单确认通知”，给用户发送确认短信或使用其他通信手段；
|
||||
5. 发送消息给用户；
|
||||
6. 发送完毕后发送“通知成功事件”到事件总线；
|
||||
7. “订单执行”模块会得到“订单配送通知”；
|
||||
8. 商家配送，送货上门，用户签收；
|
||||
9. 配送完成后发送“订单完成事件”到事件总线。
|
||||
10. (未画出）系统发送“用户评价通知”然后关闭该订单。
|
||||
|
||||
这种应用场景相当复杂，如果用串行系统架构种的管道-过滤器模式的话，所有操作都要做成同步的，对于网络购物这种大访问量的应用几乎是不可能的。所以，这种“重要不紧急”的场景很适合于使用事件驱动模式。
|
||||
|
||||
|
||||
#### 优缺点
|
||||
|
||||
优点：
|
||||
|
||||
- 分布式的异步架构，事件处理器之间高度解耦，软件的扩展性好。
|
||||
- 适用性广，各种类型的项目都可以用。
|
||||
- 性能较好，因为事件的异步本质，软件不易产生堵塞。
|
||||
- 事件处理器可以独立地加载和卸载，容易部署。
|
||||
|
||||
缺点：
|
||||
|
||||
- 涉及异步编程（要考虑远程通信、失去响应等情况），开发相对复杂。
|
||||
- 难以支持原子性操作，因为事件通过会涉及多个处理器，很难回滚。
|
||||
- 分布式和异步特性导致这个架构较难测试。
|
||||
|
||||
|
||||
### 12.5.3 微服务模式（Microservices）
|
||||
|
||||
#### 架构说明
|
||||
|
||||
在多层架构模式中，一个应用程序的所有功能都运行在一个进程中，称作单体结构（Monolithic Architecture）。当业务增长使得应用逻辑变得复杂时，代码量骤增，其增加新功能、修改、维护的成本非常高，测试、部署所花的时间也很长。因此，人们想到了面向服务（Service Oriented）这个概念。面向对象可以封装类，而面向服务可以封装业务逻辑。
|
||||
|
||||
面向服务的架构中又可以分为两类，第一类是基于事件总线模式的，第二个是基于 REST API 调用的，微服务模式属于第二种。
|
||||
|
||||
当将应用程序作为一组微服务编写时，实际上就是在编写可以协同工作的多个应用程序。其中每个微服务都有自己的职责，团队可以独立于其他微服务进行开发。这些微服务之间唯一的依赖就是通信。当微服务彼此通信时，必须确保它们之间发送的消息能够向后兼容。
|
||||
|
||||
<img src='img/Slide16.svg'>
|
||||
|
||||
图 12.5.3 微服务模式
|
||||
|
||||
此架构拓扑中有三个部分，见图 12.5.3：
|
||||
|
||||
- 网关服务：负责鉴别服务请求，然后通过 REST API 调用对应的微服务。
|
||||
- 微服务：具有很多种类的微服务，每个种类完成一个任务。当同时有很多请求到达时，可以临时创建微服务实例来应对。
|
||||
- 数据库/存储：每个服务种类都有单独的数据库/存储。所以，在微服务和数据库外面画了一个虚线框，表示它们是紧密集成的。当然，有时候可以在两类微服务间共享数据库。
|
||||
|
||||
微服务之间可能存在调用关系，如图 12.5.3 拓扑结构中的黄色虚线所示，但是需要事先注册，以便可以互相发现。
|
||||
|
||||
#### 应用场景
|
||||
|
||||
电子商务类的互联网应用非常适合用微服务架构模式，见图 12.5.3 右侧，是一个外卖网站的实例。
|
||||
|
||||
- 处于上方的派送管理、参观管理、客户管理，都是基于静态信息的管理服务。
|
||||
- 处于中间的订单服务、餐馆服务、派送服务，都是以订单为中心的动态信息的业务服务。
|
||||
- 最下方的计费服务是大家共用的服务。
|
||||
|
||||
另外，客户端软件也可以使用微服务模式，比如 Microsoft OneNotes 应用。该应用中集成了非常多的 Microsoft Office 办公套件的功能，可以自由展示各类文档，还能允许用户在上面随手写写画画。总之就是一个文档的仓库。
|
||||
|
||||
各种文档格式之间没有多大关系，所以完全可以封装成一个个微服务，各自处理好文档的展示、编辑、保存等功能。
|
||||
|
||||
#### 微服务模式的最佳实践
|
||||
|
||||
【最佳实践：何时可以采用微服务模式】
|
||||
|
||||
满足以下条件时，可以考虑使用此模式：
|
||||
|
||||
1. 响应需求变慢，需求开发时间变长。
|
||||
2. 交付的效率变差，bug 数越来越多。
|
||||
3. 业务复杂度变高，应用达到 3 个或 3 个以上，或者模块达到 5 个或以上。
|
||||
4. 团队人数变多，开发至少有5人以上，运维至少2人。
|
||||
5. 项目需要长期迭代维护，至少一年以上。
|
||||
|
||||
但是在决定之前，还是要首先考虑单体模式，毕竟它比较成熟。
|
||||
|
||||
【最佳实践：如何拆分服务】
|
||||
|
||||
1. 基于业务逻辑拆分
|
||||
根据团队规模划分业务模块的粒度。
|
||||
|
||||
2. 基于可扩展拆分
|
||||
将系统中的业务模块按照稳定性排序，将已经成熟和改动不大的服务拆分为稳定服务，将经常变化和迭代的服务拆分为变动服务。
|
||||
|
||||
稳定的服务粒度可以粗一些，即使逻辑上没有强关联的服务，也可以放在同一个子系统中
|
||||
|
||||
不稳定的服务粒度可以细一些，但也不要太细，始终记住要控制服务的总数量。
|
||||
|
||||
3. 基于可靠性拆分
|
||||
将系统中的业务模块按照优先级排序，将可靠性要求高的核心服务和可靠性要求低的非核心服务拆分开来，这样可以单独保证核心服务的高可用。
|
||||
|
||||
4. 基于性能拆分
|
||||
类似基于可靠性拆分，基于性能拆分将性能要求高或者性能压力大的模块拆分出来，避免性能压力大的服务影响其他服务。
|
||||
|
||||
5. 综合
|
||||
以上几种拆分方式不是多选一，而是可以根据实际情况自由排列组合。
|
||||
例如可以基于可靠性拆分出服务 A，基于性能拆分出服务 B，基于可扩展拆分出 C/D 两个服务，加上原有的服务 X，最后总共拆分出 5 个服务（A/B/C/D/X）。
|
||||
|
||||
|
||||
#### 优缺点
|
||||
|
||||
优点：
|
||||
|
||||
- 可以分别编写，维护和部署每个微服务
|
||||
- 易于扩展，因为你可以仅扩展需要扩展的微服务
|
||||
- 更新迭代应用程序的各个部分比较容易，因为它们较小，并且与其他部分的耦合较少
|
||||
- 高度可维护和可测试–微服务模式满足快速频繁的开发和部署
|
||||
- 更好的开发规模，更快的开发速度。
|
||||
- 支持水平缩放和细粒度缩放。
|
||||
- 小体量，较低了开发人员的认知复杂性。
|
||||
|
||||
缺点：
|
||||
|
||||
- 一旦部署就很难下线进行改动，所以会一直保留旧版本，那么就要一直向后兼容，增加开发负担。
|
||||
- 当微服务数量很多时会带来管理困难。
|
||||
- 复杂性从代码转移到基础设施。
|
||||
- RPC 调用和网络通信的大量增加。
|
||||
- 整个系统的安全性管理更具有挑战性。
|
||||
- 整个系统的设计变得更加困难。
|
||||
- 引入了分布式系统的复杂性。
|
||||
|
||||
### 12.5.4 插件模式（Plug-in）
|
||||
|
||||
#### 架构说明
|
||||
|
||||
插件模式架构模式也称为微内核（Micro-Kernal）。这种模式允许你将其他应用程序功能作为插件添加到核心应用程序，从而提供可扩展性以及功能分离。
|
||||
|
||||
微内核架构模式由两种类型的架构组件组成：核心系统和插件模块。
|
||||
- 核心系统仅包含使系统运行所需的最小功能。
|
||||
- 插件模块，提供应用程序功能和自定义处理逻辑的可扩展性，灵活性和隔离性。
|
||||
|
||||
读者都熟悉我们日常使用的计算机系统，一般是由主板+CPU+内存+硬盘+键盘鼠标，即可完成基本任务，称作核心系统。在主板上有很多扩展槽，可以插上声卡，计算机便具有声音的输入输出功能；还可以插上 USB 设备，便具有该 USB 设备提供的功能。这些外设可以叫做插件。
|
||||
|
||||
更严格地说，硬盘、鼠标、键盘都不是核心系统，也算作插件。
|
||||
|
||||
见图 12.5.4。
|
||||
|
||||
<img src='img/Slide17.svg'>
|
||||
|
||||
|
||||
#### 应用场景
|
||||
|
||||
很多允许第三方进行扩展的软件都设计成插件模式。这种插件，可以按功能设计，也可以都是同一个功能但是服务于不同的地区（因为各个地区的应用场景不同）。
|
||||
|
||||
我们一起看一下 VSCode 组成结构，就是一个典型的插件模式，见图 12.5.4 右侧。
|
||||
|
||||
VSCode 是基于 Electron 构建的，主要由三部分构成：
|
||||
|
||||
- Electron，包括 Monaco Editor 和 UI，Extension Host。
|
||||
|
||||
Monaco Editor 是一个基于网页的编辑器，可以进行高亮、悬停提示，导航到定义、自动补全、格式化等功能。
|
||||
|
||||
VSCode 的主进程和插件进程是分开管理的，Extension Host 就是用来管理插件进程的。
|
||||
|
||||
VSCode 中的大部分功能都是通过 Extension Host 来实现的。符合语言服务协议的插件对应的高亮等语言特性就会反映到 Monaco Editor 上。VSCode 默认集成了各种语言的插件。
|
||||
|
||||
- Language Server Protocol 和 Debug Adapter Protocol，语言服务协议Debug 适配协议。
|
||||
|
||||
这两个协议主要是为了将编辑器和编程语言/调试服务的功能分离开，实现任何语言只要编写对应的语言服务即可。目前各大编辑器都已经支持了这个协议。
|
||||
|
||||
- Language Server
|
||||
外部的 Language Server 语言服务需要单独实现，就是各种编程语言（如 Java, Python, C#）和编辑语言（如 Markdown）的各种特性定义。
|
||||
|
||||
Extension Host 是用来确保插件：
|
||||
- 不影响启动速度
|
||||
- 不会减低 UI 响应速度
|
||||
- 不会改变 UI 样式
|
||||
|
||||
因此保证 VSCode 的稳定和快速的密码就在于使用 Extension Host 将主进程和插件进程分开，使插件不会影响到 VSCode 主进程的性能和稳定。
|
||||
|
||||
在编写插件的时候 VSCode 可以让插件设置 Activation Events 来对插件懒加载。比如只有打开了 Markdown 文件才打开对应的插件。这样可以降低无谓的 CPU 和内存使用。
|
||||
|
||||
|
||||
还有一种编程模式，常用于 Unix/Linux 的命令行模式中，如下伪代码片段：
|
||||
|
||||
```python
|
||||
while(True):
|
||||
sleep(10) # 休眠 10 毫秒
|
||||
event = check_event(device1) # 检测事件
|
||||
if event is not None:
|
||||
process(event) # 处理事件
|
||||
|
||||
event = check_event(device2) # 检测事件
|
||||
if event is not None:
|
||||
process(event) # 处理事件
|
||||
```
|
||||
|
||||
这是用一个 while(True) 写的“死循环”，它不断地检测每个设备上有没有新的事件到来，如果有，就进行相应的处理。为了不让 CPU 持续运转，在每次循环开始都要休眠 10 毫秒，否则 CPU 会被 100% 占用。
|
||||
|
||||
这种模式常用于通信场景中，因为通信板卡都是以事件的形式把各种通信事件发送给应用程序，比如响铃、摘机、按键、挂机等。而应用程序处理这些事件也是非常地迅速，向设备发送一个命令后，就可以异步地立刻返回而无需等待，基本可以在毫秒级返回。
|
||||
|
||||
对于不同的设备，采用轮询方式依次进行检测，通常这些设备之间是独立的，没有任何关系。
|
||||
|
||||
其实在 Windows 操作系统上的编程模式也是一个消息循环，这在 Win32 API 中非常典型，但是在后续的升级 API 中使用了事件、委托等方式，避免让程序员直接看到消息循环，提高了系统的安全性。
|
||||
|
||||
#### 优缺点
|
||||
|
||||
优点：
|
||||
|
||||
- 极大的灵活性和可扩展性，能够快速响应不断变化的环境。
|
||||
- 高性能，因为你可以自定义和简化应用程序以仅包括所需的那些功能。
|
||||
- 良好的便携性， 且易于部署。
|
||||
- 插件模块可以单独进行测试。
|
||||
|
||||
缺点：
|
||||
|
||||
- 核心系统的框架需要设计得非常鲁棒和巧妙。
|
||||
- 对插件的控制需要特别地精细，预先设计好接口协议。
|
||||
- 以上两点都造成这类架构模式不易实现，一旦实现后会出现很多意外的 bug，而且如果接口协议太复杂的话，没有第三方会使用这个系统。
|
||||
|
|
@ -1,11 +1,11 @@
|
|||
|
||||
## 12.5 环形系统的架构模式
|
||||
## 12.6 环形系统的架构模式
|
||||
|
||||
### 12.5.1 MVC 模式
|
||||
### 12.6.1 模型-视图-控制器-模式（MVC）
|
||||
|
||||
MVC 这个名词很多读者都熟悉，它代表了 Model-View-Controller。但大多数人熟悉的应该是 MVC 框架和设计模型，我们这里要讲解的是 MVC 架构模型。表 12.5.1 举例说明了三者的区别。
|
||||
MVC 这个名词很多读者都熟悉，它代表了 Model-View-Controller。但大多数人熟悉的应该是 MVC 框架和设计模型，我们这里要讲解的是 MVC 架构模型。表 12.6.1 举例说明了三者的区别。
|
||||
|
||||
表 12.5.1 三种概念的举例比较
|
||||
表 12.6.1 三种概念的举例比较
|
||||
|
||||
|MVC|基本功能|MVC架构举例|MVC框架举例|MVC设计举例|
|
||||
|-|-|-|-|-|
|
||||
|
|
@ -16,12 +16,6 @@ MVC 这个名词很多读者都熟悉，它代表了 Model-View-Controller。但
|
|||
|
||||
#### 架构说明
|
||||
|
||||
见图 12.5.1。
|
||||
|
||||
<img src='img/Slide18.svg'>
|
||||
|
||||
图 12.5.1 MVC 架构
|
||||
|
||||
MVC 模式将交互式应用程序拆分为三个部分：
|
||||
|
||||
- 模型（model）：包含业务功能及数据、状态。
|
||||
|
|
@ -30,12 +24,36 @@ MVC 模式将交互式应用程序拆分为三个部分：
|
|||
|
||||
MVC 模式通过将内部信息表示、用户信息呈现以及用户操作接收分开的方式解耦组件，实现高效的架构重用。
|
||||
|
||||
见图 12.6.1。
|
||||
|
||||
<img src='img/Slide18.svg'>
|
||||
|
||||
图 12.6.1 MVC 架构
|
||||
|
||||
以老式插卡游戏机为例：
|
||||
|
||||
- 游戏主机是控制器 C。注意这里的“控制”不是指用户的操作，而是对各个零部件的控制。它接收手柄的操作信号，把模型中指定的视图播放到显示器上。
|
||||
- 游戏卡是模型 M，封装了游戏的数据和逻辑，和其它两个部件完全无关，可以任意更换游戏卡，只要接口一致即可。它决定显示器上的图像。
|
||||
- 游戏手柄和显示器是视图 V。注意，手柄是用户交互设备，所以属于视图，而不是属于控制器。
|
||||
|
||||
#### 应用场景
|
||||
|
||||
一般用于主流开发语言所构建的互联网网页应用架构，比如 ASP.NET MVC、Spring MVC。
|
||||
|
||||
在图 12.6.1 右侧显示了 ASP.NET MVC 框架的工作流程：
|
||||
|
||||
1. 用户浏览器向 Web Application 提出请求 URL（如：https://xxx.com/home/index）；
|
||||
2. Routing Module 执行 RouteTable 中定义的路由动作；
|
||||
3. MVCHandler 生成 home_Controller；
|
||||
4. 执行 URL 中的 index_action，向 Model 请求数据；
|
||||
5. Model 从数据库中获得数据；
|
||||
6. Controller 决定使用哪个 View；
|
||||
7. 把 Model 交给 View；
|
||||
8. 合成好网页后返回给用户浏览器。
|
||||
|
||||
读者可以很容易地找到 Spring MVC 框架的工作流程并自行阅读，相信会有所帮助，在此不再赘述。
|
||||
|
||||
|
||||
#### 优缺点
|
||||
|
||||
优点：
|
||||
|
|
@ -62,110 +80,65 @@ MVC使开发和维护用户接口的技术含量降低。使用MVC模式使开
|
|||
视图与控制器是相互分离，但却是联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。
|
||||
依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。
|
||||
|
||||
|
||||
#### 应用场景
|
||||
|
||||
一般用于主流开发语言所构建的互联网网页应用架构，比如 ASP.NET MVC、Spring MVC。
|
||||
|
||||
在图 12.5.1 右侧显示了 ASP.NET MVC 框架的工作流程：
|
||||
|
||||
1. 用户浏览器向 Web Application 提出请求 URL（如：https://xxx.com/home/index）；
|
||||
2. Routing Module 执行 RouteTable 中定义的路由动作；
|
||||
3. MVCHandler 生成 home_Controller；
|
||||
4. 执行 URL 中的 index_action，向 Model 请求数据；
|
||||
5. Model 从数据库中获得数据；
|
||||
6. Controller 决定使用哪个 View；
|
||||
7. 把 Model 交给 View；
|
||||
8. 合成好网页后返回给用户浏览器。
|
||||
|
||||
读者可以很容易地找到 Spring MVC 框架的工作流程自行阅读，相信会有所帮助，在此不再赘述。
|
||||
|
||||
### 12.5.2 黑板模式（Black Board）
|
||||
### 12.6.2 反馈模式（LoopBack）
|
||||
|
||||
#### 架构说明
|
||||
|
||||
#### 优缺点
|
||||
反馈模式在应用架构模式中使用得较少，它是从控制理论衍生过来的一种编程模式，但是在操作系统级别的架构模式上，基本上都是使用这种方式。
|
||||
|
||||
见图 12.6.2。
|
||||
|
||||
<img src='img/Slide19.svg'>
|
||||
|
||||
图 12.6.2 反馈模式
|
||||
|
||||
它包括消息接收、消息处理、反馈控制三个部分。
|
||||
|
||||
- 消息接收，接收上一次的运行结果作为消息的唯一来源；
|
||||
- 消息处理，针对感兴趣的消息进行处理，要求处理速度尽可能地快，以避免影响后续的操作。
|
||||
- 反馈控制，负责接收输出结果，再返回给输入端，进行闭环的调节控制，以达到预期的输入和输出的关系。
|
||||
|
||||
该模式与事件驱动模式的区别是：
|
||||
|
||||
表 12.6.1 事件驱动模式与反馈模式的区别
|
||||
|
||||
||事件驱动模式|反馈模式|
|
||||
|-|-|-|
|
||||
|形式|开环系统，可以随时增加处理单元|闭环控制系统，运行时无外界干扰|
|
||||
|运行|根据需要可以暂时停止然<br>后再开启，事件不会丢失|一旦运行就不能停止，因为停<br>止再恢复运行时状态比较复杂|
|
||||
|终止条件|无|有，事先设定|
|
||||
|事件消息来源|应用程序中的任意模块|从上一次的输出结果中来|
|
||||
|多个处理单元|并行|串行|
|
||||
|
||||
#### 扩展模式
|
||||
|
||||
可以多个接收/处理单元串联在一起，每个单元负责不同的消息，但是要求每个单元的消息处理速度非常快，不至于影响其它单元。
|
||||
|
||||
反馈控制可以是轻量级的（图中画成虚线），或者其它任何形式的，只要与输出有关即可。
|
||||
|
||||
#### 应用场景
|
||||
|
||||
一、定义
|
||||
以神经网络训练为例：
|
||||
|
||||
黑板模式是一种常用的架构模式，应用中的多种不同数据处理逻辑相互影响和协同来完成数据分析处理。黑板模式允许多个消息读写者同时存在，消息的生产者和消费者完全分开。这就像一个黑板，任何一个教授（消息的生产者）都可以在其上书写消息，任何一个学生（消息的消费者）都可以从黑板上读取消息，两者在空间和时间上可以解耦，并且互不干扰。这种模式对于没有确定解决方案策略的问题是有用的。
|
||||
1. 搭建神经网络模型；
|
||||
2. 初始化各层的网络参数；
|
||||
3. 用批量样本逐层做正向计算；
|
||||
4. 在最后的输出部分计算损失函数（与样本的标签值比较）；
|
||||
5. 把误差逐层做反向传播，更新每层的网络参数；
|
||||
6. 返回到 3，直到误差符合要求。
|
||||
|
||||
二、模式组成
|
||||
|
||||
黑板模式由3个主要组成部分组成。
|
||||
|
||||
(1)知识源：包含独立的、与应用程序相关的知识，知识源之间不直接进行通讯，它们之间的交互只通过黑板来完成。
|
||||
|
||||
(2)黑板数据结构：按照与应用程序相关的层次来组织并解决问题的数据，知识源通过不断地改变黑板数据来解决问题。
|
||||
|
||||
(3)控制组件；完全由黑板的状态驱动，黑板状态的改变决定了需要使用的特定知识。
|
||||
|
||||
黑板模式一般不会对架构产生什么影响，但它通常会要求有一个清晰的消息结构。黑板模式一般都会提供一系列的过滤器，以便消息的消费者不再接触到与自己无关的消息。在实际开发中，黑板模式常见的有两种实现方式：
|
||||
|
||||
（一）数据库作为黑板
|
||||
|
||||
利用数据库充当黑板，生产者更新数据信息，不同的消费者共享数据库中信息，这是最常见的实现方式。该方式在技术上容易实现，开发量较少，熟悉度较高。缺点是在大量消息和高频率访问的情况下，性能会受到一定影响。在该模式下，消息的读取是通过消费者主动“拉取”，因此该模式也叫做“拉模式”。
|
||||
|
||||
（二）以语音识别为例：
|
||||
|
||||
语音识别黑板里边就是语言包 ；语言包就是知识源，控制机构就是管理语言包的，当你说一句话，不知道是什么语言，所以时非确定性的问题，控制机构把你说的话对应的语言包给你看，这就是黑板模式的流程
|
||||
|
||||
所有的组件都可以访问黑板。组件可以生成添加到黑板上的新数据对象。组件在黑板上查找特定类型的数据，并通过与现有知识源的模式匹配来查找这些数据。
|
||||
|
||||
三、模式实现
|
||||
|
||||
（一）利用数据库
|
||||
|
||||
利用数据库充当黑板，不同的应用共享数据库中信息，并且可以更新数据信息。这也是最常见的实现方式。
|
||||
|
||||
（二）利用发布—订阅模式
|
||||
|
||||
这种实现方式通常采用消息队列作为黑板，队列工作在主题模式（Topic），专家作为队列的订阅者，同时可以向队列发送消息，消息会被发送至所有订阅者。以上过程实现了专家间的信息交流。
|
||||
|
||||
四、影响黑板系统的因素
|
||||
|
||||
影响黑板系统设计的最大因素是引用问题本身的特性，但是支撑应用程序的黑板体系结构有许多相似的特征和构件。对于特定应用问题，黑板系统可通过选取各种黑板、知识源和控制模块的构件来设计；也可以利用预先制定的黑板体系结构的编程环境。
|
||||
|
||||
五、应用实例
|
||||
|
||||
黑板系统的典型应用是信号处理领域，如网络信息检索、电子商务、自动控制、商业管理智能决策、语音和模式识别、智能控制领域等
|
||||
|
||||
实际应用
|
||||
|
||||
在实际应用中常见的实现模式有：
|
||||
|
||||
A 利用数据库
|
||||
|
||||
利用数据库充当黑板，不同的应用共享数据库中信息，并且可以更新数据信息。这也是最常见的实现方式。
|
||||
|
||||
特点：
|
||||
|
||||
1 便于实现信息的查询，筛选和统计，这方面关系数据库提供了SQL 92的强大支持。
|
||||
|
||||
2 不能用于较高实时性要求的环境，这种实现是工作在“拉模式”下的，并且高频率的访问数据库会导致严重的系统性能问题。
|
||||
|
||||
B 利用发布—订阅模式
|
||||
|
||||
这种实现方式通常采用消息队列作为黑板，队列工作在主题模式（Topic），专家作为队列的订阅者，同时可以向队列发送消息，消息会被发送至所有订阅者。以上过程实现了专家间的信息交流。
|
||||
|
||||
特点：
|
||||
|
||||
1、可以有效应用于实时性要求较高的系统，这种实现工作在“推模式”下。
|
||||
|
||||
2、难于实现信息的统计分析，不像实现方式一那样可以通过SQL支持，这些工作必须开发者自己完成。
|
||||
|
||||
六、优缺点分析
|
||||
|
||||
优点：可用于非确定性问题求解，启发式解决过程，可维护性，可重用
|
||||
|
||||
缺点：不能确保期望结果，效率低下，回退，不支持并行，共享空间的访问需要同步
|
||||
|
||||
### 12.5.3 解释器模式
|
||||
|
||||
#### 架构说明
|
||||
|
||||
#### 优缺点
|
||||
|
||||
#### 应用场景
|
||||
优点：
|
||||
|
||||
- 不受外界干扰的闭环系统。
|
||||
- 控制行为（处理逻辑）简单，系统运行稳定。
|
||||
|
||||
缺点：
|
||||
|
||||
- 比较难设计和实现。
|
||||
- 反馈信号需要妥善处理，反馈力度太强会引起系统崩溃，太弱则不起作用。
|
||||
- 因为要正向、反向反复运行，所以运行性能较低。
|
||||
|
||||
|
|
@ -1,27 +1,30 @@
|
|||
|
||||
### 从架构反推产品战略
|
||||
## 13.7 康威定律
|
||||
|
||||
从前面的学习中我们知道，系统架构都是为产品战略服务的，失败的架构也是由失败的策略所决定的。因此，我们根据系统架构可以反向推出产品战略。
|
||||
康威定律是一句格言，指出“**一个团队设计的系统来通常反映了他们自己的沟通（组织）结构**”。它以计算机程序员梅尔文·康威的名字命名，他于1967年提出了这个想法。原文是：
|
||||
|
||||
https://blog.csdn.net/lclfans1983/article/details/115659312
|
||||
康威定律
|
||||
**Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.**
|
||||
|
||||
<img src="img/Slide4.SVG"/>
|
||||
笔者最初也是不明白康先生在讲什么，直到在写作的时候分析了微软 Cortana 的产品战略和系统架构之后，才恍然大悟。
|
||||
|
||||
图 xxxx 亚马逊 Alexa 与 微软 Cortana 的对比
|
||||
见图 13.7.1。
|
||||
|
||||
<img src="img/Slide20.SVG"/>
|
||||
|
||||
图 13.7.1 亚马逊 Alexa 与 微软 Cortana 的对比
|
||||
|
||||
图例：
|
||||
|
||||
- 带双箭头的实线：网络或数据通信
|
||||
- 单箭头虚线：开发行为
|
||||
- 蓝色虚线框：产品边界
|
||||
- 黄色虚线框：第三方服务
|
||||
- 黄色开发者：外部开发者
|
||||
- 蓝色开发者：内部开发者
|
||||
- 蓝色虚线框：产品边界
|
||||
- 黄色虚线框：第三方服务
|
||||
- 带双箭头的实线：网络或数据通信
|
||||
|
||||
#### ..1 半开放的亚马逊 Alexa
|
||||
#### 13.7.1 半开放的亚马逊 Alexa
|
||||
|
||||
亚马逊智能音箱产品 Alexa 无疑是一个成功的产品，在 2018 年的一个第三方的统计报告中的数字告诉我们：
|
||||
亚马逊智能音箱产品 Alexa 无疑是一个**成功**的产品，在 2018 年的一个第三方的统计报告中的数字告诉我们：
|
||||
|
||||
- Alexa 平台上的技能超过了 5 万个；
|
||||
- 有数十万开发者，其中有一些独立开发者通过技能开发实现盈利；
|
||||
|
|
@ -36,13 +39,13 @@ https://blog.csdn.net/lclfans1983/article/details/115659312
|
|||
在 Server 端开发了一套无代码/低代码的服务框架，第三方开发者在服务器上注册登录后，根据服务器端指定的流程，输入一些可定制的规则，完成两件事：1. 识别用户的语音问话的含义；2. 做出相应的响应。
|
||||
|
||||
|
||||
#### ..2 封闭的微软 Cortana
|
||||
#### 13.7.2 封闭的微软 Cortana
|
||||
|
||||
微软的 Cortana 也无疑是一个不成功的产品。
|
||||
微软的 Cortana 也无疑是一个**不成功**的产品。
|
||||
|
||||
首先从定位上看，Alexa 是放在用户家里的，为用户提供生活服务；而 Cortana 是运行在计算机上的，局限在为用户提供工作助理功能上，这是先天性的缺陷。
|
||||
|
||||
其次我们看看它的产品架构。在 图 xxx 中我们省去了很多架构的细节，关键的元素是开发者所处的位置：
|
||||
其次我们看看它的产品架构。在 图 13.7.1 中我们省去了很多架构的细节，关键的元素是开发者所处的位置：
|
||||
|
||||
- Alexa，开发者是第三方的，在虚线框外部；
|
||||
- Cortana，开发者是第一方，在虚线框内部。
|
||||
|
|
@ -55,21 +58,21 @@ https://blog.csdn.net/lclfans1983/article/details/115659312
|
|||
|
||||
其中，第一点的代码位置限制了 Cortana 的技能的快速扩展，因为第三方根本不可能加入到这个生态系统中来。
|
||||
|
||||
#### ..3 假设 Cortana 有一个开放架构...
|
||||
当年笔者看到了 Cortana 的架构后，不禁心里发紧，深知这是 Windows Team 的一贯作风 —— 这就是**康威定律**的具体体现：Windows Team 本身就是一个封闭的组织，很多人在里面工作了十几年，所以设计出来的产品也是封闭的。就算投入几百人做 Cortana 技能，但是如果这些人不是服务领域的专家，也不会做出什么好的服务体验的，这就根本不能和亚马逊的“全民皆兵”的模式媲美。
|
||||
|
||||
当年笔者看到了 Cortana 的架构后，不禁心里发紧，深知这是 Windows Team 的一贯作风。就算微软投入几百人做 Cortana 技能，但是这些人不是服务领域的专家，不会做出什么好的服务体验的，这就根本不能和亚马逊的“全民皆兵”的模式媲美。
|
||||
#### 13.7.3 假设 Cortana 有一个开放架构...
|
||||
|
||||
所以，笔者自己在 Windows 现有的技术基础上构想了一个架构，如图 xxx 所示
|
||||
所以，笔者自己在 Windows 现有的技术基础上构想了一个架构，如图 13.7.1 最右侧所示
|
||||
|
||||
- Cortana App 依然存在，由 Windows Team 维护；
|
||||
- 增加一个 Cortana（Assistant）UWP App，它对外可以接入第三方服务，对内可以被 Cortana App 通过 UWP 内部机制调用（相当于是一个本地启动的服务）。这样做的好处是：虽然 Cortana App 跟随 Windows 的发布节奏（至少半年才发布一次），但是 Cortana UWP 可以随时在 Windows 应用商店中发布，像普通的 UWP App 一样，自由地迭代更新。这个 UWP App 由 Cortana 项目组来负责。
|
||||
- 第三方 UWP App，是第三方通过 Windows 应用商店在 Windows 10 上发布的应用。它和 Cortana UWP App 一样，可以对内为 Cortana App 提供服务，对外调用自己的服务。比如，网易云音乐 UWP 只访问网易云自己提供的服务，淘宝 UWP 只访问阿里提供的服务。这些 UWP 可以在不显式启动的情况下为 Cortana App 提供服务，只要实现相应的开发接口即可。
|
||||
|
||||
笔者所在团队的 PM Manager 看到这个架构设计后兴奋无比，它的最大好处可以总结为：
|
||||
笔者所在中国团队的 PM Manager 看到这个架构设计后兴奋无比，它的最大好处可以总结为：
|
||||
|
||||
1. Cortana 技能可随时更新。
|
||||
2. 第三方可以参与技能提供。
|
||||
3. Cortana 技能开发的难度降低了很多。
|
||||
|
||||
但是也无法说服美国总部做出这种希望掌控一起的战略性的改变。
|
||||
但是理由再充分，也无法说服美国总部做出改变，他们希望掌控一切，关起门来自己玩儿。
|
||||
|
||||
|
|
@ -0,0 +1 @@
|
|||
用不同的架构解决 KWIC 问题
|
||||
Различия файлов скрыты, потому что одна или несколько строк слишком длинны
|
До Ширина: | Высота: | Размер: 56 KiB После Ширина: | Высота: | Размер: 57 KiB |
|
До Ширина: | Высота: | Размер: 61 KiB После Ширина: | Высота: | Размер: 61 KiB |
Различия файлов скрыты, потому что одна или несколько строк слишком длинны
|
После Ширина: | Высота: | Размер: 50 KiB |
Различия файлов скрыты, потому что одна или несколько строк слишком длинны
|
До Ширина: | Высота: | Размер: 75 KiB После Ширина: | Высота: | Размер: 75 KiB |
|
До Ширина: | Высота: | Размер: 65 KiB После Ширина: | Высота: | Размер: 65 KiB |
Различия файлов скрыты, потому что одна или несколько строк слишком длинны
|
После Ширина: | Высота: | Размер: 60 KiB |
Различия файлов скрыты, потому что одна или несколько строк слишком длинны
|
После Ширина: | Высота: | Размер: 63 KiB |
Различия файлов скрыты, потому что одна или несколько строк слишком длинны
|
После Ширина: | Высота: | Размер: 80 KiB |
Различия файлов скрыты, потому что одна или несколько строк слишком длинны
|
После Ширина: | Высота: | Размер: 49 KiB |
Различия файлов скрыты, потому что одна или несколько строк слишком длинны
|
До Ширина: | Высота: | Размер: 79 KiB После Ширина: | Высота: | Размер: 79 KiB |
Различия файлов скрыты, потому что одна или несколько строк слишком длинны
|
После Ширина: | Высота: | Размер: 55 KiB |
Различия файлов скрыты, потому что одна или несколько строк слишком длинны
|
До Ширина: | Высота: | Размер: 43 KiB После Ширина: | Высота: | Размер: 43 KiB |
Различия файлов скрыты, потому что одна или несколько строк слишком длинны
|
После Ширина: | Высота: | Размер: 72 KiB |
Различия файлов скрыты, потому что одна или несколько строк слишком длинны
|
После Ширина: | Высота: | Размер: 56 KiB |
Различия файлов скрыты, потому что одна или несколько строк слишком длинны
|
После Ширина: | Высота: | Размер: 65 KiB |
Различия файлов скрыты, потому что одна или несколько строк слишком длинны
|
После Ширина: | Высота: | Размер: 71 KiB |
Различия файлов скрыты, потому что одна или несколько строк слишком длинны
|
После Ширина: | Высота: | Размер: 69 KiB |
Различия файлов скрыты, потому что одна или несколько строк слишком длинны
|
До Ширина: | Высота: | Размер: 100 KiB После Ширина: | Высота: | Размер: 108 KiB |
Различия файлов скрыты, потому что одна или несколько строк слишком длинны
|
До Ширина: | Высота: | Размер: 77 KiB После Ширина: | Высота: | Размер: 78 KiB |
Различия файлов скрыты, потому что одна или несколько строк слишком длинны
|
После Ширина: | Высота: | Размер: 94 KiB |
|
|
@ -0,0 +1,2 @@
|
|||
|
||||
https://www.cnblogs.com/gaojingsong/p/13184296.html
|
||||
|
До Ширина: | Высота: | Размер: 51 KiB После Ширина: | Высота: | Размер: 51 KiB |
|
До Ширина: | Высота: | Размер: 90 KiB После Ширина: | Высота: | Размер: 90 KiB |
|
До Ширина: | Высота: | Размер: 102 KiB После Ширина: | Высота: | Размер: 102 KiB |
|
До Ширина: | Высота: | Размер: 86 KiB После Ширина: | Высота: | Размер: 86 KiB |
|
До Ширина: | Высота: | Размер: 93 KiB После Ширина: | Высота: | Размер: 93 KiB |
|
До Ширина: | Высота: | Размер: 72 KiB После Ширина: | Высота: | Размер: 72 KiB |
|
До Ширина: | Высота: | Размер: 99 KiB После Ширина: | Высота: | Размер: 99 KiB |
|
До Ширина: | Высота: | Размер: 59 KiB После Ширина: | Высота: | Размер: 59 KiB |
|
До Ширина: | Высота: | Размер: 113 KiB После Ширина: | Высота: | Размер: 113 KiB |
|
До Ширина: | Высота: | Размер: 80 KiB После Ширина: | Высота: | Размер: 80 KiB |
|
До Ширина: | Высота: | Размер: 82 KiB После Ширина: | Высота: | Размер: 82 KiB |
|
До Ширина: | Высота: | Размер: 77 KiB После Ширина: | Высота: | Размер: 77 KiB |
|
До Ширина: | Высота: | Размер: 69 KiB После Ширина: | Высота: | Размер: 69 KiB |
Некоторые файлы не были показаны из-за слишком большого количества измененных файлов Показать больше
Загрузка…
Ссылка в новой задаче