系统设计中的简单法则

标签: 系统 设计 法则 | 发表时间:2012-05-07 05:25 | 作者:[email protected] (秩名)
出处:http://www.kuqin.com/jingyan/

最近,包云岗在自己的 博客中总结了系统设计中的基本法则——简单之美,列举了不少经典观点和案例。

他首先总结了麻省理工方法(MIT Approach)和新泽西方法(New Jersey Approach)的异同:

  • 简单性:两种方法都强调设计必须简单,这既是对实现的要求,也是对接口的要求。但是,MIT方法认为接口的简单要比实现的简单更加重要,而NJ方法认为实现的简单要比接口的简单更加重要。
  • 正确性:设计在任何值得注意的方面都要保证正确。但是,MIT方法认为不正确是绝对不允许的,而NJ方法认为,为了简单性,正确性可以做轻微的让步。
  • 一致性:MIT方法认为,设计必须保持一致兼容。设计可以允许轻微少量的不简单和不完整,来避免不一致。一致性和正确性同等重要。而NJ方法认为,设计不能过度不兼容一致。为了简单,一致性可以在某些方面做些牺牲,但与其允许设计中的这些处理不常见情况的部分去增加实现的复杂性和不一致性,不如丢掉它们。
  • 完整性:设计必须覆盖到实际应用的各种重要场景。所有可预料到的情况都必须覆盖到。MIT方法认为,简单性不能过度的损害完整性。NJ方法则认为,为了保证其它几种特征的品质,完整性可以作出牺牲。事实上,一旦简单性受到危害,完整性必须做出牺牲。一致性可以为实现的完整性作出牺牲;最不重要的是接口上的一致性。

包云岗还引用了一个案例来证明两种方法的差异:

一位MIT的教授一直困恼于Syscall处理时间过长出现中断时如何保护用户进程某些状态,从而让用户进程能继续执行。他问新泽西人,Unix是怎么处理这个问题。新泽西人说,Unix只支持大多数Syscall处理时间较短的情况,如果时间太长出现中断Syscall不能完成,那就会返回一个错误码,让用户重新调用Syscall。但MIT人不喜欢这个解决方案,因为这不是“正确的做法”

对于现在的互联网企业,是否还需要遵从这些法则呢?国外有篇博文《 Scalability lessons from Google, YouTube, Twitter, Amazon, eBay, Facebook and Instagram》总结了各大公司的经验教训,其中第一条就是“保持简单”。但是包云岗认为,这和New Jersey Approach的原因和内涵有所不同。不同于Unix时代相对简单的单机系统,互联网时代的大公司的系统往往都是成千上万台机器,在这样的系统上部署、管理服务(软件)是一项非常有挑战的任务。而为大规模用户提供的一项服务往往会涉及到众多模块、若干步骤。此时“简单”就是要求每个阶段、每个步骤、每个子任务尽量采用最简单的解决方案,这是由于大规模系统内在的不确定性导致的复杂性决定的。

无独有偶,包云岗发现硅谷 创业之父Paul Graham也推崇简单法则,Paul在《黑客与画家》的“设计者的品味”一章中写到,“好的设计是简单的”、“简单就是美,正如漂亮的数学证明往往是简短而巧妙的那种”。他提到,有些创业者希望第一版就能推出功能齐全的产品,满足所有的用户需求,但这种想法是致命的。在硅谷创业最忌讳的就是“Premature Optimization”。因为一方面用户需求是多样的,不同人群都有不同的需求;另一方面开发者想象的需求往往和真实的用户需求有偏差。所以,Graham推崇那种有用户参与反馈的迭代优化的方式。

包云岗还与普林斯顿大学计算机系的李凯教授有过简单法则的交流和讨论:

李凯老师的做事方式是——只抓住大方向,其他问题尽量简化。但真正要做到KISS原则其实并不容易。我在遇到问题时,往往会从各个方面去考虑问题,其中难免包含了各种细枝末节,这种方式导致问题经常会变得非常复杂。之前讲过这个例子,在移植TCP/IP协议栈到用户态时,我觉得有约10个功能需要考虑。和李老师讨论,他让我把那些功能分成两类:“必须有(Must Have)”和“可以有(Nice-to-Have)”。当我试了这种方法,发现原来Must-Have的功能其实也不过2~3个而已。而最近的例子则是在要设计一个功能让TCP/IP连接的Server在模拟器中、Client在真实机器。我考虑是尽量减少模拟器上OS的开销,所以打算采用自己写一个设备、然后让用户态程序Bypass Kernel直接访问该设备的方案。但李凯老师在了解OS开销以后,认为容忍开销、尽量直接使用模拟器自己带的功能,让开发更简单。

这些教训也让我不断地去思考为什么要用KISS原则。慢慢地我体会到,KISS原则目的其实是——“快速推进、逐步优化”。我们设计一个算法,往往可以在大脑中预先思考好,然后直接 编程写出来。但是,我们设计实现一个系统,当系统的复杂度超出我们大脑的工作记忆容量时,就无法在大脑中去“模拟”每一个细节。此时,我们应该用最快的速度去把系统建起了,然后再对各个环节进行优化。

读者朋友对系统设计的简单法则有何看法?欢迎大家发表自己的意见。

崔康 热情的技术探索者,资深软件工程师,InfoQ编辑,从事企业级Web应用的相关工作,关注性能优化、Web技术、浏览器等领域。

美工程师设计真空管运输系统:6小时环游世界
系统设计黄金法则 简单之美
举例分析系统设计的内涵及设计师职责
解析游戏设计策略之奖惩系统
简单讨论火车票系统后面的架构设计

