盟立微服務

分享：

微服務泛指數千個獨立網路標準與網路協定、程式語言、資料庫與網路伺服器元件，以上各式不同元件存在於現行軟體開發生命週期中，並做為開發人員工具使用。傳統單體式架構將所有元件都寫在一起，且基本上程式語言、Port與資料庫等都採用同一套，而且彼此密不可分，微服務架構將應用拆解為最小單位的獨立元件，彼此再透過API溝通、運行。

在微服務架構中，每個微服務都擁有各個微服務獨立的作業，並使用輕量型通訊機制 (例如 REST API 要求) 與從屬端或其他微服務通訊。
下圖顯示由多個微服務組成的應用程式架構：

舉例來說，某個銀行的報表系統中，有個子項目需要增加一個新的頁面；若以傳統的單體式架構開發，系統服務經過較長的時間過後，會因新增的功能與原有業務上或原有功能上的調整，產生調整邏輯時間花費較長的問題。且在過版的過程中，可能會有因新增的功能讓整個系統需要暫時停止的問題。若改以微服務的架構進行維運與開發，則可以針對需要新增功能的子系統進行開發、過版時也不會因新增的功能而產生讓整個系統需要暫時停止的問題。

微服務架構的優點：

可獨立部署：微服務最顯著的一個特徵是，其服務規模相較於傳統的單體式架構要小，而且可獨立部署，因此不會有為了變更一段較小的功能，或在修復、調整功能時產生暫時暫停相關服務的可能。微服務保證可幫大型應用服務化解為了做小小變更而耗費大量時間的內心挫折。不需要對應用服務有很深的了解，就能看出或瞭解能夠進一步促進速度和敏捷的方法的價值。這一類型的服務設計方便的價值除了速度以外。涉及商業問題、服務或產品的團隊部門集結在同一大型服務下、也可以各部門專注於各自負責的元件。微服務模型可讓組織針對單一服務或服務組合建立小型的跨部門團隊，並讓他們以敏捷方式運作。微服務的鬆散連結還可以建立一定程度的錯誤隔離，以及更好的應用程式復原力。由於是小型服務，學習元件運作方式的學習成本可顯著的降，加上其清晰的界限和通訊模式，使得新的團隊成員更容易瞭解元件內的程式庫並迅速做出貢獻，就速度和員工士氣來說都有顯著好處。
精確擴充：有了微服務，個別服務不僅可以個別部署，在個別擴充的時候也比單體式服務更具彈性。由此帶來的好處顯而易見：只要能正確執行，微服務的基礎架構需求低於單體式應用程式，因為它們能夠精確地只擴充有需要的元件，而不是像單體式應用程式需要擴充整個應用程式，若專案需要時，亦可以讓各個元件的團隊照不同的情境，選擇不同的程式語言。
敏捷的版本控管：因為微服務為獨自部署，所以可更輕鬆地管理錯誤 (Bug) 修正和功能版本，相比之下，單體式架構較容易有修正時影響到原本正常功能的問題。您可以逕自更新服務，而不必重新部署整個應用程式，並於發生錯誤時復原更新錯誤的部份。在許多傳統應用程式中，如果在應用程式的某個部分找到錯誤，因各個不同功能均在同一個架構底下，這可能會封鎖整個發行程序。新功能可能會保留，等待整合、測試和發佈的錯誤修正

微服務架構的挑戰：

運維的複雜性：微服務的重大好處伴隨著重大挑戰。從單體式移到微服務也意味著增加許多的管理複雜性與團隊間的溝通順暢程度；更多的團隊創造了更多的服務，然後部署在更多的地方，在專案的管理上也需要更多的溝通與協調，避免各自為政的問題。某個服務發生問題可能導致其他服務發生問題，反之亦然。記載應用軌跡資料（用於監視與解決問題）時，會變得更加浩瀚，而且可能在服務之間發生不一致，比方在A服務中，Token的狀態改變了，但B服務沒有更新Token的狀態。新版本可能造成舊版相容性問題。應用程式涉及更多的網路連線，這意味著發生延遲和連線等網路或設備的問題的機會變更多。 DevOps 方法可以解決其中許多問題，但 DevOps 採用本身有自己的挑戰。

