網(wǎng)站微服務(wù)架構(gòu)最佳實(shí)現(xiàn)

1、 網(wǎng)站的微服務(wù)架構(gòu)最佳實(shí)現(xiàn) 微服務(wù)架構(gòu)的目標(biāo)是幫助工程團(tuán)隊(duì)更快、更安全、更高質(zhì)量地交付產(chǎn)品。拆分服務(wù)允許團(tuán)隊(duì)快速迭代的同時(shí)，保證了對(duì)系統(tǒng)剩余部分的最小影響。在Medium，我們的技術(shù)堆棧始于2012年的單體Node.js應(yīng)用程序。我們已經(jīng)構(gòu)建了幾個(gè)衛(wèi)星服務(wù)，但我們還沒有制定一個(gè)系統(tǒng)地采用微服務(wù)架構(gòu)的策略。 隨著系統(tǒng)變得越來(lái)越復(fù)雜并且團(tuán)隊(duì)不斷發(fā)展，我們?cè)?018年初轉(zhuǎn)向了微服務(wù)架構(gòu)。在這篇文章中，我們希望分享我們有效地做到這一點(diǎn)并避免微服務(wù)綜合癥的經(jīng)驗(yàn)。什么是微服務(wù)架構(gòu)？首先，讓我們花一點(diǎn)時(shí)間來(lái)思考微服務(wù)架構(gòu)應(yīng)該是怎么樣到，不應(yīng)該是怎么到。 “微服務(wù)”是解決那些過載和混亂的軟件工程的手段之一。

2、我們?cè)贛edium至少這樣認(rèn)為：在微服務(wù)架構(gòu)中，多個(gè)松散耦合的服務(wù)協(xié)同工作。 每項(xiàng)服務(wù)都專注于一個(gè)目的，并具有相關(guān)行為和數(shù)據(jù)的高度凝聚力。該定義包括三個(gè)微服務(wù)設(shè)計(jì)原則：?jiǎn)我宦氊?zé) - 每項(xiàng)服務(wù)應(yīng)專注于一個(gè)目的并做得好。松耦合 - 服務(wù)對(duì)彼此知之甚少。 對(duì)一項(xiàng)服務(wù)的更改不應(yīng)要求更改其他服務(wù)。 服務(wù)之間的通信應(yīng)僅通過公共服務(wù)接口進(jìn)行。高內(nèi)聚性 - 每項(xiàng)服務(wù)將所有相關(guān)行為和數(shù)據(jù)封裝在一起。 如果我們需要構(gòu)建新功能，則所有更改應(yīng)僅本地化為一個(gè)服務(wù)。當(dāng)我們對(duì)微服務(wù)進(jìn)行構(gòu)建模型時(shí)，我們應(yīng)該遵守所有三個(gè)設(shè)計(jì)原則。 這是實(shí)現(xiàn)微服務(wù)架構(gòu)全部潛力的唯一途徑。 錯(cuò)過任何一個(gè)都會(huì)成為反模式。如果缺少單一職責(zé)，每個(gè)微服務(wù)

3、最終會(huì)做太多事情，成長(zhǎng)為多個(gè)“單體”服務(wù)。 我們不會(huì)從微服務(wù)架構(gòu)中獲得全部好處，我們也會(huì)支付運(yùn)營(yíng)成本。如果缺少松散耦合，對(duì)一個(gè)服務(wù)的更改會(huì)影響其他服務(wù)，因此我們無(wú)法快速安全地發(fā)布更改，這本應(yīng)該是微服務(wù)架構(gòu)的核心優(yōu)勢(shì)。 更重要的是，緊密耦合引起的問題可能是災(zāi)難性的，例如數(shù)據(jù)不一致甚至數(shù)據(jù)丟失。如果缺少高凝聚力，我們將最終得到一個(gè)分布式單體系統(tǒng) - 一組混亂的服務(wù)，必須同時(shí)進(jìn)行更改和部署才能構(gòu)建單一功能。 由于多個(gè)服務(wù)協(xié)調(diào)的復(fù)雜性和成本（有時(shí)跨多個(gè)團(tuán)隊(duì)），分布式單體系統(tǒng)通常比集中式單體系統(tǒng)差得多。于此同時(shí)，認(rèn)識(shí)到微服務(wù)不應(yīng)該長(zhǎng)成那樣，也同樣重要：微服務(wù)不是具有少量代碼行或“微”任務(wù)的服務(wù)。 這種誤

