Architecture

我国在最晚不晚于宋代发明了水密隔舱。所谓水密隔舱，是指将船体分成若干个互不相通的舱区，这样当一个或几个舱区进水时，整个船体仍然可以有足够的浮力而不致沉没。这是一项相当重要的发明，类似的设计思路在其他领域也有应用。

多年以前在 USENIX HotOS 2003 论文集中看到了 一篇 关于 “Crash only software” 的论文，当时有一些想法，但很多没有认真地实践。最近做的东西用到的这方面的设计方法比较多，总结一下写出来。

访问听下包发现：

两个（组）前端：fronta和frontb，跑 Linux + Squid。图片（img）、动态页面采用同一组cache，后端使用apache 2.2.6，php 5.2.4。所有图片、静态js均假定用户不刷（i.e. 设置一个较长的过期时间）来减轻负载。

Translated from here.

下面这些指导方针大体上描述了我们的观念：

·绝不增加新功能，除非由于缺失它而有人无法完成某个实际的应用。
·确定一个系统「不是什么」，和它「是什么」同样重要。不去满足整个世界的每一个需求，相反地，让系统尽可能地容易扩展，从而使增加的新需求能够以向上兼容的形式添加。
·尽可能用通用的方法来解决问题，当然，从一个实例抽象出来的范型要比闭门造车强。
·如果一个问题没有被完整地理解，那么，也许最好干脆不去解决它。
·如果能用10%的努力完成90%的工作，那么，使用这个更简单的解决方案。
·尽可能隔离复杂性。
·提供机制，而不是策略。特别地，把用户界面策略交给客户去解决。

今天发生的事情让我只能用一个四个字母的单词来形容选课系统——不知道又是哪个学校的研究生设计的，不过，这一次，让人生气的是系统的设计者恐怕没有一点关于性能的常识，系统显然是给一二十人并发访问设计的，而这次选课的人，往少了说也得有三四千……

所有的力量显然都浪费在了做那个华而不实的界面上，用以性能差著称的TomCat承担如此重要的关键性生产服务，而又不采取任何提高性能的措施，例如，分散负荷，或者，仅仅是简单地分散数据库访问，甚至极其简单的将静态页分离的方法。