面向微服務的體繫結構如今風靡全球。這是因為更快的部署節奏和更低的成本是面向微服務的體繫結構的基本承諾。 然而，對於大多數試水的公司來說，開發活動更多的是將現有的單塊應用程式轉換為面向微服務的體繫結構，這可能是許多層面上阻礙和衝突的根源。 雖然 "Greenfield" (未開發的)面向微服務的體繫結 ...
面向微服務的體繫結構如今風靡全球。這是因為更快的部署節奏和更低的成本是面向微服務的體繫結構的基本承諾。
然而，對於大多數試水的公司來說，開發活動更多的是將現有的單塊應用程式轉換為面向微服務的體繫結構，這可能是許多層面上阻礙和衝突的根源。
雖然Greenfield (未開發的)面向微服務的體繫結構實現可以堅持對當前微服務的嚴格解釋-設計原則。但在面向微服務的體繫結構中，分解的遺留應用程式存在灰色陰影，如果沒有其他原因，只能滿足預算和時間限制。
在企業管理鏈的某個地方，有一位業務主管在一個面向微服務的體繫結構中查看與這些遺留應用程式相關的分解成本，並將其與遺留代碼已經提供的價值進行比較。一旦開發成本超過了預期的收益，業務主管很可能會退出並取消該項目。
這種事經常會發生。
因此，開發經理面臨著巨大的壓力，要求他們儘快將代碼輸出。“足夠好”地成為轉型的理想目標。
現在，這不一定是一件壞事。與等待夢想到來相比，輸出工作代碼的能力總是更好。但是，“灰色的陰影”是很難管理的，問題就在於如何界定“足夠好”的界限。
因此，衝突開始了。一方想要輸出他們想要的東西，而另一方則希望做更多的改進。
對你來說，挑戰是不要讓這些不同學派在本質上是信仰支持的觀點上製造一場沒完沒了的爭吵。如果您這樣做了，它將造成一種情況，即根本不提供任何代碼。現在，衝突可以從許多相互競爭的想法中綜合出最好的想法。但是，當話語退化為永無止境的衝突時，它可能是致命的。
我通過集中討論以下三個問題來處理這類情況，以避免這種衝突：
- 設計的理由是什麼？
- 風險有多大？
- 減少風險的計劃是什麼？
請允許我詳細說明。
1. 設計的理由是什麼？
當您評估面向微服務的體繫結構的設計時，所面臨的挑戰是將過去的觀點轉移到理論基礎分析上。它的創建主要來自於單個應用程式的分解。任何設計都可能“足夠好”，只要你能證明它的好處和價值。
例如，面向微服務的體繫結構設計的首選樣式之一是採用事件驅動的方法進行服務間通信。具體來說，這意味著您使用消息節點以非同步方式在微服務之間傳遞消息。然而，從長遠來看，雖然非同步通信更加靈活和可擴展，但消息系統實現比在“面向”微服務的API之間使用同步HTTP調用的設計要複雜得多。因此，當市場時間被關註時，完全有理由將單塊應用程式中的特性重構為以HTTP API方式表示的獨立的微服務。
與非同步服務相比，同步微服務的實現通常不那麼複雜。
從長遠來看，同步通信不一定是最佳選擇，但考慮到從單塊應用程式中提取獨立的微服務所需的所有其他工作，同步對於第一個版本來說是“足夠好”的。因此，這是一個合理的理由。
然而，這並不是說同步方法沒有風險。事實上，風險有很多。當涉及到審查面向微服務的體繫結構設計時，僅僅說明理由並不是唯一的因素。風險也必須加以闡述。
2. 風險有多大？
所有的設計都有內在的風險。在上面描述的同步設計示例中，這種服務間通信方法可能會導致服務之間類型耦合的風險，由於同步HTTP通信和其他通信的性質而增加延遲增加延遲。
重要的是要讓人們知道這些風險，這樣就可以根據預期設計的合理性來權衡它們。如果風險是巨大的，再多的理由也是不夠的。另一方面，考慮到目前的需求，某些風險可能是可以接受的。訣竅是確保風險在審查過程中得到明確的傳達。討論中已知的風險總是比隱藏的風險更可取，而這種風險可能會在路上造成衝擊。此外，如果您以前知道風險，那麼隨著面向微服務的體繫結構的成熟，您可以計劃如何在未來的版本中更好地向前邁進。這就是減少風險的原因。
3. 減少風險的計劃是什麼？
一個明智的應用程式設計人員的一個標誌是能夠識別他們的設計風險，一旦確定下來他會有遠見地闡明一種方法，以減輕這些風險。沒有適當的緩解技術的風險識別是思維不完整的標誌。
如果面向微服務的體繫結構設計有很大的風險和解決這些問題的邊際計劃，那麼設計團隊需要認真考慮其可行性。此外，如果緩解計劃不切實際-超出項目的專門知識和預算-設計的可行性也需要質疑。這都是平衡的問題。
一個平衡良好的面向微服務的體繫結構設計是合理的，因為它想要滿足的條件與其固有的設計風險和旨在解決這些風險的緩解計劃相權衡。
4. 把它們放在一起
衝突是創造性進程的重要組成部分。有創造力的人往往對自己的想法堅韌不拔。所以，當你把它們放在一個房間里，讓他們為面向微服務的建築設計一個單一的設計時，緊張關係肯定會加劇。事情就是這樣的。但要振作起來！衝突是好事。
幸運的是，有了一種理性的方法，用我前面描述的三個問題來審查面向微服務的體繫結構設計，您就可以促進客觀的討論，從而產生軟體以及時滿足您的需求。沒有任何設計是完美的，特別是那些分解單個應用程式的設計。但是，交付面向微服務的體繫結構有一個很大的好處，這個體繫結構足夠好有效運作在短期和靈活性足夠持續不斷改善長期。
作者：Bob Reselman
譯者：遺失的拂曉
9月福利，關註公眾號
後臺回覆：004，領取8月翻譯集錦!
往期福利回覆：001，002, 003即可領取！