4、解來(lái)自“微服務(wù)”這個(gè)名字。 微服務(wù)架構(gòu)的目標(biāo)不是擁有盡可能多的小型服務(wù)。 只有符合上述三項(xiàng)原則，服務(wù)的提煉就是恰當(dāng)?shù)?。微服?wù)不是一直使用新技術(shù)構(gòu)建的服務(wù)。 盡管微服務(wù)架構(gòu)允許團(tuán)隊(duì)更輕松地測(cè)試新技術(shù)，但它并不是微服務(wù)架構(gòu)的主要目標(biāo)。 只有從接偶的服務(wù)中受益，團(tuán)隊(duì)才能使用完全相同的技術(shù)堆棧去構(gòu)建新到服務(wù)。微服務(wù)不是必須從頭開始構(gòu)建的服務(wù)。 如果您已經(jīng)擁有一個(gè)架構(gòu)良好的單一應(yīng)用程序，請(qǐng)避免養(yǎng)成從頭開始構(gòu)建每個(gè)新服務(wù)的習(xí)慣。 可能有機(jī)會(huì)直接從單體服務(wù)中提取邏輯。 同樣，上述三個(gè)原則應(yīng)該仍然有效。為什么是現(xiàn)在？在Medium，我們總是在做出重大產(chǎn)品或工程決策時(shí)會(huì)問“為什么是現(xiàn)在？”這個(gè)問題。 “為什么？

5、”是一個(gè)顯而易見的問題，但它假設(shè)我們擁有無(wú)限的人，時(shí)間和資源，這是一個(gè)危險(xiǎn)的假設(shè)。 當(dāng)你想到“為什么是現(xiàn)在？”時(shí)，你突然有了更多的限制 - 對(duì)當(dāng)前工作的影響，機(jī)會(huì)成本，分心的開銷等等。這個(gè)問題有助于我們更好地優(yōu)先考慮。我們現(xiàn)在需要采用微服務(wù)的原因是我們的Node.js單體應(yīng)用程序已經(jīng)成為瓶頸。首先，最緊迫和最重要的瓶頸是其性能。 某些計(jì)算量很大且I / O很重的任務(wù)不適合Node.js. 我們一直在逐步改進(jìn)整體應(yīng)用程序，但事實(shí)證明它是無(wú)效的。 它的低劣性能使我們無(wú)法提供更好的產(chǎn)品而不會(huì)使已經(jīng)非常慢的應(yīng)用程序變慢。其次，重要且有點(diǎn)緊迫的瓶頸是單體應(yīng)用程序會(huì)拖慢產(chǎn)品開發(fā)速度。 由于所有工程師都在單

6、個(gè)應(yīng)用程序中構(gòu)建功能，因此它們通常緊密耦合。 我們無(wú)法靈活地改變系統(tǒng)的一部分，因?yàn)樗部赡苡绊懫渌糠帧?我們也害怕做出重大改變，因?yàn)橛绊懱?，有時(shí)甚至難以預(yù)測(cè)。 整個(gè)應(yīng)用程序作為一個(gè)整體進(jìn)行部署，因此如果由于一次錯(cuò)誤提交導(dǎo)致部署停滯，那么所有其他更改（即使它們完全正常工作）也無(wú)法順利完成發(fā)布。 相比之下，微服務(wù)架構(gòu)允許團(tuán)隊(duì)更快地開發(fā)和迭代。 因?yàn)檫@些功能與復(fù)雜系統(tǒng)是解耦的，所以工程師可以專注于他們正在構(gòu)建的功能。 自然的，他們就可以輕易安全地做到重大變更。在我們新的微服務(wù)架構(gòu)中，功能修改后可以在一個(gè)小時(shí)內(nèi)發(fā)布上線。同樣的，工程師不必?fù)?dān)心它會(huì)如何影響系統(tǒng)的其他部分。 項(xiàng)目組的團(tuán)隊(duì)還探索了在開發(fā)

