架構師類似于建筑行業(yè)的總設計師，通常在一個軟件項目中，架構師需要完成軟件項目中所有技術環(huán)節(jié)的設計，架構師雖然說不用親自編寫所有代碼，但是架構師會對項目中所有運用的技術環(huán)節(jié)了如指掌。

因此架構師既可以是一個很簡單的工作，也可以是一個具備超高難度的工作。而具體的難度系數(shù)，取決于具體的項目類型。就好像蓋一個兩層小樓，和一個跨海大橋，對架構師的要求截然不同。

第一
比如說我們現(xiàn)在目標任務是開發(fā)一個自主品牌的mp3播放器，我們的架構師需要懂硬件，比如單片機,傳感器，聲音設備，再利用匯編或者C語言，來對該電子系統(tǒng)編寫相應的程序，就可以完成這樣的一套mp3程序開發(fā)。
但軟件的架構師在不斷進化著，在計算機發(fā)明的初期，幾乎大部分應用程序都是直接針對硬件來編寫的，但是這樣會導致程序的通用性差，所以才出現(xiàn)了操作系統(tǒng)。在目前市場上流通的大部分軟件都是工作在操作系統(tǒng)之上的。

第二
編寫這樣的應用程序需要我們架構師了解硬件，了解操作系統(tǒng)，并且能夠使用C，C++，VB，等編程語言調(diào)用操作系統(tǒng)SDK完成軟件功能開發(fā)。
由操作系統(tǒng)去跟硬件系統(tǒng)打交道，這樣對于開發(fā)人員的要求就降低了很多，同時應用程序的通用性會變得更好。

第三
隨著計算機軟件的發(fā)展，我們發(fā)現(xiàn)很多軟件都是在和數(shù)據(jù)打交道，用戶數(shù)據(jù)需要記錄到系統(tǒng)中，同時應該能快速的檢索數(shù)據(jù)，因此在我們的單機應用中出現(xiàn)了數(shù)據(jù)庫這么一類應用程序。
在需要存儲數(shù)據(jù)，搜書數(shù)據(jù)，以及對數(shù)據(jù)加工處理統(tǒng)計的時候可以把這些工作交給數(shù)據(jù)庫去處理。
做這類應用軟件的開發(fā)工程師，對硬件和操作系統(tǒng)了解即可。需要他精通數(shù)據(jù)庫，并且能用任意語言調(diào)用系統(tǒng)提供的SDK。

第四
這個是C/S應用程序架構，這里的客戶端架構與第三張圖單機應用類似，唯一不同的是在數(shù)據(jù)的來源的上作出了改變。原本的單機應用程序數(shù)據(jù)存在本地，但是一個軟件系統(tǒng)如果有多人使用多個客戶端連接的時候，不可能把數(shù)據(jù)庫再放到莫一臺客戶機中。
解決方案就是讓數(shù)據(jù)庫通過網(wǎng)絡對客戶端提供數(shù)據(jù)服務。直接通過客戶端遠程連接直接操作數(shù)據(jù)庫這種方式也是不可以的，因為數(shù)據(jù)庫如果直接對外提供數(shù)據(jù)服務，那么凡是能連接到該網(wǎng)絡的用戶都可以繞過客戶端操作數(shù)據(jù)庫，這樣數(shù)據(jù)安全就得不到保障。
因此出現(xiàn)了Server，我們通過服務器端程序來操作數(shù)據(jù)庫，客戶端程序只能選擇與服務器端交互，所有的業(yè)務操作由服務器端完成，這種模式就是C/S架構。
完成C/S架構的架構師就比做單機應用的架構師難度大很多，不僅要懂得單機應用開發(fā)所需要的知識，還需要掌握網(wǎng)路數(shù)據(jù)庫系統(tǒng)，以及web服務，socket服務等技術。
C/S應用程序架構存在一些缺點：需要更新所有已安裝的客戶端版本，而且會出現(xiàn)多個版本并存的情況，后期維護代價極高，而且很不方便。

