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