编程和架构最大的区别是“不确定性”,编程写出来的程序是确定的,而不同的架构可能都适合于某个场景。
由于不同的架构都可能或看似可能适用于需求,或者团队成员又更熟悉某种技术栈,多种选择困难症压在架构师身上。这些选择哪一种都可能正确,但是哪一种合适却没有一套通用的规范,大多数都是依赖经验和直觉。
在设计架构的时候,不能总是瞄准着大厂的水准,总是想成为业界领先。但往往这样会忽略了业务的实际需求,而放大了工作量,导致失败。
脱离了业务,空谈架构反而做不出成绩。
团队压力有时会有意无意地促进我们走向复杂,如Zookeeper的主备策略让人总比心跳更高大上,导致更多的人觉得更可靠而选择更复杂的方案。
软件领域的复杂性体现在结构的复杂性和逻辑的复杂性。
结构复杂的系统一般有以下特点:
对于解决结构复杂性的问题,我们第一想法是将组件数量减少,但是过少也会引入新问题。
如果当个组件(或对象或函数)的逻辑过于复杂,也会带来问题。比如可扩展性问题、协作问题。
通常,企业发展起来构架的第一次改革都是因为组件过于复杂,需要对系统进行分割。
功能复杂的组件还有可能采用了复杂的算法,导致难以理解、难以改进。
据说,软件架构起源于建筑学。但是建筑一旦完成就不可变,而软件却还要根据业务的发展不断地变化。
而架构本质上不能一成不变,因为业务总是在变化。因此,也不会说照搬了某个企业的架构就能一劳永逸。
软件架构都需要经历以下过程:
淘宝技术发展经历了“个人网站”-> “Oracle/支付宝/旺旺”->“Java时代1.0”->“Java时代2.0”->“Java时代3.0”->“分布式时代”
2003年,淘宝赶着上线,就直接买一个产品和服务。没有太多的时间去考虑性能、稳定性什么的,因为项目落地、快速上线、抢占市场就是第一需求。
这里淘宝其实遵循着“合适原则”和“简单原则”。
此时距离之前的上线还只是半年不到,根据“合适原则”和“简单原则”,最简单的方式还是买买买。
由于网购火爆,业务剧增,MySQL撑不住了,于是换成了Oracle,容量大、稳定、安全、性能高。
而数据量大存储不足,则购买NAS,在加上Oracle RAC实现负载均衡。
起初选择Java的原因是:PHP连接Oracle的开源库(SQL Relay)总是死锁。
PHP + Apache每次请求都会对数据库产生一个链接,没有连接池,如此性能低效,因此选择了SQL Relay。
而这个技术的问题严重影响了业务的发展,不得不解决。
回顾这次改革,选择Java同时也算是打开了人才的道路,因为招聘比Java好不少。
业务发展到这个时间,买买买已经不能解决容量、性能、成本问题了。
在性能问题上,Oracle也始终没有文本搜索的性能,而成本问题更是致命的。
根据“演化原则”,技术人员需要回顾并重构。
淘宝也做了很多优化工作,如数据分库、放弃EJB、引入Spring、加入缓存、加入CDN等等。
此时业务规模足以让技术人员去IOE(IBM、Oracle、EMC),就是开始了自研技术,可以大幅度地降低技术成本。
手机QQ的发展粗略分为四个阶段:十万级、百万级、千万级、亿级。基本上是用户规模上去,产生问题,倒逼技术架构升级。
最开始的手机QQ后台是一个普通的架构,遵循着“合适原则”和“简单原则”。
2001年,QQ同时在线人数突破一百万,存在问题:
按照“演化原则”,进行重构:
2005年,QQ同时在线人数突破千万,出现新问题:
架构再一次“演化”:
2010年,QQ同时在线人数过亿,出现问题:
于是,“演化”出新架构
存储架构:
通信架构:
学习了面对“不确定性”时架构设计的三个原则以及两个案例。
先这样吧
若有错误之处请指出,更多地关注煎鱼。