第五
主要區(qū)別是B/S架構的應用程序不需要安裝客戶端程序，而是使用大部分的計算機都有安裝的瀏覽器來作為系統(tǒng)前端來與用戶交互，而瀏覽器加載的內(nèi)容全部來由服務端輸出。
這樣B/S的架構師難度相對來說比C/S架構師低很多，并且有諸多的成熟的解決方案，比如：java的javaee架構，微軟的asp.net架構，完全開源的lamp架構，都是很成熟的解決方案。
這樣架構的優(yōu)點在于因為存在大量的成熟的解決方案，只需要一臺可連入網(wǎng)絡的服務器，就可以讓整個系統(tǒng)運轉起來。開發(fā)速度快，運營成本低。這種解決方案被廣泛接納。所以做這樣架構的程序員數(shù)量很多，也因此往往不被當做架構師來看待。但是做這樣架構的應用程序設計也架構設計中的一種。

第6
服務器端的結構沒有太大的變化，但是軟件設計的方式產(chǎn)生了變化，原本B/S架構中由服務端向瀏覽器輸出相應的html，css，js等靜態(tài)內(nèi)容即可，但如果涉及到移動互聯(lián)網(wǎng)應用開發(fā)，我們會將我們的應用程序規(guī)范化，把前端和后端完全區(qū)分開來

第七
比較類似，但多出來幾塊。我們把橫線以上的部分叫服務端，橫線以下的叫前端。我們在移動互聯(lián)網(wǎng)絡時代，經(jīng)常會涉及到自己的平臺與第三方平臺的交互，我們的應用在接入支付寶，微信，微博等功能后，還會涉及到與第三方平臺的功能交互。
通常需要我們通過服務器發(fā)起請求調(diào)用第三方的API，并且為第三方的平臺保留回調(diào)的接口，因此在制作這樣的應用程序開發(fā)的時候，架構師除了要掌握移動互聯(lián)網(wǎng)絡的技術外，還需要對第三方提供的功能與規(guī)范以及相應接口有充分的了解。

第八
通常需要我們通過服務器發(fā)起請求調(diào)用第三方的API，并且為第三方的平臺保留回調(diào)的接口，因此在制作這樣的應用程序開發(fā)的時候，架構師除了要掌握移動互聯(lián)網(wǎng)絡的技術外，還需要對第三方提供的功能與規(guī)范以及相應接口有充分的了解。
之前所展示給大家的所有架構，都是基于單服務器架構來設計的，如果只有一臺服務器，無能我們怎樣花錢來升級他的硬件配置，我們會發(fā)現(xiàn)很快將無法進一步擴容。最好的CPU，最大的內(nèi)存條也是有限度的，因此采用集群架構，才是解決問題的正確方法。
而第8張圖所畫的就是標準的分布式集群架構，集群的擴容原則就是一個人干不完的活多個人一起干，讓服務器與服務器之間，進行分工與協(xié)作。
而做分布式集群的架構的架構師，也有著較高的要求，而互聯(lián)網(wǎng)上受人敬仰的架構師大多屬于這類。你也可以認為這才是真正的架構師。

第九
項目初期用戶量少，可以選擇單服務器架構，如果項目后期服務器負載壓力過大，可以重構為分布式集群架構。
重點在于項目前端，我們來看前端的技術架構圖，這里所畫的是市面所流行的混合APP的架構。
著名的混合APP應用有很多，比如說支付寶手機客戶端，還有Facebook，這些應用都是采用混合APP架構設計的
混合APP應用使用html，和css打造用戶界面，無論是在瀏覽器，微信端，還是在APP中，都是如此。因此他具備B/S應用程序的優(yōu)點，可以在服務器端更新應用內(nèi)容，并且讓應用在ios，安卓，瀏覽器端保持高度一致性。
因此混合APP架構同時具備了web APP與原生應用的優(yōu)勢，成為了市場上主流的移動應用架構設計方法。跨平臺兼容性好，開發(fā)成本低，開發(fā)速度快。逐步取代了大量的原生應用。這也是我們兄弟全棧工程師學習的主要內(nèi)容。