无线城市架构设计思考系列——零、写在前面

 

有想法写这个系列，一方面是想给自己留下些沉淀，为团队留下些东西，另一方面不如说是希望让大家看到架构设计的复杂性——这个行当不是谁都能发表意见的。每当有外行领导，或者半懂不懂的领导对架构指手画脚时，都忍不住想写点什么。

 

其实架构涉及在整个系统的实现过程中，不是什么高级的活动。在架构、编码、运维、项目管理等等各个环节，架构说不上是最有意义的内容，在技术上也不是最困难的。顶着“架构设计”的title，未必比“高级程序员”做的事情更有价值。

 

业内观点

 

l   林士鼎（百度大数据首席架构师）：架构一词虚而又虚，存在于代码的背后，似有似无。架构师这个角色，感觉上很酷很重要，在工程实践中却经常缺位，其作用在业界也褒贬不一。

l   老赵（金融行业程序员，目前就职于摩根大通（香港），多年微软MVP）：“如果要实现一个“高性能”、“大并发”的网站，前端使用4层7层负载均衡，如果不用F5等商业产品可以先用Nginx等做反向代理。后台实现要对系统作划分，避免单点失败，也可以作独立优化。系统之间可以用异步消息传递来降低耦合；系统中不采用二段式提交或分布式事务，CAP原则中的“一致性”往往需要做出让步，而采用“最终一致”策略。数据存储方面可以做横向或纵向的划分，或者构建查询表。合理使用Schemaless的设计方式或如何MemcacheDB或Tokyo Cabinet等Key-Value存储方式可以带来更好的伸缩性。除此之外，系统中还需要部署Memcached集群作为缓存。静态文件可以使用Squid或Varnish作为缓存，避免所有IO都直接落到文件存储上……”其实老赵只是把大脑皮层最表面的某些“知识”给倾倒出来一些，我不知道这些内容给您感觉是什么，是不是会觉得很有“高度”。但是老赵觉得，这些东西看起来可能会“过瘾”，但是却毫无营养。其实所谓我们很多草根人士平时在谈论“系统架构”的时候，往往就是把各种产品，原理，实践进行组合拼接，其实说起来和看着市场上产品报价然后攒出一台电脑没有本质的区别。

但是架构设计确实是一个综合性的工作，你做好了还算光鲜，做的稍微不好，就会对其他的所有环节产生掣肘。你可能需要付出优秀架构几倍的金钱和几倍的工作来做后边的事情——但是大部分时候也就是几倍的金钱和工作而已，偶尔推翻重做，正如上边所说，架构设计不算什么最有意义的事情——这也是领导喜欢对架构指手画脚但却不自知的原因，在我的英明指导下，我们的项目取得了成功。其实没有你的领导我们会更成功，但我没办法证明给你看。为什么会这样？我想有两个方面的原因：

第一架构本身是一个均衡的过程，永远没有一个各方面都达到最优的方案，正如数据库的CAP原理，你要做到分布式和一致性，就别想百分百的可用性。你要可用性和分布式，就别想百分百的一致性。优秀的架构也会有问题，也会有不方面的地方，也会在某个环节付出巨大的代价。想挑刺非常容易。反过来，蹩脚的架构也有他的好处，可能避免了某个缺陷——比如让某个合作厂商更容易被换掉——，剩下的砸钱搞定就是了，我不关心这些细节。

第二架构本身分了多个层面，比如功能架构、硬件架构、代码架构、数据架构等等。功能架构容易被指手画脚，因为没啥门槛。反过来代码架构唧唧歪歪的人就少多了。这几个层面的架构设计都是应该综合考虑的，少了任一个层面都会有问题。同样，对任一个层面指手画脚也都会影响到其他层面。所谓一颗老鼠屎坏了一锅粥就是这个意思。

 

下边分层来说下无线城市的架构。我将更注重描述现在的问题、演化的思考过程和业界的主流观点，而不是结果。完全自己探索架构实现是不现实的，我们应该通过自己独立的思考，根据业内最佳实践设计最合适的架构。（寻找最佳实践其实是一个长期的过程，必须通过广泛的阅读、长时间的社区讨论和自身的实践，缺一不可。）