7、中安全使用生產(chǎn)數(shù)據(jù)的方法，這在多年前是無(wú)法實(shí)現(xiàn)的。 隨著我們的工程團(tuán)隊(duì)的發(fā)展，我們有機(jī)會(huì)去突破現(xiàn)狀。第三，單塊應(yīng)用程序使系統(tǒng)很難針對(duì)特定任務(wù)進(jìn)行擴(kuò)展，也很難針對(duì)不同類型的任務(wù)分離資源問題。使用單一的單塊應(yīng)用程序，我們必須在整個(gè)系統(tǒng)上下擴(kuò)展，以完成更需要資源的任務(wù)，盡管這意味著系統(tǒng)對(duì)其他更簡(jiǎn)單的任務(wù)的準(zhǔn)備過度了。為了緩解這些問題，我們分解了不同類型的請(qǐng)求來(lái)分離Node.js進(jìn)程。它們?cè)谝欢ǔ潭壬掀鹱饔茫粫?huì)擴(kuò)展，因?yàn)椋瑯?，這些微版本的單片服務(wù)是緊密耦合的。最后一點(diǎn)也同樣重要的是，單體架構(gòu)阻礙了團(tuán)隊(duì)嘗試新技術(shù)。 微服務(wù)架構(gòu)的一個(gè)主要優(yōu)點(diǎn)是每個(gè)服務(wù)都可以使用不同的技術(shù)堆棧，并與不同的技術(shù)集成。

8、這使我們能夠選擇最適合工作的工具，于此同時(shí)，我們還可以快速安全地完成工作。微服務(wù)策略采用微服務(wù)架構(gòu)并非易事。 它可能會(huì)出錯(cuò)，實(shí)際上會(huì)損害工程生產(chǎn)力。 在本節(jié)中，我們將分享七個(gè)在采用早期階段幫助我們的策略：建立具有明確價(jià)值的新服務(wù)單體數(shù)據(jù)存儲(chǔ)被認(rèn)為是有害的解耦“服務(wù)構(gòu)建”和“服務(wù)治理”徹底和一致的可觀察性并非每項(xiàng)新服務(wù)都需要從頭開始構(gòu)建尊重失敗因?yàn)樗鼈儠?huì)發(fā)生從第一天開始就避免使用“微服務(wù)綜合癥”建立具有明確價(jià)值的新服務(wù)有人可能會(huì)認(rèn)為采用新的服務(wù)器架構(gòu)意味著產(chǎn)品開發(fā)的長(zhǎng)時(shí)間停頓以及對(duì)所有內(nèi)容的大量重寫。 這是錯(cuò)誤的做法。 我們永遠(yuǎn)不應(yīng)該為了建立新的服務(wù)而建立新的服務(wù)。 每次我們建立新服務(wù)或采用新技

9、術(shù)時(shí)，都必須具有明確的產(chǎn)品價(jià)值和/或工程價(jià)值。產(chǎn)品價(jià)值應(yīng)以我們可以為用戶提供的利益為代表。 與在單體Node.js應(yīng)用程序中構(gòu)建值相比，需要一項(xiàng)新服務(wù)來(lái)提供值或使其更快地交付值。 工程價(jià)值應(yīng)該使工程團(tuán)隊(duì)更好，更快。如果構(gòu)建新服務(wù)沒有產(chǎn)品價(jià)值或工程價(jià)值，我們將其留在單一的應(yīng)用程序中。 如果十年內(nèi)Medium仍然有一個(gè)支持某些表面的單體Node.js應(yīng)用程序，那就完全沒了問題。 從單一應(yīng)用程序開始實(shí)際上有助于我們戰(zhàn)略性地對(duì)微服務(wù)進(jìn)行建模。單體數(shù)據(jù)存儲(chǔ)被認(rèn)為是有害的構(gòu)建微服務(wù)的很大一部分工作是對(duì)其持久數(shù)據(jù)存儲(chǔ)（例如，數(shù)據(jù)庫(kù)）進(jìn)行建模?？绶?wù)共享持久數(shù)據(jù)存儲(chǔ)通常似乎是將微服務(wù)集成在一起的最簡(jiǎn)單方法，然

