前言

絕大多數(shù)企業(yè)的軟件架構(gòu)都是從一個單體架構(gòu)開始的，而不是微服務(wù)架構(gòu)。因為單體架構(gòu)足夠簡單、容易上手，不需要復(fù)雜的流程就可以快速開發(fā)應(yīng)用程序。但是伴隨著企業(yè)的成長，單體架構(gòu)的風(fēng)險就會逐漸凸顯出來。在需求量激增的情況下，整個應(yīng)用程序會因為某一部分或者某一進程遇到瓶頸而受到限制。此外，因為單體架構(gòu)的緊耦合設(shè)計，應(yīng)用程序也面臨著可用性上的挑戰(zhàn)，面對日益復(fù)雜的失誤處理幾乎無法持續(xù)擴展，并且在構(gòu)建、部署和測試等流程上都變得非常困難。

然而對企業(yè)來說影響更大的一點是，單體架構(gòu)嚴(yán)重阻礙了創(chuàng)新發(fā)展。

因此，企業(yè)會在發(fā)展過程中逐漸轉(zhuǎn)向微服務(wù)架構(gòu)，將應(yīng)用程序拆分成多個“微”小的服務(wù)運行。這些微服務(wù)都是面向業(yè)務(wù)功能或者某個子領(lǐng)域進行構(gòu)建的，每個微服務(wù)實現(xiàn)一個單獨的功能。微服務(wù)的理念也提倡每個服務(wù)分別由小型的、獨立的團隊進行開發(fā)并負責(zé)管理，所以說這不僅是技術(shù)管理上的更新，更是企業(yè)組織管理上的變革。

但是談?wù)撐⒎?wù)是一回事，能夠真正地落地實施則是另一回事。本文旨在提供關(guān)于這方面的參考，全面地介紹了如何進行微服務(wù)的開發(fā)，并盡可能地從各個維度對其進行描述。從微服務(wù)的架構(gòu)設(shè)計、構(gòu)建、配置、測試、監(jiān)控、安全，到持續(xù)集成/持續(xù)交付(CICD)流水線，本文都進行了積極的探索，并提供了詳細的Go示例代碼進行說明。

另一方面，所有上述內(nèi)容的實現(xiàn)都是結(jié)合Kubernetes完成的。眾所周知，Kubernetes是目前最流行的開源平臺之一，主要用于在集群中自動化應(yīng)用程序容器的編排，包括部署、擴展和維護等。Kubernetes提供了一個以容器為中心的基礎(chǔ)設(shè)施框架，如今你很難找到一項沒有(或者沒有打算)和Kubernetes進行集成的新技術(shù)。除此之外，本文也涉及無服務(wù)器計算和服務(wù)網(wǎng)格這些熱門話題，探討了它們是如何發(fā)揮各自的優(yōu)勢為基于微服務(wù)的系統(tǒng)提供幫助的，并分別通過開源項目Nuclio和Istio進行了具體的說明。

希望讀完本文后，你可以獲得基于Kubernetes與微服務(wù)的云原生系統(tǒng)的設(shè)計、開發(fā)及管理的知識和經(jīng)驗。

目錄

主要內(nèi)容

第1章面向開發(fā)人員的Kubernetes簡介；在本章中，我們帶你進行了一番Kubernetes旋風(fēng)之旅，并了解了它與微服務(wù)的融合。Kubernetes的可擴展架構(gòu)使得大型企業(yè)組織、初創(chuàng)公司和開源組織社區(qū)能夠一起協(xié)作，圍繞Kubernetes創(chuàng)建一個生態(tài)體系，從而擴大收益并確保可持續(xù)發(fā)展。Kubernetes內(nèi)置的概念和抽象非常適合基于微服務(wù)的系統(tǒng)，它們支持軟件開發(fā)生命周期的每個階段——從開發(fā)、測試、部署，一直到監(jiān)控和故障排除。

Minikube項目讓每個開發(fā)人員都能夠在本地運行Kubernetes集群，這非常適合了解Kubernetes自身的功能和特性，并且可以在與生產(chǎn)環(huán)境非常相似的環(huán)境中進行本地測試。

Helm項目是Kubernetes的絕佳補充，作為軟件包管理解決方案為用戶提供了巨大價值。在下一章中，我們將深入研究微服務(wù)領(lǐng)域，并了解為什么微服務(wù)是在云中開發(fā)復(fù)雜、快速迭代的分布式系統(tǒng)的最佳方法。

