建站
咨詢
售后
建站咨詢
新聞中心
本文將介紹一些微服務(wù)的優(yōu)秀實踐，并提出幫助開發(fā)人員設(shè)計、編排和保護(hù)微服務(wù)架構(gòu)的一些方法。通過了解這些實踐，將為開發(fā)人員成功開發(fā)項目提供幫助。
10年積累的網(wǎng)站設(shè)計制作、成都做網(wǎng)站經(jīng)驗，可以快速應(yīng)對客戶對網(wǎng)站的新想法和需求。提供各種問題對應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識你，你也不認(rèn)識我。但先網(wǎng)站制作后付款的網(wǎng)站建設(shè)流程，更有安丘免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。
微服務(wù)的好處和挑戰(zhàn)
在深入研究微服務(wù)優(yōu)秀實踐之前，應(yīng)該首先了解微服務(wù)的好處和挑戰(zhàn)，以及為什么要使用它們的原因。
簡而言之，微服務(wù)是一種改進(jìn)的軟件架構(gòu)，可以讓開發(fā)人員：
- 更快地部署和擴(kuò)展。更小的應(yīng)用程序域允許自動化，從而實現(xiàn)更快的部署和更快的擴(kuò)展。
- 減少停機(jī)時間。限制不可用服務(wù)對主要業(yè)務(wù)功能的影響，從而提高其整體業(yè)務(wù)的正常運(yùn)行時間。
- 確保可用性。使微服務(wù)之間的功能保持離散，從而限制實例宕機(jī)時的影響。
當(dāng)然采用微服務(wù)擁有這些好處，也會面臨著一系列新的挑戰(zhàn)，其中包括服務(wù)間通信、安全性和可擴(kuò)展性。
- 服務(wù)間通信。對于單體應(yīng)用來說，所有模塊都可以固有地相互通信。因此需要管理一個證書，一旦請求經(jīng)過身份驗證和授權(quán)，就可以毫無問題地遍歷代碼路徑。當(dāng)開發(fā)人員從單體架構(gòu)中提取一個功能到微服務(wù)應(yīng)用程序時，曾經(jīng)的內(nèi)部函數(shù)調(diào)用變成了需要對這個外部微服務(wù)進(jìn)行身份驗證和授權(quán)的外部API調(diào)用。
- 安全層。認(rèn)證和授權(quán)在單體應(yīng)用中，可以在入口處一次性處理。隨著向微服務(wù)的過渡，每個微服務(wù)都需要執(zhí)行一些身份驗證和授權(quán)以強(qiáng)制執(zhí)行訪問控制。但是要求用戶每次使用不同的微服務(wù)都要進(jìn)行登錄是不現(xiàn)實的，因此需要建立一個全面的認(rèn)證策略。
- 可擴(kuò)展性。盡管微服務(wù)允許開發(fā)人員快速擴(kuò)展獨(dú)立功能，但要有效地做到這一點(diǎn)，需要良好的應(yīng)用程序管理甚至更好的工具。可擴(kuò)展性的有效性取決于開發(fā)人員的微服務(wù)編排平臺，以下將更詳細(xì)地進(jìn)行討論。
微服務(wù)的優(yōu)秀實踐
在對微服務(wù)的好處和挑戰(zhàn)的快速概述之后，以下深入研究微服務(wù)的一些優(yōu)秀實踐。這些優(yōu)秀實踐將幫助開發(fā)人員創(chuàng)建一個強(qiáng)大、易于管理、可擴(kuò)展且安全的互通微服務(wù)系統(tǒng)。
1.較小的應(yīng)用程序域
采用微服務(wù)策略需要遵循單一職責(zé)原則。通過限制單一服務(wù)的責(zé)任范圍，可以降低該服務(wù)失敗的負(fù)面影響。如果單個微服務(wù)的責(zé)任太多，發(fā)生故障或不可用將對系統(tǒng)的其余部分產(chǎn)生多米諾骨牌效應(yīng)。
顧名思義，微服務(wù)是微小的服務(wù)，而保持微服務(wù)的應(yīng)用程序域很小，可以專用于一項邏輯功能。如果出現(xiàn)任何問題，這將減少特定的微服務(wù)的影響。此外，較小的服務(wù)更易于維護(hù)，其結(jié)果是更容易更新和更快的開發(fā)。
那么這在實踐中是什么樣子的?例如，假設(shè)微服務(wù)是一個API服務(wù)器，它接受獲取數(shù)據(jù)的請求，并且這些請求必須附帶一個授權(quán)令牌。在剛開始時，這是唯一需要授權(quán)令牌的微服務(wù)。為什么不將身份驗證和令牌生成作為微服務(wù)的一部分?乍一看，其優(yōu)點(diǎn)是活動部件少，管理工作少。
當(dāng)然，開發(fā)人員如果擁有需要授權(quán)令牌的其他服務(wù)，則很快就會發(fā)現(xiàn)原來的微服務(wù)將充當(dāng)API服務(wù)器和身份驗證服務(wù)器。如果API服務(wù)器宕機(jī)，那么其身份驗證服務(wù)器也會隨之宕機(jī)。這樣，所有其他需要授權(quán)令牌的服務(wù)也是如此。
因此考慮未來的發(fā)展，開發(fā)人員需要保持微服務(wù)的微小化。
2.數(shù)據(jù)存儲分離
連接到同一個數(shù)據(jù)庫的多個微服務(wù)本質(zhì)上仍然是一個單體架構(gòu)。單體應(yīng)用只是運(yùn)行在數(shù)據(jù)庫層而不是應(yīng)用層，這使得它同樣脆弱。每個微服務(wù)都應(yīng)該盡可能地?fù)碛凶约旱臄?shù)據(jù)持久層。這不僅確保了與其他微服務(wù)的隔離，而且如果特定數(shù)據(jù)集變得不可用，還可以最大限度地減少影響范圍。
有時，不同的微服務(wù)訪問同一數(shù)據(jù)庫中的數(shù)據(jù)似乎是有意義的。然而，更深入的研究可能會發(fā)現(xiàn)，一個微服務(wù)僅適用于數(shù)據(jù)庫表的子集，而另一個微服務(wù)僅適用于完全不同的數(shù)據(jù)庫表子集。如果這兩個數(shù)據(jù)子集是完全正交的，那么這將是將數(shù)據(jù)庫分離為單獨(dú)服務(wù)的一個很好的例子。這樣，一個服務(wù)依賴于其專用數(shù)據(jù)存儲，并且該數(shù)據(jù)存儲的故障不會影響除該服務(wù)之外的任何服務(wù)。
以文件存儲為例。在采用微服務(wù)架構(gòu)時，不需要單獨(dú)的微服務(wù)使用相同的文件存儲服務(wù)。除非有實際的文件重疊，否則單獨(dú)的微服務(wù)應(yīng)該有單獨(dú)的文件存儲。
這種數(shù)據(jù)分離提高了靈活性。例如，假設(shè)有兩個微服務(wù)都與云計算提供商共享相同的文件存儲服務(wù)。其中一個微服務(wù)經(jīng)常接觸大量文件，但這些文件很小，而另一個微服務(wù)只有幾個定期訪問的文件，但這些文件的大小很大，達(dá)到數(shù)百GB。
對這兩個微服務(wù)使用通用的文件存儲服務(wù)將會降低優(yōu)化成本的靈活性，這是因為同時擁有大文件和小文件以及定期訪問的混合。如果每個微服務(wù)都有自己的數(shù)據(jù)持久層(當(dāng)然可以是一個單獨(dú)的微服務(wù))，那么就可以更靈活地找到更適合該單個微服務(wù)需求的提供者或服務(wù)。
成本優(yōu)化、選項的靈活性以及對可能失敗的單一解決方案的更少依賴，這些都是分離不同微服務(wù)數(shù)據(jù)的原因。
3.溝通渠道
微服務(wù)之間如何溝通需要深思熟慮，特別是在關(guān)注的事件方面。否則，單個不可用的服務(wù)可能導(dǎo)致通信中斷，并可能導(dǎo)致整個應(yīng)用程序崩潰。
例如在一個在線商店的微服務(wù)系統(tǒng)中，一個微服務(wù)接受在網(wǎng)站下的訂單;另一個微服務(wù)向客戶發(fā)送一條文本通知，告知收到了他們的訂單;第三個微服務(wù)通知倉庫發(fā)出產(chǎn)品。最后，第四個微服務(wù)更新庫存計數(shù)。
微服務(wù)之間有兩種通信方式：同步和異步。如果使用同步通信來處理上述示例，Web服務(wù)器可能會通過首先向客戶通知服務(wù)發(fā)送請求來處理新訂單。客戶通知服務(wù)在得到響應(yīng)之后，Web服務(wù)器向倉庫通知服務(wù)發(fā)送請求，然后再次等待響應(yīng)。最后，Web服務(wù)器向庫存更新程序發(fā)送請求。這個同步方法如圖1所示：
圖1 微服務(wù)之間的同步通信
當(dāng)然，在客戶通知服務(wù)發(fā)生故障情況下，通知客戶的請求可能會超時或返回錯誤，或者可能讓W(xué)eb服務(wù)器無限期地等待響應(yīng)。那么倉庫通知服務(wù)可能永遠(yuǎn)不會收到發(fā)送請求。而微服務(wù)之間的同步通信可以創(chuàng)建一個依賴鏈，如果鏈中的任何連接中斷，該鏈就會中斷。
在異步通信中，服務(wù)發(fā)送請求并在不等待響應(yīng)的情況下繼續(xù)發(fā)送。在一種可能的異步方法中，Web服務(wù)器可能會發(fā)送“通知客戶”請求，然后完成其任務(wù)?？蛻敉ㄖ?wù)負(fù)責(zé)通知客戶并向倉庫通知服務(wù)發(fā)送異步請求，倉庫通知服務(wù)負(fù)責(zé)向庫存更新服務(wù)發(fā)送請求。這個示例如圖2所示：
圖2 微服務(wù)之間的鏈?zhǔn)疆惒酵ㄐ?/p>
當(dāng)然在這個模型中，看到異步通信仍然會產(chǎn)生依賴鏈，單個服務(wù)的故障仍然會中斷應(yīng)用程序。
異步通信的一種簡單但有效的方法是采用發(fā)布/訂閱模式。當(dāng)感興趣的事件發(fā)生時，生產(chǎn)者(在本例中為微服務(wù))將該事件的記錄發(fā)布到消息隊列服務(wù)。對此類事件感興趣的任何其他微服務(wù)作為該事件的消費(fèi)者訂閱消息隊列服務(wù)。微服務(wù)只與消息隊列服務(wù)交談和監(jiān)聽，而不是彼此通信。
這個示例如圖3所示：
圖3 消息隊列服務(wù)促進(jìn)異步通信
消息隊列是一個獨(dú)立的服務(wù)，與所有微服務(wù)分離。它負(fù)責(zé)接收已發(fā)布的事件并通知訂閱者發(fā)生的這些事件。這確保了一個微服務(wù)的故障(可能意味著消息延遲傳遞)，但對其他相關(guān)但不關(guān)心的服務(wù)的影響最小。
有很多工具可以完成這種異步通信(例如Kafka或RabbitMQ)。因此需要尋找將這些工具集成為微服務(wù)異步通信主干的方法。
在有些情況下，微服務(wù)之間需要同步通信。大多數(shù)請求-響應(yīng)交互出于必要是同步的。例如，查詢數(shù)據(jù)庫的API服務(wù)器必須等待查詢響應(yīng);獲取緩存數(shù)據(jù)的Web服務(wù)器必須等待鍵值存儲響應(yīng)。
當(dāng)需要同步通信時，開發(fā)人員需要使用開源Kong Gateway來確保其通信快速可靠地路由到正確的微服務(wù)。
4.兼容性
盡可能保持向后兼容性，這樣消費(fèi)者就不會遇到損壞的API。實現(xiàn)這一點(diǎn)的常用方法是遵循路徑級兼容性保證，如/api/v1或/api/v2。任何向后不兼容的更改都會轉(zhuǎn)到新路徑，如/api/v3。
然而，盡管開發(fā)人員作為軟件工程師盡了最大的努力，但有時還是需要棄用API，所以不會一直運(yùn)行它們。使用API網(wǎng)關(guān)請求轉(zhuǎn)換插件，其微服務(wù)可以通過在原始API響應(yīng)旁邊輕松注入棄用通知或附加類似于Kubernetes的“棄用標(biāo)頭”來提醒API使用者。
5.編排微服務(wù)
微服務(wù)的編排是流程和工具成功的關(guān)鍵因素。從技術(shù)上講，開發(fā)人員可以使用systemd和Docker或podman之類的東西在虛擬機(jī)上運(yùn)行容器，但這無法提供與容器編排平臺相同級別的彈性。這會對采用微服務(wù)架構(gòu)帶來的正常運(yùn)行時間和可用性優(yōu)勢產(chǎn)生負(fù)面影響。對于有效的微服務(wù)編排，開發(fā)人員需要依賴經(jīng)過實戰(zhàn)考驗的容器編排平臺;該領(lǐng)域的領(lǐng)導(dǎo)者顯然是Kubernetes。
Kubernetes管理所有容器的配置和部署，同時處理負(fù)載平衡、擴(kuò)展、高可用性副本集和網(wǎng)絡(luò)通信問題。
開發(fā)人員可以在本地部署Kubernetes，也可以在Azure Kubernetes Service、Red Hat OpenShift或Amazon Elastic Kubernetes Service中使用。Kubernetes內(nèi)置的調(diào)度、復(fù)制和網(wǎng)絡(luò)功能使微服務(wù)編排比在傳統(tǒng)操作系統(tǒng)上容易得多。
將Kubernetes與Kuma服務(wù)網(wǎng)格和Kong Ingress Controller結(jié)合使用，就創(chuàng)建了可發(fā)現(xiàn)、受監(jiān)控且具有彈性的微服務(wù)。
6.微服務(wù)安全
隨著應(yīng)用程序包含越來越多的微服務(wù)，確保適當(dāng)?shù)陌踩钥赡軙兊脧?fù)雜。用于執(zhí)行安全策略的集中式系統(tǒng)對于保護(hù)應(yīng)用程序免受惡意用戶、黑客和錯誤代碼的侵害至關(guān)重要。無論是在虛擬機(jī)上還是在Kubernetes上運(yùn)行，Kong都應(yīng)該是開發(fā)人員使用微服務(wù)的安全故事的開始。Kong維護(hù)的大量安全插件可以輕松滿足微服務(wù)的一些最常見的需求，其中包括身份驗證、授權(quán)、流量控制和速率限制。
示例：使用Kong Ingress Controller進(jìn)行速率限制
為了演示工作中的安全插件示例，將部署Kong的速率限制(Rate Limiting)插件，以展示Kong如何防止對應(yīng)用程序的過多入站請求。將使用kind創(chuàng)建一個本地Kubernetes集群，然后按照以下說明部署Kong Ingress控制器。
在創(chuàng)建集群并部署Kong Ingress Controller之后，第一步是設(shè)置速率限制插件?？梢詾椴煌姆秶O(shè)置插件。將使用Kubernetes集群上的默認(rèn)項目作為用例，并將插件范圍限定為默認(rèn)命名空間。
然后為該服務(wù)創(chuàng)建一個“echo服務(wù)”和一個入口。在本例中，采用了Kong的Kubernetes Ingress控制器入門文檔中的示例：
需要做的最后一件事就是測試，將從Kubernetes文檔中借用shell-demo進(jìn)行集群內(nèi)測試：
在進(jìn)入shellpod之前，需要kong-proxy的集群IP：
現(xiàn)在，可以通過shell訪問的pod并測試速率限制：
大多數(shù)云計算提供商不需要使用中間pod來測試速率限制的額外步驟，這為開發(fā)人員提供了開箱即用的負(fù)載均衡器。在這種情況下，由于使用的是kind，因此沒有配置負(fù)載均衡器，而這個測試來自集群內(nèi)部。如果有可用的負(fù)載平衡器，同樣的測試也可以在外部進(jìn)行。
速率限制只是一個例子，說明Kong能夠滿足整體微服務(wù)戰(zhàn)略和優(yōu)秀實踐的安全考慮，并且可以輕松提供全面的解決方案。Kong維護(hù)多個插件和產(chǎn)品，以使通信渠道萬無一失、API更改影響最小化，并使應(yīng)用程序域易于管理。另外，它與大多數(shù)編程語言和供應(yīng)商選項兼容。
7.指標(biāo)和監(jiān)控
基于微服務(wù)的架構(gòu)可能導(dǎo)致數(shù)百或數(shù)千個小型模塊化服務(wù)的大規(guī)模擴(kuò)展。盡管這為提高速度、可用性和覆蓋范圍帶來了巨大潛力，但一個龐大的微服務(wù)系統(tǒng)需要一種戰(zhàn)略性和系統(tǒng)性的監(jiān)控方法。通過密切關(guān)注所有的微服務(wù)，將確保它們能夠正常運(yùn)行，對用戶可用，并正確使用資源。當(dāng)這些期望中的任何一個沒有得到滿足時，可以采取適當(dāng)?shù)男袆觼響?yīng)對。
如今有多種廣泛采用的監(jiān)控解決方案可以無縫集成到基礎(chǔ)設(shè)施中。一些解決方案使用指標(biāo)導(dǎo)出器SDK，可以通過在微服務(wù)中添加一兩行代碼來集成。其他的可以作為插件與API網(wǎng)關(guān)或服務(wù)網(wǎng)格集成，用于監(jiān)控網(wǎng)絡(luò)問題和資源使用情況。
通過監(jiān)控微服務(wù)并清楚地顯示數(shù)字，可以就如何保持微服務(wù)的健康運(yùn)行和可用性做出明智的決策。在這樣做時，將會讓用戶感到滿意。
采用監(jiān)控工具收集指標(biāo)時，可視化工具和儀表盤可以使用這些指標(biāo)，幫助查看微服務(wù)背后的數(shù)字。例如，上周三晚上8點(diǎn)有多少用戶在線?自從發(fā)布這個新特性以來，CPU負(fù)載增加了多少?產(chǎn)品發(fā)貨API和發(fā)票API之間的延遲是多少?
結(jié)語
微服務(wù)是一個令人興奮的旅程。企業(yè)在開始時從更快的部署和可擴(kuò)展性、減少停機(jī)時間以及全面提高業(yè)務(wù)可用性獲得令人難以置信的好處。然后再加入編排平臺，以及一些由Kong及其插件支持的優(yōu)秀實踐，以上只介紹了Kong所能做的一小部分，因此強(qiáng)烈建議查看Kong Hub所有可用的功能，以簡化微服務(wù)之旅。
網(wǎng)站欄目：面向開發(fā)人員的七個微服務(wù)優(yōu)秀實踐
分享鏈接：http://www.dlmjj.cn/article/dpipcid.html
