Apache Cassandra——可擴展微服務應用程序的持久數據存儲

經過使用微服務，團隊能夠更快地響應變化，而無需改動整個應用程序。利用微服務，開發團隊能夠構建出具備魯棒性和可擴展性的系統，從而適應當今應用程序的需求。

 

然而，使用微服務也帶來了一系列挑戰。在本文中，咱們將就此展開討論。

 

軟件工程師和架構師正在遠離基於單1、龐大的代碼庫的單體應用程序。因爲公司須要在全球範圍內運營，晝夜不停地開展業務，加上工做中對敏捷性和客戶需求響應能力的要求也愈來愈高，所以對單體應用程序的管理和擴展變得愈來愈難。

 

微服務架構做爲一種新的方式，其出現填補了這一空缺。企業的軟件團隊已經從他們的領域驅動設計(Domain Driven Design)經驗中有所收穫，並已經接受了持續集成和持續交付(CI/CD)有着幫助軟件更高效地投入生產的能力。

 

經過使用微服務，團隊能夠更快地響應變化，而無需改動整個應用程序。他們提倡根據服務的生命週期組建小型團隊，並示範瞭如何構建出具備魯棒性和可擴展性的系統，以便適應當今應用程序的需求。

 

 

---

 

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數據庫可提供一樣的應用程序設計方法——普遍分佈、可伸縮並可以在多個環境中運行。同時考量應用程序設計和數據庫設計將使您可以更加充分地享受微服務帶來的好處。