第2章微服務(wù)入門；本章我們討論了很多問題。首先是微服務(wù)的基本原理——少即是多，以及如何將系統(tǒng)分解為許多小型的、自包含的微服務(wù)來幫助其擴展。我們還討論了使用微服務(wù)架構(gòu)的開發(fā)人員所面臨的挑戰(zhàn)。我們提供了大量關(guān)于構(gòu)建基于微服務(wù)的系統(tǒng)的概念、選項、最佳實踐和實用建議。在這一點上，你應(yīng)該理解微服務(wù)提供的靈活性，但也需要你謹(jǐn)慎選擇使用它們的多種方式。

第3章示例應(yīng)用程序——Delinkcious；

• 3.1技術(shù)需求

• 3.2為什么選擇Go

• 3.3認識Go kit

• 3.4 Delinkcious目錄結(jié)構(gòu)

• 3.5 Delinkcious微服務(wù)

• 3.6數(shù)據(jù)存儲

• 3.7小結(jié)

• 3.8擴展閱讀

第4章構(gòu)建CI/CD流水線；

• 4.1技術(shù)需求

• 4.2理解CI/CD流水線

• 4.3選擇CI/CD流水線工具

• 4.4.1 Jenkins x

• 4.4.2 Spinnaker

• 4.4.3 Travis Cl和CircleCl

• 4.4.4 Tekton

• 4.4.5Argo CD

• 4.4.6自研工具

• 4.4 GitOps

• 4.5使用CircleCI構(gòu)建鏡像

• 4.6為Delinkcious設(shè)置持續(xù)交付

• 4.7小結(jié)

• 4.8擴展閱讀

第5章使用Kubernetes配置微服務(wù)；在本章中，我們討論了與配置有關(guān)的所有內(nèi)容(不包括密鑰管理)。首先是傳統(tǒng)配置方法，然后研究了動態(tài)配置,重點是遠程配置存儲和遠程配置服務(wù)。

接下來，我們討論了Kubernetes特有的一些選項，重點介紹了ConfigMap。我們介紹了創(chuàng)建和管理ConfigMap的方法，還有Pod如何將ConfigMap用作環(huán)境變量(靜態(tài)配置)或者作為文件掛載卷，當(dāng)運維工程師修改相應(yīng)的ConfigMap時，它們會自動更新。最后，我們研究了一些更強大的選項如自定義資源，并討論了服務(wù)發(fā)現(xiàn)這個特殊但非常重要的功能。到目前為止，你應(yīng)該基本理解了配置，并且可以使用傳統(tǒng)的方式或以Kubernetes特有的方式配置微服務(wù)。

第6章Kubernetes與微服務(wù)安全；在本章中，我們認真研究了一個嚴(yán)肅的主題:安全性。基于微服務(wù)的架構(gòu)和Kubernetes對于支持關(guān)鍵任務(wù)目標(biāo)并經(jīng)常管理敏感信息的大型企業(yè)分布式系統(tǒng)來說非常有意義。除了開發(fā)和發(fā)展此類復(fù)雜系統(tǒng)所面臨的挑戰(zhàn)之外，我們還必須意識到，此類系統(tǒng)為攻擊者提供了非常誘人的目標(biāo)。

我們必須使用嚴(yán)格的流程和最佳實踐來保護系統(tǒng)、用戶和數(shù)據(jù)。首先，我們介紹了安全性原則和最佳實踐，并且還看到了它們?nèi)绾蜗嗷ブС郑约癒ubernetes如何致力于應(yīng)用它們來支持我們安全地開發(fā)和維護系統(tǒng)。

我們還討論了作為Kubernetes 上微服務(wù)安全性基礎(chǔ)的支柱:認證/授權(quán)/準(zhǔn)入、集群內(nèi)部和外部的安全通信、強大的密鑰管理(存儲加密和傳輸加密）以及分層安全策略。

此時，你應(yīng)該對安全機制有了清晰的了解，并有足夠的信息來決定如何將它們集成到系統(tǒng)中。安全性是個持續(xù)的話題，但是利用最佳實踐將使你在每個時間點都能在安全性與系統(tǒng)其他要求之間找到適當(dāng)?shù)钠胶狻?/p>

第7章API與負載均衡器；

• 7.1技術(shù)需求

• 7.2熟悉Kubernetes服務(wù)

• 7.3東西流量與南北流量

• 7.4理解ingress和負載均衡器

• 7.5提供和使用公有REST API

• 7.6提供和使用內(nèi)部gRPC API

