【架构】08-架构设计三原则

最新推荐文章于 2024-10-26 18:46:01 发布

孤独如梦

最新推荐文章于 2024-10-26 18:46:01 发布

阅读量3.9k

点赞数

分类专栏：架构文章标签：架构

本文链接：https://blog.csdn.net/xiaoxizhe/article/details/83411666

版权

架构专栏收录该内容

7 篇文章 0 订阅

订阅专栏

一、前言

成为架构师是每个程序员的梦想，但是程序员和架构师之间有一个巨大的鸿沟，需要程序员去跨域方能成为架构师，那就是“不确认性”。

对于编程而言，其结果是确定的，但是对于架构是不确定的。架构没有编程那么的的约束，可以使用这种方式去实现，而对各种选择，我们就容易迷茫，到底是选择业务最先进的技术，还是开源、商业的…,面对各种选择，架构师可以遵循下面三个原则来做出选择，那就是：

合适原则
简单原则
演化原则

二、合适原则

合适原则的宣言:"合适优于业界领先"

很多技术人员有很强的技术情节，每次都想挑战自己，想达到甚至超越业界领先水平。但是一般这样做下去的结果就是失败。几个人的团队想要做出QQ、微信这个体量的应用，那是不可能的，为什么呢?

将军不打无兵之仗

大公司分工很细，一个小系统可能就有十几个人负责，整个研发团队有上百人，但是小公司的话，整个团队才十几个人。十几个想做几十人的活，并且还想做的更好，不能说绝对不可能，但是难度会非常大。

没那么多个却想干那么多人的活，是失败的主要原因。
罗马不是一天建成的

业界领先的方案并不是某个天才忽然间想到的，而是经过不断的发展才不断完善的。阿里中间件团队 2008 年成立，发展到现在已经有十年了。我们只知道他们抗住了多少次“双 11”，做了多少优秀的系统，但经历了什么样的挑战、踩了什么样的坑，只有他们自己知道。！这些挑战和踩坑，都是架构设计非常关键的促进因素，单纯靠拍脑脑袋或者头脑风暴，是不可能和真正实战相比的。

没有那么多的积累，却想一步登天，是失败的第二个原因。
冰山下面才是关键
业务领先方案不是天才想出来的，而是业务倒逼出来的。业务发展到一定阶段，旧的方案已经不适合于现在的业务场景,需要一个新的方案来满足业务。通过创新和尝试才会有新的方案。

没有那么卓越的业务场景，却幻想灵光一现成为天才，是失败的第三个原因。

所以说，真正优秀的架构是在公司现有人才、业务、条件等约束下，能够合理的整合资源，发挥出最大的功效，并且能够快速落地。

三、简单原则

简单原则的宣言：简单优于复杂

软件架构的一门技术活，很多人都会把软件架构与传统的建筑做对比，它们二者间有很多的相似之处。但是它们有很大的区别，建筑追求的是不变，可以追求复杂，而软件追求的是变。建筑建好以后，几十年上百年都可能不会发生改变，但是软件的话，会跟着需求不段的发生变化。复杂在建筑领域代表的是先进，但是在软件领域代表的则是问题。
软件领域的复杂主要体现在下面几个方面：

结构复杂性
- 组成复杂系统的组件多
- 组件间的关系复杂
逻辑复杂性

意识到结构复杂性后，我们的第一反应就是减小组件，但是减小组件会有另外一个问题，那就是组件逻辑复杂。假如我们把电商的所有模块(登录、注册、购物车、商品、支付、订单)放在一个组件，那就是典型的逻辑复杂性。
把这些放在一起会有什么样的问题呢？
- 代码体量大，每次clone代码都要好久
- 每次部署都花费很久、每次修改都要重新部署
- 生产定位问题困难，并且每次出问题都要拉上所有的小伙伴。
- 需求满天飞，因为所有的业务都在一个系统里，每天都在开会、开会中。
- 版本太多，每天都要上线很多个版本，系统每天要重启十几次。
不用多想，出现这样的问题，每个人都会受不了。
功能复杂的另一个特点，就是算法复杂。算法复杂的一个问题就是定位问题困难。

无论是结构复杂还是逻辑复杂，都会改系统带来很大问题，所有在做架构时，在有复杂方案和简单方案可以选择时，尽量选择简单方案。