大部分人對于BAT的技術有一種莫名的崇拜感，覺得只有非常牛逼和天才才能做出現在的這些系統，但經過前面兩篇博文的分析，我們可以看到其實并沒有什么神秘的力量和魔力融合在技術里面，而是業務的不斷發展推動技術的不斷發展，一步一個腳印，持續幾年甚至十幾年的發展，才能達到當前技術復雜度、先進性、牛逼度。

　　拋開BAT各自差異很大的業務，站在技術的角度來看，其實BAT的技術架構基本是一樣的，再將視角放大，你會發現整個互聯網行業的技術發展，最后都是殊途同歸。

　　如果你正處于一個創業公司，或者正在成為另一個BAT的路上而拼搏，那么深入理解這種技術模式（或者叫技術結構、技術架構），對于自己的發展、公司的發展都大有裨益，你將不會再迷茫，你也不再會心里打鼓，CTO將對你刮目相看，CEO將奉你為神明：）

　　接下來小編將逐一介紹每個技術點，包括為什么會有這些技術點，這些技術點的主要場景是什么，這些技術點將如何發展。

　　SQL

　　即關系數據。前幾年NoSQL火了一陣子，很多人都理解為NoSQL是完全拋棄關系數據，全部采用非關系型數據，但事實經過幾年的試驗后，大家發現關系數據不可能完全拋棄，NoSQL不是NoSQL，而是NotOnlySQL，即NoSQL是SQL的補充。

　　所以互聯網行業也必須依賴關系數據，考慮到Oracle太貴，還需要專人維護，一般情況下互聯網行業都是用MySQL、PostgreSQL這類開源數據庫。這類數據庫的特點是開源免費，拿來就用；但缺點是性能相比商業數據庫要差較多。隨著互聯網業務的發展，性能要求越來越高，必然要面對一個問題：將數據拆分到多個數據庫實例才能滿足業務的性能需求（其實Oracle也一樣，只是時間早晚的問題）。

　　數據庫拆分滿足了性能的要求，但帶來了復雜度的問題：數據如何拆分、數據如何組合。這個復雜度的問題解決起來并不是那么容易，如果每個業務都去實現一遍，重復造輪子將導致投入浪費、效率降低，業務開發想快都快不起來。

　　所以互聯網公司流行的做法是發展到一定階段后，就會將這部分功能獨立成中間件，例如百度的DBProxy、淘寶的TDDL。不過這部分的要求很高，將分庫分表做到自動化和平臺化，不是一件容易的事情，所以一般是很牛逼的公司才會做。典型的有：百度的DBProxy、淘寶TDDL。

　　NoSQL

　　NoSQL首先體現在數據結構上與傳統的SQL的不同，例如典型的Memcached的Key-value結構、Redis的復雜數據結構、MongoDB的文檔數據結構；其次NoSQL無一例外的都會將性能作為自己的一大買點。

　　NoSQL的這兩個特點很好的彌補了關系數據庫的不足，因此在互聯網行業NoSQL的應用基本上是基礎要求，要是你聽到一個號稱自己是互聯網公司卻連NoSQL都沒用，那基本上可以判斷是掛羊頭賣狗肉類型的。

　　由于NoSQL方案一般都會自己本身就提供集群的功能，例如Memcached的一致性hash集群、Redis3.0的集群，因此NoSQL在剛開始應用的時候很方便，不像SQL分庫分表那么復雜。一般公司也不會在開始的時候就考慮將NoSQL包裝成存儲平臺，但如果公司發展很大，例如Memcached的節點有上千甚至幾千的時候，NoSQL集群就很有意義了：首先是集中管理能夠大大提升運維效率；其次是集中管理可以大大提升資源利用效率，2000臺機器，如果利用率能提升10%，就是減少200臺機器，一年幾十萬就節省出來了。

　　所以，NoSQL發展到一定規模后，一般都是走集群路線，當然要發展到這個階段，一般也是很牛逼的公司才會這么做。

　　典型的有：Twitter的Twemproxy，豆瓣的BeansDB、騰訊TTC。

　　小文件存儲

　　除了關系型的業務數據外，互聯網行業還有很多用于展示的數據，例如淘寶的商品圖片、商品描述；Facebook的用戶圖片，新浪微博的一條微博內容等等。這些數據具有3個典型特征：一是數據小，一般在1M一下；二是數量巨大，Facebook2013年就達到了每天上傳3.5億張的照片；三是訪問量巨大，Facebook每天的訪問量超過10億。

　　由于互聯網行業基本上每個業務都會有大量的小數據，如果每個業務都自己去考慮如何設計海量存儲和海量訪問，效率自然會低，重復造輪子，投入浪費，自然而然的想法就是將小文件存儲做成統一的和業務無關的平臺。

