來一張看上去是淘寶的架構的圖：
參考地址：http://hellojava.info/?p=520
說幾點我認可的地方：
架構需要掌握的點：
通信連接方式：
大量的連接通常會有兩種方式： 1. 大量client連一個server 在現如今NonBlocking-IO這么成熟的情況下，一個支持大量client的server已經不那么難寫了。 有一個點要特別注意，就是當server掛掉的時候，不能出現所有client都在一個時間點發起重連，那樣基本就是災難。 通常可以采用的方法是client重連前都做隨機時間的sleep，另外就是重連的間隔采取避讓算法。 2. 一個client連大量的server
高並發這個點需要掌握CAS、常見的lock-free算法、讀寫鎖、線程相關知識（例如線程交互、線程池）等，
通信層面的高並發在NonBlocking-IO的情況下，最重要的是要注意在整體設計和代碼實現上盡量減少對io線程池的時間占用。
伸縮性： 伸縮性的問題圍繞着以下兩種場景在解決： 1. 無狀態場景 無狀態場景通常會把很多狀態放在db，當量到一定階段后會需要引入服務化，去緩解對db連接數太多的情況。 2. 有狀態場景 所謂狀態其實就是數據，通常采用Sharding來實現伸縮性，Sharding有多種的實現方式，常見的有這么一些： 2.1 規則Sharding 2.2 一致性Hash
參考我的另一篇文章：http://www.cnblogs.com/charlesblc/p/6033345.html 2.3 Auto Sharding Auto Sharding的好處是基本上不用管數據搬遷，而且隨着量上漲加機器就OK，但通常Auto Sharding的情況下對如何使用會有比較高的要求，
而這個通常也就會造成一些限制，這種方案例如HBase。 2.4 Copy Copy這種常見於讀遠多於寫的情況，實現起來又會有最終一致的方案和全局一致的方案，最終一致的多數可通過消息機制等，
全局一致的例如zookeeper/etcd之類的，既要全局一致又要做到很高的寫支撐能力就很難實現了。 穩定性： 1. 無狀態場景 2. 有狀態場景 全局一致類型的場景中，如果一台掛了，就通常意味着得有選舉機制來決定其他機器哪台成為主，常見的例如基於paxos的實現。 可維護性 整個系統環境應該怎么搭建，部署，配套的維護工具、監控點、報警點、問題定位、問題處理策略等等。
再來一張貌似是京東架構的圖：
參考頁面地址：http://geek.csdn.net/news/detail/98500
說一下認為其中有道理的地方：
要關注的技術領域，高可用、高並發、分布式，以及一些基礎技術、新語言、存儲、容器、系統等。
架構於不同系統，不同公司文化，不同公司層次（初建期，發展期，成熟期），都有着不同的定義和理解。
公司初建期：用戶服務基礎。
公司發展期：用戶服務基礎，滿足高速擴充的業務需求，提純基礎結構。
公司成熟期：用戶服務基礎，滿足業務需求，提純基礎結構，技術驅動衍生新生態系統。
架構又可分：基礎架構、系統架構、業務架構、代碼架構。優秀的架構特點，簡單，易懂，多變，相對靈活（根據系統迭代期、研發理解能力、團隊大小取決）。
具備哪些素質才能成為是出色的架構師？
一個出色的架構師，至少有一門用很深的編程語言作為常委語言，一個出色架構師需要突出代碼讀寫能力作為基礎。
讀代碼能力尤為重要，要能結合代碼讀出業務邏輯，以及里面優秀架構思路，不足之處，讀代碼同時學習。
學習能力，思維方式：學習技術、框架，不光會用、知其原理、並能舉一反三的思維。結合已學到的知識組合創新思維，將繁雜的事，簡單化處理。
忍耐能力：作為一個團隊技術頭頭，一般都會有一些孤獨感。可能這就是大家常說的技術范。
再就是對於系統改造循序漸近的，得忍受那種全部都重做的沖動,一點一點的進行處理。
重生能力：作為架構師，熟悉自己所在團隊和系統是必然的。抽時間讓自己跳出原有既定思維和慣性，重新認識自己團隊和系統。
溝通能力：需要跟與人打交道，當然需要良好溝通能力了。
別於社交網絡、搜索和游戲等網站，電商網站的用戶流量有哪些特點？
電商網站流量特點，突發性流量暴增，根本無法精確的預估的量。可能剛開始幾萬的量，突然幾分鍾就上到幾十、幾百、上千萬、十倍百倍千倍的往上增。
相比社交、搜索、游戲網站，差異最大點，就在直接牽涉精確的金額的問題。所以對於精准和延時，緩存有一些差異化的。
社交網絡：一般延時可做大點，及時性通訊可以端對端。
搜索：一般多級緩存，大多計算好往前推，延時也可做大點，另外搜索本就模糊的匹配，精准性方面要求沒那么嚴格。
游戲網站：大多客戶端大型游戲，客戶端數據緩存幾秒之后再進行傳輸，或者一些直接本地存數據，后端根服務器交互。
根據上面的比對，還是有比較真實感知到是有差異的。差異點主要集中在於 money 交易這一點上。
高流量、高並發情況下，如何保證整個系統的可靠性和穩定性
高流量、高並發是交易所有系統都面臨這樣一個問題，記憶深刻的用戶刷爆品商品的問題，還有利用軟件來刷的。
入口層：過濾掉大部分軟件刷的情況，衍生了風控系統，秒殺系統。
應用層: 讀寫分離、緩存、隊列、令牌、系統拆分、隔離、系統升級（可水平擴容方向）。
其他：
時間換空間：降低單次請求時間，這樣在單位時間內系統並發就會提升。
空間換時間：拉長整體處理業務時間，換取后台系統容量空間。
可靠性和穩定性：會做一堆的容災方案，從機房、網絡、應用、存儲、渠道、業務等多維度容災。做一堆的降級策略，從流量、應用、渠道、業務 等對多維度做。
每年大型促銷、流量、訂單量不斷翻倍。推動你去做異構、拆分系統、異步、服務化、容災、降級等等，一堆堆的優化。
關於一些技術框架，實際上最終實現都大同小異，會去了解實現原理，以及做的好的地方，比如Elasticsearch底層用的Lucene。
而Lucene之前用過還專門看過源碼，基本都是通的。加入了分布式存儲的副本概念，以及sharding子機器並行執行理念，收集結果返回。
再來一張不明所以的圖：
再來一張牛逼的圖：
