轉：全棧工程師的知識棧列表

from: http://blog.csdn.net/caopeng26/article/details/52235883

 

版權聲明：本文爲博主原創文章，未經博主容許不得轉載。

 

目錄(?)[+]

 

通往互聯網架構師之路—全棧工程師

一、首先咱們看什麼是架構師？架構師應該具有哪些能力？

你們都知道不少公司都有架構師這個職位，可是我想告訴你們的是看一我的是否是架構師不是看職位，而是看他所具有的能力以及正在作的事，因此有架構師頭銜的人不必定具有架構師的能力，而不是架構師的人卻在作着架構師的工做。

二、架構師相似於建築行業的總設計師，一般在一個軟件項目中，架構師須要完成軟件項目中全部技術環節的設計，架構師雖說不用親自編寫全部代碼，可是架構師會對項目中全部運用的技術環節瞭如指掌。

三、所以架構師既能夠是一個很簡單的工做，也能夠是一個具有超高難度的工做。而具體的難度係數，取決於具體的項目類型。就好像蓋一個兩層小樓，和一個跨海大橋，對架構師的要求大相徑庭。

四、在今天的課程中，陳老師給你們畫了一些不一樣類型項目的架構圖。若是想要成爲架構師，你們能夠看一下要成爲架構師針對不一樣項目類型須要掌握的技術。

五、你們能夠看到框裏面並列列出了不少技術，只要位於同一層的技術掌握一個就能夠完成完整的軟件流程設計，不要求掌握所有。

咱們來看第一張圖

六、好比說咱們如今目標任務是開發一個自主品牌的mp3播放器，咱們的架構師須要懂硬件，好比單片機,傳感器，聲音設備，再利用匯編或者C語言，來對該電子系統編寫相應的程序，就能夠完成這樣的一套mp3程序開發。

七、但軟件的架構師在不斷進化着，在計算機發明的初期，幾乎大部分應用程序都是直接針對硬件來編寫的，可是這樣會致使程序的通用性差，因此纔出現了操做系統。在目前市場上流通的大部分軟件都是工做在操做系統之上的。

所以咱們能夠看見第二張圖的這樣的架構。

八、編寫這樣的應用程序須要咱們架構師瞭解硬件，瞭解操做系統，而且可以使用C，C++，VB，等編程語言調用操做系統SDK完成軟件功能開發。 
由操做系統去跟硬件系統打交道，這樣對於開發人員的要求就下降了不少，同時應用程序的通用性會變得更好。

再看看第三張圖

九、隨着計算機軟件的發展，咱們發現不少軟件都是在和數據打交道，用戶數據須要記錄到系統中，同時應該能快速的檢索數據，所以在咱們的單機應用中出現了數據庫這麼一類應用程序。

十、在須要存儲數據，搜書數據，以及對數據加工處理統計的時候能夠把這些工做交給數據庫去處理。

十一、作這類應用軟件的開發工程師，對硬件和操做系統瞭解便可。須要他精通數據庫，而且能用任意語言調用系統提供的SDK。

在看看第四張圖

十二、這個是C/S應用程序架構，這裏的客戶端架構與第三張圖單機應用相似，惟一不一樣的是在數據的來源的上做出了改變。本來的單機應用程序數據存在本地，可是一個軟件系統若是有多人使用多個客戶端鏈接的時候，不可能把數據庫再放到莫一臺客戶機中。

1三、解決方案就是讓數據庫經過網絡對客戶端提供數據服務。直接經過客戶端遠程鏈接直接操做數據庫這種方式也是不能夠的，由於數據庫若是直接對外提供數據服務，那麼凡是能鏈接到該網絡的用戶均可以繞過客戶端操做數據庫，這樣數據安全就得不到保障。

1四、所以出現了Server，咱們經過服務器端程序來操做數據庫，客戶端程序只能選擇與服務器端交互，全部的業務操做由服務器端完成，這種模式就是C/S架構。

1五、完成C/S架構的架構師就比作單機應用的架構師難度大不少，不只要懂得單機應用開發所須要的知識，還須要掌握網路數據庫系統，以及web服務，socket服務等技術。

1六、C/S應用程序架構存在一些缺點：須要更新全部已安裝的客戶端版本，並且會出現多個版本並存的狀況，後期維護代價極高，並且很不方便。

由於這些緣由，就出現了B/S這些架構的軟件。

第五張圖

如圖所示，咱們能夠看到此架構的服務端與第四張的服務器端基本一致。

1七、主要區別是B/S架構的應用程序不須要安裝客戶端程序，而是使用大部分的計算機都有安裝的瀏覽器來做爲系統前端來與用戶交互，而瀏覽器加載的內容所有來由服務端輸出。

1八、這樣B/S的架構師難度相對來講比C/S架構師低不少，而且有諸多的成熟的解決方案，好比：java的javaee架構，微軟的asp.net架構，徹底開源的lamp架構，都是很成熟的解決方案。

1九、這樣架構的優勢在於由於存在大量的成熟的解決方案，只須要一臺可連入網絡的服務器，就可讓整個系統運轉起來。開發速度快，運營成本低。這種解決方案被普遍接納。因此作這樣架構的程序員數量不少，也所以每每不被當作架構師來看待。可是作這樣架構的應用程序設計也架構設計中的一種。

咱們來看第6張圖

