大型网站技术架构这本书，囤积已久，最近终于有时间，从头到尾浏览了一遍。看这本书的原因，颇有一些功利性，说白了，就是冲着书名去的。大型网站架构一直心向往之，读完之后，收获也是颇多，值得向大家推荐。

曾经看到一本冯唐的零散文集，其中有篇文章印象颇深。他在文章的开头，提出了一个问题：如何写好一首诗。大唐盛世300年，诗人不计其数，但最终留下唐诗300首。这么个简单地问题，可以说上的上是让古往今来的诗人们前赴后继了。答案也很简单，先学，学到什么程度呢？从模仿开始，读遍前人之作，看遍前人所感，触类旁通，一步一个脚印。就好比攀爬终南山，不沿着前人的脚印，怎么爬到山顶一览众山小呢？

本书作者也表达了类似的观点，我想这点在技术上也是想通的。不多看看NB的技术是什么样子的？怎么会有能力做出与之媲美甚至是超越之的完美技术解决方案呢？

本书在思想上，除了这点启发之外，对架构的重视也值得一提。技术上得架构，类比于建筑业可以说是图纸设计，类比于广告业可以说是方案策划。但是不同之处在于，技术架构影响深远，而且由于应对的挑战随行业发展快速变化，因此必须足够灵活多变。这对架构提出了很高的要求，也正是本书吸引我的一点。

但是尽管书名看起来像是程序员专享，但作者仍然点出了，给用户提供有价值的产品和优秀的体验才是关键，这点每个互联网从业者应该都会赞同，至少都在内心有所追求。

技术上而言，这本书给我提供了一套体系。两年前开始接触web开发，零零散散做了不少的事情，也逐步建立了一些自己的体系，但与本书参照了之后，收获仍是颇丰。无本之木不牢，因此技术体系很重要。从MVC的模型，到Restful API，再到web优化的准则。这些体系化的说明，使得我的技术层次更加清晰，也更加脱离闷头乱撞的状态了。不过说到优化，根据自己的经验来看，对于一个编程基础不算太差，人也不笨的程序员来说，优化往往不是什么大问题。主要的问题在于找到优化点。计算机是一门科学，因此任何优化都应该是有理有据的，通过高效的工具和经验找到瓶颈再优化，比奢求瞎猫撞上死耗子，还是要靠谱一些的。而随着技术了解的深入，我们总是希望自己承担一些模块的设计，这也被很多公司认为是区分初级工程师和熟练工程师的分水岭。这件事要我说，跟打德州扑克很相似：你必须对自己的底牌足够了解，才能打得出一手好牌。要设计后端存储，你就必须知道mysql的特性、优化点、系统可能的瓶颈、存储量、redis的应用场景、维护手段。如果这些你都不了解，那做什么设计呢？可以想象的场景就是，面向用户的产品成了你的练兵场，存储不知不觉挂了，你才知道mysql到底该怎么用。除此之外，程序员应该是很懒的一批人，个人认为，技术成长，应该越“懒”越好。为啥上线要手动上传文件到服务器？这个时代还应该存在人肉测试么？新人来了还是要花一天安装和熟悉环境？机器磁盘都要爆了，还要凌晨四点手动清理？每个人的时间有限，作为程序员，真的要让自动化再多一点。与此同时，很多人把产品的发布作为一个里程碑，但却对产品的安全问题视而不见。安全的代码依赖于对漏洞的清晰认知、良好的编程习惯、流程保证与漏洞监测机制。当不安全的代码上线的时候，你就是为自己埋了一个很大很大的坑。。

除却这些技术上的启发和细节，本书在安利个人技术的成长上面，不吝笔墨。第一点应该是在最开始说的：阅尽好的东西，你才能写出接近甚至超越的代码。苹果的联合创始人沃兹在自传中讲述了自己成为电脑专家的过程：对电脑的狂热让他把市面上所有的机型都拆了又装，装了又拆，从熟悉到自己重新设计，他从copy，上升到了design。而第二点，则是不要沉迷于代码，甚至不要沉迷于架构。很多人国人沉迷于某项技术，因此会在不恰当的时候做出背离实际情况的坚持。熟悉web前端优化的同学都知道，CDN是个好东西，那些前端文件、静态资源，大可以通过CDN的方式来解决。但这并不意味着CDN是标准程序。结合成本、实际问题，应该量体裁衣。有时候基本的静态资源服务器，就可以实现网站的需求，并不一定要“奢侈”的接入CDN。就连维基百科，都是多种方式相互结合，而并非完全依靠CDN这个“圣杯”。最后一点，则是说架构师，这个职业方向，承担的责任很多，做的事情也需要更多的思考。有人说架构师最需要代码能力，有人说架构师最需要设计能力，有人说最需要带领团队。但是我最认同一位技术公司首席架构师的说法：架构师说到底，需要具有非常强的problem-solving的能力。这突破了技术的限制，让你能够调动自己所有的脑细胞和能力，来解决你团队遇到的技术、产品、等等问题。

作为一名程序员，遇到这本书十分的开心，接触到很多很赞的技术细节，也见识了作者架构的功力。这也让我更加期待接下来要看的《企业应用架构模式》了。不过在那之前，真诚推荐这本《大型网站技术架构》。