微服務(wù)架構(gòu)是一種架構(gòu)風(fēng)格，一個(gè)大型復(fù)雜軟件應(yīng)用由多個(gè)微服務(wù)架構(gòu)組成。系統(tǒng)中的各個(gè)微服務(wù)架構(gòu)可被獨(dú)立部署，各個(gè)微服務(wù)架構(gòu)之間是松耦合的。每個(gè)微服務(wù)架構(gòu)僅關(guān)注于完成一項(xiàng)任務(wù)并很好地完成該任務(wù)。在所有情況下，每項(xiàng)任務(wù)代表著一個(gè)小的業(yè)務(wù)能力。

隨著人們轉(zhuǎn)向云原生策略，我們需要一個(gè)支持它的架構(gòu)。作為面向服務(wù)架構(gòu)的一種變體，微服務(wù)架構(gòu)有助于數(shù)字世界中的服務(wù)多樣化。

企業(yè)不能忽視的 3 大微服務(wù)架構(gòu)優(yōu)勢(shì)

1.微服務(wù)架構(gòu)的自動(dòng)化部署
微服務(wù)架構(gòu)中，系統(tǒng)會(huì)被拆分為若干個(gè)微服務(wù)架構(gòu)，每個(gè)微服務(wù)架構(gòu)又是一個(gè)獨(dú)立的應(yīng)用程序。單體架構(gòu)中的應(yīng)用程序只需要部署一次，而微服務(wù)架構(gòu)中有多少服務(wù)就需要部署多少次。隨著服務(wù)數(shù)量的增加，部署的難度就會(huì)增加。業(yè)務(wù)的粒度劃分得越細(xì)，微服務(wù)架構(gòu)的數(shù)量就越多。因此就出現(xiàn)了自動(dòng)化部署技術(shù)，例如Docker容器自動(dòng)化部署技術(shù)方便了微服務(wù)架構(gòu)項(xiàng)目下各模塊在服務(wù)器上的部署。

2.服務(wù)集中化管理
微服務(wù)架構(gòu)系統(tǒng)是按照業(yè)務(wù)單元來劃分的，服務(wù)數(shù)量越多，管理起來越復(fù)雜。在這里，微服務(wù)架構(gòu)提供了集中化管理組件Spring Cloud Config，人們可以在Spring Cloud Config配置文件中統(tǒng)一配置服務(wù)，這樣很大程度上方便了對(duì)項(xiàng)目的集中化管理。

3.支持熔斷機(jī)制
微服務(wù)架構(gòu)就是分布式的。在分布式系統(tǒng)中，服務(wù)之間是相互依賴的，如果一個(gè)服務(wù)出現(xiàn)了故障或者網(wǎng)絡(luò)延遲，在高并發(fā)的情況下，就會(huì)導(dǎo)致線程阻塞，在很短的時(shí)間內(nèi)該服務(wù)的線程資源會(huì)消耗殆盡，最終使得該服務(wù)不可用。

微服務(wù)架構(gòu)主要受益于此，因?yàn)槁氊?zé)分工要容易得多。
構(gòu)建單個(gè)服務(wù)在理論上可能聽起來很簡單，但實(shí)際上要復(fù)雜得多。當(dāng)我們將應(yīng)用程序分解為單個(gè)服務(wù)時(shí)，如果有一個(gè)龐大的團(tuán)隊(duì)構(gòu)建單個(gè)服務(wù)，事情就會(huì)變得更順利。

微服務(wù)架構(gòu)的挑戰(zhàn)
1. 技術(shù)多樣性
微服務(wù)架構(gòu)的主要優(yōu)勢(shì)之一是在開發(fā)單個(gè)服務(wù)時(shí)可以靈活地使用各種技術(shù)基礎(chǔ)。這意味著工程團(tuán)隊(duì)必須維護(hù)多種工具來維護(hù)這些微服務(wù)，只是因?yàn)槊總€(gè)服務(wù)使用不同的技術(shù)。

在這里，每個(gè)微服務(wù)組件都不同，不是因?yàn)槿魏渭夹g(shù)要求，而是基于開發(fā)人員的個(gè)人喜好。這不僅在開發(fā)人員切換團(tuán)隊(duì)時(shí)成為技能問題，而且在應(yīng)用程序進(jìn)入維護(hù)模式時(shí)會(huì)縮減所有操作。突然之間，鑒于技術(shù)的多樣性，我們需要更多的人力和資源來維護(hù)應(yīng)用程序。

從財(cái)務(wù)角度來看，它在維護(hù)技能和運(yùn)行時(shí)資源方面都涉及更多成本。

2. 復(fù)雜系統(tǒng)通信
基于微服務(wù)的架構(gòu)強(qiáng)制執(zhí)行模塊化結(jié)構(gòu)，其中應(yīng)用程序被分解為多個(gè)獨(dú)立部署的微服務(wù)。區(qū)別就在這里——當(dāng)我們使用單體架構(gòu)時(shí)，所有的依賴關(guān)系都被隱藏并編碼在組件之間的依賴關(guān)系規(guī)則中。

