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

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

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

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

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

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

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

因此，開發(fā)經(jīng)理面臨著巨大的壓力，要求他們盡快將代碼輸出?！白銐蚝谩钡爻蔀檗D(zhuǎn)型的理想目標。

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

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

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

1. 設(shè)計的理由是什么？

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

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

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

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

然而，這并不是說同步方法沒有風(fēng)險。事實上，風(fēng)險有很多。當(dāng)涉及到審查面向微服務(wù)的體系結(jié)構(gòu)設(shè)計時，僅僅說明理由并不是唯一的因素。風(fēng)險也必須加以闡述。

2. 風(fēng)險有多大？

所有的設(shè)計都有內(nèi)在的風(fēng)險。在上面描述的同步設(shè)計示例中，這種服務(wù)間通信方法可能會導(dǎo)致服務(wù)之間類型耦合的風(fēng)險，由于同步HTTP通信和其他通信的性質(zhì)而增加延遲增加延遲。

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

3. 減少風(fēng)險的計劃是什么？

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

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

一個平衡良好的面向微服務(wù)的體系結(jié)構(gòu)設(shè)計是合理的，因為它想要滿足的條件與其固有的設(shè)計風(fēng)險和旨在解決這些風(fēng)險的緩解計劃相權(quán)衡。

4. 把它們放在一起

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

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

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