　　和SQL和NoSQL不同的是，小文件存儲不一定需要公司或者業務規模很大，基本上可以認為業務在起步階段就可以考慮做小文件統一存儲。得益于開源運動的發展和最近幾年大數據的火爆，在開源方案的基礎上封裝一個小文件存儲平臺并不是太難的事情。例如HBase、Hadoop、Hypertable、FastDFS等都可以作為小文件存儲的底層平臺，只需要在這些開源方案三再包裝一下基本上就可以用了。

　　典型的有：淘寶的TFS、京東JFS、Facebook的Haystack。

　　開發框架

　　在系列文章的第2篇《BAT解密：業務如何驅動技術發展》中我們深入分析了互聯網業務發展的一個特點：復雜性越來越高。復雜性增加的典型現象就是系統越來越多，不同的系統由不同的小組開發。如果每個小組用不同的開發框架和技術，將會帶來很多問題，典型的問題有：

　　技術人員之間沒有共同的技術語言，交流合作少

　　每類技術都需要投入大量的人力和資源和熟練精通

　　不同團隊之間人員無法快速流動，人力資源不能高效的利用

　　所以，互聯網公司都會指定一個大的技術方向，然后使用統一的開發框架，例如Java相關的開發框架SSH、SpringMVC、Play、Ruby的RubyonRails、PHP的ThinkPHP、Python的Django等等。使用統一的開發框架能夠解決上面提到的各種問題，大大提升組織和團隊的開發效率。

　　對于框架的選擇，有一個總的原則：優選成熟的框架，避免盲目追逐新技術！為什么呢？

　　首先，成熟的框架資料文檔齊備，各種坑基本上都有人踩過了，遇到問題很容易通過搜索解決

　　其次，成熟的框架受眾更廣，招聘時更加容易招聘到合適的人才

　　第三，成熟的框架更加穩定，不會出現大的變動，適合長期發展

　　以我親身經歷的一個反例為例：我們使用了Play1作為Java開發框架，因為它是輕量級的Java開發框架，但沒想到Play2直接改為Scala語言開發，Play1的架構演進停滯，而我們又不能切換為Play2，結果就導致只能一直用Play1，有新的需求只能自己開發。

　　服務器

　　開發框架只是負責完成業務功能的開發，真正能夠運行起來，給用戶提供服務，還需要服務器配合。

　　獨立開發一個成熟的web服務器，成本非常高；且業界又有那么多成熟的開源web服務器，所以互聯網行業基本上都是拿來主義，挑選一個流行的開源服務器即可。牛逼一點的公司，可能會在開源服務器的基礎上，結合自己的業務特點做二次開發，例如淘寶的Tengine，但一般公司基本上只需要將開源服務器摸透，優化一下參數，調整一下配置就差不多了。

　　選擇一個服務器主要和開發語言相關，例如：Java的有Tomcat、Jboss、Resin等，PHP/Python的用Nginx，當然最保險的就是用Apache了，什么語言都支持。

　　有的人可能擔心Apache的性能之類的問題，其實不用過早擔心這個，等到你的業務真的發展到Apache撐不住的時候再考慮切換也可以，那時候你有的是錢，有的是人，有的是時間。

　　容器

　　容器是最近幾年年才開始火起來的，其中以Docker為代表，在BAT級別的公司已經有較多的應用，例如騰訊：騰訊萬臺規模的Docker應用實踐；新浪微博：微博紅包：大規模Docker集群實踐經驗分享等等。

　　傳統的虛擬化技術是虛擬機，解決了跨平臺的問題，但由于虛擬機太龐大，啟動慢，運行時太占資源，在互聯網行業并沒有大規模的應用；而Docker的容器技術，雖然沒有跨平臺，但啟動快，幾乎不占資源，推出后立刻就火起來了，預計Docker類的容器技術將是技術發展的主流方向。

　　千萬不要以為Docker只是一個虛擬化或者容器技術，它將在很大程度上改變我們目前的技術形勢：

　　運維方式會發生革命性的變化：Docker啟動快，幾乎不占資源，隨時啟動和停止，基于Docker打造自動化運維、智能化運維將成為主流方式

　　設計模式會發生本質化的變化：啟動一個新的容器實例代價如此低，將鼓勵設計思路朝“微服務”的方向發展。

　　例如一個傳統的網站包括登錄注冊、頁面訪問、搜索等功能，沒有用容器的情況下，除非有特別大的訪問量，否則這些功能開始時都是集成在一個系統里面的；有了容器技術后，一開始設計就可以將這些功能按照服務的方式設計，避免后續訪問量增大時又要重構系統。

　　如何學習呢？有沒有Java架構師學習視頻教程？咨詢動力節點官網在線老師：回復“Java架構師資源”