---
title: '学架构笔记8和9：架构设计三原则以及案例'
pubDate: 2018-06-15
tags:
  - 'architect'
  - '后台'
  - '笔记'
description: '学架构笔记8和9：架构设计三原则以及案例'
---

编程和架构最大的区别是“不确定性”，编程写出来的程序是确定的，而不同的架构可能都适合于某个场景。

由于不同的架构都可能或看似可能适用于需求，或者团队成员又更熟悉某种技术栈，多种选择困难症压在架构师身上。这些选择哪一种都可能正确，但是哪一种合适却没有一套通用的规范，大多数都是依赖经验和直觉。

## 三个原则

### 合适原则

在设计架构的时候，不能总是瞄准着大厂的水准，总是想成为业界领先。但往往这样会忽略了业务的实际需求，而放大了工作量，导致失败。

1. 往往没有业务量，就不会有太多的人力资源去支撑“大架构”
2. 业界顶尖的架构都是通过逐步完善得出的
3. 好的架构不是想出来的，是业务场景和压力的情况下逼出来的

脱离了业务，空谈架构反而做不出成绩。

### 简单原则

团队压力有时会有意无意地促进我们走向复杂，如Zookeeper的主备策略让人总比心跳更高大上，导致更多的人觉得更可靠而选择更复杂的方案。

软件领域的复杂性体现在结构的复杂性和逻辑的复杂性。

#### 结构的复杂性

结构复杂的系统一般有以下特点：

1. 组件数量多
2. 组件之间的关系复杂
3. 定位组件问题困难

对于解决结构复杂性的问题，我们第一想法是将组件数量减少，但是过少也会引入新问题。

#### 逻辑的复杂性

如果当个组件（或对象或函数）的逻辑过于复杂，也会带来问题。比如可扩展性问题、协作问题。

通常，企业发展起来构架的第一次改革都是因为组件过于复杂，需要对系统进行分割。

功能复杂的组件还有可能采用了复杂的算法，导致难以理解、难以改进。

### 演化原则

据说，软件架构起源于建筑学。但是建筑一旦完成就不可变，而软件却还要根据业务的发展不断地变化。

而架构本质上不能一成不变，因为业务总是在变化。因此，也不会说照搬了某个企业的架构就能一劳永逸。

软件架构都需要经历以下过程：

1. 设计出来的架构满足当前业务
2. 架构不断迭代，取其精华去其糟粕
3. 也许要重构重写，但是总有东西能延续

## 案例

### 淘宝

淘宝技术发展经历了“个人网站”-> “Oracle/支付宝/旺旺”->“Java时代1.0”->“Java时代2.0”->“Java时代3.0”->“分布式时代”

#### 个人网站

2003年，淘宝赶着上线，就直接买一个产品和服务。没有太多的时间去考虑性能、稳定性什么的，因为项目落地、快速上线、抢占市场就是第一需求。

![](https://source.mkshell.com/15290417695274.jpg)

这里淘宝其实遵循着“合适原则”和“简单原则”。

#### Oracle/支付宝/旺旺

此时距离之前的上线还只是半年不到，根据“合适原则”和“简单原则”，最简单的方式还是买买买。

由于网购火爆，业务剧增，MySQL撑不住了，于是换成了Oracle，容量大、稳定、安全、性能高。

而数据量大存储不足，则购买NAS，在加上Oracle RAC实现负载均衡。

![](https://source.mkshell.com/15290420416513.jpg)

#### Java时代1.0

起初选择Java的原因是：PHP连接Oracle的开源库（SQL Relay）总是死锁。

> PHP + Apache每次请求都会对数据库产生一个链接，没有连接池，如此性能低效，因此选择了SQL Relay。

而这个技术的问题严重影响了业务的发展，不得不解决。

回顾这次改革，选择Java同时也算是打开了人才的道路，因为招聘比Java好不少。

![](https://source.mkshell.com/15290423923519.jpg)

#### Java时代2.0

业务发展到这个时间，买买买已经不能解决容量、性能、成本问题了。

在性能问题上，Oracle也始终没有文本搜索的性能，而成本问题更是致命的。

根据“演化原则”，技术人员需要回顾并重构。

![](https://source.mkshell.com/15290426033565.jpg)

淘宝也做了很多优化工作，如数据分库、放弃EJB、引入Spring、加入缓存、加入CDN等等。

#### Java时代3.0

此时业务规模足以让技术人员去IOE（IBM、Oracle、EMC），就是开始了自研技术，可以大幅度地降低技术成本。

### 手机QQ

手机QQ的发展粗略分为四个阶段：十万级、百万级、千万级、亿级。基本上是用户规模上去，产生问题，倒逼技术架构升级。

#### 十万级

最开始的手机QQ后台是一个普通的架构，遵循着“合适原则”和“简单原则”。

![](https://source.mkshell.com/15290432323622.jpg)

#### 百万级

2001年，QQ同时在线人数突破一百万，存在问题：

1. 接入服务器性能吃紧，内存不足
2. CPU、网卡带宽、流量到了瓶颈
3. 单台服务器支持不了所有的在线用户（注册用户也存不下）

按照“演化原则”，进行重构：

![](https://source.mkshell.com/15290433716224.jpg)

#### 千万级

2005年，QQ同时在线人数突破千万，出现新问题：

1. 同步流量太大，状态同步服务器遇到了单机瓶颈
2. 在线状态信息量太大导致单台服务器存储不足
3. 单台状态同步服务器支撑不了所有的在线用户
4. 单台接入服务器支撑不了所有在线用户的在线状态信息

架构再一次“演化”：

![](https://source.mkshell.com/15290435251484.jpg)

#### 亿级

2010年，QQ同时在线人数过亿，出现问题：

1. 灵活性差，功能扩展困难
2. 无法支撑某些关键功能
3. 之前一直在原基础上升级，现在需要重新设计

于是，“演化”出新架构

存储架构： ![](https://source.mkshell.com/15290436741344.jpg)

通信架构： ![](https://source.mkshell.com/15290436905683.jpg)

## 总结

学习了面对“不确定性”时架构设计的三个原则以及两个案例。

_先这样吧_

若有错误之处请指出，更多地关注[煎鱼](http://www.jianyujianyu.com)。