儘管如此，這些挑戰無法阻止非採用者採用微服務，或阻止採用者深化其微服務承諾。新的 IBM 意見調查資料透露，56% 的非現行使用者可能在未來兩年內採用微服務，而 78% 的現行微服務使用者可能會增加他們投入在微服務的時間、金錢和精力（如：圖1）

技術的多樣性：由於每個微服務都是一個獨立的部署單元，各團隊之間有相當的自由選擇需要的技術。微服務可以用各種不同的語言，使用不同的庫與程式框架，並使用不同的資料儲存方式。這使得團隊可以選擇團隊內部合適的工具來工作，有些語言和庫更適合某些型別的問題。技術多樣性通常以最佳符合專案情境或是整個專案中最多成員熟悉的工具為中心進行討論，但往往微服務最大的好處卻是更令人頭疼的版本問題。在單體架構中你可以只使用一個單一的版本庫，這種情況經常導致升級出現問題。系統的一部分可能需要升級，來實現使用它的新功能，但不能因為升級而中斷系統的另一部分。處理程式庫或程式框架的版本問題是其中的一個難題，因為隨著程式碼庫的增大，難度會呈指數級增長。

這裡有一個風險，有這麼多的技術多樣性，開發團隊會被壓倒。一般來說，大多陣列織都鼓勵有限的一組技術。這種鼓勵是通過提供共同的工具來支援監測，使它更容易將服務穩定在一個小的通用環境中。用單體架構系統，早期對語言和框架的決定是很難逆轉的。經過十年左右，這些的決定可能會限制團隊並使團隊陷入尷尬的技術境地。微服務讓團隊嘗試新工具，並逐步一次遷移系統的一個個服務，使新老技術有所關聯，在重構服務架構時不必一次將全部的功能與元件都完成，而可以較平滑的完成重構。
其他因素：微服務的支持者們經常說服務更容易擴充套件：若一個服務會有大量的負載，就可以針對需要的獨立套件進行擴充，而不用對整個應用進行擴充套件。微服務允許你隔離敏感資料以及給資料增加安全性。此外，在保證微服務間互動安全的前提下，微服務相較單體式服務架構是難以被攻入的。安全問題越來越重要，這可以成為使用微服務的主要考慮因素。

產品資訊

2021.11.24

盟立微服務

分享：

可獨立部署：微服務最顯著的一個特徵是，其服務規模相較於傳統的單體式架構要小，而且可獨立部署，因此不會有為了變更一段較小的功能，或在修復、調整功能時產生暫時暫停相關服務的可能。微服務保證可幫大型應用服務化解為了做小小變更而耗費大量時間的內心挫折。不需要對應用服務有很深的了解，就能看出或瞭解能夠進一步促進速度和敏捷的方法的價值。這一類型的服務設計方便的價值除了速度以外。涉及商業問題、服務或產品的團隊部門集結在同一大型服務下、也可以各部門專注於各自負責的元件。微服務模型可讓組織針對單一服務或服務組合建立小型的跨部門團隊，並讓他們以敏捷方式運作。微服務的鬆散連結還可以建立一定程度的錯誤隔離，以及更好的應用程式復原力。由於是小型服務，學習元件運作方式的學習成本可顯著的降，加上其清晰的界限和通訊模式，使得新的團隊成員更容易瞭解元件內的程式庫並迅速做出貢獻，就速度和員工士氣來說都有顯著好處。
精確擴充：有了微服務，個別服務不僅可以個別部署，在個別擴充的時候也比單體式服務更具彈性。由此帶來的好處顯而易見：只要能正確執行，微服務的基礎架構需求低於單體式應用程式，因為它們能夠精確地只擴充有需要的元件，而不是像單體式應用程式需要擴充整個應用程式，若專案需要時，亦可以讓各個元件的團隊照不同的情境，選擇不同的程式語言。
敏捷的版本控管：因為微服務為獨自部署，所以可更輕鬆地管理錯誤 (Bug) 修正和功能版本，相比之下，單體式架構較容易有修正時影響到原本正常功能的問題。您可以逕自更新服務，而不必重新部署整個應用程式，並於發生錯誤時復原更新錯誤的部份。在許多傳統應用程式中，如果在應用程式的某個部分找到錯誤，因各個不同功能均在同一個架構底下，這可能會封鎖整個發行程序。新功能可能會保留，等待整合、測試和發佈的錯誤修正