[ comments ]

相关 [系统 设计 法则] 推荐:

系统设计中的简单法则

- - 酷勤网-挖经验 [expanded by feedex.net]
最近,包云岗在自己的 博客中总结了系统设计中的基本法则——简单之美,列举了不少经典观点和案例. 他首先总结了麻省理工方法(MIT Approach)和新泽西方法(New Jersey Approach)的异同:. 简单性:两种方法都强调设计必须简单,这既是对实现的要求,也是对接口的要求. 但是,MIT方法认为接口的简单要比实现的简单更加重要,而NJ方法认为实现的简单要比接口的简单更加重要.

评价系统设计篇

- - 互联网 - ITeye博客
评论系统大家都见得非常多了,大到京东、淘宝、亚马逊,小到个人网站、博客都有评论系统,小型网站采用传统PHP+Mysql方式就能很快将系统搭建起来,同时采用单库单表方式就能轻松解决数据存储、数据查询等问题,但是对于上述中大型网站而言,已经远远不能支撑系统正常运行了. 接下来将从系统架构、数据存储、高性能服务等方面来揭示京东的评价系统在面对海量数据、海量请求的情况是如何处理的.

思考系统API设计的问题

- edware_love - C++博客-首页原创精华区
最近正好在思考系统API设计中考量的一些问题,. 我现在的理解是这样的,假设有巨大的真实内存. windows首先将高2G的内存自己占了,用作各种内核对象. 这2G内存共享给每个进程,但进程不能直接访问,只能通过windows给定的函数访问. : 然后每个进程都给他2G内存,进程如果创建自己的对象就放到自己那2G内存里面,如果要建立内核对象就放到共享的那高2G里面去.

财务系统设计的思考

- - 行业应用 - ITeye博客
说到财务系统的设计,就不由得联想到了目前很流行的一个职业“互联网产品经理”,他们的设计着眼于用户体验,创造出新的功能,改善着上亿网民的生活,比如扫一扫,摇一摇等. 财务系统不同于互联网的产品,它的复杂性对于没有深入了解它的人来说,是不太能想象出来的. 互联网的功能开发,讲究的是时效,从一个点子,到产品发布可能只用一周的时间,然后如果市场冷淡,可能第三周就下线了.

12306订票系统设计关键点

- - 互联网旁观者
12306全国火车票网上售票网站的情况大家都见到了,如果让你来设计该订票网站,你会如何设计才能应对如此大规模以及高并发的情况呢. 以下是百度前技术总监邵辉给出的设计:. 列车在线订票系统的业务逻辑比较简单,不用多说. 可能的瓶颈有两个,一个是车次和剩余票量的查询,一个是下单. 在设计软件架构之前,需要先研究产品需求、软硬件条件、网络环境以及关联系统的接口,但这些资料无从获得,所以只能做几点分析和假设,做为设计的前提条件.

网购秒杀系统架构设计

- - 企业架构 - ITeye博客
秒杀活动只是网站营销的一个附加活动,这个活动具有时间短,并发访问量大的特点,如果和网站原有应用部署在一起,必须会对现有业务造成冲击,稍有不慎可能导致整个网站瘫痪. 用户在秒杀开始前,通过不停刷新浏览器页面以保证不会错过秒杀,这些请求如果按照一般的网站应用架构,访问应用服务器、连接数据库,会对应用服务器和数据库服务器造成极大的负载压力.

秒杀系统设计的知识点

- - 互联网 - ITeye博客
A, 高并发,cache,锁机制 . B, 基于缓存架构redis,Memcached的先进先出队列. C, 稍微大一点的秒杀,肯定是分布式的集群的,并发来自于多个节点的JVM,synchronized所有在JVM上加锁是不行了. F, 如何防止用户来刷, 黑名单. G, 利用memcached的带原子性特性的操作做并发控制. .

O2O供应链系统架构设计

- - 美团技术团队
本文是美团技术沙龙第一期, O2O技术架构与实践上的分享内容. 请在微信搜索“美团技术团队”关注我们的公众账号,了解更多活动信息. 英国知名供应链专家Martin Christopher曾经说过一句非常深刻的话:“21世纪的竞争不是企业和企业之间的竞争,而是供应链和供应链之间的竞争. 在风云变幻、寡头纷争的O2O战场,美团屡出重拳并步步为营,战绩不俗.

(转)面向鲁棒的系统设计

- - jackyrong
本来打算叫做面向异常的编程的,后来觉得可能多的是系统健壮性方面,于是改名面向鲁棒的系统设计,所谓鲁棒,鲁棒是Robust的音译,也就是健壮和强壮的意思. 它是在异常和危险情况下系统生存的关键. 平时在做业务系统的时候,尤其是最近一年多接触的超复杂系统,发现处理线上问题所占的时间越来越多,总结发现,其实这些问题大都是之前欠下的债,至于为啥欠债,大多数情况下迫于项目或者日常的时间压力,很多设计从简,业务流程考虑主流程和分支流程,异常流程关注的少,不管三七二十一,功能先上线再说,如此便导致了恶性循环.

秒杀系统设计详解

- - 企业架构 - ITeye博客
高并发系统的设计及秒杀实践 - (秒杀队列、分库存). 秒杀场景一般会在电商网站举行一些活动或者节假日在12306网站上抢票时遇到. 对于电商网站中一些稀缺或者特价商品,电商网站一般会在约定时间点对其进行限量销售,因为这些商品的特殊性,会吸引大量用户前来抢购,并且会在约定的时间点同时在秒杀页面进行抢购.