如何理解Greenfield面向微服務的體系結構

如何理解Greenfield面向微服務的體系結構，相信很多沒有經(jīng)驗的人對此束手無策，為此本文總結了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個問題。

創(chuàng)新互聯(lián)主打移動網(wǎng)站、成都網(wǎng)站設計、成都網(wǎng)站制作、外貿網(wǎng)站建設、網(wǎng)站改版、網(wǎng)絡推廣、網(wǎng)站維護、空間域名、等互聯(lián)網(wǎng)信息服務，為各行業(yè)提供服務。在技術實力的保障下，我們?yōu)榭蛻舫兄Z穩(wěn)定，放心的服務，根據(jù)網(wǎng)站的內容與功能再決定采用什么樣的設計。最后，要實現(xiàn)符合網(wǎng)站需求的內容、功能與設計，我們還會規(guī)劃穩(wěn)定安全的技術方案做保障。

面向微服務的體系結構如今風靡全球。這是因為更快的部署節(jié)奏和更低的成本是面向微服務的體系結構的基本承諾。

然而，對于大多數(shù)試水的公司來說，開發(fā)活動更多的是將現(xiàn)有的單塊應用程序轉換為面向微服務的體系結構，這可能是許多層面上阻礙和沖突的根源。

雖然Greenfield (未開發(fā)的)面向微服務的體系結構實現(xiàn)可以堅持對當前微服務的嚴格解釋-設計原則。但在面向微服務的體系結構中，分解的遺留應用程序存在灰色陰影，如果沒有其他原因，只能滿足預算和時間限制。

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

這種事經(jīng)常會發(fā)生。

因此，開發(fā)經(jīng)理面臨著巨大的壓力，要求他們盡快將代碼輸出。“足夠好”地成為轉型的理想目標。

現(xiàn)在，這不一定是一件壞事。與等待夢想到來相比，輸出工作代碼的能力總是更好。但是，“灰色的陰影”是很難管理的，問題就在于如何界定“足夠好”的界限。

因此，沖突開始了。一方想要輸出他們想要的東西，而另一方則希望做更多的改進。

對你來說，挑戰(zhàn)是不要讓這些不同學派在本質上是信仰支持的觀點上制造一場沒完沒了的爭吵。如果您這樣做了，它將造成一種情況，即根本不提供任何代碼?，F(xiàn)在，沖突可以從許多相互競爭的想法中綜合出最好的想法。但是，當話語退化為永無止境的沖突時，它可能是致命的。

1. 設計的理由是什么？

當您評估面向微服務的體系結構的設計時，所面臨的挑戰(zhàn)是將過去的觀點轉移到理論基礎分析上。它的創(chuàng)建主要來自于單個應用程序的分解。任何設計都可能“足夠好”，只要你能證明它的好處和價值。

例如，面向微服務的體系結構設計的首選樣式之一是采用事件驅動的方法進行服務間通信。具體來說，這意味著您使用消息節(jié)點以異步方式在微服務之間傳遞消息。然而，從長遠來看，雖然異步通信更加靈活和可擴展，但消息系統(tǒng)實現(xiàn)比在“面向”微服務的API之間使用同步HTTP調用的設計要復雜得多。因此，當市場時間被關注時，完全有理由將單塊應用程序中的特性重構為以HTTP API方式表示的獨立的微服務。

與異步服務相比，同步微服務的實現(xiàn)通常不那么復雜。

從長遠來看，同步通信不一定是最佳選擇，但考慮到從單塊應用程序中提取獨立的微服務所需的所有其他工作，同步對于第一個版本來說是“足夠好”的。因此，這是一個合理的理由。

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

2. 風險有多大？

所有的設計都有內在的風險。在上面描述的同步設計示例中，這種服務間通信方法可能會導致服務之間類型耦合的風險，由于同步HTTP通信和其他通信的性質而增加延遲增加延遲。

重要的是要讓人們知道這些風險，這樣就可以根據(jù)預期設計的合理性來權衡它們。如果風險是巨大的，再多的理由也是不夠的。另一方面，考慮到目前的需求，某些風險可能是可以接受的。訣竅是確保風險在審查過程中得到明確的傳達。討論中已知的風險總是比隱藏的風險更可取，而這種風險可能會在路上造成沖擊。此外，如果您以前知道風險，那么隨著面向微服務的體系結構的成熟，您可以計劃如何在未來的版本中更好地向前邁進。這就是減少風險的原因。

3. 減少風險的計劃是什么？

一個明智的應用程序設計人員的一個標志是能夠識別他們的設計風險，一旦確定下來他會有遠見地闡明一種方法，以減輕這些風險。沒有適當?shù)木徑饧夹g的風險識別是思維不完整的標志。

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

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

4. 把它們放在一起

沖突是創(chuàng)造性進程的重要組成部分。有創(chuàng)造力的人往往對自己的想法堅韌不拔。所以，當你把它們放在一個房間里，讓他們?yōu)槊嫦蛭⒎盏慕ㄖO計一個單一的設計時，緊張關系肯定會加劇。事情就是這樣的。但要振作起來！沖突是好事。

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

看完上述內容，你們掌握如何理解Greenfield面向微服務的體系結構的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝各位的閱讀！

網(wǎng)頁名稱：如何理解Greenfield面向微服務的體系結構
文章轉載：http://muchs.cn/article28/pdpijp.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站改版、全網(wǎng)營銷推廣、營銷型網(wǎng)站建設、外貿建站、品牌網(wǎng)站建設、服務器托管

廣告

聲明：本網(wǎng)站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)