簡單實現微服務架構的實踐分享

為了實施微服務架構，我們一直在遵循實踐原則：每個微服務都必須擁有自己的獨立資料庫來避免資料庫級別的耦合。

為了更好地解決特殊場景的問題，微服務架構不提倡使用適合所有場景的標準化技術，而是為了根據每個服務的特性選擇更合適的技術。

當請求量增加時，只需要擴充套件一些服務而不是所有服務；同樣，當資料庫效能無法滿足需求時，則僅需擴充套件和升級某些服務的資料庫。

這也是微服務的架構的優勢所在；《領域驅動設計》引入了上下文“ boundedcase”的概念，透過梳理業務來找到不同業務上下文之間的界限，幫助我們找到了劃分小服務的方法，重點是業務邊界。JamesLewis和MartinFowler在微服務的定義中還強調，微服務是基於業務能力的構建。

因此，評估公司是否需要使用微服務架構通常會檢查這五個關鍵條件：

1. 資料量
2. 業務複雜度
3. 團隊規模
4. 應對業務流量變化
5. 是否有足夠的容錯和災難需求

Dobo是相對早期的微服務架構，可以使應用程式能夠透過高效能RPC實現服務的輸出和輸入功能以及Spring框架無縫整合。

不同型別的應用程式可以透過微服務功能演變為現代應用。

目前許多企業可能都面臨著是否要將單體架構進行微服務升級改造的問題。但從一個大一統的系統，拆分成一個一個單獨的小服務，企業需要投入的人力、物力、財力是非常巨大的。在沒有足夠的資源投入之前，不妨選擇一些折中的方案。

傳統架構的最大問題就是緊耦合，在應用迭代、升級的過程中，除了升級微服務架構之外，選擇一些可插拔式的技術工具也可以很好的解決問題。比如： FinClip小程式容器技術 ，這是一種以小程式技術為載體，發展成組裝式的企業應用架構技術。

從應用層來說，只要把FinClip SDK嵌入到企業的App中，就能立刻獲得小程式執行能力。不管你的專案是什麼軟體架構，都可以透過這種嵌入式的小程式技術去獲得APP並行開發、熱更新、敏捷迭代的能力。

從開發角度來說，這是一種「Native + 小程式」的混合開發模式，藉助這種模式可以讓小程式執行在自有 App 中，將臃腫的 App 功能打散，功能模組互相解耦實現模組化開發，各業務模組間互不影響，透過管理後臺即能實現實時動態更新與釋出。對於一些積重難返的專案來說，採用這種入侵性小、可插拔式的技術是一種值得嘗試的解決方案。