微服務

快速的【微】服務架構簡介

Grace Ma 2019/12/26 12:50:03
384

前言

工欲善其事,必先利其器,加上近期一直很夯的微服務,讓我們來一探虛實,繼續看下去~

 

為什麼要使用微服務?

 

三層架構

(三層式架構)

應用程式組合的基本架構有三種:

1. 將前端和後端放在同一個程式或組合元件之中,使用單一執行檔加上獨立的資料庫。

2. 前端和後端各自獨立執行檔,加上外部資料庫。

3. 前端+後端+儲存資料於記憶體中,全部組成一個執行個體。

 

隨著時間的推演產生三個問題:

1. 維運工作的增加。

2. 龐大的程式的行數與複雜度。

3. 伺服器處理量的增長造成處理速度緩慢。

 

擴充方式:

(橫向擴充應用程式)

(垂直擴充應用程式)

 

將所有程式打包成一包應用程式執行檔稱為「一整塊程式集合體」。當檔案越多,啟動、編譯和設定配置則會花費越多時間。

隨著軟體的生命周期演進,系統模組、功能越來越多,快速膨脹的應用程式,程式碼不斷的增加讓開發、部署、測試、維護都變得困難重重。

「一整塊程式集合體」擴充不易,常常受限於硬體設備,該如何提升應用程式執行效率要依靠並行與分割,但一整塊的程式包難以達成。

 

1. 並行

若要以一個程序執行工作A中所有步驟,那麼需要依序處理完全部,才能繼續處理下一份工作,處理的時間會以一項工作計算。

如果將工作A拆分成好幾項作業,那麼只需要各自獨立運行其中單獨的作業,即可並行計算處理時間。

2. 分割

假設有工作A、B、C,可以將這些工作各自分配給一群執行序進行平行處理,若需要增加工作的處理量,可以加入更多的執行序來進行,以提升效率。

 

如何讓「一整塊程式集合體」變得更有效率,將應用程式縮小為一項工作中的各種作業,獨立且併行也可互相同步支援,且抽掉其中一項不影響整個工作體。

 

什麼是微服務?

微服務概念是將系統拆分為單獨作業的小應用程式,容易替換、可獨立開發、獨立部署。

每一個應用程式透過不同的組合方式來搭建成一塊塊模組,所有應用程式皆可協同作業,且共同使用單一標準化規範。

多個應用程式群形成微服務生態系,互相依靠但可各自控管,對於功能的添加、移除、變更,擁有更高的自主性及機動性。

(一整塊程式集合體)

(微服務)

(各模組共用微服務)

使用微服務架構的優點:

1. 提升開發產量

2. 簡化測試流程

3. 增加可擴充性

4. 部署更靈活

5. 降低應用程式維運技術

 

轉換微服務架構步驟:

一、從「一整塊程式集合體」中的關鍵模組,區分出模組中的獨立功能,此功能執行的作業盡可能單一化,

若一項工作中包含很多的作業,應拆解為各項單獨作業的微服務。

二、專案系統的組織架構必須重組,確保每個微服務都有工程團隊能進行分配,

三、穩定且易擴充的微服務生態系統,須有專門的基礎建設組織來負責設計、建構與維護執行應用程式的基礎建設。

拆分後的應用程式應考量微服務間的互動和整體上的複雜度,尤其在設定配置上的控管非常重要。

四、詳細的計劃與執行文件,且經過實際模擬測試處理量,直到通過安全的穩定度檢驗。

五、開始逐一進行轉移,並不斷進行可行性驗證。

 

微服務適合所有專案系統嗎?

考量到微服務的基礎建設通常極為複雜,如果沒有合適的團隊進行操作,很難維持一定的穩定性。

通常採用微服務架構代表已經面臨擴充性的挑戰,龐大的系統造成維運上的困難,才會有轉換需求的產生。

 

微服務架構

微服務的用戶端不是傳統應用程式的前端,而是應用程式介面(API)與靜態端點。

例:

客戶資料微服務

端點(1.) get_customer_information       查詢客戶資料

端點(2.) update_customer_information 更新客戶資料

端點(3.) delete_customer_information   刪除客戶資料

 

微服務端點互動及儲存體介紹

(傳輸&存取)

大部分微服務會使用記憶體(或使用快取)或外部資料庫儲存相關資料。

1. 若儲存於記憶體中,則無須使用網路呼叫外部資料庫並回傳資料給用戶。

2. 若資料儲存於外部資料庫中,微服務必須對資料庫發送另外的請求、等待回應,然後繼續完成其他工作。

 

微服務架構需要一群微服務協同工作,以達成一整個模組中所有應用程式的功能,因此需定義標準化的微服務互動模式。

 

微服務的API端點應該要標準化,但不是所有微服務都使用相同的端點,而是類型應該一至。

REST與Apache Thrift為常見的API端點類型,同一系統中不建議使用不同的端點類型,會造成監控方式更為複雜。

端點類型取決微服務內部運作,也會限制它的架構。

例:

透過HTTP的REST通訊端點,很難建構非同步微服務,必須對服務加入基於訊息的端點。

 

微服務購過遠端程序呼叫(RPC)互動,它讓網路呼叫的操作行為如同本機程序呼叫。

其使用的通訊協定視架構與組織支援以及端點而定。

例:

