最近學習了李運華老師在極客時間的《從0開始學架構》文章，為了了解深刻便于複習思考整理了思維導圖筆記，大家可以參考學習。
對于前面幾篇文章中的思維導圖原圖，有需要的同學可以關注後發私信，我會把原圖發給你們。後續其他章節的思維導圖也會陸續更新。歡迎大家關注、收藏！
前言
現在一些網際網路公司的技術都很厲害，比如淘寶、京東。但經過前面對架構的本質、架構的設計原則、架構的設計模式、架構演進等多方位的探讨和闡述，可以發現其實都是業務的不斷發展推動了技術的發展。整個網際網路行業的技術發展，最後都是殊途同歸，都是使用差不多的标準技術架構和分層技術點。
網際網路架構架構
網際網路的标準技術架構如下圖所示，這張圖基本上涵蓋了網際網路技術公司的大部分技術點，不同的公司隻是在具體的技術實作上稍有差異，但不會跳出這個架構的範疇。
“存儲層”技術
從上面可以看到，當公司規模發展到一定階段後，基本上都是基于某個開源方案搭建統一的存儲平台。
“開發層”技術
“服務層”技術
網際網路業務的不斷發展帶來了複雜度的不斷提升，業務系統也越來越多，系統間互相依賴程度加深。
服務層的主要目标其實就是為了降低系統間互相關聯的複雜度。
“服務名字系統”和“服務總線系統”簡單對比如下表所示，
消息隊列系統基本功能的實作比較簡單，但要做到高性能、高可用、消息時序性、消息事務性則比較難。
“網絡層”技術
通常情況下，我們在設計高可用和高性能系統的時候，主要關注點在系統本身的複雜度。但是當我們站在一個公司的的角度來思考架構的時候，網際網路業務的高性能和高可用需要站在網絡層的角度整體設計架構。
使用者層技術
“業務層”技術
“平台”技術
思考
Q：既然存儲技術發展到最後都是存儲平台，為何沒有出現存儲平台的開源方案，但雲計算卻都提供了存儲平台方案？
A：
1.存儲平台的開發成本高，由于存儲平台是核心的平台，高可用，高性能是必須的，這就導緻需要經驗豐富的進階工程師來開發。而雲平台作為服務提供商，有能力開發出來存儲平台。
2.需要使用存儲平台的公司不多，而且一般是大型的公司，小公司的業務規模都不大，對于存儲平台的需求基本不高，雲平台面向的是所有使用者，衆口難調，是以提供基礎服務。
3.上雲方案對于很多小型公司來說，是一種最簡單的方式了，成本低，性能可用性都能達到很高的水準。而開源的平台存儲受限于幾個條件 ：
①涉及到的存儲太多，開發測試都需要很大的人力
②小公司沒條件采用，大公司有自己的，使用的人不多，不能快速疊代發展
③沒有大型公司的參與，無法推廣使用。
。。。。。
Q：使用統一的開發架構和開發語言可以讓團隊開發效率更高，但這樣做會帶來什麼問題？
A:
1.程式沒有用适合的語言開發，程式效率低下，比如現在需要開發記憶體的緩存系統，但團隊開發語言是java，java是一門進階語言，适合做業務系統，用java做記憶體操作記憶體會效率低下，而且浪費嚴重。
2.開發架構和開發語言，都是有場景限制的，尺有所短，寸有所長。
3.可能發生“手裡有錘子後，看到什麼都是釘子”的情況，在業務規模小的時候采用單一語言單一架構，當規模大了還是應該有一定的靈活性，有一個主力的語言和架構，合适的工作用合适語言和架構，而微服務架構的比較适合混合語言和架構的模式。
4.違背了合适原則，本來用C++語言最合适，偏偏使用了Java
5.容易出現思維盲區，有可能有更好的替代品
。。。。。
Q：為什麼可以購買負載均衡和 CDN 服務，但卻不能購買多機房和多中心服務？
A：CDN和LB是基于通用技術和協定，實作請求的排程與轉發等功能。是以負載均衡和cdn基本是和業務無關，具有通用性；而每個業務對資料的一緻性和事務要求都不一樣，需要單獨設計，是以無法将多機房和多中心作為基礎服務對外提供。
Q：虛拟業務域劃分的粒度需要粗一些還是要細一些？你建議虛拟業務域的數量大概是多少？
A：粗一些比較好，本來虛服務域就是來解決系統拆分過細的問題。
虛拟業務域的數量以5±2原則比較合适。
Q：運維平台或者測試平台，有的公司是由中間件團隊負責開發，有的是運維和測試團隊自己開發，你覺得兩種方式各有什麼優缺點，分别适用什麼場景呢？
A：關注點不同，所能設計的産品也會有重點跟非重點的差別，
中間件可能更關注的是功能的實作，重點在于技術。平台架構有保障，代碼品質高，開發效率高，但是前期業務溝通成本大；
運維團隊可能關注的是平台的運作穩定以及硬體方面的性能；
測試團隊在于平台本身功能點的覆寫情況；
是以由專門的團隊來處理，讓後其他的隊伍提需求。
。。。。。。