快速的【微】服務架構簡介
前言
工欲善其事，必先利其器，加上近期一直很夯的微服務，讓我們來一探虛實，繼續看下去~
為什麼要使用微服務？
(三層式架構)
應用程式組合的基本架構有三種：
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
高品質微服務-建構跨工程組織的標準化系統
碁峰資訊
