引用
业内观点
林士鼎（百度大数据首席架构师）：架构一词虚而又虚，存在于代码的背后，似有似无。架构师这个角色，感觉上很酷很重要，在工程实践中却经常缺位，其作用在业界也褒贬不一。
老赵：“如果要实现一个“高性能”、“大并发”的网站，前端使用4层7层负载均衡，如果不用F5等商业产品可以先用Nginx等做反向代理。后台实现要对系统作划分，避免单点失败，也可以作独立优化。系统之间可以用异步消息传递来降低耦合；系统中不采用二段式提交或分布式事务，CAP原则中的“一致性”往往需要做出让步，而采用“最终一致”策略。数据存储方面可以做横向或纵向的划分，或者构建查询表。合理使用Schemaless的设计方式或如何MemcacheDB或Tokyo Cabinet等Key-Value存储方式可以带来更好的伸缩性。除此之外，系统中还需要部署Memcached集群作为缓存。静态文件可以使用Squid或Varnish作为缓存，避免所有IO都直接落到文件存储上……”其实老赵只是把大脑皮层最表面的某些“知识”给倾倒出来一些，我不知道这些内容给您感觉是什么，是不是会觉得很有“高度”。但是老赵觉得，这些东西看起来可能会“过瘾”，但是却毫无营养。其实所谓我们很多草根人士平时在谈论“系统架构”的时候，往往就是把各种产品，原理，实践进行组合拼接，其实说起来和看着市场上产品报价然后攒出一台电脑没有本质的区别。
但是架构设计确实是一个综合性的工作，你做好了还算光鲜，做的稍微不好，就会对其他的所有环节产生掣肘。你可能需要付出优秀架构几倍的金钱和几倍的工作来做后边的事情——但是大部分时候也就是几倍的金钱和工作而已，偶尔推翻重做，正如上边所说，架构设计不算什么最有意义的事情——这也是领导喜欢对架构指手画脚但却不自知的原因。
为什么会这样？我想有两个方面的原因：
第一，架构本身是一个均衡的过程，永远没有一个各方面都达到最优的方案，正如数据库的CAP原理，你要做到分布式和一致性，就别想百分百的可用性。你要可用性和分布式，就别想百分百的一致性。优秀的架构也会有问题，也会有不方面的地方，也会在某个环节付出巨大的代价。想挑刺非常容易。反过来，蹩脚的架构也有他的好处，可能避免了某个缺陷——比如让某个合作厂商更容易被换掉——，剩下的砸钱搞定就是了，我不关心这些细节。
第二，架构本身分了多个层面，比如功能架构、硬件架构、代码架构、数据架构等等。有些层面的架构是特别容易被指手画脚的（如功能架构），因为没啥门槛。反过来代码架构唧唧歪歪的人就少多了。
我们该怎么办？似乎没有什么太好的办法。只有努力推进架构的演化，尽可能的挽回。