转载

学架构笔记8和9:架构设计三原则以及案例

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

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

三个原则

合适原则

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

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

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

简单原则

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

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

结构的复杂性

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

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

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

逻辑的复杂性

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

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

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

演化原则

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

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

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

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

案例

淘宝

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

个人网站

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

学架构笔记8和9:架构设计三原则以及案例

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

Oracle/支付宝/旺旺

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

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

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

学架构笔记8和9:架构设计三原则以及案例

Java时代1.0

起初选择Java的原因是:PHP连接Oracle的开源库(SQL Relay)总是死锁。

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

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

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

学架构笔记8和9:架构设计三原则以及案例

Java时代2.0

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

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

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

学架构笔记8和9:架构设计三原则以及案例

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

Java时代3.0

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

手机QQ

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

十万级

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

学架构笔记8和9:架构设计三原则以及案例

百万级

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

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

按照“演化原则”,进行重构:

学架构笔记8和9:架构设计三原则以及案例

千万级

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

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

架构再一次“演化”:

学架构笔记8和9:架构设计三原则以及案例

亿级

2010年,QQ同时在线人数过亿,出现问题:

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

于是,“演化”出新架构

存储架构:

学架构笔记8和9:架构设计三原则以及案例

通信架构:

学架构笔记8和9:架构设计三原则以及案例

总结

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

先这样吧

若有错误之处请指出,更多地关注煎鱼。

原文  https://www.jianyujianyu.com/arichtect-learning-3-principle-example/
正文到此结束
Loading...