我應該轉向基於微服務的架構嗎？

Question

我正在研究整體系統。 它的所有代碼都在一個存儲庫中（Web API和后台工作程序）。 系統使用Nodejs編寫，MongoDB（Mongoose）用作數據存儲。 我的目標是為項目的發展開辟一條新道路。 起初，我想知道是否可以轉向基於微服務的體系結構。

整體架構會產生一些問題：

• 如果我的后台工作人員需要擴展規模。 我必須將所有項目部署到服務器，盡管只使用其中的一小部分。
• 代碼更改時，必須重新部署所有系統。 如果在重新部署系統時付款處理器調用webhook怎么辦？

使用微服務的優勢非常明顯：

• 單個微服務的代碼量較小。 對此更容易推理。
• 能夠選擇最適合特定用例的編程工具。
• 易於擴展。

查看當前代碼，我注意到在所有項目中都使用了Mongoose ODM（對象文檔映射器）模型來創建，查詢和更新數據庫中的模型。 作為良好編程的原則，應該抽象所有與數據庫的交互。 業務邏輯不應泄漏到其他系統層。 我可以通過引入REPOSITORY模式（域驅動設計）來做到這一點。 盡管代碼仍在Web api和后台工作人員之間共享，但這並不是一項艱巨的任務。

如果我決定將存儲庫提取到獨立的微服務中，則會出現很多問題：

• 必須引入某種查詢語言以適應復雜的搜索查詢。
• 接口必須提供一種遍歷搜索結果（基於光標的導航）的方法，而無需通過網絡返回所有數據庫文檔。

由於該項目尚處於初期階段，而且我是唯一的開發人員，因此轉向基於微服務的體系結構似乎有些過頭。 也許我應該考慮其他方法？

將業務邏輯和與數據庫的交互提取到單獨的存儲庫中，並在服務之間共享以避免服務之間的復雜通信協議？

Answer 1

根據我過去幾年在微服務領域的工作經驗，在當前情況下這似乎有些過頭，但從長遠來看會有所收獲。

根據上述信息，我的想法是：

• 代碼結構-在上述上下文中應用的微服務體系結構（MSA）意味着不將DAO，業務邏輯等分開，而是根據業務功能在設計系統上更多。 例如，如果它是一個電子商務應用程序，那么您可以將運輸，購物車，搜索作為單獨的服務進行運輸，這些服務可以進一步分為較小的服務。 在此處閱讀有關域驅動設計的更多信息。
• 部署單元-將微服務應用程序保持為獨立的部署單元是關鍵原則。 因此，請保留應用程序的垂直部分，並將其打包為帶有應用程序代碼，App Server（如果有），數據庫和操作系統（Linux等）的Docker映像。

• 通信-使用MSA，服務之間的通信成為關鍵，因此通用做法是保留面向消息的通信方法（有關反應式系統和反應式編程的更多信息，請參見）。

• PaaS解決方案-有多種可用的PaaS解決方案，您可以應用這些解決方案，這樣您就不必擔心容器管理，容器編排，自動擴展，配置管理，日志管理和監視等所有其他方面。 PaaS解決方案：

• https://www.nanoscale.io/由TIBCO

• https://fabric8.io/-由RedHat

• https ://openshift.io-通過RedHat

• 雲供應商平台 -AWS，Azure和Google Cloud從部署角度來看，它們都對Microservices App都提供了特定的支持，如果您不想在組織中部署PaaS解決方案，我們可以將其用作替代解決方案。

希望這些指針可以幫助您了解整體情況，以便您可以為將來的需求構建體系結構。

Answer 2

我正在開發一個整體系統...我的目標是為項目的發展樹立新的道路。 起初，我想知道是否可以轉向基於微服務的體系結構。

您需要以什么方式發展項目？ 它會主要是錯誤修正，添加功能，提高性能和/或可伸縮性嗎？ 您是否期望將來有其他開發商合作？ 您目前有維護問題嗎？ 在指導您的選擇時，應考慮這些問題（以及更多）的答案。

您似乎正在圍繞微服務架構的優缺點來做家庭作業，因此，如果您沒有問自己為什么甚至一開始都這樣做，那么現在是這樣做的好時機。

也許我應該考慮其他方法？

總是有個好老的不休息-怎么了;）