如何理解Greenfield面向微服務(wù)的體系結(jié)構(gòu)

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

面向微服務(wù)的體系結(jié)構(gòu)如今風(fēng)靡全球。這是因?yàn)楦斓牟渴鸸?jié)奏和更低的成本是面向微服務(wù)的體系結(jié)構(gòu)的基本承諾。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. 把它們放在一起

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

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

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