• 7.7 通過消息隊列發(fā)送和接收事件

• 7.8服務(wù)網(wǎng)格

• 7.9小結(jié)

• 7.10擴展閱讀

第8章有狀態(tài)服務(wù)；

• 8.1技術(shù)需求

• 8.2抽象存儲

• 8.3在Kubernetes集群外存儲數(shù)據(jù)

• 8.4使用Statefulset在Kubernetes集群內(nèi)存儲數(shù)據(jù)

• 8.5通過本地存儲實現(xiàn)高性能

• 8.6在Kubernetes中使用關(guān)系型數(shù)據(jù)庫

• 8.7在Kubernetes中使用非關(guān)系型數(shù)據(jù)存儲

• 8.8小結(jié)

• 8.9擴展閱讀

第9章在Kubernetes上運行Serverless任務(wù)；在本章中，我們介紹并實現(xiàn)了Delinkcious 的鏈接檢查。首先，我們討論了Serverless場景，包括它的兩種常見含義，即不處理實例、節(jié)點或服務(wù)器，使用云函數(shù)服務(wù)。然后，我們在Delinkcious 中實現(xiàn)了一個松耦合的解決方案以進行鏈接檢查，該解決方案利用了我們的NATS消息系統(tǒng)在檢查鏈接時分發(fā)事件。然后，我們介紹了Nuclio，并用它來完成ServerIss函數(shù)的管理，讓 LinkManager 在Serverless函數(shù)上啟動鏈接檢查，并在以后收到通知時可以更新鏈接狀態(tài)。

最后，我們研究了Kubernetes上許多其他Serverless函數(shù)解決方案和框架。此時，你應(yīng)該對Serverless計算和Serverless函數(shù)的內(nèi)容有了深入的了解。你應(yīng)該能夠就你的系統(tǒng)和項目是否可以從Serverless函數(shù)中受益，以及采用哪種解決方案最合適做出明智的決定。顯然，Serverless計算的好處是實實在在的，并且這不是一種曇花一現(xiàn)的時尚。我預(yù)計Kubernetes中的Serverless解決方案最終將會合并到一起(可能圍繞KNative)，并且將成為大多數(shù)Kubernetes部署的基石，即使它們不是核心Kubernetes的一部分。

第10章微服務(wù)測試；在本章中，我們討論了測試的主題及其各種風(fēng)格:單元測試、集成測試和各種端到端測試，我們還深入研究了測試是如何構(gòu)建的。我們演示了鏈接管理器單元測試，添加了一個新的冒煙測試，并引入了Telepresence，以便在本地修改代碼的同時，針對實際的Kubernetes集群加速編輯–測試–調(diào)試生命周期。

然而，測試也是有成本的，一味盲目地添加越來越多的測試并不能使你的系統(tǒng)變得更好或者具有更高的質(zhì)量。在測試的數(shù)量和質(zhì)量之間有許多重要的權(quán)衡，例如開發(fā)和維護測試所需的時間、運行測試所需的時間和資源，以及測試早期發(fā)現(xiàn)的問題的數(shù)量和復(fù)雜性。你應(yīng)該有足夠的環(huán)境來為你的系統(tǒng)做出這些艱難的決定，并選擇最適合你的測試策略。

同樣重要的是要記住測試會隨著系統(tǒng)的發(fā)展而變化，當(dāng)風(fēng)險越來越高時，即使對于同一組織，測試水平也必須要提高。如果你是一個業(yè)余開發(fā)人員，擁有一個測試版產(chǎn)品并且只有幾個非正式的測試用戶，你可能不需要那么嚴(yán)格的測試（除非它能節(jié)省你的開發(fā)時間)。但是，隨著公司的發(fā)展，用戶逐漸聚集，更多的人使用你的產(chǎn)品進行關(guān)鍵任務(wù)應(yīng)用程序，代碼中出現(xiàn)問題產(chǎn)生的影響會促使系統(tǒng)需要更嚴(yán)格的測試。

第11章微服務(wù)部署；

• 11.1技術(shù)需求

• 11.2 Kubernetes部署

• 11.3多環(huán)境部署

• 11.4理解部署策略

• 11.5回滾部署

• 11.6管理版本和依賴

• 11.7本地開發(fā)部署

• 11.8小結(jié)

• 11.9擴展閱讀

第12章監(jiān)控、日志和指標(biāo)；

• 12.1技術(shù)需求

• 12.2 Kubernetes的自愈能力

• 12.3 Kubernetes集群自動伸縮