在微服務(wù)架構(gòu)中，所有這些依賴項(xiàng)都必須在基礎(chǔ)架構(gòu)配置中進(jìn)行編碼（引入基礎(chǔ)架構(gòu)即代碼的概念）。這包括基礎(chǔ)設(shè)施的維護(hù)和配置。

需要注意的另一點(diǎn)是，在單體應(yīng)用中，通信是作為內(nèi)存調(diào)用發(fā)生的，而在談?wù)撐⒎?wù)時(shí)，通信在進(jìn)程之間移動(dòng)，可能通過網(wǎng)絡(luò)進(jìn)行。這帶來了新的挑戰(zhàn)，例如延遲和速度損失。假設(shè)我們循環(huán)調(diào)用遠(yuǎn)程微服務(wù)；它會(huì)在每次循環(huán)迭代時(shí)增加延遲，使服務(wù)調(diào)用無法使用。

這個(gè)問題的一個(gè)可能的解決方案是，如果我們以一種避免服務(wù)調(diào)用循環(huán)的方式設(shè)計(jì)我們的服務(wù)。

3. 遷移
如果您已經(jīng)考慮遷移到微服務(wù)架構(gòu)，那么您正計(jì)劃遷移現(xiàn)有的單體應(yīng)用程序，將每個(gè)域分解為新服務(wù)。

當(dāng)我們知道基于微服務(wù)的架構(gòu)強(qiáng)制執(zhí)行模塊化結(jié)構(gòu)時(shí)，我們必須在將單體分解為新的單個(gè)組件時(shí)引入新的連接及其依賴關(guān)系。現(xiàn)在從傳統(tǒng)應(yīng)用程序調(diào)用微服務(wù)可能有點(diǎn)麻煩。為什么？因?yàn)槿鄙偈聞?wù)管理可能會(huì)出現(xiàn)一些問題，因?yàn)樗鼈兌荚趩误w應(yīng)用程序中交織在一起。

何時(shí)使用微服務(wù)架構(gòu)？
當(dāng)您想要適應(yīng)可擴(kuò)展性、敏捷性和可管理性時(shí)，您想要縮短上市時(shí)間。
如果您打算使用當(dāng)今的編程語言或技術(shù)堆棧重寫您的遺留應(yīng)用程序，以跟上當(dāng)前的市場(chǎng)需求和解決方案。
有許多獨(dú)立的業(yè)務(wù)軟件組件可以跨多個(gè)渠道重用，例如登錄服務(wù)、身份驗(yàn)證設(shè)施、搜索選項(xiàng)等。
如果您計(jì)劃不時(shí)使用新功能更新您的應(yīng)用程序，并且還需要靈活地刪除過時(shí)或不太喜歡的部分。

什么時(shí)候不使用微服務(wù)架構(gòu)？
我們都知道基于微服務(wù)的架構(gòu)強(qiáng)制執(zhí)行模塊化結(jié)構(gòu)。然而，真正的問題是每個(gè)應(yīng)用程序是否都需要分解為模塊/片段/微服務(wù)。

如果您的應(yīng)用程序不復(fù)雜，則不適合。進(jìn)一步詳細(xì)說明，您不打算添加新功能；沒有太多可試驗(yàn)的東西，您的功能或產(chǎn)品始終保持不變，等等。
如果您沒有相當(dāng)熟練的團(tuán)隊(duì)規(guī)模精通各種編程語言或技術(shù)堆棧，則很有可能會(huì)導(dǎo)致高成本以及頻繁和延長的停機(jī)時(shí)間。
有些應(yīng)用程序不需要分解成更簡單的模塊。重要的是要知道哪些應(yīng)用程序在分解時(shí)性能更好，以及何時(shí)將它們放在一起更好。這是構(gòu)建無縫產(chǎn)品體驗(yàn)的第一步。

軟件架構(gòu)風(fēng)格推動(dòng)產(chǎn)品發(fā)揮其全部潛力。這不是要遵循任何架構(gòu)模式的規(guī)則并根據(jù)樣式進(jìn)行構(gòu)建。這更像是一次了解我們?nèi)绾问刮覀兊姆?wù)交付無縫的旅程。如果您認(rèn)為您的產(chǎn)品交付能力可以通過微服務(wù)架構(gòu)得到放大，那么您應(yīng)該這樣做。今天，我們看到許多企業(yè)級(jí)托管微服務(wù)平臺(tái)出現(xiàn)在市場(chǎng)上。借助這些平臺(tái)，DevOps 團(tuán)隊(duì)可以跨環(huán)境管理和部署微服務(wù)。確保微服務(wù)可投入生產(chǎn)，以縮短上市時(shí)間、增強(qiáng)應(yīng)用穩(wěn)定性并增強(qiáng)應(yīng)用安全性。