最近思考一些网站架构的问题，这两天着重思考了下memcache对于网站架构的作用以及意义。

memcache作为一个很早就出现的网站架构的一环有很重要的历史意义，但随着技术的不断发展，各种不同的中间件在整个系统中的作用也在不断的发生着变化。

myspace曾经作为全世界流量最大的网站，而memcache在myspace的网站架构中起到了至关重要的作用，myspace采用了自行开发的memcache，每台服务器拥有至少64g的内存，全部用来做缓冲，每个服务器缓冲的内容完全相同，每个服务器之间采用类似连锁复制的概念来进行同步，每当一个服务器的cache发生了变化，会从该服务器开始顺序的触发复制更新到所有的cache服务器。

在myspace的架构中，memchache的作用毋庸置疑，没有cahce这一层，只靠sqlserver是无法支撑这么大的流量的，但我并不清楚myspace是在什么阶段引入的cache层，而且在myspace使用的是收费的sqlserver，每台高配的sqlserver需要巨额的授权费，每台8核的服务器，需要支付微软近rmb80万的授权费，这样引入cache层的另一个很重要的作用是减少成本。

现代的数据库服务器都自己带有cache层，同时绝大部分数据库的操作都完全是在内存中完成的，所以数据库的支持能力比起memchache来说，除了多了存储开销以外，就是数据的重新组织，但如果有足够的内存，而经常访问的sql比较固定来说，那么数据库本身的cache层可以部分替代memcache的功效。

无论如何，纯粹做cache的性能是要高于数据库服务器的，这点毋庸置疑，但是要考虑到引入cache层意味着给开发以及部署都带来了新的麻烦，这点是需要有得失权衡的，我思考的建议是，当网站的访问量并不那么大时，不需要引入memcache，直到访问量到达一定的级别，比如数据库服务器如果少于10台，完全没有必要引入memcache，因为此时运营的成本很低，而不考虑cache层无论是开发，部署还是运营都可以减少很大的便利。当访问量进一步增加，此时假设每增加一台数据库可以提供200的并发性能提升，而引入cache层可以提供300的并发提升，此时引入cache层将在性价比上得到体现，当数据库规模比如达到了100台的规模，此时同时维护100台数据库服务器会是一种很大的运营开销，而相对来说cache的运营维护要低很多，所以到不如使用60台cache，40台数据库的架构，如果数据库是收费的，则此时的成本优势则更明显。

综上所述，在网站的访问量规模不大的情况下，尽量不要引入cache层增加网站架构的复杂，带来不必要的运营，开发，测试的麻烦，当访问规模到达一定程度后再考虑使用memcache而提高性价比。

最近在某社区网站上看到一位网友的吐槽——“免费云空间除了搭博客还能干点啥？”，看到这个问题，我的心情完全可以用五味杂陈来形容。一方面，功能强大的PaaS服务，竟被看做一个只能搭建博客的玩具，心里多少有些不舒服；另一方面，PaaS服务近年来鲜有大的发展，各方面依然有待提高，所以更多的是被作为免费空间或搭建个人博客使用。作为一个长期关注并看好PaaS服务的IT爱好者，看到PaaS的这种窘境，心中有种说不出的痛。那么，究竟是什么原因使得PaaS(xAE)服务发展缓慢？我认为是下面几个因素造成的。

第一、政策因素。有关政策规定，服务器位于国内的网站必须先备案才能上线运营。然而，国内各大PaaS服务商普遍面临的一个窘境就是，一方面用户有强烈的绑定独立域名的需求，而另一方面，受制于现有政策，PaaS服务商没有提供ICP备案的资格。

因此，大多数PaaS服务商选择了不支持独立域名绑定，或者在海外搭建反向代理来间接支持该功能。如此一来，或不能满足用户的基本需求，或访问缓慢，经常出现“连接超时”、“网络被重置”等网络错误，影响用户体验。即便是支持域名绑定到国内IP的服务商，也要求待绑定域名已经完成备案，从而导致了很多用户不得不先购买一个廉价的国内空间备案，再将域名绑回PaaS服务。即便这样操作具有一定的可行性，但也大大增加了使用PaaS服务的复杂程度；从另一方面讲，在用户将顶级域名解析到PaaS服务之后，同时也面临着因IP指向变更而导致备案被注销的危险。

假如备案政策能够对PaaS服务有所倾斜的话，那么许多要求不甚严格的中小网站（如企业宣传网站、个人博客）便可以直接迁移到PaaS云服务，既提高了网站性能，同时又降低使用成本（按需付费有利于中小网站）。

第二、兼容性不好。从xAE的始祖Google App Engine(GAE)开始，xAE便有一个“臭毛病”，就是要使用其提供的服务，则必须使用给定的API接口。如此一来，造成了非常严重的后果：

1.给用户程序的迁入造成了很大障碍。特殊的服务器环境使得绝大多数既有程序必须移植才能使用，既增加了程序的使用难度，降低了可用程序的丰富性，也加大了程序因移植而导致的不确定性和不稳定性。以新浪SAE的PHP环境为例，尽管PHP语言有很多现成的程序，但受限于本地I/O写操作，Discuz!、PHPWind等热门程序均不能直接使用；即便是最成熟的WordPress程序，也存在一些问题，远不如在虚拟主机上跑原生程序方便。

2.这也给用户程序的迁出造成了不便。在PaaS服务的稳定性还不能完全得到验证的情况下，保证应用可以在发生故障时迅速迁出就显得至关重要了。但是，由于程序严格依赖于PaaS环境，就使得迁移时不得不二次修改程序，增加了迁移难度；更糟糕的是，可能会因为迁出云平台有某一服务能力、而迁入云平台没有该能力导致服务不可用。以NoSQL数据库为例，新浪SAE使用的是KVDB，而百度BAE使用的则是MongoDB和Redis，一旦更换平台，势必造成很多麻烦。此外，当云平台储存的数据量稍大些时，数据的导出也是一个不小的问题。从迁出这个角度来看，我们也不难理解WordPress为什么会成为PaaS平台上最流行的程序了。

所以，我认为PaaS服务向虚拟主机看齐并不是一件十分丢人的事情，而是一件十分紧迫的事情，一件PaaS要腾飞必须做的事情。当然，看齐并不是要照抄，毕竟PaaS附带的众多服务是普通虚拟主机所难以企及的。我的建议是，借鉴新浪SAE的Wrappers设计，将MemCache、云存储等服务以文件夹映射的形式提供给开发者使用，尽量做到在为开发者提供优质、丰富服务的同时做到对其透明，这才是PaaS服务超越虚拟主机的根本。