一、背景 遠程服務將電腦程式的工作範圍從單機擴展到網路,從本地延伸至遠程,是構建分散式系統的首要基礎。遠程服務調用(Remote Procedure Call,RPC)在電腦科學中已經存在了超過四十年時間。但很多人無法明確區分RPC與Rest。本文就講一講RPC和Rest的本質區別。 二、分析 ...
從系統的組織和部署結構方面來看,軟體架構的演化進程顯然有著從簡單到複雜的趨勢。那是否最新最複雜的架構就是目前業界選擇的最佳架構呢?非也。沒有最好的架構,只有最合適的架構。在軟體架構的選擇上,“合適”比“新”更加重要。
對於整個軟體架構發展進程,我們可以大致分為三大階段:單體架構、SOA架構、微服務架構。今天就來簡單分析一下架構的發展與優劣勢,希望能對大家的項目開發有所助益。
(1)單體架構
單體架構就是把所有的業務邏輯和控制邏輯全部都放在了一起,一個程式里包括了所有的相關功能。(All in one)。比如一個 ERP 系統中包括了商品模塊,訂單模塊,銷售模塊,庫存模塊,報表統計等等。
單體架構基本解決了所有簡單的問題,由於開發時所有業務代碼都在一起,測試的時候不需要聯調各種服務,發佈維護非常輕鬆。
但缺點也很明顯,每次修改代碼都心驚膽戰,甚至添加一個簡單的功能,或者修改一個BUG都會造成隱含的缺陷。一旦某一個模塊出了問題,那基本就是全盤 GG。如果想針對某個具體模塊提升性能,難度也比較大。
總的來說單體架構前期開發成本低、開發周期短,適合小型項目。對於大型項目來說不易開發、擴展和維護。技術棧受限,只能使用一種語言開發。系統性能擴展只能通過擴展集群節點,成本高。
單體架構優劣勢:
優勢 |
劣勢 |
---|---|
|
|
(2)面向服務架構(SOA)
隨著業務系統越來越複雜,單體架構垂直拆分演變出了SOA( Service-Oriented Architecture),即面向服務的架構。它可以根據需求通過網路對鬆散耦合的粗粒度應用組件(服務)進行分散式部署、組合和使用。一個服務通常以獨立的形式存在於操作系統進程中。比如上面舉的這個 ERP 系統,可以按照功能,將用戶,商品,交易等不同的部分拆分為了獨立的服務(當然,資料庫也需要進行拆分)。
從架構上來說,是將重覆功能或模塊抽取成組件的形式,對外提供服務,在項目與服務之間使用ESB(企業服務匯流排)的形式作為通信的橋梁。而ESB 就是一根管道,用來連接各個服務節點。為了集 成不同系統,不同協議的服務,ESB 做了消息的轉化解釋和路由工作,讓不同的服務互聯互通;
聽起來這種方式比之前的單體架構厲害了不少,但還是會有一些對應的問題,比如每一個拆分之後的服務“依然還是單體服務”,有一些每個模塊中都會使用的公共模塊沒有拆分(這也會導致 ESB 比較複雜)。
總結來說,面向服務架構有這些優劣勢:
面向服務架構優劣勢:
優勢 |
劣勢 |
---|---|
|
|
3)微服務架構
那如果我們不僅按照垂直方向拆分,同時也按照水平方向進行進一步拆分,那也就是微服務的架構模式了,微服務架構強調的一個重點是“業務需要徹底的組件化和服務化”,原有的單個業務系統會拆分為多個可以獨立開發、設計、運行的小應用。這些小應用之間通過服務完成交互和集成。其實和 SOA 架構類似,微服務是在 SOA 上做的升華。
還是以ERP系統舉例,系統里的商品,用戶,訂單,庫存等不同的部分都成為了獨立的微服務,每一個服務之間都可以進行直接的通信溝通。
那麼也就是說,微服務其實就是在移除了 ESB 之後,更為輕量和更為松耦合的服務,並把 ESB 的控制邏輯以 SDK 的方式註入到每個微服務中進行服務控制和治理,架構更為的分散式。
由於微服務的要素之一就是“微”,所以大多數微服務都是基於容器進行調度管理的(這也是我們為什麼經常會在微服務的相關介紹中看到 Docerk,k8s 的相關字樣)
微服務架構優劣勢:
優勢 | 劣勢 |
---|---|
|
|
從工作到現在經歷過大大小小的幾十個項目,每個項目都會基於當前的項目階段、技術情況去選擇合適技術架構。(很多大型企業的應用目前都還是單體架構)。隨著技術的發展,隨著業務的發展App版本不斷迭代,新功能不斷增加,業務上的處理邏輯越變越複雜。許多企業可能都面臨著是否要將單體架構進行微服務升級改造的問題。但從一個大一統的系統,拆分成一個一個單獨的小服務,企業需要投入的人力、物力、財力是非常巨大的。在沒有足夠的資源投入之前,不妨選擇一些折中的方案。
傳統架構的最大問題就是緊耦合,在應用迭代、升級的過程中,除了升級微服務架構之外,選擇一些可插拔式的技術工具也可以很好的解決問題。比如:FinClip小程式容器技術 ,這是一種以小程式技術為載體,發展成組裝式的企業應用架構技術。
從應用層來說,只要把FinClip SDK嵌入到企業的App中,就能立刻獲得小程式運行能力。不管你的項目是什麼軟體架構,都可以通過這種嵌入式的小程式技術去獲得APP並行開發、熱更新、敏捷迭代的能力。
從開發角度來說,這是一種「Native + 小程式」的混合開發模式,藉助這種模式可以讓小程式運行在自有 App 中,將臃腫的 App 功能打散,功能模塊互相解耦實現模塊化開發,各業務模塊間互不影響,通過管理後臺即能實現實時動態更新與發佈。對於一些積重難返的項目來說,採用這種入侵性小、可插拔式的技術是一種值得嘗試的解決方案。