[网站架构]Boom&Bust---18个月架构

>>>>Boom and bust

我做互联网的几年，最深刻的感悟就是“18个月架构”——从公司对网站的投资回报模型开始，到产品部门设计产品，最后才走到功能实现的流程，当我拿到这份功能需求的时候，我更希望看到的是一个roadmap，一个不多不少，刚好18个月的产品规划。

为什么是18个月？没有什么很科学的解释，完全是对成功的互联网企业产品的分析和自己的亲身经历。越失败的公司在设计产品产品的时候考虑的路子越窄，当然这里是排除有创新的技术实力雄厚的员工数量很少的互联网企业。一个优秀的互联网企业，最直观的表现就是对待产品的态度，最终要做什么，每一步怎么实现，装饰性功能带来效应的线性增长状况和催化效应等等，都应该考虑在18个月内。

为什么一个简单的不得了的功能一定要费很大的精力去做？为什么要破坏书本上和某某技术大牛的经验之谈去写bad smell的代码？website的架构在高可扩展性、高可用性和高并发支持外，还有没有更重要的？

都是搞技术的，我们从starbucks对http的理解上来看：

"Even those who are Web-savvy often struggle to understand that the Web isn't about middleware solutions supporting XML over HTTP, nor is it a crude RPC mechanism. This is a shame because the Web has much more value than simple point-to-point connectivity; it is in fact a robust integration platform."

我挺赞同他们对http的理解，我也认为集合了原子性操作的http其实是扮演着集成平台的角色。当我们把所有功能划分为Get和Post操作并keep focus在这些问题上的时候，忽略了“战略”。战略就是产品的roadmap，是盈利模式的逐步实现。因此web的架构，还有一个维度，我喜欢叫做“产品战略架构”，也就是大家都常听到的“应用架构”。

因此，对于web的架构，是应用架构和系统架构的平衡。因为要去选择这个平衡，所以要放弃很多“看起来很美好的东西”。web的架构不会十全十美，不会永远都是可以随意靠Scale-Out来解决问题，走到一定的阶段，重写比重构更经济，当一个架构无法再承载目前的数据和访问压力的时候，重新设计一套方案往往都会是比较正确的选择——产品或者其某一部分已经达到了一个临界点，可以在这上面做文章了！假设这时候我们已经经历了M个月，那么剩下的18-M个月已经不再那么重要，互联网的产品的变化往往很难预计，当在一个相对成熟的产品之上再做“战略”的时候，产品应该提出一个6个月的路线图，这时的架构需要去重构，去扩张，去做性能优化以支撑，这6个月往往都是实验性的产品变化，当相对稳定的时候，再去考虑该如何重写。

回到文章的标题，wikipedia上对于Boom and bust这个经济学里的词汇是这样定义的“Boom and bust phenomenon have existed for centuries. During a "boom" period, buyers find themselves paying increasingly higher prices until the "bust", at which time the goods and commodities for which they have paid inflated prices may end up as valueless or nearly so.”。可惜的是没有人对该词条做过中文翻译，大概意思是说，在经济繁荣的时期，买家支付越来越高的价格，导致商品因为他们支付的价格膨胀，直到经济萧条的时候买家不再提高价格了，但是这时候他们才发现这些商品已经是豪无价值了。

所以我对于web架构的理解，是：产品设计与系统架构是紧密相关的，架构的不是功能，而是产品和其与其他产品的集成，并保证整个系统在高并发高负载下的高可用性。