開發(fā)者要么出于本能，要么很快就能在痛苦中發(fā)覺：即便一個(gè)很小的變化也能改變一切。就像攀巖那樣，每次挪移都會(huì)影響到未來的抉擇，因此如果在開始時(shí)考慮不周的話，可能會(huì)在今后突然導(dǎo)致致命的危機(jī)。隨著對(duì)開發(fā)生命周期和上市時(shí)間縮短這方面需求的增長，在架構(gòu)初期的任何決定都比以前更加重要。
　　想要定義合適的軟件架構(gòu)，不應(yīng)僅僅搭出高級(jí)架構(gòu)的框架，還應(yīng)聯(lián)合所有利益相關(guān)者，包括程序員、管理員、市場(chǎng)推廣人員等，最終一同得出走向成功的愿景規(guī)劃。
　　新一場(chǎng)“客戶端與服務(wù)器端之辯”
　　架構(gòu)師需要決定將繁重的任務(wù)放在哪邊。無分軟件架構(gòu)模式與風(fēng)格，大眾都在就這個(gè)問題爭(zhēng)論不休。
　　Battery Ventures風(fēng)投的Adrian Cockcroft在推特上就這個(gè)主題引發(fā)了一次著名的公眾辯論：“Etsy 讓我知道了為什么單一整體式應(yīng)用是一條死路，請(qǐng)?jiān)诳沙掷m(xù)擴(kuò)展部署中使用微服務(wù)架構(gòu)。”
　　
　　Etsy’s CTO John Allspaw回應(yīng)道：“在這點(diǎn)上你缺少批判性思考，因?yàn)槟阆胂蟛坏剿軒淼乃泻锰帯！?br /> 　　
　　而Allspaw在另一條推特中解釋道：“選擇變少了，機(jī)會(huì)卻擴(kuò)大了。只留幾個(gè)人們有著深刻理解的工具和模式，反而更有優(yōu)勢(shì)。”
　　下面是相關(guān)的一點(diǎn)背景。單一整體式架構(gòu)指的是傳統(tǒng)的“一切歸于主機(jī)”的軟件開發(fā)方法。所有的進(jìn)程與子程序都是龐大代碼庫的一部分，它們運(yùn)行在不同的服務(wù)器上，以便最小化延遲，最大化正常運(yùn)行時(shí)間。
　　較新的架構(gòu)是微服務(wù)，它包括了一系列獨(dú)立進(jìn)程，彼此實(shí)時(shí)協(xié)調(diào)運(yùn)作。最初，這聽起來就像是重啟古老的“客戶端與服務(wù)器端之辯”。基本上這個(gè)比喻很直觀，不過還有來自移動(dòng)市場(chǎng)約束的三個(gè)顯著差異。這三點(diǎn)差異與面向服務(wù)架構(gòu)（SOA）的更新、企業(yè)服務(wù)總線（ESB）調(diào)用這些服務(wù)、以及進(jìn)行一定程度的集中管制（CG）以避免復(fù)雜程度難以控制這三點(diǎn)相關(guān)。
　　SOA、ESB和CG
　　SOA從世紀(jì)之交就已存在，它是一種處理web服務(wù)更為有效的方式。這些年來，許多不同的方面都在使用SOA。也就是說需要取決于特定情況下使用哪種定義的SOA，才能確定微服務(wù)相關(guān)的方法。
　　Oracle的技術(shù)網(wǎng)絡(luò)經(jīng)理Bob Rhubart這樣總結(jié)SOA的關(guān)系：“就現(xiàn)狀來講，微服務(wù)并不是SOA的替代品，更像是隨著SOA逐漸過于嚴(yán)格和整體單一化，為了保留靈活度而采用的一種方式。”隨著大量服務(wù)開始向上擴(kuò)展，趨勢(shì)逐漸明顯：快速直接的溝通成為噩夢(mèng)。通常ESB將訪問方法或接口與每個(gè)服務(wù)一一對(duì)應(yīng)。如果要更新系統(tǒng)，比如公司出售，或者供應(yīng)商的任務(wù)重新分配，這時(shí)所有開發(fā)者必須要更新ESB。
　　集中式和分散式管制的價(jià)值也是有爭(zhēng)議的。高級(jí)工程師Martin Fowler和James Lewis根據(jù)開發(fā)社區(qū)的討論總結(jié)：“集中式管制的后果之一就是出現(xiàn)標(biāo)準(zhǔn)單一技術(shù)平臺(tái)的傾向。根據(jù)經(jīng)驗(yàn)來講，這種辦法過于嚴(yán)苛——并非每個(gè)問題都是個(gè)釘子，可以用一個(gè)錘子（解決方案）來搞定。”然而，有時(shí)候使用集中管制的單一整體式架構(gòu)仍然更有意義。
　　從單一整體式架構(gòu)中獲益的項(xiàng)目
　　盡管在看法、專業(yè)化和細(xì)微差異上仍有很大的商榷空間，不過有些指標(biāo)確實(shí)能夠表明何種架構(gòu)更適合某種具體目標(biāo)。例如，Stack Exchange的工程師VP David Fullerton這樣描述單一整體式架構(gòu)：這是個(gè)讓人感到乏味的架構(gòu)，卻能造就令人興奮的結(jié)果。他在紐約QCon的演講中這樣描述自己的單一整體式架構(gòu)：“其規(guī)模很適合我們。我們每個(gè)月要處理40億個(gè)請(qǐng)求，峰值達(dá)到3000個(gè)/秒；每天處理8億個(gè)SQL查詢，峰值達(dá)到8500個(gè)/秒。”
　　單一整體式架構(gòu)在時(shí)間有限時(shí)，能提供非常清晰的路徑，關(guān)鍵是要盡快建立并運(yùn)行起來。如果整支團(tuán)隊(duì)已經(jīng)集中在一起，并取得同步，就能更有效地協(xié)作，繼續(xù)完成任務(wù)。部署很簡單，擴(kuò)展起來也相對(duì)簡單。團(tuán)隊(duì)只需要在大量虛擬機(jī)或獨(dú)立主機(jī)上通過負(fù)載平衡器運(yùn)行多個(gè)副本。一般來講，團(tuán)隊(duì)最終會(huì)構(gòu)建出單一整體式架構(gòu)的核心，然后通過微服務(wù)手段構(gòu)建可擴(kuò)展組件。
　　從微服務(wù)架構(gòu)中獲益的項(xiàng)目
　　關(guān)于是否使用微服務(wù)，有很多贊成的論調(diào)，不過行業(yè)分析師指出：無論是應(yīng)用自身，還是團(tuán)隊(duì)磨合，都會(huì)有很嚴(yán)重的溝通問題。當(dāng)然，微服務(wù)在文檔、測(cè)試與解決不兼容問題的時(shí)間上肯定有著更高的閾值。
　　PayPal的CTO James Barrese表示：他們從單一整體式架構(gòu)轉(zhuǎn)到了微服務(wù)架構(gòu)上，以便能在更短周期內(nèi)更快地更新。
　　在新的移動(dòng)、面向項(xiàng)目團(tuán)隊(duì)中，由于工作一般具有獨(dú)立性、跨時(shí)區(qū)性、多平臺(tái)性，因而整體進(jìn)程安排起來更好一些。這種架構(gòu)允許團(tuán)隊(duì)成員成為某個(gè)功能的專家，讓應(yīng)用更新的時(shí)間跨度越來越短。想要隔離并下線出現(xiàn)問題的組件非常簡單。在企業(yè)層面上，公司無需再耗費(fèi)昂貴的投資來組建特定的開發(fā)堆棧。
　　結(jié)論
　　微服務(wù)軟件架構(gòu)代表軟件開發(fā)架構(gòu)的未來趨勢(shì)么？PwC顯然是認(rèn)可這一看法的，他們指出：
　　諸如Netflix、Gilt、PayPal和Condé Nast這樣的公司都是以網(wǎng)站可以容納高吞吐量而著稱。然而，盡管他們最近對(duì)系統(tǒng)做了大修大改，但那些老舊而更偏向單一整體式的架構(gòu)無法再快速增加或修改原有功能了。因此，現(xiàn)在他們都在轉(zhuǎn)用基于微服務(wù)的架構(gòu)，采用更模塊化、更松散耦合的方式。
　　不過事實(shí)上，單一整體式的結(jié)構(gòu)并未滅亡，而且仍舊在快速原型法中扮演著最有效的角色，盡管到了生命周期后期，團(tuán)隊(duì)會(huì)逐漸轉(zhuǎn)向微服務(wù)。但在切實(shí)可用的人工智能出現(xiàn)前，最好的辦法就是結(jié)合兩種架構(gòu)，一起使用。
?

普通下載普通下載

相關(guān)電子資料下載

• Spring Cloud ：打造可擴(kuò)展的微服務(wù)網(wǎng)關(guān) 60
• SpringCloud微服務(wù)架構(gòu)：實(shí)現(xiàn)分布式系統(tǒng)的無縫協(xié)作 62
• 類隔離的使用場(chǎng)景 106
• 微服務(wù)架構(gòu)組件分析,看這篇就夠了 285
• 邊緣計(jì)算微服務(wù)操作系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn) 193
• 【Spring Cloud 】基于微服務(wù)架構(gòu)的智慧工地監(jiān)管平臺(tái)源碼帶APP 150
• 聊聊這個(gè)有趣的話題：分布式單體 106
• Java版智慧工地云平臺(tái)源碼（微服務(wù)+Java+Springboot+Vue+MySQL），支持私有化部署， 369
• Service Mesh：探索分布式系統(tǒng)的幻覺與未來 141
• 微服務(wù)的4種部署策略，你都清楚嗎？ 298