系統網站架構（淘寶、京東）& 架構師能力

來一張看上去是淘寶的架構的圖：

參考地址：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

說一下認爲其中有道理的地方：

要關注的技術領域，高可用、高併發、分佈式，以及一些基礎技術、新語言、存儲、容器、系統等。

架構於不一樣系統，不一樣公司文化，不一樣公司層次（初建期，發展期，成熟期），都有着不一樣的定義和理解。

公司初建期：用戶服務基礎。
公司發展期：用戶服務基礎，知足高速擴充的業務需求，提純基礎結構。
公司成熟期：用戶服務基礎，知足業務需求，提純基礎結構，技術驅動衍生新生態系統。

架構又可分：基礎架構、系統架構、業務架構、代碼架構。優秀的架構特色，簡單，易懂，多變，相對靈活（根據系統迭代期、研發理解能力、團隊大小取決）。

具有哪些素質才能成爲是出色的架構師？
一個出色的架構師，至少有一門用很深的編程語言做爲常委語言，一個出色架構師須要突出代碼讀寫能力做爲基礎。
讀代碼能力尤其重要，要能結合代碼讀出業務邏輯，以及裏面優秀架構思路，不足之處，讀代碼同時學習。

學習能力，思惟方式：學習技術、框架，不光會用、知其原理、並能觸類旁通的思惟。結合已學到的知識組合創新思惟，將繁雜的事，簡單化處理。
忍耐能力：做爲一個團隊技術頭頭，通常都會有一些孤獨感。可能這就是你們常說的技術範。
再就是對於系統改造循序漸近的，得忍受那種所有都重作的衝動,一點一點的進行處理。
重生能力：做爲架構師，熟悉本身所在團隊和系統是必然的。抽時間讓本身跳出原有既定思惟和慣性，從新認識本身團隊和系統。
溝通能力：須要跟與人打交道，固然須要良好溝通能力了。

別於社交網絡、搜索和遊戲等網站，電商網站的用戶流量有哪些特色？

電商網站流量特色，突發性流量暴增，根本沒法精確的預估的量。可能剛開始幾萬的量，忽然幾分鐘就上到幾10、幾百、上千萬、十倍百倍千倍的往上增。
相比社交、搜索、遊戲網站，差別最大點，就在直接牽涉精確的金額的問題。因此對於精準和延時，緩存有一些差別化的。

社交網絡：通常延時可作大點，及時性通信能夠端對端。
搜索：通常多級緩存，大多計算好往前推，延時也可作大點，另外搜索本就模糊的匹配，精準性方面要求沒那麼嚴格。
遊戲網站：大多客戶端大型遊戲，客戶端數據緩存幾秒以後再進行傳輸，或者一些直接本地存數據，後端根服務器交互。
根據上面的比對，仍是有比較真實感知到是有差別的。差別點主要集中在於 money 交易這一點上。

 

高流量、高併發狀況下，如何保證整個系統的可靠性和穩定性

高流量、高併發是交易全部系統都面臨這樣一個問題，記憶深入的用戶刷爆品商品的問題，還有利用軟件來刷的。

入口層：過濾掉大部分軟件刷的狀況，衍生了風控系統，秒殺系統。
應用層: 讀寫分離、緩存、隊列、令牌、系統拆分、隔離、系統升級（可水平擴容方向）。
其餘： 
時間換空間：下降單次請求時間，這樣在單位時間內系統併發就會提高。
空間換時間：拉長總體處理業務時間，換取後臺系統容量空間。
可靠性和穩定性：會作一堆的容災方案，從機房、網絡、應用、存儲、渠道、業務等多維度容災。作一堆的降級策略，從流量、應用、渠道、業務 等對多維度作。

每一年大型促銷、流量、訂單量不斷翻倍。推進你去作異構、拆分系統、異步、服務化、容災、降級等等，一堆堆的優化。

 

關於一些技術框架，實際上最終實現都大同小異，會去了解實現原理，以及作的好的地方，好比Elasticsearch底層用的Lucene。

而Lucene以前用過還專門看過源碼，基本都是通的。加入了分佈式存儲的副本概念，以及sharding子機器並行執行理念，收集結果返回。

 

 

 再來一張不明因此的圖：

 

 

再來一張牛逼的圖：