构建可扩展性系统的系列原则

从下线的百度空间后台找到一篇2008年文章分享如下，虽然已经过去7年，但其中的理念在今天依旧有效及被广泛讨论。

Building Scalable Web Sites一书大家基本上是冲着Flickr和Cal Henderson首席架构师的名头去的（首席目前创业做Slack），最近看到有中文版了就订了一本，书中全部代码用PHP为例，但其实没学过PHP的也大多能看懂。分享其中三个可扩展架构的观点。

1、使用远程服务的第一原则是不依赖远程服务，即Client需要具备容错策略，另外一方面远程服务要考虑冗余性，即Server能够failover到其它节点。远程服务的类型有好几种类型

1) 远程API，如XML-RPC, HTTP接口等。

这个是业务相关的，容错需要服务实现方和调用方自身去考虑及实现。

2) 存储类，如MySQL, NFS，Message Queue。

MySQL可用主从或MySQL proxy, NFS不知道，不稳定，关键业务用的场合不多。

3) Cache, 如Memcached,

Memcached默认可以分布多个，容错怎样处理？如果cache失效对系统影响比较大的话可以写双份，否则就立即切换到备用cache。

2、使用异步。异步系统也是架构中讨论较多的地方，任何一大型的系统，都会有不少异步的设计。

书中提到一种Ticket模型（点击图片全屏缩放浏览）

Ticket异步模型除了书中介绍的用来转换图片服务的场景之外，比如用在IM里面比如在群中发送图片功能。

1) 发送方发送/粘贴图片，立即显示发送完毕

2) 群中所有接收方立即显示接收到图片(只是个Ticket)

3) 系统实际上处于发送方上传图片中

4) 同时群中用户拿ticket去要图片(轮询or通知)。

5) 发送方上传完毕

6) 接收方凭Ticket获取到图片最终资源显示。

这个场景理论上就是和Ticket模型相似，但在实际操作上群图片还有更多细节考虑。

3、使用轻量级协议。HTTP和XML被过量使用，某些高访问场合未必是最好的选择。这就是Flickr为什么要使用自己的存储服务和协议。在当年2008年以及更早时候，使用XML的格式作为API还是非常流行，但到2015年的今天，很少有新的API用XML来承载了。

但这个问题是双面的，首先作者强调，“大多数场合，自行开发协议是糟糕的主意”，Tim也非常认同这一点。前面有多次文章提到。

另外中文版翻译的代码排版比较差，空行缩进行距等细节未注意，英文版书名是Building Scalable Web Site，感兴趣读者可以进一步了解。

(EOF)

顺便补充下百度空间的经历，大约在2006年注册，主要是考虑其功能简洁，没有广告。加上百度机房链路也不错，在广东访问比其它BSP快，因此就开始在上面写文章。早期的百度空间岁月比较愉快，平台较少干扰作者及读者，因此作者可以高效的创作，读者也有较好的访问及阅读体验。

后来也许是产品经理KPI的原因，空间后面的发展情况就让用户满意度越来越低，2008年我转移到独立blog域名发表文章，但空间上老的数据未做迁移，也很少维护。

在2012年左右，百度空间升级了一次，原来的 hi.baidu.com/username 中的username被重新洗牌，可能未及时维护的原因，所有文章的页面被自动重新分配了一个随机的URL。作为一个blog空间提供商，这个改变是非常不负责任的，URL的变化导致互联网上所有指向百度空间文章的URL都已失效。到2015年，整个空间下线。

为什么使用轻量协议是双刃剑？请回复“20”了解标准化的好处。

如果对可扩展架构感兴趣，前几天也介绍了我们可扩展架构群的一些情况，可回复“arch”进一步了解。

本文是TimYang原创的有关架构、技术、开发等方面系列文章，可长按下方微信号复制及订阅

TimYang_net