面向微服務的體系結構評審中須要問的三個問題-咖啡雜談：Java、新聞、故事和觀點

面向微服務的體系結構現在風靡全球。這是由於更快的部署節奏和更低的成本是面向微服務的體系結構的基本承諾。

然而，對於大多數試水的公司來講，開發活動更多的是將現有的單塊應用程序轉換爲面向微服務的體系結構，這多是許多層面上阻礙和衝突的根源。

雖然Greenfield (未開發的)面向微服務的體系結構實現能夠堅持對當前微服務的嚴格解釋-設計原則。但在面向微服務的體系結構中，分解的遺留應用程序存在灰色陰影，若是沒有其餘緣由，只能知足預算和時間限制。

在企業管理鏈的某個地方，有一位業務主管在一個面向微服務的體系結構中查看與這些遺留應用程序相關的分解成本，並將其與遺留代碼已經提供的價值進行比較。一旦開發成本超過了預期的收益，業務主管極可能會退出並取消該項目。

這種事常常會發生。

所以，開發經理面臨着巨大的壓力，要求他們儘快將代碼輸出。「足夠好」地成爲轉型的理想目標。

如今，這不必定是一件壞事。與等待夢想到來相比，輸出工做代碼的能力老是更好。可是，「灰色的陰影」是很難管理的，問題就在於如何界定「足夠好」的界限。

所以，衝突開始了。一方想要輸出他們想要的東西，而另外一方則但願作更多的改進。

對你來講，挑戰是不要讓這些不一樣學派在本質上是信仰支持的觀點上製造一場沒完沒了的爭吵。若是您這樣作了，它將形成一種狀況，即根本不提供任何代碼。如今，衝突能夠從許多相互競爭的想法中綜合出最好的想法。可是，當話語退化爲永無止境的衝突時，它多是致命的。

我經過集中討論如下三個問題來處理這類狀況，以免這種衝突：

• 設計的理由是什麼？
• 風險有多大？
• 減小風險的計劃是什麼？

請容許我詳細說明。

1. 設計的理由是什麼？

當您評估面向微服務的體系結構的設計時，所面臨的挑戰是將過去的觀點轉移到理論基礎分析上。它的建立主要來自於單個應用程序的分解。任何設計均可能「足夠好」，只要你能證實它的好處和價值。

例如，面向微服務的體系結構設計的首選樣式之一是採用事件驅動的方法進行服務間通訊。具體來講，這意味着您使用消息節點以異步方式在微服務之間傳遞消息。然而，從長遠來看，雖然異步通訊更加靈活和可擴展，但消息系統實現比在「面向」微服務的API之間使用同步HTTP調用的設計要複雜得多。所以，當市場時間被關注時，徹底有理由將單塊應用程序中的特性重構爲以HTTP API方式表示的獨立的微服務。

​ 與異步服務相比，同步微服務的實現一般不那麼複雜。

從長遠來看，同步通訊不必定是最佳選擇，但考慮到從單塊應用程序中提取獨立的微服務所需的全部其餘工做，同步對於第一個版原本說是「足夠好」的。所以，這是一個合理的理由。

然而，這並非說同步方法沒有風險。事實上，風險有不少。當涉及到審查面向微服務的體系結構設計時，僅僅說明理由並非惟一的因素。風險也必須加以闡述。

2. 風險有多大？

全部的設計都有內在的風險。在上面描述的同步設計示例中，這種服務間通訊方法可能會致使服務之間類型耦合的風險，因爲同步HTTP通訊和其餘通訊的性質而增長延遲增長延遲。

重要的是要讓人們知道這些風險，這樣就能夠根據預期設計的合理性來權衡它們。若是風險是巨大的，再多的理由也是不夠的。另外一方面，考慮到目前的需求，某些風險多是能夠接受的。訣竅是確保風險在審查過程當中獲得明確的傳達。討論中已知的風險老是比隱藏的風險更可取，而這種風險可能會在路上形成衝擊。此外，若是您之前知道風險，那麼隨着面向微服務的體系結構的成熟，您能夠計劃如何在將來的版本中更好地向前邁進。這就是減小風險的緣由。

3. 減小風險的計劃是什麼？

一個明智的應用程序設計人員的一個標誌是可以識別他們的設計風險，一旦肯定下來他會有遠見地闡明一種方法，以減輕這些風險。沒有適當的緩解技術的風險識別是思惟不完整的標誌。

若是面向微服務的體系結構設計有很大的風險和解決這些問題的邊際計劃，那麼設計團隊須要認真考慮其可行性。此外，若是緩解計劃不切實際-超出項目的專門知識和預算-設計的可行性也須要質疑。這都是平衡的問題。

一個平衡良好的面向微服務的體系結構設計是合理的，由於它想要知足的條件與其固有的設計風險和旨在解決這些風險的緩解計劃相權衡。

4. 把它們放在一塊兒

衝突是創造性進程的重要組成部分。有創造力的人每每對本身的想法堅韌不拔。因此，當你把它們放在一個房間裏，讓他們爲面向微服務的建築設計一個單一的設計時，緊張關係確定會加重。事情就是這樣的。但要振做起來！衝突是好事。

幸運的是，有了一種理性的方法，用我前面描述的三個問題來審查面向微服務的體系結構設計，您就能夠促進客觀的討論，從而產生軟件以及時知足您的需求。沒有任何設計是完美的，特別是那些分解單個應用程序的設計。可是，交付面向微服務的體系結構有一個很大的好處，這個體系結構足夠好有效運做在短時間和靈活性足夠持續不斷改善長期。

原文： https://www.theserverside.com...

做者：Bob Reselman

譯者：遺失的拂曉