10、而，它實(shí)際上是有害的，我們應(yīng)該不惜一切代價(jià)避免它。這就是原因。首先，持久數(shù)據(jù)存儲(chǔ)是關(guān)于實(shí)現(xiàn)細(xì)節(jié)的?？绶?wù)共享數(shù)據(jù)存儲(chǔ)會(huì)將一個(gè)服務(wù)的實(shí)現(xiàn)細(xì)節(jié)暴露給整個(gè)系統(tǒng)。如果該服務(wù)更改了數(shù)據(jù)的格式，或者添加了緩存層，或者切換到不同類型的數(shù)據(jù)庫(kù)，則還必須相應(yīng)地更改許多其他服務(wù)。這違反了松散耦合的原則。其次，持久數(shù)據(jù)存儲(chǔ)不是服務(wù)行為，即如何修改，解釋和使用數(shù)據(jù)。如果我們跨服務(wù)共享數(shù)據(jù)存儲(chǔ)，則意味著其他服務(wù)也必須復(fù)制服務(wù)行為。這違反了高內(nèi)聚的原則 - 給定域中的行為泄露給多個(gè)服務(wù)。如果我們修改一個(gè)行為，我們將不得不一起修改所有這些服務(wù)。在微服務(wù)架構(gòu)中，只有一個(gè)服務(wù)應(yīng)該負(fù)責(zé)特定類型的數(shù)據(jù)。 所有其他服務(wù)應(yīng)該通過負(fù)責(zé)服

11、務(wù)的API請(qǐng)求數(shù)據(jù)，或者保留數(shù)據(jù)的只讀非規(guī)范（可能具體化）副本。這可能聽起來(lái)很抽象，所以這是一個(gè)具體的例子。 假設(shè)我們正在構(gòu)建一個(gè)新的推薦服務(wù)，它需要來(lái)自規(guī)范帖子表的一些數(shù)據(jù)，目前在AWS DynamoDB中。 我們可以通過兩種方式之一為新推薦服務(wù)提供發(fā)布數(shù)據(jù)。在單體存儲(chǔ)模型中，推薦服務(wù)可以直接訪問單體應(yīng)用程序所執(zhí)行的相同持久存儲(chǔ)。這是一個(gè)壞主意，因?yàn)椋壕彺婵赡芎芗?。如果推薦服務(wù)與單體應(yīng)用程序共享相同的緩存，我們也必須在推薦服務(wù)中復(fù)制緩存實(shí)現(xiàn)細(xì)節(jié);如果推薦服務(wù)使用自己的緩存，當(dāng)單體應(yīng)用更新帖子數(shù)據(jù)時(shí)，我們將不知道何時(shí)使其緩存無(wú)效。如果單體應(yīng)用程序決定更改為使用RDS而不是DynamoDB來(lái)存

12、儲(chǔ)帖子數(shù)據(jù)，我們將不得不重新實(shí)現(xiàn)推薦服務(wù)中的邏輯以及訪問帖子數(shù)據(jù)的所有其他服務(wù)。單體應(yīng)用程序具有解釋帖子數(shù)據(jù)的復(fù)雜邏輯，例如，如何確定帖子是否應(yīng)該對(duì)給定用戶不可見。我們必須在推薦服務(wù)中重新實(shí)現(xiàn)這些邏輯。一旦整體應(yīng)用程序更改或添加新邏輯，我們也需要在任何地方進(jìn)行相同的更改。即使推薦服務(wù)是自己的數(shù)據(jù)訪問模式的錯(cuò)誤選項(xiàng)，推薦服務(wù)仍然停留在DynamoDB上。在解耦存儲(chǔ)模型中，推薦服務(wù)不能直接訪問發(fā)布數(shù)據(jù)，也不能直接訪問任何其他新服務(wù)。發(fā)布數(shù)據(jù)的實(shí)現(xiàn)細(xì)節(jié)僅保留在一個(gè)服務(wù)中。有不同的方法來(lái)實(shí)現(xiàn)這一目標(biāo)。理想情況下，應(yīng)該有一個(gè)擁有帖子數(shù)據(jù)的郵政服務(wù)，其他服務(wù)只能通過郵政服務(wù)的API訪問郵政數(shù)據(jù)。但是，為所

