架构设计三原则

架构的不确定性

优秀程序员和架构师之间还有一个明显的鸿沟需要跨越，这个鸿沟就是“不确定性”。

1. 编程本质是确定的，同样一段代码，不管是谁写的，不管什么时候执行，执行的结果应该都是确定的
2. 架构设计本质上是不确定的，同样的一个系统，A 公司和 B 公司做出来的架构可能差异很大，但最后都能正常运转；

架构设计并没有像编程语言那样的语法来进行约束，更多的时候是面对多种可能性时进行选择
关键原因在于架构设计领域并没有一套通用的规范来指导架构师进行架构设计，更多是依赖架构师的经验和直觉

有几个共性的原则隐含其中，这就是：合适原则、简单原则、演化原则，架构设计时遵循这几个原则，有助于你做出最好的选择。

合适原则

“合适优于业界领先”。

• 没那么多人，却想干那么多活，是失败的第一个主要原因。
• 没那么多人，却想干那么多活，是失败的第一个主要原因。
• 没有那么卓越的业务场景，却幻想灵光一闪成为天才，是失败的第三个主要原因。

简单原则

“简单优于复杂”。

• 组件越多，就越有可能其中某个组件出现故障
• 某个组件改动，会影响关联的所有组件
• 定位一个复杂系统中的问题总是比简单系统更加困难

演化原则

“演化优于一步到位”。

• 对于建筑来说，永恒是主题；而对于软件来说，变化才是主题。
• 软件架构设计其实更加类似于大自然“设计”一个生物，通过演化让生物适应环境，逐步变得更加强大：

架构案例

淘宝

《淘宝技术发展》。淘宝技术发展主要经历了
“个人网站”→“Oracle/ 支付宝 / 旺旺”→“Java 时代 1.0”→“Java 时代 2.0”→“Java 时代 3.0”→“分布式时代”。

1. 个人网站
   2003 年 4 月 7 日马云提出成立淘宝，2003 年 5 月 10 日淘宝就上线了，中间只有 1 个月，怎么办？淘宝的答案就是：买一个。
   淘宝当时在初创时，没有过多考虑技术是否优越、性能是否海量以及稳定性如何，主要的考虑因素就是：快！
   在考虑如何买的时候，淘宝的决策依据主要也是“快”。
   买一个什么样的网站？答案是：轻量一点的，简单一点的。
   买一个系统是为了“快速可用”，而买一个轻量级的系统是为了“快速开发”。
   

2. Oracle/ 支付宝 / 旺旺
   流量和交易量迅速上涨，业务发展很快，在 2003 年底，MySQL 已经撑不住了。
   淘宝的方案非常简单，就是换成 Oracle。
   买更高配置的 Oracle，这个是当时情况下最快的方法。
   后来数据量变大了，本地存储不行了。买了 NAS（Network Attached Storage，网络附属存储）
   加上 Oracle RAC
   

3. Java 时代 1.0
   因为淘宝当时找了一个 PHP 的开源连接池 SQL Relay 连接到 Oracle，而这个代理经常死锁，死锁了就必须重启，而数据库又必须用 Oracle，于是决定换个开发语言。最后淘宝挑选了 Java
   将淘宝网站从 PHP 热切换到了 Java，后来又做了支付宝。
   这次切换语言，更多是为以后业务发展做铺垫，毕竟当时 PHP 语言远远没有 Java 那么火、那么好招人。
   这次架构的变化没有再简单通过“买”来解决，而是通过重构来解决，架构设计和选择遵循了“演化原则”。
   

4. Java 时代 2.0
   Java 时代 2.0，淘宝做了很多优化工作：数据分库、放弃 EJB、引入 Spring、加入缓存、加入 CDN、采用开源的 JBoss。
   前面的阶段，淘宝考虑的都是“快”，而现在开始考虑“容量、性能、成本”
   随着业务的发展，已经不是靠“买”就能够解决问题了
   

5. Java 时代 3.0 和分布式时代
   Java 时代 3.0 是淘宝技术飞跃的开始，简单来说就是淘宝技术从商用转为“自研”，典型的就是去 IOE 化。
   到了这个阶段，业务规模急剧上升后，原来并不是主要复杂度的 IOE 成本开始成为了主要的问题，因此通过自研系统来降低 IOE 的成本

手机 QQ

《QQ 1.4 亿在线背后的故事》
粗略划分为 4 个阶段：十万级、百万级、千万级、亿级

1. 十万级 IM 1.X
   遵循的是“合适原则”和“简单原则”。
   

2. 百万级 IM 2.X
   按照“演化原则”的指导进行了重构， 架构设计时也遵循了“合适原则”和“简单原则”
   

3. 千万级 IM 3.X
   这次的方案相比之前的方案来说并不简单了，这是业务特性决定的。
   

4. 亿级 IM 4.X
   IM 后台从 1.0 到 3.5 都是在原来基础上做改造升级的，但是持续打补丁已经难以支撑亿级在线，IM 后台 4.0 必须从头开始，重新设计实现！
   再次遵循了“演化原则”，决定重新打造一个这么复杂的系统

   • 存储
     
   • 通讯
     

结论

即使是现在非常复杂、非常强大的架构，也并不是一开始就进行了复杂设计
首先采取了简单的方式（简单原则），满足了当时的业务需要（合适原则），随着业务的发展逐步演化而来的（演化原则）