Gergely Orosz 文章翻译-软件架构被高估，简明设计被低估
原文链接：《Software Architecture is Overrated, Clear and Simple Design is Underrated》
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2021-02-10
《恰如其分的软件架构》
前言 这两周集中时间间歇性读完了《恰如其分的软件架构》这本书。这本书讲的是架构方法，架构方法是一种思维模型（mind set），这种思维模型叫作“风险驱动模型”。 这本书经我们团队的架构师推荐，列在我们团队的集体书目里很久了。但真正去读它、读完它的人又很少。究其原因，还是这本书的内容以谈概念为主，虽然书中举的例子非常生动，仍然始终无法摆脱“为了谈概念而举玩具例子”的问题-这几乎是所有架构书的通病。似乎正统的架构书籍都不可避免地举一些传统行业或者经典软件（比如很多书籍都会反复出现在“xxx 播放器”）的例子。这些软件架构非常经典，可以只用一些小的组件、场景，就讲清楚典型的组件、模式和架构风格的用处。但没有很深的工程/架构经验的读者读这些书的时候，仿佛重新回到了抄书和念书的大学课堂，对于脱离现实的例子只会产生“左耳进右耳出”的感觉。能够温故而知新，是一本书经典化的特征。而能够阅读非入门级的纯理论书籍，则是一个程序员的认知能力和经验达到了一定程度的特征。我读这本书里很多细节还是很痛苦，证明我还是对于形式化的符号（symbol）、记法（notion）还不是很熟悉，而且对于书中运用的问题解...
2019-09-26
架构整洁之道笔记
最早的《The Clean Architecture》诞生于 2012年，这个问题很早就被讨论清楚了。 思维导图： 注意，所有的接口都是在高层声明的：UseCase Input Port 和 UseCase Output port，所以高层可以实现高层的接口，低层也可以实现高层的接口。 注意，sofa的分层就是在一个横向的模块里声明了业务用例的接口和 core-model 的接口，这样源代码级的依赖都集中在抽象上： Use Case Interactor 和 Presenter 应该是可测试的，而 Data Access Interface、View、ORM 应该是 humble object。所以一个应用的低层（外层）应该是被排除掉不做测试的。 附件下载： xmind 关于源代码中的依赖关系的一些澄清： “使用”并不意味着“定义”，而只是引用 dashed outline 代表虚线框，也代表抽象。
2023-02-13
推荐系统相关
新闻的推荐系统是为了给信息流的用户推荐资讯 feed。接口返回的信息不一定会被外显曝光。 在瀑布流式的外显曝光场景下，重排能够减少用户的疲劳度。 这就涉及到推荐系统的设计，流量要经过什么样的链路呢？ 接入层、推荐中控、画像、召回、粗排、精排、重排。这些系统会形成星型架构和树形架构。 不同的架构之间有一个典型的优缺点需要取舍：链路长度会影响网络传输的最终效率，也会影响推荐系统的性能。 feeds推荐引擎典型架构.drawio
2018-04-02
一个滚动重启的状态保存问题
很多时候滚动重启，都会导致状态丢失。比较好的设计方法是把服务本身设计成无状态的，然后在上游的服务上做好 failover，然后增加 standby server，让 sticky 数据 transmit 到 standby 机器上，让 request 失败以后可以自己由上游重传到 standby server。然后就可以滚动重启了。 这大部分场景下还要考虑幂等的问题。 这就看得出热配置热替换的重要性了。在大多数情况下，除了发布新的 feature 升级以外，都应该尽量用热配置来避免重启。
2021-05-27
插件化架构
为什么要实现插件化架构 业务和平台要解耦。业务和平台都是多对多的关系。全链路里既有业务，也有平台。大家应该如何 talk by interface。我们看待复杂组织的业务流程，要线性看，看到很多节点；也要分层看，看到复合的层次。在这种情况下，上层架构域和下层架构域之间怎么实现复杂度的管理？ 如果我们需要构建大规模的泛交易平台，我们需要靠插件化架构把我们的系统组装起来。 插件化架构通常需要一个 runtime 层（或者 boot 层）、core 层。 从业务视角来看，要解决多团队协同的问题 因为多个业务域/团队没有把能力用统一的方式透出，所以没有人能够知道统一的技术能力应该怎么串联。进行全链路沟通需要大量的沟通对齐工作。 从业务视角来看，复杂性业务要素包含本业务用例里的各种模型。 从平台视角来看，要解决复杂性管理问题 平台要支撑多种业务，业务的复杂性、差异性，以及众多业务需求不确定性，在各平台内部如何管理和支撑？简单的 if-else 不易于管理，确保对业务的支撑能力不相互影响。隔离是最好的管理手法。 从平台视角来看，复杂性业务要素包含本域内标准系统用例里的各种模型。 同一个模型，...
2022-01-19
演进式架构
如果读一本书，没有附带正确的复盘（提出反馈并总结反馈），则浪费了这次读书的完整机会。 复盘需要经过痛苦的思索，把一些之前自己没有办法充分接受的观点，充分接受。 本书是一本讲战略的书。 这本书告诉我们很多概念，一旦加上“架构”前缀，突然就有了特殊的含义：架构特征（architectural characteristic）、架构量子（architectural quantum）、架构维度（architectural dimension）、架构模式（architectural pattern）。 新时代的架构愿景-怎样用敏捷的方式来拥抱变化？ 架构难以被修改是由架构本身的不变性决定的，架构天然就是难以修改的。 有些人可能认为，就好像建筑业的实践那样，应该先完成这类架构设计，再开始开发。但需求是快速变动的这一事实告诉我们，我们可能要经常修改我们架构，以拥抱需求变化。 “需求总是在动态变化的”，比“架构应该是被预先确定”，更加像是一个事实（后者更加像是一个观点）。 当代的架构是： 不断努力的结果 【能够响应不断变化的需求和外部人员的反馈】 实施这种架构以替代传统架构，是需要决策者（技术...