13、有核心數(shù)據(jù)模型構(gòu)建新服務(wù)可能是一項(xiàng)昂貴的前期投資。當(dāng)人員配置有限時(shí)，還有一些更實(shí)用的方法。根據(jù)數(shù)據(jù)訪問模式，它們實(shí)際上可能是更好的方式。在選項(xiàng)B中，單一應(yīng)用程序可讓推薦服務(wù)知道何時(shí)更新相關(guān)的帖子數(shù)據(jù)。通常，這不必立即發(fā)生，因此我們可以將其卸載到排隊(duì)系統(tǒng)。在選項(xiàng)C中，ETL管道生成推薦服務(wù)的發(fā)布數(shù)據(jù)的只讀副本，以及可能對(duì)推薦有用的其他數(shù)據(jù)。在這兩個(gè)選項(xiàng)中，推薦服務(wù)完全擁有其數(shù)據(jù)，因此它可以靈活地緩存數(shù)據(jù)或使用最適合的數(shù)據(jù)庫(kù)技術(shù)。解耦“服務(wù)構(gòu)建”和“服務(wù)治理”如果構(gòu)建微服務(wù)很難，那么治理服務(wù)往往更難。 當(dāng)治理服務(wù)與構(gòu)建每個(gè)服務(wù)相結(jié)合時(shí)，它會(huì)減慢工程團(tuán)隊(duì)的速度，團(tuán)隊(duì)必須不斷重新發(fā)明這樣做。 我們希望

14、讓每項(xiàng)服務(wù)都專注于自己的工作而不用擔(dān)心如何運(yùn)行服務(wù)的復(fù)雜問題，包括網(wǎng)絡(luò)，通信協(xié)議，部署，可觀察性等。服務(wù)治理應(yīng)該與每個(gè)服務(wù)的實(shí)現(xiàn)完全分離。將“服務(wù)構(gòu)建”和“服務(wù)治理”分離的策略是使運(yùn)行服務(wù)任務(wù)與服務(wù)技術(shù)無(wú)關(guān)，并且使自己的意見，以便應(yīng)用工程師可以完全專注于每個(gè)服務(wù)自己的業(yè)務(wù)邏輯。由于最近在容器化，容器編排，服務(wù)網(wǎng)格，應(yīng)用程序性能監(jiān)控等方面的技術(shù)進(jìn)步，“服務(wù)治理”的解耦變得比以往更容易實(shí)現(xiàn)。網(wǎng)格化，網(wǎng)格（例如，服務(wù)發(fā)現(xiàn)，路由，負(fù)載平衡，流量路由等）是服務(wù)治理的關(guān)鍵部分。傳統(tǒng)方法是為每種平臺(tái)/語(yǔ)言提供庫(kù)。它工作但不理想，因?yàn)閼?yīng)用程序仍然需要非常繁瑣的工作來(lái)集成和維護(hù)庫(kù)。通常，應(yīng)用程序仍然需要單獨(dú)實(shí)現(xiàn)

15、某些邏輯。現(xiàn)代解決方案是在Service Mesh中運(yùn)行服務(wù)。在Medium，我們使用Istio和Envoy作為sidecar代理。構(gòu)建服務(wù)的應(yīng)用工程師根本不需要擔(dān)心網(wǎng)絡(luò)問題。通信協(xié)議。無(wú)論您選擇哪種技術(shù)堆棧或語(yǔ)言來(lái)構(gòu)建微服務(wù)，從一個(gè)高效，類型化（typed），跨平臺(tái)且需要最少開發(fā)開銷的成熟RPC解決方案開始是非常重要的。支持向后兼容性的RPC解決方案也使部署服務(wù)更加安全，即使它們之間存在依賴關(guān)系。在Medium，我們選擇了gRPC。一個(gè)常見的替代方案是RESTJSON over HTTP，長(zhǎng)期以來(lái)，它一直是服務(wù)器通信的良好解決方案。但是，盡管該堆棧非常適合瀏覽器與服務(wù)器通信，但它對(duì)于服務(wù)器到

