cjh的博客

文章目录合适原则1. 将军难打无兵之仗2. 罗马不是一天建成的3. 冰山下面才是关键简单原则1. 结构的复杂性2. 逻辑的复杂性演化原则之前聊了架构设计的主要目的是为了解决软件系统复杂度带来的问题，并分析了复杂度的来源。现在会分两篇文章讲讲架构设计的 3 个原则，以及架构设计原则的案例。成为架构师是每个程序员的梦想，但并不意味着把编程做好就能够自然而然地成为一个架构师，优秀程序员和架构师之间还有一个明显的鸿沟需要跨越，这个鸿沟就是“不确定性”。对于编程来说，本质上是不能存在不确定的，对于同样一段代码，

文章目录低成本安全1. 功能安全2. 架构安全规模1. 功能越来越多，导致系统复杂度指数级上升2. 数据越来越多，系统复杂度发生质变关于复杂度来源，之前已经聊了高性能、高可用和可扩展性，现在来聊聊复杂度另外三个来源低成本、安全和规模。低成本当我们的架构方案只涉及几台或者十几台服务器时，一般情况下成本并不是我们重点关注的目标，但如果架构方案涉及几百上千甚至上万台服务器，成本就会变成一个非常重要的架构设计考虑点。例如，A 方案需要 10000 台机器，B 方案只需要 8000 台机器，单从比例来看，也就节

文章目录预测变化应对变化复杂度来源前面已经讲了高性能和高可用，现在来聊聊可扩展性。可扩展性指系统为了应对将来需求变化而提供的一种扩展能力，当有新的需求出现时，系统不需要或者仅需要少量修改就可以支持，无须整个系统重构或者重建。由于软件系统固有的多变性，新的需求总会不断提出来，因此可扩展性显得尤其重要。在软件开发领域，面向对象思想的提出，就是为了解决可扩展性带来的问题；后来的设计模式，更是将可扩展性做到了极致。得益于设计模式的巨大影响力，几乎所有的技术人员对于可扩展性都特别重视。设计具备良好可扩展性的系

之前，已经分析了系统复杂度的来源：高性能。现在，我们聊聊系统复杂度的第二个来源：高可用。参考维基百科，先来看看高可用的定义。系统无中断地执行其功能的能力，代表系统的可用性程度，是进行系统设计时的准则之一。这个定义的关键在于“无中断”，但恰好难点也在“无中断”上面，因为无论是单个硬件还是单个软件，都不可能做到无中断，硬件会出故障，软件会有 bug；硬件会逐渐老化，软件会越来越复杂和庞大……除了硬件和软件本质上无法做到“无中断”，外部环境导致的不可用更加不可避免、不受控制。例如，断电、水灾、地震，

上次分析了架构设计的主要目的是为了解决软件系统复杂度带来的问题。那么从今天开始，将深入分析复杂度的 6 个来源，先来聊聊复杂度的来源之一高性能。对性能孜孜不倦的追求是整个人类技术不断发展的根本驱动力。例如计算机，从电子管计算机到晶体管计算机再到集成电路计算机，运算性能从每秒几次提升到每秒几亿次。但伴随性能越来越高，相应的方法和系统复杂度也是越来越高。现代的计算机 CPU 集成了几亿颗晶体管，逻辑复杂度和制造复杂度相比最初的晶体管计算机，根本不可同日而语。软件系统也存在同样的现象。最近几十年软件系统性能飞

架构设计的目的架构设计的误区架构设计的真正目的简单的复杂度分析案例聊了架构出现的历史背景和推动因素。以史为鉴，对我们了解架构设计的目的很有帮助。谈到架构设计，相信每个技术人员都是耳熟能详，但如果深入探讨一下，“为何要做架构设计？”或者“架构设计目的是什么？”类似的问题，大部分人可能从来没有思考过，或者即使有思考，也没有太明确可信的答案。架构设计的误区关于架构设计的目的，常见的误区有：因为架构很重要，所以要做架构设计这是一句正确的废话，架构是很重要，但架构为何重要呢？例如：不做架构设计系统就跑

架构设计的历史背景机器语言（1940 年之前）汇编语言（20 世纪 40 年代）高级语言（20 世纪 50 年代）第一次软件危机与结构化程序设计（20 世纪 60 年代~20 世纪 70 年代）第二次软件危机与面向对象（20 世纪 80 年代）软件架构的历史背景理解了架构的有关概念和定义之后，今天，将讲讲架构设计的历史背景。我认为，如果想要深入理解一个事物的本质，最好的方式就是去追寻这个事物出现的历史背景和推动因素。我们先来简单梳理一下软件开发进化的历史，探索一下软件架构出现的历史背景。机器语言（194

架构到底是指什么？系统与子系统模块与组件框架与架构重新定义架构小结虽然“架构”这个词常见，但如果深究一下“架构”到底指什么，大部分人也许并不一定能够准确地回答。例如：架构和框架是什么关系？有什么区别？Linux 有架构，MySQL 有架构，JVM 也有架构，使用 Java 开发、MySQL 存储、跑在 Linux 上的业务系统也有架构，应该关注哪个架构呢？微信有架构，微信的登录系统也有架构，微信的支付系统也有架构，当我们谈微信架构时，到底是在谈什么架构？要想准确地回答这几个问题，关键在于梳理几