4
我在由多個微服務的哈斯克爾項目。有多種服務需要同時使用某些類型，因此在不同的庫中定義，並由需要它們導入的每個類型（每種類型都有版本）。但有些事情讓我感到不舒服，我想知道哪些是關於該主題的最佳做法。特別是：最佳實踐分享類型的多個哈斯克爾包/微服務
- 我不知道如何處理共享類型的實例。爲了避免孤兒，必須在類型的模塊中爲每種類型定義實例。但是，有些實例並不是所有導入該軟件包的微服務都需要的，並且必須將其包含在內，而且可能會向微服務添加冗餘依賴關係。一個例子是由前端和後端共享的數據類型T。它有一個存儲的實例，以便存儲在前端不需要的數據庫中，但仍使前端依賴於存儲包。
- 爲了避免以前的問題，我可以每個類型都有「離開」一個微服務來代表該類型通過網絡線路的時候推出的包裝。在前面的例子中，我將有一個可保存牛逼這將有一個實例爲商店。儘管如此，這爲整個開發過程增加了很多開銷。
- 它甚至分享或應每個微服務定義自己的每一種類型的代表類型是一個好主意，所以什麼也沒被共享？因此，對於一個類型Ť一個微服務MA將具有AT表示和實例以連載它，以便將數據發送到微服務乙這將數據解碼成表示MB.T 。
最後，關於此事的後勤方面，
- 什麼是項目結構最便捷的方式？ monorepo會比單獨的回購/子模塊更好嗎？
- 可能與前一個，有沒有什麼辦法可以自動找出當共享庫中的一個被修改，因爲在庫中的變化影響的一段代碼正在使用由微服務微服務應該被重新部署？
如果您有兩種共享類型的服務，那麼這兩種類型相互耦合。那麼使他們成爲微服務有什麼意義呢？爲什麼不把它們定義爲一個獨立的模塊，並將它們組合成一個可執行文件？這樣編譯器會告訴你兩個模塊是否可以相互通信。 –
嗯 - 例如對於通信目的，IMO有一個「真值定義」（類型定義及其串行器/解串器代碼），可能耦合多個服務是有意義的。一個服務創建實例，通過線路發送它們，另一個服務消耗它們。最後，耦合是不可避免的，你只需要選擇它發生的地方。 –
是否要在單獨的可執行文件中運行服務，或者同一個可執行文件中的不同線程與您是否希望將代碼放在不同的回購站中是不同的問題（您希望構建項目以便這是一個無聊的問題，它是）。我建議：如果你有一個很好的理由（例如爲了能夠以不同的方式版本依賴關係），建議：將所有內容保存在同一個回購中，並且當你有明顯的分工時，考慮分離成單獨的項目（在同一個回購中，全部由堆棧管理） ）超越了建築美學的一些模糊概念。 – jberryman