16、服務(wù)器的通信效率很低，尤其是當(dāng)我們需要發(fā)送大量請(qǐng)求時(shí)。如果沒有自動(dòng)生成的存根和樣板代碼，我們將不得不手動(dòng)實(shí)現(xiàn)服務(wù)器/客戶端代碼?？煽康腞PC實(shí)現(xiàn)不僅僅包裝網(wǎng)絡(luò)客戶端。另外，REST是“固執(zhí)己見的”，認(rèn)知存在門檻，但總是讓每個(gè)人都對(duì)每個(gè)細(xì)節(jié)都達(dá)成一致很困難，例如，這個(gè)調(diào)用真的是REST，還是只是一個(gè)RPC？這是一種資源還是一種操作，諸如此類！部署。擁有一致的方法來(lái)構(gòu)建，測(cè)試，打包，部署和管理服務(wù)非常重要。所有Medium的微服務(wù)都在容器中運(yùn)行。目前，我們的編排系統(tǒng)是AWS ECS和Kubernetes的混合體，但朝著Kubernetes的方向在走。我們構(gòu)建了自己的系統(tǒng)來(lái)構(gòu)建，測(cè)試，打包和部署服務(wù)

17、，稱為BBFD。它在“跨服務(wù)工作一致性”和“為個(gè)人服務(wù)提供采用不同技術(shù)堆棧的靈活性”之間取得平衡。它的工作方式是讓每個(gè)服務(wù)提供基本信息，例如，要監(jiān)聽的端口，構(gòu)建/測(cè)試/啟動(dòng)服務(wù)的命令等，BBFD將負(fù)責(zé)其余的工作。良好且一致的可觀察性可觀察性包括允許我們了解系統(tǒng)如何工作的過程，約定和工具，以及在不工作時(shí)對(duì)問題進(jìn)行分類?？捎^察性包括日志記錄，性能跟蹤，指標(biāo)，儀表板，警報(bào)，并且對(duì)于微服務(wù)架構(gòu)的成功至關(guān)重要。當(dāng)我們從單個(gè)服務(wù)遷移到具有許多服務(wù)的分布式系統(tǒng)時(shí)，可能會(huì)發(fā)生兩件事：我們失去了可觀察性，因?yàn)樗兊酶y或更容易被忽視。不同的團(tuán)隊(duì)重新發(fā)明了輪子，我們最終得到了零碎的可觀察性，這實(shí)際上是低可觀察性，

18、因?yàn)楹茈y使用碎片數(shù)據(jù)連接點(diǎn)或分類任何問題。從一開始就具有良好且一致的可觀察性非常重要，因此我們的DevOps團(tuán)隊(duì)提出了一致的可觀察性策略，并構(gòu)建了支持實(shí)現(xiàn)這一目標(biāo)的工具。每項(xiàng)服務(wù)都會(huì)自動(dòng)獲取詳細(xì)的DataDog儀表板，警報(bào)和日志搜索，這些服務(wù)在所有服務(wù)中也是一致的。我們還大量使用LightStep來(lái)了解系統(tǒng)的性能。并非每項(xiàng)新服務(wù)都需要從頭開始構(gòu)建在微服務(wù)架構(gòu)中，每個(gè)服務(wù)都做一件事并且做得非常好。請(qǐng)注意，它與如何構(gòu)建服務(wù)無(wú)關(guān)。如果您從單一服務(wù)遷移，請(qǐng)記住，如果您可以從單體應(yīng)用程序中剝離微服務(wù)并不總是必須從頭開始構(gòu)建。在這里，我們采取務(wù)實(shí)的態(tài)度。我們是否應(yīng)該從頭開始構(gòu)建服務(wù)取決于兩個(gè)因素：（1）N