• 12.4使用Kubernetes供應(yīng)資源

• 12.5正確地優(yōu)化性能

• 12.6日志

• 12.7在Kubernetes上收集指標(biāo)12.8警報

• 12.9分布式跟蹤

• 12.10小結(jié)

• 12.11擴展閱讀

第13章服務(wù)網(wǎng)格與lstio；在本章中，我們討論了服務(wù)網(wǎng)格，并重點介紹了Istio。Istio是一個復(fù)雜的項目，它構(gòu)建在Kubernetes 之上，并使用代理創(chuàng)建了一個影子集群。Istio具有出色的功能，它可以在非常細粒度的級別進行流量整形，還能提供復(fù)雜的認證和授權(quán)、實施高級策略、收集大量信息并幫助集群擴展。

我們介紹了Istio架構(gòu)及其強大的功能，并探討了Delinkcious 如何從這些功能中獲益。然而，想用好Istio一點也不簡單。它創(chuàng)建了大量的自定義資源，并以復(fù)雜的方式擴展了現(xiàn)有的Kubernetes資源(與Kubernetes服務(wù)對應(yīng)的虛擬服務(wù))。

我們還介紹了Istio的替代方案，包括Linkerd 2.0、Envoy、AWS App Mesh和 Consul。此時，你應(yīng)該對服務(wù)網(wǎng)格的好處以及Istio能給你的項目帶來什么幫助有了一個很好的了解。至于是否應(yīng)該立即將Istio集成到你的系統(tǒng)中，還是考慮替代方案之一，或者再觀望一段時間，你可能還需要一些額外的閱讀和實驗，以便做出更明智的決策。

我相信服務(wù)網(wǎng)格尤其是Istio將會變得非常重要，并將成為大型Kubernetes集群的標(biāo)準(zhǔn)最佳實踐。

第14章微服務(wù)和Kubernetes的未來；在本章中，我們討論了微服務(wù)和Kubernetes 接下來的發(fā)展方向。種種跡象表明，微服務(wù)和Kubernetes將繼續(xù)成為設(shè)計、構(gòu)建、發(fā)展和運行云原生、大規(guī)模、分布式系統(tǒng)的主要因素。這是個好消息。小型程序、腳本和移動應(yīng)用程序并不會消失，但后端系統(tǒng)將變得龐大，能夠處理更多的數(shù)據(jù)，并將覆蓋我們生活中的方方面面。虛擬現(xiàn)實、傳感器和人工智能等技術(shù)將需要處理和存儲越來越多的數(shù)據(jù)。

在微服務(wù)領(lǐng)域的短期發(fā)展中,gRPC將成為一種流行的服務(wù)間通信傳輸工具和公共接口。Web客戶端將能夠通過用于Web的gRPC技術(shù)使用gRPC。與REST API相比，GraphQL是另一項重大改進。業(yè)界仍然需要一些時間來理解如何設(shè)計和構(gòu)建基于微服務(wù)的架構(gòu)，構(gòu)建單個微服務(wù)非常簡單，但建立一個協(xié)調(diào)的微服務(wù)系統(tǒng)是另一回事。容器和Kubernetes解決了基于微服務(wù)的架構(gòu)存在的一些難題。服務(wù)網(wǎng)格等新技術(shù)將很快獲得關(guān)注，無服務(wù)器計算幫助開發(fā)人員更快地部署和更新應(yīng)用程序。容器和虛擬化的合并將帶來更安全的系統(tǒng)。Operator將把更大、更有用的構(gòu)建塊管理變成現(xiàn)實。集群聯(lián)邦將成為可擴展系統(tǒng)的新領(lǐng)域。

此時，你應(yīng)該對這些技術(shù)未來的發(fā)展有了自己的認識。這些知識將使你能夠提前計劃，并就當(dāng)前要投資的技術(shù)以及哪些技術(shù)需要進一步成熟做出自己的評估。

簡而言之，我們正處于一個激動人心的新時代的開端，我們將學(xué)習(xí)如何構(gòu)建前所未有的規(guī)模的可靠系統(tǒng)。希望你能夠繼續(xù)努力，掌握這些驚人的技術(shù)，構(gòu)建自己的系統(tǒng)，并為社區(qū)做出自己的貢獻。

【Kubernetes微服務(wù)實戰(zhàn)】剛出版，需要完整版的小伙伴，可以轉(zhuǎn)發(fā)此文關(guān)注小編，私信小編【Kubernetes】來獲取地址！！