精心設計的單體架構也是好的

banq發表於2018-10-08
架構
該文認為單體巨石架構如果經過良好設計也是很好的，但是什麼是良好設計呢？原文：

DevOps Days London今年很棒！會談很有意思，文化包容性和友好性。

我一直認為我們應該建立'正確的服務'，而不是為了用'微服務'而用'微服務'。使用微服務相當於還要使用Kubernetes和一個docker容器 - 你會有更多的etcd節點......

在這篇博文中，我想分享DevOps天開放空間討論的一個結果，討論什麼是/為什麼好的巨石單體架構，為什麼它可以作為起步開始。

那麼為什麼經過良好設計和開發的巨石系統也是很好的？

1. 快速失敗 - 他們讓開發團隊專注於提供功能（證明或反駁假設），而不是複雜的微服務架構
2. 它可以幫助您瞭解您的需求（第一次實現UML圖和領域模型時並不完美）
3. 微服務的開發很複雜（例如，優雅降級，健康檢查，重試）和監控
4. 微服務依賴性很難跟蹤

那麼好的巨石看起來像什麼：

1. 程式碼庫由元件模組化（例如發票，專案）
2. 元件之間的非同步通訊應使用佇列（例如RabbitMQ）。某個程式碼庫只是釋出和使用訊息
3. 在一個單獨的程式中如果使用佇列最好了（例如RabbitMQ docker容器）

[img index=1]

一旦應用被證明，那麼如果需要，可以開始分解了：

1. 支援水平縮放
2. 降低部署風險
3. 將應用程式元件的開發分發給其他小隊
4. 簡化除錯和維護

參與討論後的結論是：在糟糕的巨石單體在分解為微服務之前，將這個巨石單體設計為良好架構是重要的步驟，這是因為無論巨石多麼糟糕，它已經過實戰測試了。

banq評：在需求開始之初，需要快速迭代，摸清需求，發現需求中邏輯，摸清實體與值物件，以及它們所處的上下文，及其在這個上下文中的存在意義，使用SpringBoot進行快速原型開發是一條好的方式，雖然SpringBoot是微服務框架，但是專案開始之初，用它來做一個小型的單體系統，然後讓前端配合介面設計，最終讓使用者使用起來。

總得來說：我們需要一種方法和技術來摸清需求，快速拿出原型。DDD+Spring Boot無疑是這套快速敏捷的組合。

Well Architected Monoliths is good

[該貼被banq於2018-10-08 10:29修改過]

相關文章