19、ode.js適合該任務(wù)的程度如何;（2）在不同的技術(shù)堆棧中重新實(shí)現(xiàn)的成本是多少。如果Node.js是一個(gè)很好的技術(shù)選項(xiàng)并且現(xiàn)有的實(shí)現(xiàn)很好，我們將代碼從單體應(yīng)用程序中刪除，并用它創(chuàng)建一個(gè)微服務(wù)。即使采用相同的實(shí)現(xiàn)，我們?nèi)詫@得微服務(wù)架構(gòu)的所有好處。我們的Node.js單體應(yīng)用程序的架構(gòu)使我們可以相對(duì)輕松地使用現(xiàn)有實(shí)現(xiàn)構(gòu)建單獨(dú)的服務(wù)。我們將在本文稍后討論如何正確構(gòu)建單體應(yīng)用。尊重失敗，因?yàn)樗麄儠?huì)發(fā)生在分布式環(huán)境中，更多的東西可能會(huì)失敗，而且它們會(huì)失敗。 如果處理不當(dāng)，任務(wù)關(guān)鍵型服務(wù)的失敗可能是災(zāi)難性的。 我們應(yīng)該始終考慮如何測(cè)試故障并優(yōu)雅地處理故障。首先，我們應(yīng)該期待一切都會(huì)在某些時(shí)候失敗。對(duì)于R

20、PC調(diào)用，需要付出額外的努力來(lái)處理故障情況。確保我們?cè)诎l(fā)生故障時(shí)具有良好的可觀察性（如上所述）。在線提供新服務(wù)時(shí)始終測(cè)試失敗。 它應(yīng)該是新服務(wù)檢查列表的一部分。盡可能構(gòu)建自動(dòng)恢復(fù)。從第一天起避免使用微服務(wù)綜合癥微服務(wù)不是靈丹妙藥 - 它解決了一些問題，但創(chuàng)造了一些其他問題，我們將其稱為“微服務(wù)綜合癥”。如果我們從第一天開始就不去考慮它們，那么事情會(huì)變得很快，如果我們以后再照顧它們會(huì)花費(fèi)更多。以下是一些常見癥狀。建模不良的微服務(wù)造成的傷害大于好處，特別是當(dāng)你有超過幾個(gè)時(shí)。允許太多不同的語(yǔ)言/技術(shù)選擇，這會(huì)增加運(yùn)營(yíng)成本并使工程組織分散。將運(yùn)營(yíng)服務(wù)與構(gòu)建服務(wù)相結(jié)合，這大大增加了每項(xiàng)服務(wù)的復(fù)雜性并減慢了團(tuán)隊(duì)的速度。忽略數(shù)據(jù)建模，最終得到具有單體數(shù)據(jù)存儲(chǔ)的微服務(wù)。缺乏可觀察性，這使得難以對(duì)性能問題或故障進(jìn)行分類。當(dāng)遇到問題時(shí)，團(tuán)隊(duì)傾向于創(chuàng)建新服務(wù)而不是修復(fù)現(xiàn)有服務(wù)，即使后者可能是更好的選擇。盡管這些服務(wù)是松散耦合的，但缺乏對(duì)整個(gè)系統(tǒng)的全面了解可能會(huì)有問題。我們應(yīng)該停止構(gòu)建單體服務(wù)嗎？隨著最近的技術(shù)創(chuàng)新，采用微服務(wù)架構(gòu)要容易得多。這是否意味著我們都應(yīng)該停止構(gòu)建單一服務(wù)？雖然新技術(shù)支持得更好，但微服務(wù)架構(gòu)仍然存在高度復(fù)雜性和復(fù)雜性。對(duì)于小型團(tuán)隊(duì)來(lái)說(shuō)，單一的應(yīng)用程序通常仍然是更好的選擇。但是，請(qǐng)花些時(shí)間來(lái)構(gòu)建單體應(yīng)用程序，以便以后在系統(tǒng)和團(tuán)隊(duì)成長(zhǎng)時(shí)