--- tags: 學習筆記, 架構 --- SOA MSA Serverless ======= # SOA 服務導向架構 一種分散式運算的軟體設計方法。軟體的部分組件(呼叫者),可以透過網路上的通用協定呼叫另一個應用軟體元件執行、運作,讓呼叫者獲得服務。SOA原則上採用開放標準、與軟體資源進行互動並採用表示的標準方式。因此應能跨越廠商、產品與技術。一項服務應視為一個獨立的功能單元,可以遠端存取並獨立執行與更新,例如在線上線查詢信用卡帳單。 服務導向的架構在宏觀(服務)上,而不是在微觀上(物件)因此提高了重複使用性。同時,服務導向的架構可以簡化與傳統系統的互連和使用。 ## SOA 下服務的特性 1. 針對某特定要求的輸出,該服務就是運作一項商業邏輯 1. 具有完備的特性(self-contained) 1. 消費者並不需要瞭解此服務的運作過程 1. 可能由底層其他服務組成 ## SOA 原則 1. 可重複使用, 粒度, 模組性, 可組合型, 物件化原件, 構件化以及具互動操作性 1. 符合開放標準(通用的或行業的) 1. 服務的識別和分類,提供和發布,監控和跟蹤。 # MicroService 是一種軟體架構風格,它是以專注於單一責任與功能的小型功能區塊 (Small Building Blocks) 為基礎,利用模組化的方式組合出複雜的大型應用程式,各功能區塊使用與語言無關 (Language-Independent/Language agnostic) 的 API 集相互通訊。 微服務是一種以業務功能為主的服務設計概念,每一個服務都具有自主運行的業務功能,對外開放不受語言限制的 API (最常用的是 HTTP),應用程式則是由一個或多個微服務組成。 微服務的規劃與單體式應用程式十分不同,微服務中每個服務都需要避免與其他服務有所牽連,且都要能夠自主,並在其他服務發生錯誤時不受干擾。 微服務理念中有數個資料庫的規劃方式。 相較於單一應用佈署與開發的成本較為低廉,可以針對單一服務進行變更及重新佈署,而非變更單一服務卻需要重新佈署整體。 * 每個服務都各有一個資料庫,同屬性的服務可共享同個資料庫。 * 所有服務都共享同個資料庫,但是不同表格,並且不會跨域存取。 * 每個服務都有自己的資料庫,就算是同屬性的服務也是,資料庫並不會共享。 資料庫並不會只存放該服務的資料,而是「該服務所會用到的所有資料」。更深層一點的舉例:假設有個文章服務,而這個服務可能會需要判斷使用者的帳號⋯⋯等。那麼文章服務的資料庫就可以放入使用者的部分資料。此舉是為了避免服務之間的相依性,避免文章服務呼叫使用者服務。 微服務中最重要的就是每個服務的獨立與自主,因此服務與服務之間也不應該有所溝通。倘若真有溝通,也應採用異步溝通的方式來避免緊密的相依性問題。 * 事件存儲中心(Event Store) 這可以讓你在服務叢集中廣播事件,並且在每個服務中監聽這些事件並作處理,這令服務之間沒有緊密的相依性,而這些發生的事件都會被保存在事件存儲中心裡。這意味著當微服務重新上線、部署時可以重播(Replay)所有的事件。這也造就了微服務的資料庫隨時都可以被刪除、摧毀,且不需要從其他服務中取得資料。 * 訊息佇列(Message Queue) 這令你能夠在服務叢集中廣播消息,並傳遞到每個服務中。具有這個功能的像是 NSQ 或是 RabbitMQ。你能夠在 A 服務上廣播一個「建立新使用者」的事件,這個事件可以順便帶有新使用者的資料。而 B 服務可以監聽這個事件並在接收到之後有所處理。這些過程都是異步處理的,這意味著 A 服務並不需要等到 B 服務處理完該事件後才能繼續,而這也代表 A 服務無法取得 B 服務的處理結果。與事件存儲中心近乎相似,但有所不同的是:訊息佇列並不會保存事件。一旦事件被消化(接收)後就會從佇列中消失,這很適合用在像發送歡迎信件的時機。 ## 特性 * 每個服務都容易被取代。 * 服務是以能力來組織的,例如使用者介面、前端、推薦系統、帳單或是物流等。 * 由於功能被拆成多個服務,因此可以由不同的程式語言、資料庫實作。 * 架構是對稱而非分層(即生產者與消費者的關係)。 * 適用於具持續交付 (Continuous Delivery) 的軟體開發流程。 * 與服務導向架構 (Service-Oriented Architecture) 不同,後者是整合各種業務的應用程式,但微服務只屬於一個應用程式。 # Serverless Functions as a Service / FaaS 一部分服務邏輯由應用實現,但是跟傳統架構不同在於:他們運行於無狀態的容器中,可以由事件觸發,短暫的,完全被第三方管理。 Serverless 不是不需要伺服器,而是將伺服器佈署、維運等瑣碎的工作轉交給第三方(AWS Lambda)處理,開發者只須將程式上傳到 Serverless 服務即可,因此可以不管系統維運將心力全部放在撰寫業務邏輯的程式碼,就像是沒有 Server。 Serverless 的服務不像傳統伺服器必須始終維持運行,等待使用者呼叫並給予回應。而是有人呼叫時觸發事件才開始運行,運行結束後即關閉,因此他沒有狀態的存在。 由於這些特色(無狀態、事件觸發)也導致 Serverless 的計費方式特殊,透過每次運行所使用的資源量來計費,這樣的計費方式較為彈性而靈活。一個簡單的對比是過往需要兼顧伺服器維運時,服務流量高低峰落差大,存在很大的資源浪費。 # 總結 * SOA 服務導向架構 是一種分散式運算的軟體設計方法。軟體的部分組件(呼叫者),可以透過網路上的通用協定呼叫另一個應用軟體元件執行、運作,讓呼叫者獲得服務。SOA原則上採用開放標準、與軟體資源進行互動並採用表示的標準方式。因此應能跨越廠商、產品與技術。一項服務應視為一個獨立的功能單元,可以遠端存取並獨立執行與更新。 服務導向架構提高了重複使用性,同時可以簡化與傳統系統的互連和使用。 具有以下特性 * 針對某特定要求的輸出,該服務就是運作一項商業邏輯 * 消費者並不需要瞭解此服務的運作過程 * 可能由底層其他服務組成 * 可重複使用, 粒度, 模組性, 可組合型, 物件化原件, 構件化以及具互動操作性 * 符合開放標準(通用的或行業的) * 服務的識別和分類,提供和發布,監控和跟蹤。 * Microservice 微服務 微服務有點像是在 SOA 的基礎上更進一步去實際應用,將所有服務切分得更加細緻成為獨立運行於容器上的個體,而且每個服務要避免與其他服務牽連,在其他服務發生錯誤時不受干擾,再透過相同的協定將應用程式所需的服務組合成一個應用程式。由於都是可以獨立運行的個體且以服務為導向設計(去中心化),因此若需要針對特定服務進行擴充時會變得較為彈性。 * Serverless 在 SOA 、 Microservice 的概念漸漸流行後,有人注意到了雖然 SOA 以及 Microservice 的設計已經成功使各個服務之間解耦並且使效能擴充有了一定的彈性。但開發人員在開發時仍需要關注許多無關業務邏輯的事情,必須處理伺服器的環境佈署以及維運,而且往往需要耗費大量的心力於此。 因此進一步提出了 Serverless 這樣一個概念,他讓一部分服務邏輯由應用實現,但是跟傳統架構不同在於:他們運行於無狀態的容器中,可以由事件觸發,短暫的,完全被第三方管理。Serverless 不是不需要伺服器,而是將伺服器佈署、維運等瑣碎的工作轉交給第三方(AWS Lambda)處理。 我覺得 SOA 、 MicroService 、 Serverless 就像是一連串概念的演化,以服務為基本模組來設計架構,減少開發以及維運的成本。
×
Sign in
Email
Password
Forgot password
or
By clicking below, you agree to our
terms of service
.
Sign in via Facebook
Sign in via Twitter
Sign in via GitHub
Sign in via Dropbox
Sign in with Wallet
Wallet (
)
Connect another wallet
New to HackMD?
Sign up