簡要剖析：可擴充套件的微服務架構

應用程式狀態管理和資料驅動的決策

隨著應用程式和系統的複雜性不斷增加，處理這些問題的團隊的規模也不斷擴大。

在這種情況下，將系統作為整體系統會阻止開發團隊快速前進。

這就需要一種方法，使得獨立的功能團隊能將對其他團隊的依賴降到最小，並完整地提供所需的功能。

人們從一開始就試圖實現這個目標：從物件導向的程式設計，到面向服務的體系結構，到企業服務匯流排，最後到現在的微服務。

真實世界的例子問題

微服務的前提是與功能相關的所有內容都應以自給自足的方式存在 。

想象一下單片應用程式電子商務應用程式（儘管是超簡化範圍），它應該具有以下模組：

 

這些功能中的每一個都可能具有不同的利用率級別，並且將整個應用程式擴充套件到最大級別將消耗與利用率無關的資源。

一個人每次會話登入一次，可能會進行多次搜尋，但不經常更新他們的購物車，然後最終退出。又或者，使用者會在結賬後退出。

在這種情況下，搜尋功能和庫存檢查功能將比其他功能使用得多。

可以將應用程式分解為自給自足的服務，即微服務，然後根據功能上的負載來縮放適當的服務。

但是，完全自給自足意味著每個服務都有自己的端到端完整技術堆疊，包括資料庫。

如果資料在多個服務之間是通用的，則資料庫層將從微服務中解脫出來，有利於建立公共共享資料層。

這允許Saga模式的一致實現，使得參與的服務可以互發訊號並在相同的資料庫上操作。

這下問題該解決了吧？

快了，但還沒解決。

以下是對高效能的進一步要求：

電信：

• vEPC或5G核心

• IMS

• OSS / BSS

• 呼叫欺詐預防

金融服務：

• 信用卡欺詐預防

• 投資組合風險管理

• 實時滑點計算

電子商務

• 實時庫存管理

• 實時訂單管理

• 搜尋與庫存水平一致

在這些用例中，資料處理通常具有不到5毫秒的延遲預算。

這也是分離資料和業務邏輯的流行概念開始需要對兩種業務邏輯進行一些改進的地方 ：

1. 應用程式狀態控制業務邏輯

應用程式邏輯保留在應用程式中，即微服務和

2. 資料驅動的決策制定業務邏輯

資料驅動的業務邏輯保持接近資料，即在資料庫中。

這種分離允許兩個層根據各層的效能需求獨立擴充套件，同時不會產生不一致的/離散的資料集  或 為保證各層的彈性而基礎設施足跡人為膨脹地拼接在一起的多層結構。

VoltDB的能用之處在哪裡？

VoltDB是一個分散式記憶體資料庫，旨在為快速移動的流資料提供實時智慧決策。

藉助儲存過程框架和記憶體資料儲存引擎，VoltDB以可擴充套件的方式、最低延遲驅動大多數複雜的業務邏輯，即使在虛擬化環境（如VM和容器）中也是如此。

所有這些都不會影響ACID對企業級資料庫的預期保證。

如果您正處於將應用程式遷移到微服務架構的過程中，請看看我們如何透過跨功能一致性來幫助滿足您的資料處理需求吧。