Merge pull request fenixsoft#320 from mzlogin/feature/typo-17

fix: typo
zhangqinghua-fork · Jan 5, 2022 · 867fbc6 · 867fbc6
2 parents fff758c + daf849e
commit 867fbc6
Showing 1 changed file with 3 additions and 3 deletions.
diff --git a/methodology/forward-msa/governance.md b/methodology/forward-msa/governance.md
@@ -36,9 +36,9 @@ Ensuring and validating that assets and artifacts within the architecture are ac
 
 软件研发的认知负荷，本质上是来自技术的认知复杂度。每次技术进步都伴随着新知识、新概念的诞生，说技术进步会伴随复杂度升级也无不可。只是微服务或者说分布式系统所提倡许多理念，都选择偏向于机器而不是人，有意无意地加剧了该现象。举个具体例子，心理学研究告诉我们，与现实世界不符合的模型会带来更高的认知负荷，因此面向对象编程（OOP）这种以人类观察世界的视角去抽象系统的设计方式是利于降低认知负荷的，但分布式系统提倡面向资源编程（服务间交互是 REST，服务内部并不反对你使用 OOP），服务之间的交互绝不提倡面向对象来进行，Martin Fowler 曾经撰文《[Microservices and the First Law of Distributed Objects](https://martinfowler.com/articles/distributed-objects-microservices.html)》强调分布式的第一原则就是不要分发对象（Don't Distribute Your Objects）。微服务加剧认知负荷还体现在很多其他方面，如异步通信（异步比同步更难理解）、粗粒度服务接口（粗粒度 API 比细粒度 API 更难使用，关于这点在 Martin Fowler 的原文中也有详细的解释）、容错处理（服务容错比异常更为复杂）、去中心化（尽管中心化设计会降低可用性，但确实比非中心化有更高的可管理性）等等。该结果并不让人感到意外，在[原始分布式时代](/architecture/architect-history/primitive-distribution.html)中笔者就提到过，分布式系统早已放弃了 UNIX 所追求的简单性是系统第一属性的设计哲学。
 
-由于认知负荷是与概念、模型、业务、代码的规模呈正比关系，这些工作都是由人来做的，最终都能被某种比例系数放大之后反应到人员规模上，可以认为认知负荷的复杂度是 O(k×N)（为便于讲解，这里复杂度刻意写成未除消系数的形式），单体与微服务的差别是复杂度比例系数 k 的大小差别，微服务架构的 k 要比单体架构的 k 更大。软件研发的整体复杂度是认知负荷与协作成本两者之和，对于单体架构是 O(k×N)+O(N^2^)，对于微服务架构，整体复杂度就是 O(k×N)+O(NlogN)，由于高次项的差异，N 的规模增加时单体架构的复杂度增长更快，这就定量地论证了“软件规模小时微服务的复杂度高于单体系统，规模大时则相反”的观点。
+由于认知负荷是与概念、模型、业务、代码的规模呈正比关系，这些工作都是由人来做的，最终都能被某种比例系数放大之后反应到人员规模上，可以认为认知负荷的复杂度是 O(k×N)（为便于讲解，这里复杂度刻意写成未消除系数的形式），单体与微服务的差别是复杂度比例系数 k 的大小差别，微服务架构的 k 要比单体架构的 k 更大。软件研发的整体复杂度是认知负荷与协作成本两者之和，对于单体架构是 O(k×N)+O(N^2^)，对于微服务架构，整体复杂度就是 O(k×N)+O(NlogN)，由于高次项的差异，N 的规模增加时单体架构的复杂度增长更快，这就定量地论证了“软件规模小时微服务的复杂度高于单体系统，规模大时则相反”的观点。
 
-笔者用了千余字的篇幅，目的不是为了证明这个观点的正确，很多架构师仅凭经验也能直观感受出它是正确的。笔者的目的是想解释清楚软件研发的复杂性的来源与差距程度，并说明微服务中分治思想对控制软件研发复杂性的价值。假如只能用一个词来形容微服务解决问题的核心思想，笔者给的答案就是“分治”，这即是微服务的基本特征，也是微服务应对复杂性的手段。
+笔者用了千余字的篇幅，目的不是为了证明这个观点的正确，很多架构师仅凭经验也能直观感受出它是正确的。笔者的目的是想解释清楚软件研发的复杂性的来源与差距程度，并说明微服务中分治思想对控制软件研发复杂性的价值。假如只能用一个词来形容微服务解决问题的核心思想，笔者给的答案就是“分治”，这既是微服务的基本特征，也是微服务应对复杂性的手段。
 
 ## 发展的治理
 
@@ -56,7 +56,7 @@ Ensuring and validating that assets and artifacts within the architecture are ac
 > - 孩子上学时，你换上了大户型的学区房；
 > - 孩子离家读书时，你也终于走上人生巅峰，换了一套梦想中的大别墅。
 
-对于你住进大别墅的这个过程，后一套房子并不是前一套房子的“升级版本”，两套房子之间只有逻辑意义上继承关系，没有实质血源上的继承关系，你最后的大别墅绝对不是在最初的六人间宿舍基础上添砖加瓦扩建而来的。同理，大型软件的建设是一个不断推倒从来的演进过程，前一个版本对后一个版本的价值在于它满足了这个阶段用户的需要，让团队成功适应了这个阶段的复杂度，可以向下一个台阶迈进。对于最终用户来说，一个能在演进过程中逐步为用户提供价值的系统，体验也要远好于一个憋大招的系统——哪怕这大招最终能成功憋出来，这个道理就如下图这幅关于理想交通工具的漫画所示。
+对于你住进大别墅的这个过程，后一套房子并不是前一套房子的“升级版本”，两套房子之间只有逻辑意义上继承关系，没有实质血源上的继承关系，你最后的大别墅绝对不是在最初的六人间宿舍基础上添砖加瓦扩建而来的。同理，大型软件的建设是一个不断推倒重来的演进过程，前一个版本对后一个版本的价值在于它满足了这个阶段用户的需要，让团队成功适应了这个阶段的复杂度，可以向下一个台阶迈进。对于最终用户来说，一个能在演进过程中逐步为用户提供价值的系统，体验也要远好于一个憋大招的系统——哪怕这大招最终能成功憋出来，这个道理就如下图这幅关于理想交通工具的漫画所示。
 
 :::center
 ![](./images/evolution.png)