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