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
2018-11-28
正交性
所谓正交性（orthogonal 意为正交的），就是设计的维度与其他维度完全隔离，一个正交的设计/值域设计，其变化绝不会受其他正交维度影响，也不会影响其他正交维度。 我们可以把 API 设计成正交的。这样 API 有独立变化的空间的。 我们可以把问题域切分清楚。问题域之间完全不相互干涉（注意跨问题域问题）。 我们可以把变量、字段、列设计成正交的。这样不同业务场景下，列之间的赋值不会相互覆盖。
2020-12-02
服务治理组件笔记
背景 service-centric architecture 以服务为中心的架构，和 SOA 的区别是？ 服务治理的模式 server-side pattern：容易集中管控，易单点失败。 client-side pattern：不容易集中管控，不易单点失败。 演化流程 基础治理能力：通信协议统一、命名服务的统一、监控预警、运营平台 高性能/易用性：通信框架高性能/通信框架轻量化/分布式链路追踪/测试工具可视化 全方位的治理能力：全链路压测平台/深度服务化 SOA/链路级流量治理/易用化平台构建 业界前言探索：SET 化高扩展架构/云原生架构治理 治理体系 该有的治理能力都要有。 注册中心 服务注册 服务概要 提供者 消费者 监控报警 节点监控 性能监控 业务监控 异常监控 服务运营 配置管理 服务分组 节点管理 服务鉴权 数据分析 性能指标 来源去向 主机分析 数据报表 调用链路 关键组件-本地代理 比如 LocalAgent，能够做到：策略下沉，解耦功能，对业务服务侵入性低。 但 Provider/Consumer 还需要使用自己的 sdk，它和远端的 ...
2020-09-02
异地多活与单元化
背景介绍 名词解释 ldc logical data center idc internet data center ldc 是 idc 的进化版，是一种单元化部署方案。 扩展模式 vs 镜像模式 扩展模式是把服务/数据库分拆，然后部署到不同的机房里面，相当于放大了一个物理机房。 镜像模式是每个机房里部署的服务都是一样的，每个机房承担一定流量。 镜像模式的容灾效果更好，难度在如何切分流量上。容灾还要考虑机房级容灾、部署地容灾的问题。多地部署带来距离，距离带来延时，延时带来 replica 的风险。 单元化部署 所谓 cell，是一个能完成所有业务操作的自包含集合（每个单元，都是其他单元的镜像）。一般的 soa 架构，服务是分层的，而且每一层的任一节点都可以被其他机房调用。而单元化部署的结果是，本单元的上层节点，只会调用本单元的下层节点。它具有一个站点全部的功能，但不具有一个站点全部的流量。 这种单元化部署实际上就要求底层的数据也要做 sharding。单元化的结果是，数据库连接可以更好地被复用-多个单元互相跨 db 连接，其实很浪费资源。 单元化是按核心数据维度，对业务系统的部署...
2022-01-19
演进式架构
如果读一本书，没有附带正确的复盘（提出反馈并总结反馈），则浪费了这次读书的完整机会。 复盘需要经过痛苦的思索，把一些之前自己没有办法充分接受的观点，充分接受。 本书是一本讲战略的书。 这本书告诉我们很多概念，一旦加上“架构”前缀，突然就有了特殊的含义：架构特征（architectural feature）、架构量子（architectural quantum）、架构维度（architectural dimension）、架构模式（architectural pattern）。 新时代的架构愿景-怎样用敏捷的方式来拥抱变化？ 架构难以被修改是由架构本身的不变性决定的，架构天然就是难以修改的。 有些人可能认为，就好像建筑业的实践那样，应该先完成这类架构设计，再开始开发。但需求是快速变动的这一事实告诉我们，我们可能要经常修改我们架构，以拥抱需求变化。 “需求总是在动态变化的”，比“架构应该是被预先确定”，更加像是一个事实（后者更加像是一个观点）。 当代的架构是： 不断努力的结果 【能够响应不断变化的需求和外部人员的反馈】 实施这种架构以替代传统架构，是需要决策者（技术领导者或者架构...
2018-04-02
一个滚动重启的状态保存问题
很多时候滚动重启，都会导致状态丢失。比较好的设计方法是把服务本身设计成无状态的，然后在上游的服务上做好 failover，然后增加 standby server，让 sticky 数据 transmit 到 standby 机器上，让 request 失败以后可以自己由上游重传到 standby server。然后就可以滚动重启了。 这大部分场景下还要考虑幂等的问题。 这就看得出热配置热替换的重要性了。在大多数情况下，除了发布新的 feature 升级以外，都应该尽量用热配置来避免重启。
2025-07-15
系统的弹性
背景介绍 1999年，Dan Kegel 在互联网上发表了一篇文章，首次将 C10K 问题带入软件工程师的视野。在那个互联网勃兴的年代，计算机的运算处理能力，ISP 能够提供的带宽和网速都还十分有限，用户的数量也很少（那时候一个网站几百个人是很正常的事）。Dan Kegel 却已经敏锐地注意到极端的场景下资源紧张的问题。按照他的观察，某些大型的网络站点需要面对高达10000个客户端的并行请求。以当时的通行系统架构，单机服务器并不足以处理这个这个问题（当时绝大部分系统也没有那么大的流量，所以大部分人也没意识到这个问题）。因此，系统设计者必须为 C10K 问题做好准备。在那篇文章之中， Dan Kegel 提出了使用非阻塞异步 IO 模型，和使用各种内核系统调用黑魔法来提高系统 IO 性能的方式，来提高单机的并行处理能力。不得不说，这篇文章在当时很有先驱意义，它使得大规模网络系统的流量问题浮上了水面，也让人们意识到了系统容量建模和扩容提升性能的重要性。在它的启发下，C10K 问题出现了很多变种，从并发 C10K clients，到并发 C10K connections，到 C10K ...
