微服務并非包治百病，子產品化單體是更好的解決方案

微服務不能“包治百病”

時下微服務是一個不錯的架構，它具備子產品化、可伸縮和高容錯這些優點。許多公司都采用微服務架構并取得了巨大的成功，自然而然地，如果你正開始一個新項目，微服務似乎是最佳選擇。

然而，大多數采用微服務取得成功的公司并不是一開始就選擇了這種架構。以Airbnb和Twitter為例，他們在單體應用過于龐大之後才選擇了微服務路線，現在也仍在解決由此帶來的複雜性。即使是大公司也仍在尋找使用微服務的最佳方法。是以說，微服務是一把雙刃劍，需要權衡利弊。

從單體應用遷移到微服務也絕不是一項簡單任務，未經過測驗，便采用微服務建構一個新産品則更加複雜。隻有在充分評估了替代方案之後，才應該認真考慮是否使用微服務架構。

微服務僅适用于成熟産品

關于從頭開始使用微服務，馬丁·福勒（Martin Fowler）總結道：

1.幾乎所有成功的微服務都是從一個過于龐大而不得不拆分的單體應用開始的。 2.幾乎所有從頭開始以微服務建構的系統，最後都會因嚴重的問題而失敗。這種情況導緻許多人認為，就算你确信你的應用将快速發展壯大，也不應該一開始便采用微服務。

初版設計很難優化得很好，新産品的前幾次疊代重點在于尋找使用者的真正痛點。是以，成功取決于保持靈活并能快速優化和重構。在這方面，微服務就比單體應用差得多。如果你沒有把握設計好最初的方案，就采用了微服務，那麼你的啟程之路将更加困難，因為重構微服務比重構單體應用要困難得多。

微服務不是本地部署的最佳選擇

由于所有部件都是動态變化的，微服務部署需要搭配更強大的自動化機制。在正常環境下，我們可以依靠持續部署管道（continuous deployment pipelines）來完成工作——任務開發者部署微服務，消費端盡管使用線上服務就可以了。

然而這并不适用于本地環境，如果開發者釋出一個包，需要消費端自行在其本地環境上部署和配置其他的服務，這使得部署變得更具挑戰性。

确切的說，開發本地微服務應用也是可行的，正如Semaphore（一個CI/CD平台）也提供了本地化部署模式。然而，在這個過程中我們需要克服幾個挑戰：

1.本地微服務的版本控制規則需要更加嚴格，你必須跟蹤參與釋出的每個單獨的微服務。 2.你必須進行完整的內建和端到端測試，因為你無法在生産環境中進行測試 3.如果不能直接通路生産環境，對微服務應用進行故障排查會困難得多

子產品化單體或許是更好的解決方案

開發人員想要避免采用單體架構的一個常見原因是，單體更容易變成一坨“代碼屎山”。那時很難再添加新功能，因為一切都是互相關聯的。

但是單體不一定是一團糟。以Shopify為例：他的代碼行數超過300萬行，是世界上最大的Rails單體應用之一。但有一點，系統過于龐大會給開發人員帶來許多痛苦：

應用非常脆弱，新的代碼會産生許多意想不到的影響。作出一些更改可能會引發一連串無關的測試用例失敗。例如，計算運費和計算稅率複用了一些代碼，那麼更改計算稅率代碼的同時可能會影響運費計算的結果。這是高耦合和缺乏邊界的結果，也導緻測試用例難以編寫，并且在CI上運作得非常緩慢。

Shopify沒有選擇将整個單體應用重寫為微服務，而是選擇了子產品化作為解決方案。

子產品化有助于設計更好的單體或者微服務。如果沒有認真地定義好子產品，我們要麼陷入傳統的分層式單體（大泥球），或者更差的結果，成了分布式單體應用，它同時具備單體和微服務兩者的缺點。

子產品化的工作量很大，但它也帶來了巨大的價值，使開發可以更加直接。新開發人員在開始變更代碼之前不必了解整個應用，一次隻需要熟悉一個子產品。良好的子產品化可以使一個大單體更好上手。

子產品化是切換到微服務之前的必要步驟，并且有可能是更好的解決方案。與微服務類似，子產品化單體應用通過将代碼拆分為一些獨立的子產品來解決代碼耦合的問題。與微服務通過網絡進行通信不同，單體應用中的子產品通過内部API調用進行通信。

分層式單體對比子產品化單體，子產品化單體具有微服務的許多特征，卻沒有微服務面臨的諸多挑戰。

如何快速子產品化單體？

如何快速子產品化單體？采用小程式容器是最簡便的方案。不如FinClip 提供的可插拔式的技術工具：這是一種以小程式技術為載體，發展成子產品化的企業應用架構技術。

從應用層來說，隻要把FinClip SDK嵌入到企業的App中，就能立刻獲得小程式運作能力。不管你的項目是什麼軟體架構，都可以通過這種嵌入式的小程式技術去獲得APP并行開發、熱更新、靈活疊代的能力。

小程式容器和單體架構的結合可以實作前後端分離。前端開發者可以專注于小程式的界面設計和互動邏輯，而後端開發者可以專注于服務的實作和資料處理，兩者之間的接口通過網絡來進行互動。這種方式可以提高開發效率和部署速度，同時也可以降低應用程式的耦合性和維護成本。

從開發角度來說，這是一種「Native + 小程式」的混合開發模式，借助這種模式可以讓小程式運作在自有 App 中，将臃腫的 App 功能打散，功能子產品互相解耦實作子產品化開發，各業務子產品間互不影響，通過管理背景即能實作實時動态更新與釋出。對于一些積重難返的項目來說，采用這種入侵性小、可插拔式的技術是一種值得嘗試的解決方案。