前言
絕大多數企業的軟件架構都是從一個單體架構開始的，而不是微服務架構。因爲單體架構足夠簡單、容易上手，不需要複雜的流程就可以快速開發應用程序。但是伴隨着企業的成長，單體架構的風險就會逐漸凸顯出來。在需求量激增的情況下，整個應用程序會因爲某一部分或者某一進程遇到瓶頸而受到限制。此外，因爲單體架構的緊耦合設計，應用程序也面臨着可用性上的挑戰，面對日益複雜的失誤處理幾乎無法持續擴展，並且在構建、部署和測試等流程上都變得非常困難。
然而對企業來說影響更大的一點是，單體架構嚴重阻礙了創新發展。
因此，企業會在發展過程中逐漸轉向微服務架構，將應用程序拆分成多個“微”小的服務運行。這些微服務都是面向業務功能或者某個子領域進行構建的，每個微服務實現一個單獨的功能。微服務的理念也提倡每個服務分別由小型的、獨立的團隊進行開發並負責管理，所以說這不僅是技術管理上的更新，更是企業組織管理上的變革。
但是談論微服務是一回事，能夠真正地落地實施則是另一回事。本文旨在提供關於這方面的參考，全面地介紹瞭如何進行微服務的開發，並儘可能地從各個維度對其進行描述。從微服務的架構設計、構建、配置、測試、監控、安全，到持續集成/持續交付(CICD)流水線，本文都進行了積極的探索，並提供了詳細的Go示例代碼進行說明。
另一方面，所有上述內容的實現都是結合Kubernetes完成的。衆所周知，Kubernetes是目前最流行的開源平臺之一，主要用於在集羣中自動化應用程序容器的編排，包括部署、擴展和維護等。Kubernetes提供了一個以容器爲中心的基礎設施框架，如今你很難找到一項沒有(或者沒有打算)和Kubernetes進行集成的新技術。除此之外，本文也涉及無服務器計算和服務網格這些熱門話題，探討了它們是如何發揮各自的優勢爲基於微服務的系統提供幫助的，並分別通過開源項目Nuclio和Istio進行了具體的說明。
希望讀完本文後，你可以獲得基於Kubernetes與微服務的雲原生系統的設計、開發及管理的知識和經驗。
目錄
主要內容
第1章面向開發人員的Kubernetes簡介；在本章中，我們帶你進行了一番Kubernetes旋風之旅，並瞭解了它與微服務的融合。Kubernetes的可擴展架構使得大型企業組織、初創公司和開源組織社區能夠一起協作，圍繞Kubernetes創建一個生態體系，從而擴大收益並確保可持續發展。Kubernetes內置的概念和抽象非常適合基於微服務的系統，它們支持軟件開發生命週期的每個階段——從開發、測試、部署，一直到監控和故障排除。
Minikube項目讓每個開發人員都能夠在本地運行Kubernetes集羣，這非常適合瞭解Kubernetes自身的功能和特性，並且可以在與生產環境非常相似的環境中進行本地測試。
Helm項目是Kubernetes的絕佳補充，作爲軟件包管理解決方案爲用戶提供了巨大價值。在下一章中，我們將深入研究微服務領域，並瞭解爲什麼微服務是在雲中開發複雜、快速迭代的分佈式系統的最佳方法。
第2章微服務入門；本章我們討論了很多問題。首先是微服務的基本原理——少即是多，以及如何將系統分解爲許多小型的、自包含的微服務來幫助其擴展。我們還討論了使用微服務架構的開發人員所面臨的挑戰。我們提供了大量關於構建基於微服務的系統的概念、選項、最佳實踐和實用建議。在這一點上，你應該理解微服務提供的靈活性，但也需要你謹慎選擇使用它們的多種方式。
第3章示例應用程序——Delinkcious；
3.1技術需求
3.2爲什麼選擇Go
3.3認識Go kit
3.4 Delinkcious目錄結構
3.5 Delinkcious微服務
3.6數據存儲
3.7小結
3.8擴展閱讀
第4章構建CI/CD流水線；
4.1技術需求
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構建鏡像
4.6爲Delinkcious設置持續交付
4.7小結
4.8擴展閱讀
第5章使用Kubernetes配置微服務；在本章中，我們討論了與配置有關的所有內容(不包括密鑰管理)。首先是傳統配置方法，然後研究了動態配置,重點是遠程配置存儲和遠程配置服務。
接下來，我們討論了Kubernetes特有的一些選項，重點介紹了ConfigMap。我們介紹了創建和管理ConfigMap的方法，還有Pod如何將ConfigMap用作環境變量(靜態配置)或者作爲文件掛載卷，當運維工程師修改相應的ConfigMap時，它們會自動更新。最後，我們研究了一些更強大的選項如自定義資源，並討論了服務發現這個特殊但非常重要的功能。到目前爲止，你應該基本理解了配置，並且可以使用傳統的方式或以Kubernetes特有的方式配置微服務。
第6章Kubernetes與微服務安全；在本章中，我們認真研究了一個嚴肅的主題:安全性。基於微服務的架構和Kubernetes對於支持關鍵任務目標並經常管理敏感信息的大型企業分佈式系統來說非常有意義。除了開發和發展此類複雜系統所面臨的挑戰之外，我們還必須意識到，此類系統爲攻擊者提供了非常誘人的目標。
我們必須使用嚴格的流程和最佳實踐來保護系統、用戶和數據。首先，我們介紹了安全性原則和最佳實踐，並且還看到了它們如何相互支持，以及Kubernetes如何致力於應用它們來支持我們安全地開發和維護系統。
我們還討論了作爲Kubernetes 上微服務安全性基礎的支柱:認證/授權/准入、集羣內部和外部的安全通信、強大的密鑰管理(存儲加密和傳輸加密）以及分層安全策略。
此時，你應該對安全機制有了清晰的瞭解，並有足夠的信息來決定如何將它們集成到系統中。安全性是個持續的話題，但是利用最佳實踐將使你在每個時間點都能在安全性與系統其他要求之間找到適當的平衡。
第7章API與負載均衡器；
7.1技術需求
7.2熟悉Kubernetes服務
7.3東西流量與南北流量
7.4理解ingress和負載均衡器
7.5提供和使用公有REST API
7.6提供和使用內部gRPC API
7.7 通過消息隊列發送和接收事件
7.8服務網格
7.9小結
7.10擴展閱讀
第8章有狀態服務；
8.1技術需求
8.2抽象存儲
8.3在Kubernetes集羣外存儲數據
8.4使用Statefulset在Kubernetes集羣內存儲數據
8.5通過本地存儲實現高性能
8.6在Kubernetes中使用關係型數據庫
8.7在Kubernetes中使用非關係型數據存儲
8.8小結
8.9擴展閱讀
第9章在Kubernetes上運行Serverless任務；在本章中，我們介紹並實現了Delinkcious 的鏈接檢查。首先，我們討論了Serverless場景，包括它的兩種常見含義，即不處理實例、節點或服務器，使用雲函數服務。然後，我們在Delinkcious 中實現了一個松耦合的解決方案以進行鏈接檢查，該解決方案利用了我們的NATS消息系統在檢查鏈接時分發事件。然後，我們介紹了Nuclio，並用它來完成ServerIss函數的管理，讓 LinkManager 在Serverless函數上啓動鏈接檢查，並在以後收到通知時可以更新鏈接狀態。
最後，我們研究了Kubernetes上許多其他Serverless函數解決方案和框架。此時，你應該對Serverless計算和Serverless函數的內容有了深入的瞭解。你應該能夠就你的系統和項目是否可以從Serverless函數中受益，以及採用哪種解決方案最合適做出明智的決定。顯然，Serverless計算的好處是實實在在的，並且這不是一種曇花一現的時尚。我預計Kubernetes中的Serverless解決方案最終將會合併到一起(可能圍繞KNative)，並且將成爲大多數Kubernetes部署的基石，即使它們不是核心Kubernetes的一部分。
第10章微服務測試；在本章中，我們討論了測試的主題及其各種風格:單元測試、集成測試和各種端到端測試，我們還深入研究了測試是如何構建的。我們演示了鏈接管理器單元測試，添加了一個新的冒煙測試，並引入了Telepresence，以便在本地修改代碼的同時，針對實際的Kubernetes集羣加速編輯–測試–調試生命週期。
然而，測試也是有成本的，一味盲目地添加越來越多的測試並不能使你的系統變得更好或者具有更高的質量。在測試的數量和質量之間有許多重要的權衡，例如開發和維護測試所需的時間、運行測試所需的時間和資源，以及測試早期發現的問題的數量和複雜性。你應該有足夠的環境來爲你的系統做出這些艱難的決定，並選擇最適合你的測試策略。
同樣重要的是要記住測試會隨着系統的發展而變化，當風險越來越高時，即使對於同一組織，測試水平也必須要提高。如果你是一個業餘開發人員，擁有一個測試版產品並且只有幾個非正式的測試用戶，你可能不需要那麼嚴格的測試（除非它能節省你的開發時間)。但是，隨着公司的發展，用戶逐漸聚集，更多的人使用你的產品進行關鍵任務應用程序，代碼中出現問題產生的影響會促使系統需要更嚴格的測試。
第11章微服務部署；
11.1技術需求
11.2 Kubernetes部署
11.3多環境部署
11.4理解部署策略
11.5回滾部署
11.6管理版本和依賴
11.7本地開發部署
11.8小結
11.9擴展閱讀
第12章監控、日誌和指標；
12.1技術需求
12.2 Kubernetes的自愈能力
12.3 Kubernetes集羣自動伸縮
12.4使用Kubernetes供應資源
12.5正確地優化性能
12.6日誌
12.7在Kubernetes上收集指標12.8警報
12.9分佈式跟蹤
12.10小結
12.11擴展閱讀
第13章服務網格與lstio；在本章中，我們討論了服務網格，並重點介紹了Istio。Istio是一個複雜的項目，它構建在Kubernetes 之上，並使用代理創建了一個影子集羣。Istio具有出色的功能，它可以在非常細粒度的級別進行流量整形，還能提供複雜的認證和授權、實施高級策略、收集大量信息並幫助集羣擴展。
我們介紹了Istio架構及其強大的功能，並探討了Delinkcious 如何從這些功能中獲益。然而，想用好Istio一點也不簡單。它創建了大量的自定義資源，並以複雜的方式擴展了現有的Kubernetes資源(與Kubernetes服務對應的虛擬服務)。
我們還介紹了Istio的替代方案，包括Linkerd 2.0、Envoy、AWS App Mesh和 Consul。此時，你應該對服務網格的好處以及Istio能給你的項目帶來什麼幫助有了一個很好的瞭解。至於是否應該立即將Istio集成到你的系統中，還是考慮替代方案之一，或者再觀望一段時間，你可能還需要一些額外的閱讀和實驗，以便做出更明智的決策。
我相信服務網格尤其是Istio將會變得非常重要，並將成爲大型Kubernetes集羣的標準最佳實踐。
第14章微服務和Kubernetes的未來；在本章中，我們討論了微服務和Kubernetes 接下來的發展方向。種種跡象表明，微服務和Kubernetes將繼續成爲設計、構建、發展和運行雲原生、大規模、分佈式系統的主要因素。這是個好消息。小型程序、腳本和移動應用程序並不會消失，但後端系統將變得龐大，能夠處理更多的數據，並將覆蓋我們生活中的方方面面。虛擬現實、傳感器和人工智能等技術將需要處理和存儲越來越多的數據。
在微服務領域的短期發展中,gRPC將成爲一種流行的服務間通信傳輸工具和公共接口。Web客戶端將能夠通過用於Web的gRPC技術使用gRPC。與REST API相比，GraphQL是另一項重大改進。業界仍然需要一些時間來理解如何設計和構建基於微服務的架構，構建單個微服務非常簡單，但建立一個協調的微服務系統是另一回事。容器和Kubernetes解決了基於微服務的架構存在的一些難題。服務網格等新技術將很快獲得關注，無服務器計算幫助開發人員更快地部署和更新應用程序。容器和虛擬化的合併將帶來更安全的系統。Operator將把更大、更有用的構建塊管理變成現實。集羣聯邦將成爲可擴展系統的新領域。
此時，你應該對這些技術未來的發展有了自己的認識。這些知識將使你能夠提前計劃，並就當前要投資的技術以及哪些技術需要進一步成熟做出自己的評估。
簡而言之，我們正處於一個激動人心的新時代的開端，我們將學習如何構建前所未有的規模的可靠系統。希望你能夠繼續努力，掌握這些驚人的技術，構建自己的系統，併爲社區做出自己的貢獻。
【Kubernetes微服務實戰】剛出版，需要完整版的小夥伴，可以轉發此文關注小編，私信小編【Kubernetes】來獲取地址！！