微服務架構的挑戰：

運維的複雜性：微服務的重大好處伴隨著重大挑戰。從單體式移到微服務也意味著增加許多的管理複雜性與團隊間的溝通順暢程度；更多的團隊創造了更多的服務，然後部署在更多的地方，在專案的管理上也需要更多的溝通與協調，避免各自為政的問題。某個服務發生問題可能導致其他服務發生問題，反之亦然。記載應用軌跡資料（用於監視與解決問題）時，會變得更加浩瀚，而且可能在服務之間發生不一致，比方在A服務中，Token的狀態改變了，但B服務沒有更新Token的狀態。新版本可能造成舊版相容性問題。應用程式涉及更多的網路連線，這意味著發生延遲和連線等網路或設備的問題的機會變更多。 DevOps 方法可以解決其中許多問題，但 DevOps 採用本身有自己的挑戰。

儘管如此，這些挑戰無法阻止非採用者採用微服務，或阻止採用者深化其微服務承諾。新的 IBM 意見調查資料透露，56% 的非現行使用者可能在未來兩年內採用微服務，而 78% 的現行微服務使用者可能會增加他們投入在微服務的時間、金錢和精力（如：圖1）

技術的多樣性：由於每個微服務都是一個獨立的部署單元，各團隊之間有相當的自由選擇需要的技術。微服務可以用各種不同的語言，使用不同的庫與程式框架，並使用不同的資料儲存方式。這使得團隊可以選擇團隊內部合適的工具來工作，有些語言和庫更適合某些型別的問題。技術多樣性通常以最佳符合專案情境或是整個專案中最多成員熟悉的工具為中心進行討論，但往往微服務最大的好處卻是更令人頭疼的版本問題。在單體架構中你可以只使用一個單一的版本庫，這種情況經常導致升級出現問題。系統的一部分可能需要升級，來實現使用它的新功能，但不能因為升級而中斷系統的另一部分。處理程式庫或程式框架的版本問題是其中的一個難題，因為隨著程式碼庫的增大，難度會呈指數級增長。

這裡有一個風險，有這麼多的技術多樣性，開發團隊會被壓倒。一般來說，大多陣列織都鼓勵有限的一組技術。這種鼓勵是通過提供共同的工具來支援監測，使它更容易將服務穩定在一個小的通用環境中。用單體架構系統，早期對語言和框架的決定是很難逆轉的。經過十年左右，這些的決定可能會限制團隊並使團隊陷入尷尬的技術境地。微服務讓團隊嘗試新工具，並逐步一次遷移系統的一個個服務，使新老技術有所關聯，在重構服務架構時不必一次將全部的功能與元件都完成，而可以較平滑的完成重構。
其他因素：微服務的支持者們經常說服務更容易擴充套件：若一個服務會有大量的負載，就可以針對需要的獨立套件進行擴充，而不用對整個應用進行擴充套件。微服務允許你隔離敏感資料以及給資料增加安全性。此外，在保證微服務間互動安全的前提下，微服務相較單體式服務架構是難以被攻入的。安全問題越來越重要，這可以成為使用微服務的主要考慮因素。