通過使用微服務，團隊可以更快地響應變化，而無需改動整個應用程序。利用微服務，開發團隊可以構建出具有魯棒性和可擴展性的系統，從而適應當今應用程序的需求。
然而，使用微服務也帶來了一系列挑戰。在本文中，我們將就此展開討論。
軟件工程師和架構師正在遠離基於單一、龐大的代碼庫的單體應用程序。由於公司需要在全球范圍內運營，晝夜不停地開展業務，加上工作中對敏捷性和客戶需求響應能力的要求也越來越高，因此對單體應用程序的管理和擴展變得越來越難。
微服務架構作為一種新的方式，其出現填補了這一空缺。企業的軟件團隊已經從他們的領域驅動設計(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數據庫可提供同樣的應用程序設計方法——廣泛分布、可伸縮並能夠在多個環境中運行。同時考量應用程序設計和數據庫設計將使您能夠更加充分地享受微服務帶來的好處。