Loading...
avatar
Articles
1748
Tags
1820
Categories
32
Home
Archives
Tags
Categories
About
守株阁Gergely Orosz 文章翻译-软件架构被高估,简明设计被低估 Back to Home
Search
Home
Archives
Tags
Categories
About

Gergely Orosz 文章翻译-软件架构被高估,简明设计被低估

Created2022-01-19|Updated2026-10-08|系统架构
|Word Count:14|Reading Time:1mins|Post Views:

原文链接:《Software Architecture is Overrated, Clear and Simple Design is Underrated》

Author: magicliang
Link: https://magicliang.github.io/2022/01/19/Gergely-Orosz-%E6%96%87%E7%AB%A0%E7%BF%BB%E8%AF%91-%E8%BD%AF%E4%BB%B6%E6%9E%B6%E6%9E%84%E8%A2%AB%E9%AB%98%E4%BC%B0%EF%BC%8C%E7%AE%80%E6%98%8E%E8%AE%BE%E8%AE%A1%E8%A2%AB%E4%BD%8E%E4%BC%B0/
Copyright Notice: All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
系统架构翻译
Related Articles
cover
2018-01-30
几种共识算法
达成共识的英文原文是 come to consensus。达成共识以后,也未必代表数据是完全一致的(Raft 算法中 leader 发出 append log 的 commit 命令即算达成共识?但如果中途数据丢失,则还是会有子节点数据不一致)。 在分布式环境下,多个系统协同工作的效率,受制于系统交叉点的性能。在需要达成分布式共识的场景下,分布式共识算法在保证系统安全性的同时,限制了全系统横向扩展的性能提升。 根据环境的不同,可以应用不同的共识算法。 在完全互信的环境下-私有链、私有的分布式数据库,节点之间可以使用 Paxos 或者 Raft 这种 leader 相对固定的算法。 在有限互信的环境下-联盟链,可以使用 PBFT。PBFT 算法是依据确定性的投票(可能是漫长的投票,也可能进入死循环)达到确定性一致的算法。 在没有互信的情况下-公有链,可以使用 POW/POS/DPOS/POA。这类算法是基于概率得到正确的最终一致性,性能比 PBFT 要稍微好点。 最好的共识算法应该模块化,例如 Corda 中的 notary,Hyperledger fabric 中的 solo/k...
cover
2022-01-19
Gergely Orosz 文章翻译-成为一个更好的技术写作者
原文链接:《Becoming a Better Writer in Tech》
cover
2018-11-28
正交性
所谓正交性(orthogonal 意为正交的),就是设计的维度与其他维度完全隔离,一个正交的设计/值域设计,其变化绝不会受其他正交维度影响,也不会影响其他正交维度。 我们可以把 API 设计成正交的。这样 API 有独立变化的空间的。 我们可以把问题域切分清楚。问题域之间完全不相互干涉(注意跨问题域问题)。 我们可以把变量、字段、列设计成正交的。这样不同业务场景下,列之间的赋值不会相互覆盖。
cover
2020-09-02
异地多活与单元化
核心结论 单元化不是“多建几套机房”,也不是把应用复制到多个城市就结束。它解决的是一个更具体的问题:当业务规模大到单机房、单库、单服务集群都无法继续水平扩展时,如何让一部分用户或一部分业务身份的请求,从接入层、服务层、中间件到数据层,都尽量闭环在同一个逻辑单元里。 一个成熟的单元化系统,至少要把四个域对齐: 域 需要对齐的内容 失配后的结果 流量域 请求能按用户、商家、地域、订单等分片标识进入指定单元 入口正确,内部调用仍然乱跳 数据域 核心数据按同一分片规则落到对应单元 服务闭环,数据库跨城访问 故障域 单元故障只影响该单元承载的流量和数据 一个局部故障拖垮全站 治理域 路由规则、注册中心、发布、监控、演练都理解单元 规则靠人工同步,切换时失控 这个定义能把几个常被混用的词分开: 概念 隔离对象 是否要求存储隔离 常见用途 AZ(Availability Zone) 基础设施故障域 不要求 机房级容灾、容量冗余 Set / Cell 业务流量和业务数据 通常要求 容量扩展、故障隔离、异地多活 RZone / GZone / ...
cover
2022-01-17
如何成为一名优秀的架构师
成为一个架构师:为了这一刻,你准备了多久? 架构师的关注点:顶层设计、长期视角。 寿命:数据 > 代码(特指业务逻辑)> 技术(特指业务逻辑的载体) 不是传道受业,而是观点分享。 架构师的几种 profile:有架构能力、以架构为生也是一种架构师。 长期战略:对于任何一家公司,架构设计一定是必要的,而且需要自行解决。架构师的职责是保证组织拥有正确的设计,控制复杂度。 架构师的关键特质: 目标正确:限制条件和目标价值产生理解偏差。是架构师最常见的问题。 能力满足:为组织带来更好的外部适应性。 持续减熵:好架构等于发现、规划和演化。 思考深度和实战经验最重要:这是任何的书本都不能带给我们的。包容、求真、良知、勇气。 有没有德?考虑组织长期利益(基于良知做判断)。 有没有勇气?承担责任,决定命运。 有没有眼光?是否擅于思考? 独立、理性、有深度的思考。长期感召力,来自于良知、成功、经验和勇气。 从复盘中学习。 郭东白.pdf
cover
2023-02-13
推荐系统相关
新闻的推荐系统是为了给信息流的用户推荐资讯 feed。接口返回的信息不一定会被外显曝光。 在瀑布流式的外显曝光场景下,重排能够减少用户的疲劳度。 这就涉及到推荐系统的设计,流量要经过什么样的链路呢? 接入层、推荐中控、画像、召回、粗排、精排、重排。这些系统会形成星型架构和树形架构。 不同的架构之间有一个典型的优缺点需要取舍:链路长度会影响网络传输的最终效率,也会影响推荐系统的性能。 feeds推荐引擎典型架构.drawio
avatar
magicliang
关于技术以及人生
Articles
1748
Tags
1820
Categories
32
Github
Announcement
人生只是,守株待兔
Recent Posts
密码学 18:mTLS 与 TLS 终止后,客户端、代理和后端分别信谁
密码学 18:mTLS 与 TLS 终止后,客户端、代理和后端分别信谁2026-10-06
密码学 17:恢复连接、PSK 与 0-RTT 省掉了什么
密码学 17:恢复连接、PSK 与 0-RTT 省掉了什么2026-10-06
密码学 16:TLS 怎样保护每条记录
密码学 16:TLS 怎样保护每条记录2026-10-06
密码学 15:TLS 1.3 握手逐步解释
密码学 15:TLS 1.3 握手逐步解释2026-10-06
密码学 14:证书为什么能绑定服务名与公钥
密码学 14:证书为什么能绑定服务名与公钥2026-10-06
© 2017 - 2026 By magicliangFramework Hexo 8.1.2|Theme Butterfly 5.7.0
Search
Loading Database