20、從2010年之後，智能手機在國內大量普及，幾年時間誕生了數百萬的App與手機遊戲，每每一個項目既擁有本身的網站，又擁有獨立的APP，並且做爲一個總體的系統，iOS，安卓，與網頁的數據應該是一致的。

2一、那麼要作到這樣的架構設計的話，咱們須要讓咱們的ios，安卓客戶端共用咱們的服務端，這樣咱們的多端才能保持數據高度一致。

2二、服務器端的結構沒有太大的變化，可是軟件設計的方式產生了變化，本來B/S架構中由服務端向瀏覽器輸出相應的html，css，js等靜態內容便可，但若是涉及到移動互聯網應用開發，咱們會將咱們的應用程序規範化，把前端和後端徹底區分開來。

2三、服務器端提供數據交互服務，並編寫相應的接口，移動端進行接口調用，並完成界面數據填充以負責用戶交互，即使是移動端瀏覽器，也應採用這種方式來交互。

接下來看第7張圖

2四、它和6張圖比較相似，但多出來幾塊。咱們把橫線以上的部分叫服務端，橫線如下的叫前端。咱們在移動互聯網絡時代，常常會涉及到本身的平臺與第三方平臺的交互，咱們的應用在接入支付寶，微信，微博等功能後，還會涉及到與第三方平臺的功能交互。

2五、一般須要咱們經過服務器發起請求調用第三方的API，而且爲第三方的平臺保留回調的接口，所以在製做這樣的應用程序開發的時候，架構師除了要掌握移動互聯網絡的技術外，還須要對第三方提供的功能與規範以及相應接口有充分的瞭解。

來看第8張圖

2六、若是隻是從功能實現來講，可以按照第7張圖完成架構設計的架構師，已經能知足需求。可是在實際運營的項目中，除了有功能需求之外，還要有質量需求，好比：網站的負載能力，網絡併發鏈接數，系統的數據吞吐量，項目是否具備擴容能力等。

2七、以前所展現給你們的全部架構，都是基於單服務器架構來設計的，若是隻有一臺服務器，無能咱們怎樣花錢來升級他的硬件配置，咱們會發現很快將沒法進一步擴容。最好的CPU，最大的內存條也是有限度的，所以採用集羣架構，纔是解決問題的正確方法。

2八、而第8張圖所畫的就是標準的分佈式集羣架構，集羣的擴容原則就是一我的幹不完的活多我的一塊兒幹，讓服務器與服務器之間，進行分工與協做。

2九、而作分佈式集羣的架構的架構師，也有着較高的要求，而互聯網上受人敬仰的架構師大多屬於這類。你也能夠認爲這纔是真正的架構師。

看第9張圖

30、服務器端同第7張，第8張能夠是一致的，具體是選擇哪一個服務器的架構，取決於項目的規模。 
項目初期用戶量少，能夠選擇單服務器架構，若是項目後期服務器負載壓力過大，能夠重構爲分佈式集羣架構。

3一、第9張圖的重點在於項目前端，咱們來看前端的技術架構圖，這裏所畫的是市面所流行的混合APP的架構。

3二、著名的混合APP應用有不少，好比說支付寶手機客戶端，還有Facebook，這些應用都是採用混合APP架構設計的。

3三、混合APP應用使用html，和css打造用戶界面，不管是在瀏覽器，微信端，仍是在APP中，都是如此。所以他具有B/S應用程序的優勢，能夠在服務器端更新應用內容，而且讓應用在ios，安卓，瀏覽器端保持高度一致性。

3四、利用單頁web APP開發技術，可以讓網頁程序像原生應用同樣流暢，而web APP的缺點在於，網頁js程序沒法調用手機硬件功能，可是混合APP架構能夠經過微信sdk，微博sdk ，iOS bridges，安卓bridge是等方式來獲取微信APP，微博APP以及手機硬件的功能。

3五、所以混合APP架構同時具有了web APP與原生應用的優點，成爲了市場上主流的移動應用架構設計方法。跨平臺兼容性好，開發成本低，開發速度快。逐步取代了大量的原生應用。這也是咱們兄弟全棧工程師學習的主要內容。

3六、爲何定這個主題呢？其實咱們會發現全盞所涉及的開發領域和架構師基本一致，區別在於能力與深度

3七、好比分佈式服務部分，若是全盞工程師，可使用相似Laravel框架這樣的全盞框架解決本地服務，webservice ，消息隊列等問題，

3八、但架構師則應該能深刻了解其中原理，並作出相應設計

3九、全棧工程師只要加深各個領域知識深度，很容易向架構師方向發展

40、由於在以往的大公司大團隊時代，學科越分越細，所以不管大學課程仍是培訓機構，此前都是按專業和學科劃分

4一、若是學linux，那麼從組網作網絡配置，搭建文件共享或者郵件發送，web服務等都須要學習和掌握

4二、學h5的話，webgl遊戲開發，網頁開發都有學習，其實對於全棧或者架構師發展來講，這樣並很差

4三、若是作全棧，那麼我不須要學習如何作網管，因此使用linux應該集中在web服務環境上，相似，學h5，應該着重在移動端觸屏設備開發爲主，因此劃分維度不一樣，

4四、若是有了這個認識，就不會被誤導，覺得全棧或者架構師就是什麼技術都學，什麼都會。我麼要的是更專業，學習更深。

4五、相信經過今天的分享，你們對如何學習，如何發展，如何成爲架構師，能有一個很好的認識。