Apache Cassandra——可擴充套件微服務應用程式的持久資料儲存
阿新 • • 發佈：2020-12-25
通過使用微服務，團隊可以更快地響應變化，而無需改動整個應用程式。利用微服務，開發團隊可以構建出具有魯棒性和可擴充套件性的系統，從而適應當今應用程式的需求。
然而，使用微服務也帶來了一系列挑戰。在本文中，我們將就此展開討論。
軟體工程師和架構師正在遠離基於單一、龐大的程式碼庫的單體應用程式。由於公司需要在全球範圍內運營，晝夜不停地開展業務，加上工作中對敏捷性和客戶需求響應能力的要求也越來越高，因此對單體應用程式的管理和擴充套件變得越來越難。
微服務架構作為一種新的方式，其出現填補了這一空缺。企業的軟體團隊已經從他們的領域驅動設計(Domain Driven Design)經驗中有所收穫，並已經接受了持續整合和持續交付(CI/CD)有著幫助軟體更高效地投入生產的能力。
通過使用微服務，團隊可以更快地響應變化，而無需改動整個應用程式。他們提倡根據服務的生命週期組建小型團隊，並示範瞭如何構建出具有魯棒性和可擴充套件性的系統，以便適應當今應用程式的需求。
01 向微服務遷移 微服務方法是建立在以往的所有實踐經驗和技術基礎之上的。 微服務是通過多個小型且相互獨立的程序來建構複雜的應用程式的。這些程序之間通過像是REST這樣與語言無關的輕量級應用程式介面（API）進行相互溝通。 將這些微服務分佈到多個伺服器或裝置映象上，再根據擴充套件需要對這些伺服器進行復制——這樣，這些服務就可以達到擴充套件的目的。 這些服務好比小型的建築模組，它們高度解耦，專注於執行小塊任務，並促進了系統構建的模組化。這每一個服務模組都是獨立部署和獨立管理的。像是容器這類的技術正在逐步成為建立此類服務的預設選擇。 從現存的單體應用向微服務遷移，其過程包括將單體應用程式的任務劃分為微服務架構所具有的不同且獨立的服務。之後，所有的或大多數的功能都將在微服務架構中實現。 您可以根據業務邏輯、前端和資料訪問來拆分單體程式。根據模組拆分單體應用程式後，它將逐漸縮小。之後當再需要新功能時，相比在單體程式中寫入更多程式碼，我們可以通過建立微服務來實現這些功能。 獨立執行服務有著以下這些明顯優勢：
02 微服務應用程式面臨的挑戰 微服務架構在帶來一些顯著好處的同時，也帶來了一些挑戰。通過應用正確的方法可以解決許多挑戰問題。 從一開始，非常重要的是為服務選擇正確的功能。為單體的每個功能都建立微服務會帶來不必要的複雜性。微服務的目標是分解應用程式，以實現敏捷應用程式的開發和部署。微服務領域的領先思想者山姆·紐曼(Sam Newman)倡導了一條有用的經驗法則，那就是，如果程式碼庫太大而無法由一個小團隊管理時，就應該考慮將其分解了。 同樣，如果實施不正確，服務間通訊的成本也會很高。您需要從訊息傳遞和RPC等選項中選擇成本最低的方法來滿足需求。 例如，向客戶通知他們的計程車或包裹即將到達的通知僅需要一對一的單向請求，而不是一對多的通知；之後，該通知期望在指定時間範圍內得到答覆。 另一個挑戰是複雜性。部署微服務應用程式通常需要一個分散式環境，該環境可以跨多個環境執行，從資料中心的不同伺服器到完全分散式的環境（如雲）。 這些分散式環境隨後將需要使用容器編排工具（例如Kubernetes）進行管理。仔細考慮好如何利用Kubernetes建立的新容器之類來實現流程自動化可以消除嚴重的擴充套件難題。 除此之外，您還必須考慮如何逐步測試和管理應用程式。由於涉及的服務與平臺的數量之多及其相互依賴性，微服務端到端的測試可能具有挑戰性。儘管面臨各種挑戰，您的應用程式複雜且多變，微服務仍將為您的企業不斷效勞。
03 微服務和資料 除了應用程式的程序之外，對由此產生的資料進行分析也很重要。每個微服務可以是無狀態的，也可以是有狀態的。這意味著無狀態的微服務不會在呼叫之間維護服務內的任何狀態資訊。該服務會接收請求，處理請求併發迴響應，但不會保留任何狀態資訊以備將來呼叫。 有狀態的微服務將以某種形式持久化以使其正常執行。使用微服務的系統通常會混合使用無狀態元件和有狀態元件——例如，用於更改檔案的服務可能不需要隨時保留該檔案的副本，而客戶服務應用程式的元件則會產生必須儲存的資料。 當您需要狀態資訊時，不要把它放在內部儲存；把它放在外部的資料儲存中會更容易些。用於保留狀態的資料儲存型別將取決於您的需求以及隨著時間的推移您預計產生的資料量。 您可以選擇傳統的關係資料庫管理系統（RDBMS），NoSQL資料庫或某種型別的雲端儲存。在外部保留狀態資訊可以為之提供可用性，可靠性、可伸縮性和一致性。 對於產生大量資料的應用程式，如果這些資料要求被有效地編排組織，資料庫通常比物件儲存或雲端儲存更好。對於涉及事務或客戶服務的應用程式，規模效能也很重要。您可以瞭解一下NoSQL資料庫（例如Apache Cassandra）可能在這方面提供的幫助。 由於Apache Cassandra可以通過新增節點來線性擴充套件，它已成為微服務應用程式中流行的持久資料儲存選擇。 例如，在Monzo公司，微服務和Cassandra的結合使得這個銀行領域的挑戰者每年都能將客戶群增加四倍，而不會遇到任何問題。Monzo公司表示，在高峰時期，它可以在銀行中現有的1,500種微服務中每秒處理300,000次讀取，所有這些微服務都連線到其Apache Cassandra叢集。 在微服務應用程式面臨很多不定因素的情況下，支援該應用程式的任何資料庫實施都必須能夠輕鬆擴充套件並連線到所有元件。 使用Kubernetes之類的容器編排工具來管理應用程式和資料庫例項可以實現這一點。使用Kubernetes Operator進行管理，在需要時新增資料庫節點，可以避免擴充套件資料庫方面的很多管理問題。 同樣值得考慮的是資料一致性和彈性問題。在分散式計算環境中，可以重播丟失的訊息並重新建立事務。 這在分散式資料庫中並不是那麼簡單，因此需要研究如何處理資料一致性的問題。Cassandra根據Paxos原則和最終一致性進行處理——這確保了所有資料副本在每個節點上都是一致的。 對於需要ACID事務的應用程式，可能需要一個單獨的資料庫例項；對於絕大多數應用程式，數毫秒內即可達到的最終一致性是足夠支援正常執行的。
04 微服務的未來 微服務可滿足當今IT的需求。它們可以駐留在世界各地的多個數據中心環境中，也可以在混合雲部署中實施，以提供足夠的規模和對資料的即時訪問。 這樣就可以滿足應用程式的需求，例如連續可用性和無延遲。考量微服務應用程式也意味著考量應用程式將產生的資料。 使用分散式NoSQL資料庫可提供同樣的應用程式設計方法——廣泛分佈、可伸縮並能夠在多個環境中執行。同時考量應用程式設計和資料庫設計將使您能夠更加充分地享受微服務帶來的好處。
01 向微服務遷移 微服務方法是建立在以往的所有實踐經驗和技術基礎之上的。 微服務是通過多個小型且相互獨立的程序來建構複雜的應用程式的。這些程序之間通過像是REST這樣與語言無關的輕量級應用程式介面（API）進行相互溝通。 將這些微服務分佈到多個伺服器或裝置映象上，再根據擴充套件需要對這些伺服器進行復制——這樣，這些服務就可以達到擴充套件的目的。 這些服務好比小型的建築模組，它們高度解耦，專注於執行小塊任務，並促進了系統構建的模組化。這每一個服務模組都是獨立部署和獨立管理的。像是容器這類的技術正在逐步成為建立此類服務的預設選擇。 從現存的單體應用向微服務遷移，其過程包括將單體應用程式的任務劃分為微服務架構所具有的不同且獨立的服務。之後，所有的或大多數的功能都將在微服務架構中實現。 您可以根據業務邏輯、前端和資料訪問來拆分單體程式。根據模組拆分單體應用程式後，它將逐漸縮小。之後當再需要新功能時，相比在單體程式中寫入更多程式碼，我們可以通過建立微服務來實現這些功能。 獨立執行服務有著以下這些明顯優勢：
- 適用於多種語言：只要服務的端點API返回所需的輸出，您可以選擇任何語言或技術來開發它。
- 部署的樂趣：微服務的獨立性使其更易於部署。與單體應用程式不同，微服務更新或擴充套件元件時不需要使整個應用程式離線。
- 級聯較少：同樣，任何一項服務的故障都不會導致整個應用程式的級聯故障。如果您沒有遵循好的設計方法（例如Netflix方法），那麼部分故障可能會出現，但是服務的獨立性使得除錯過程更加有針對性。
- 迴圈利用：一旦走上微服務之路，服務程式碼可以輕鬆地被重複利用到其它專案中。
02 微服務應用程式面臨的挑戰 微服務架構在帶來一些顯著好處的同時，也帶來了一些挑戰。通過應用正確的方法可以解決許多挑戰問題。 從一開始，非常重要的是為服務選擇正確的功能。為單體的每個功能都建立微服務會帶來不必要的複雜性。微服務的目標是分解應用程式，以實現敏捷應用程式的開發和部署。微服務領域的領先思想者山姆·紐曼(Sam Newman)倡導了一條有用的經驗法則，那就是，如果程式碼庫太大而無法由一個小團隊管理時，就應該考慮將其分解了。 同樣，如果實施不正確，服務間通訊的成本也會很高。您需要從訊息傳遞和RPC等選項中選擇成本最低的方法來滿足需求。 例如，向客戶通知他們的計程車或包裹即將到達的通知僅需要一對一的單向請求，而不是一對多的通知；之後，該通知期望在指定時間範圍內得到答覆。 另一個挑戰是複雜性。部署微服務應用程式通常需要一個分散式環境，該環境可以跨多個環境執行，從資料中心的不同伺服器到完全分散式的環境（如雲）。 這些分散式環境隨後將需要使用容器編排工具（例如Kubernetes）進行管理。仔細考慮好如何利用Kubernetes建立的新容器之類來實現流程自動化可以消除嚴重的擴充套件難題。 除此之外，您還必須考慮如何逐步測試和管理應用程式。由於涉及的服務與平臺的數量之多及其相互依賴性，微服務端到端的測試可能具有挑戰性。儘管面臨各種挑戰，您的應用程式複雜且多變，微服務仍將為您的企業不斷效勞。
03 微服務和資料 除了應用程式的程序之外，對由此產生的資料進行分析也很重要。每個微服務可以是無狀態的，也可以是有狀態的。這意味著無狀態的微服務不會在呼叫之間維護服務內的任何狀態資訊。該服務會接收請求，處理請求併發迴響應，但不會保留任何狀態資訊以備將來呼叫。 有狀態的微服務將以某種形式持久化以使其正常執行。使用微服務的系統通常會混合使用無狀態元件和有狀態元件——例如，用於更改檔案的服務可能不需要隨時保留該檔案的副本，而客戶服務應用程式的元件則會產生必須儲存的資料。 當您需要狀態資訊時，不要把它放在內部儲存；把它放在外部的資料儲存中會更容易些。用於保留狀態的資料儲存型別將取決於您的需求以及隨著時間的推移您預計產生的資料量。 您可以選擇傳統的關係資料庫管理系統（RDBMS），NoSQL資料庫或某種型別的雲端儲存。在外部保留狀態資訊可以為之提供可用性，可靠性、可伸縮性和一致性。 對於產生大量資料的應用程式，如果這些資料要求被有效地編排組織，資料庫通常比物件儲存或雲端儲存更好。對於涉及事務或客戶服務的應用程式，規模效能也很重要。您可以瞭解一下NoSQL資料庫（例如Apache Cassandra）可能在這方面提供的幫助。 由於Apache Cassandra可以通過新增節點來線性擴充套件，它已成為微服務應用程式中流行的持久資料儲存選擇。 例如，在Monzo公司，微服務和Cassandra的結合使得這個銀行領域的挑戰者每年都能將客戶群增加四倍，而不會遇到任何問題。Monzo公司表示，在高峰時期，它可以在銀行中現有的1,500種微服務中每秒處理300,000次讀取，所有這些微服務都連線到其Apache Cassandra叢集。 在微服務應用程式面臨很多不定因素的情況下，支援該應用程式的任何資料庫實施都必須能夠輕鬆擴充套件並連線到所有元件。 使用Kubernetes之類的容器編排工具來管理應用程式和資料庫例項可以實現這一點。使用Kubernetes Operator進行管理，在需要時新增資料庫節點，可以避免擴充套件資料庫方面的很多管理問題。 同樣值得考慮的是資料一致性和彈性問題。在分散式計算環境中，可以重播丟失的訊息並重新建立事務。 這在分散式資料庫中並不是那麼簡單，因此需要研究如何處理資料一致性的問題。Cassandra根據Paxos原則和最終一致性進行處理——這確保了所有資料副本在每個節點上都是一致的。 對於需要ACID事務的應用程式，可能需要一個單獨的資料庫例項；對於絕大多數應用程式，數毫秒內即可達到的最終一致性是足夠支援正常執行的。
04 微服務的未來 微服務可滿足當今IT的需求。它們可以駐留在世界各地的多個數據中心環境中，也可以在混合雲部署中實施，以提供足夠的規模和對資料的即時訪問。 這樣就可以滿足應用程式的需求，例如連續可用性和無延遲。考量微服務應用程式也意味著考量應用程式將產生的資料。 使用分散式NoSQL資料庫可提供同樣的應用程式設計方法——廣泛分佈、可伸縮並能夠在多個環境中執行。同時考量應用程式設計和資料庫設計將使您能夠更加充分地享受微服務帶來的好處。