使用REST端點的微服務與其他微服務透過HTTP互動

而使用Thrift端點的微服務互相以HTTP或自訂機制通訊

 

微服務生態系

 

微服務並不單獨存在,微服務的建構、執行、互動的環境,稱之為微服務生態系。

微服務生態系的基礎建設包含硬體、網路、建構、部署管道、服務查詢、負載平衡等等…。

 

微服務生態系可分為四層:

(微服務四層)

第一層:硬體

硬體層可架構實體伺服器或是租用雲端空間等等...,但若是租用空間須考量提供租用的範圍和配置。如何選擇可依照公司評估建置成本、可用性、可靠性與維運成本。

每個伺服器上需安裝一套作業系統,可依照需建構的應用程式、開發語言、函式庫及工具而定。

另外還需要專屬的資料儲存空間,以及主機監控、日誌紀錄等建置。

 

建置重點:

1. 實體伺服器

2. 資料庫

3. 作業系統

4. 資源隔離與抽象化

5. 組態管理

6. 主機層級監控

7. 主機層級日誌紀錄

 

第二層:通訊

通訊層負責於各層中傳遞資訊,穿梭於生態系中各層級。

第二層包含網路、DNS、RPC、API端點、服務查詢、服務登錄與負載平衡

 

RPC、端點與訊息

微服務間透過網路以遠端程序呼叫(RPC)或傳送資訊給各API端點。

使用指定的通訊協定,透過網路傳輸發送標準的格式資料,給其他服務或保證傳遞訊息的代理機制。

● 傳輸方式一、

服務使用HTTP透過網路相互溝通,以REST端點發送請求與接收回應,資料通常套用JSON格式。

此傳輸方式為同步化,請求後須等待回應完成,再繼續執行下一項工作。

● 傳輸方式二、

使用指定的通訊協定,透過網路傳輸發送訊息給訊息代理機制,它會將通訊導向其他微服務。

此種傳輸方式為非同步化,傳送訊息給代理機制後可繼續執行其他項目,不需等待回應。

 

服務查詢、服務登錄與負載平衡

微服務架構中,處理量必須導向不同的應用程式,然後分發給執行特定微服務的伺服器。

為了有效率的執行,於通訊程需要建置三種技術:

1. 服務查詢:通訊層必須安排好每個微服務的IP位置與埠號,讓呼叫以及請求可以正確送達,這是透過服務查詢。

2. 服務登錄:而服務查詢需要服務登錄,它記錄整個生態系中所有微服務的IP位置及埠號。

3. 負載平衡:將微服務產生的處理量,平均分散給所有軟硬體資源使用量,以達到最佳化資源使用、

最大化吞吐率、最小化回應時間、同時避免過載的目的。。

 

建置重點:

1. 網路

2. DNS

3. 遠端程序呼叫(RPC)

4. 端點

5. 訊息

6. 服務查詢

7. 服務登錄

8. 負載平衡

 

第三層:應用程式平台

包含獨立於微服務的內部工具與服務。

自助內部開發工具:

於微服務當中當負責的團隊不同時,建置內部應用介面可易於取用相關設定,通常使用以標準定義及直覺化選項。

提供給各團隊使用而不用至底層變動,如此可減少設定風險,也能帶來開發及維護的便利性。

 

開發循環:

第一項需求是提供儲存、追蹤、版本控管,與搜尋程式碼的集中化版本控制系統。

第二項需求是穩定與有效率的開發環境,模擬正式環境配置與設定越擬真越好。

 

測試、建構、打包與釋出

開發與部署間的測試、建構、打包與釋出步驟,應該要盡可能於資訊整合後集中化管理與標準化管理。

開發完成後,提交程式修改時應該要執行更動所關聯的完整測試,且新版本應該自動建構與打包。

 

部署管道

從開發環境轉換至測試環境在到各個正式的伺服器(內部、外部)上的過程。

微服務的生態系部署非常複雜,經過大量部署及自動化設定配置,需要穩定及可靠的標準程序。

 

日誌紀錄與監控

所有微服務都應該具有微服務層日誌,紀錄所有對微服務的請求與回應。

考量到微服務開發變更快速,要停留在錯誤發生時的狀況是不太可能的,

所以需要監控微服務層所有重要的數據,好讓開發人員可以迅速瞭解錯誤發生當下的狀況。

 

建置重點:

1. 自助內部開發工具

2. 開發環境

3. 測試、打包、建構與釋出工具

4. 部署管道

5. 微服務層日誌紀錄

6. 微服務層監控

 

第四層:微服務

微服務生態系最上層,單獨存在微服務與微服務專屬的組態。

建置重點:

1. 微服務

2. 微服務的組態

 

結尾

投資有風險取用請謹慎,別讓您的決策搖搖欲墜,只有穩健的執行方案才能讓您的系統歷久彌新、屹立不搖。

 

參考資料:

https://www.ithome.com.tw/node/74544

同步與非同步差異

https://zh.wikipedia.org/wiki/Thrift

Apache Thrift簡介

https://en.wikipedia.org/wiki/Representational_state_transfer

REST

https://en.wikipedia.org/wiki/Remote_procedure_call

RPC

高品質微服務-建構跨工程組織的標準化系統

https://www.gotop.com.tw/

碁峰資訊

Grace Ma
IT中的一份子,默默耕耘的SA