目錄
什么是云原生？
云原生之前
云原生
云原生簡介
微服務
DevOps
持續交付
容器化
云原生的發展歷程
云原生技術生態現狀
云原生基金會 —— CNCF
云原生技術社區
云原生技術產業
我們正處于時代的關鍵節點
2019 年，云原生技術普及元年
云原生代表技術
“12要素”
基準代碼
依賴
配置
后端服務
構建、發布、運行
進程
端口綁定
并發
易處理
環境等價
日志
管理進程
云原生應用的邏輯依賴關系
技術的趨勢和影響
軟件生命周期維度看云原生
微軟的 Azure 計算服務架構
Completing the picture
參考資料
Kotlin 開發者社區
容器化包裝：軟件應用的進程應該包裝在容器中獨立運行。
動態管理：通過集中式的編排調度系統來動態的管理和調度。
微服務化：明確服務間的依賴，互相解耦。
https://dzone.com/articles/cloud-native-seeing-through-the-hype
云原生準確來說是一種文化，更是一種潮流，它是云計算的一個必然導向。意義在于讓云成為云化戰略成功的基石，而不是障礙。
FaaS Landscape
Service Mesh 的思路，體現在將 SDK 客戶端的功能剝離出來，放到 Sidecar 中。通過這種方式，實現應用的輕量化。此時絕大部分的功能都在剝離，應用中只留下一個輕量級的客戶端。這個輕量級客戶端中還保留有少數功能和信息，比如目標服務的標識（指出要調用的目標），序列化的實現。
Cloud Native 翻譯為云原生，是Matt Stine提出的一個概念，它是一個思想的集合，包括DevOps、持續交付（Continuous Delivery）、微服務（MicroServices）、敏捷基礎設施（Agile Infrastructure）、康威定律（Conways Law）等，以及根據商業能力對公司進行重組。Cloud Native既包含技術（微服務，敏捷基礎設施），也包含管理（DevOps，持續交付，康威定律，重組等）。Cloud Native也可以說是一系列Cloud技術、企業管理方法的集合。
Cloud Native是更好的工具、自我修復系統、和自動化系統的集合，可以讓應用和基礎設施的部署和故障修復更加快速和敏捷，極大的降低企業在云計算方面的部署成本。
目前業界公認的云原生主要包括以下幾個層面的內容。
容器，服務網格，微服務，不可變的基礎設施，公開的API都接近云原生相關概念。
云原生技術可以讓系統松耦合，支持彈性伸縮、可管理的、清晰的。通過整合健壯且有效的自動化，工程師可以用很少的勞動來完成頻繁的、預期中的高危代碼修改。
微服務解決的是我們軟件開發中一直追求的低耦合+高內聚，記得有一次我們系統的接口出了問題，結果影響了用戶的前臺操作，于是黎叔拍案而起，靈魂發問：“為啥這兩個會互相影響？！”
微服務可以解決這個問題，微服務的本質是把一塊大餅分成若干塊低耦合的小餅，比如一塊小餅專門負責接收外部的數據，一塊小餅專門負責響應前臺的操作，小餅可以進一步拆分，比如負責接收外部數據的小餅可以繼續分成多塊負責接收不同類型數據的小餅，這樣每個小餅出問題了，其它小餅還能正常對外提供服務。
隨著微服務化架構的優勢展現和快速發展，2013年，MartinFlower對微服務概念進行了比較系統的理論闡述，總結了相關的技術特征。首先，微服務是一種架構風格，也是一種服務；其次，微服務的顆粒比較小，一個大型復雜軟件應用由多個微服務組成，比如Netflix目前由500多個的微服務組成；最后，它采用UNIX設計的哲學，每種服務只做一件事，是一種松耦合的能夠被獨立開發和部署的無狀態化服務（獨立擴展、升級和可替換）。微服務架構如圖1-8所示。
圖： 微服務架構示例
由微服務的定義分析可知，一個微服務基本是一個能獨立發布的應用服務，因此可以作為獨立組件升級、灰度或復用等，對整個大應用的影響也較小，每個服務可以由專門的組織來單獨完成，依賴方只要定好輸入和輸出口即可完全開發，甚至整個團隊的組織架構也會更精簡，因此溝通成本低、效率高。根據業務的需求，不同的服務可以根據業務特性進行不同的技術選型，是計算密集型還是I/O密集型應用都可以依賴不同的語言編程模型，各團隊可以根據本身的特色獨自運作。服務在壓力較大時，也可以有更多容錯或限流服務。
微服務架構確實有很多吸引人的地方，然而它的引入也是有成本的，它并不是銀彈，使用它會引入更多技術挑戰，比如性能延遲、分布式事務、集成測試、故障診斷等方面，企業需要根據業務的不同的階段進行合理的引入，不能完全為了微服務而“微服務”
DevOps的意思就是開發和運維不再是分開的兩個團隊，而是你中有我，我中有你的一個團隊。我們現在開發和運維已經是一個團隊了，但是運維方面的知識和經驗還需要持續提高。
DevOps如果從字面上來理解只是Dev（開發人員）+Ops（運維人員），實際上，它是一組過程、方法與系統的統稱，其概念從2009年首次提出發展到現在，內容也非常豐富，有理論也有實踐，包括組織文化、自動化、精益、反饋和分享等不同方面。首先，組織架構、企業文化與理念等，需要自上而下設計，用于促進開發部門、運維部門和質量保障部門之間的溝通、協作與整合，簡單而言組織形式類似于系統分層設計。其次，自動化是指所有的操作都不需要人工參與，全部依賴系統自動完成，比如上述的持續交付過程必須自動化才有可能完成快速迭代。再次，DevOps的出現是由于軟件行業日益清晰地認識到，為了按時交付軟件產品和服務，開發部門和運維部門必須緊密合作。總之，DevOps強調的是高效組織團隊之間如何通過自動化的工具協作和溝通來完成軟件的生命周期管理，從而更快、更頻繁地交付更穩定的軟件。如圖所示，
圖 DevOps強調組織的溝通與協作
持續交付的意思就是在不影響用戶使用服務的前提下頻繁把新功能發布給用戶使用，要做到這點非常非常難。我們現在兩周一個版本，每次上線之后都會給不同的用戶造成不同程度的影響。
它更多是代表一種軟件交付的能力，過程示例請參考圖：
圖 持續交付流程
容器化的好處在于運維的時候不需要再關心每個服務所使用的技術棧了，每個服務都被無差別地封裝在容器里，可以被無差別地管理和維護，現在比較流行的工具是docker和k8s。
基于虛擬機技術，陸續出現了 IaaS/PaaS/FaaS 等形態，以及他們的開源版本。
2013 年 docker 出現，容器技術成熟，然后圍繞容器編排一場大戰，最后在 2017 年底，kubernetes 勝出。2015 年 CNCF 成立，并在近年形成了 cloud native 生態。
云原生（Cloud Native）最初來描述云上應用的典型架構與特性，隨著容器、kubernetes、Serverless、FaaS技術的演進，CNCF（Cloud Native Computing Foundation ，云原生計算基金會）把云原生的概念更廣泛地定義為“讓應用更有彈性、容錯性、觀測性的基礎技術，讓應用更容易部署、管理的基礎軟件、讓應用更容易編寫、編排的運行框架等”，希望能夠讓開發者最好的利用云的資源、產品和交付能力。
下邊大致梳理一下云原生的發展過程。
2004 年 ~ 2007 年，Google 已在內部大規模地使用像 Cgroups 這樣的容器技術；
2008 年，Google 將 Cgroups 合并進入了 Linux 內核主干。
2013 年，Docker 項目正式發布。
2014 年，Kubernetes 項目也正式發布。
2015 年，CNCF 成立。
2017 年，CNCF 達到 170 個成員和 14 個基金項目。
2018 年，CNCF 成立三周年有了 195 個成員，19 個基金會項目和 11 個孵化項目，如此之快的發展速度在整個云計算領域都是非常罕見的。
2014 年 Kubernetes 項目發布的原因也非常容易理解，因為有了容器和 Docker 之后，就需要有一種方式去幫助大家方便、快速、優雅地管理這些容器，這就是 Kubernetes 項目的初衷。在 Google 和 Redhat 發布了 Kubernetes 之后，這個項目的發展速度非常之快。
2015 年由 Google、Redhat 以及微軟等大型云計算廠商以及一些開源公司共同牽頭成立了 CNCF 云原生基金會。CNCF 成立之初，就有 22 個創始會員，而且 Kubernetes 也成為了 CNCF 托管的第一個開源項目。在這之后，CNCF 的發展速度非常迅猛。
因此，如今我們所討論的云原生技術生態是一個龐大的技術集合。CNCF 有一張云原生全景圖（https://github.com/cncf/landscape），在這個全景圖里已經有 200 多個項目和產品了，這些項目和產品也都是和 CNCF 的觀點所契合的。所以如果以這張全景圖作為背景，加以思考就會發現，我們今天所討論的云原生其實主要談論了以下幾點：
CNCF 是目前云計算領域最成功的開源基金會之一，是 Kubernetes、 etcd、Envoy 等知名開源項目的托管基金會。
云原生技術社區，比如像 CNCF 目前正式托管的 20 多個項目共同構成了現代云計算生態的基石，其中像 Kubernetes 這樣的項目已經成為了世界第四活躍的開源項目；目前從 CNCF 畢業的項目以及有 6 個，分別是 Kubernetes 、Prometheus、Envoy、CoreDNS、containerd、Fluentd 。
除了前面兩點之外，現在全球各大公有云廠商都已經支持了 Kubernetes。此外，還有 100 多家技術創業公司也在持續地進行投入。現在阿里巴巴也在談全面上云，而且上云就要上云原生，這也是各大技術公司擁抱云原生的一個例子。
2019 年正是云原生時代的關鍵節點，為什么這么說？我們這里就為大家簡單梳理一下。
從 2013 年 Docker 項目發布開始說起，Docker 項目的發布使得全操作系統語義的沙盒技術唾手可得，使得用戶能夠更好地、更完整地打包自己的應用，使得開發者可以輕而易舉的獲得了一個應用的最小可運行單位，而不需要依賴任何 PaaS 能力。這對經典 PaaS 產業其實是一個“降維打擊”。
2014 年的時候，Kubernetes 項目發布，其意義在于 Google 將內部的 Borg/Omega 系統思想借助開源社區實現了“重生”，并且提出了“容器設計模式”的思想。而 Google 之所以選擇間接開源 Kubernetes 而不是直接開源 Borg 項目，其實背后的原因也比較容易理解：Borg/Omega 這樣的系統太復雜了，是沒辦法提供給 Google 之外的人使用，但是 Borg/Omega 這樣的設計思想卻可以借助 Kubernetes 讓大家接觸到，這也是開源 Kubernetes 的重要背景。
這樣到了 2015 年到 2016 年，就到了容器編排“三國爭霸”的時代，當時 Docker、Swarm、Mesos、Kubernetes 都在容器編排領域展開角逐，他們競爭的原因其實也比較容易理解， 那就是 Docker 或者容器本身的價值雖然大，但是如果想要讓其產生商業價值或者說對云的價值，那么就一定需要在編排上面占據一個有利的位置。
其中，Swarm 更偏向于生態，而 Mesos 技術更強一些。相比之下， Kubernetes 則兼具了兩者優勢，最終在 2017 年“三國爭霸”的局面中得以勝出，成為了當時直到現在的容器編排標準。這一過程的代表性事件就是 Docker 公司宣布在核心產品中內置了 Kubernetes 服務，并且 Swarm 項目逐漸停止維護。
到了 2018 年的時候，云原生技術理念開始逐漸萌芽，這是因為此時 Kubernetes 以及容器都成為了云廠商的既定標準，以“云”為核心的軟件研發思想逐步形成。
而到了 2019 年，情況似乎又將發生一些變化。
為什么說 2019 年很可能是一個關鍵節點呢？我們認為 2019 年是云原生技術的普及元年。
首先大家可以看到，在 2019 年，阿里巴巴宣布要全面上云，而且“上云就要上云原生”。我們還可以看到，以“云”為核心的軟件研發思想，正逐步成為所有開發者的默認選項。像 Kubernetes 等云原生技術正在成為技術人員的必修課，大量的工作崗位正在涌現出來。
這種背景下，“會 Kubernetes” 已經遠遠不夠了，“懂 Kubernetes”、“會云原生架構” 的重要性正日益凸顯出來。 從 2019 年開始，云原生技術將會大規模普及，這也是為什么大家都要在這個時間點上學習和投資云原生技術的重要原因。
“12要素”英文全稱是The Twelve-Factor App，最初由Heroku的工程師整理起步，是集體貢獻總結的智慧，如圖所示。
圖：12要素
根據基于云的軟件開發模式，12要素比較貼切地描述了軟件應用的原型，并詮釋了使用原生云應用架構的原因。比如，一個優雅的互聯網應用在設計過程中，需要遵循的一些基本原則和云原生有異曲同工之處。通過強化詳細配置和規范，類似Rails的基于“約定優于配置”（convention over configuration）的原則，特別在大規模的軟件生產實踐中，這些約定非常重要，從無狀態共享到水平擴展的過程，從松耦合架構關系到部署環境。基于12要素的上下文關聯，軟件生產就變成了一個個單一的部署單元；多個聯合部署的單元組成一個應用，多個應用之間的關系就可以組成一個復雜的分布式系統應用。
下面簡要介紹圖1-9中的這些原則。相信很多開發者在實際開發工作中已經很好地應用了其中的一些原則，只是沒有意識到概念本身。對這些原則比較陌生的開發者，如果想了解更多的操作過程，請參閱《云原生時代下的12要素（12-Factor）應用與實踐》一文。
每一個部署的應用都在版本控制代碼庫中被追蹤。在多個部署環境中，會有多種部署實例，單個應用只有一份代碼庫，多份部署相當于運行了該應用的多個實例，比如開發環境一個實例，測試環境、生產環境都有一個實例。
實際上，在云計算架構中，所有的基礎設施都是代碼配置，即Infrastructure as Code（IaC），整個應用通過配置文件就可以編排出來，而不再需要手工的干預，做到基礎服務也是可以追蹤的。
應用程序不會隱式依賴系統級的類庫，通過依賴清單聲明所有依賴項，通過依賴隔離工具確保程序不會調用系統中存在，但清單中未聲明依賴項，并統一應用到生產和開發環境。比如通過合適的工具（例如Maven、Bundler、NPM），應用可以很清晰地對部署環境公開和隔絕依賴性，而不是模糊地對部署環境產生依賴性。
在容器應用中，所有應用的依賴和安裝都是通過DockerFile來完成聲明的，通過配置能明確把依賴關系，包括版本都明確地圖形化展示出來，不存在黑盒。
環境變量是一種清楚、容易理解和標準化的配置方法，將應用的配置存儲于環境變量中，保證配置排除在代碼之外，或者其他可能在部署環境（例如研發、展示、生產）之間區別的任何代碼，可以通過操作系統級的環境變量來注入。
實例根據不同的環境配置運行在不同的環境中，此外，實現配置即代碼，在云環境中，無論是統一的配置中心還是分布式的配置中心都有好的實踐方式，比如Docker的環境變量使用。
不用區別對待本地或第三方服務，統一把依賴的后端作為一種服務來對待，例如數據庫或者消息代理，作為附加資源，同等地在各種環境中被消耗。比如在云架構的基礎服務中，計算、網絡、存儲資源都可以看作是一種服務去對待使用即可，不用區分是遠程還是本地的。
應用嚴格區分構建、發布、運行這3個階段。3個階段是嚴格分開的，一個階段對應做一件事情，每個階段有很明確的實現功能。云原生應用的構建流程可以把發布配置挪到開發階段，包括實際的代碼構建和運行應用所需的生產環境配置。在云原生應用中，基于容器的Build-Ship-Run和這3個階段完全吻合，也是Docker對本原則的最佳實踐。
進程必須無狀態且無共享，即云應用以一個或多個無狀態不共享的程序運行。任何必要狀態都被服務化到后端服務中（緩存、對象存儲等）。
所有的應用在設計時就認為隨時隨地會失敗，面向失敗而設計，因此進程可能會被隨時拉起或消失，特別是在彈性擴容的階段。
不依賴于任何網絡服務器就可以創建一個面向網絡的服務，每個應用的功能都很齊全，通過端口綁定對外提供所有服務，比如Web應用通過端口綁定（Port binding）來提供服務，并監聽發送至該端口的請求（包括HTTP）。
在容器應用中，應用統一通過暴露端口來服務，盡量避免通過本地文件或進程來通信，每種服務通過服務發現而服務。
進程可以看作一等公民，并發性即可以依靠水平擴展應用程序來實現，通過進程模型進行擴展，并且具備無共享、水平分區的特性。
在互聯網的服務中，業務的爆發性隨時可能發生，因此不太可能通過硬件擴容來隨時提供擴容服務，需要依賴橫向擴展能力進行擴容。
所有應用的架構設計都需要支持能隨時銷毀的特點，和狀態的無關性保持一致，允許系統快速彈性擴展、改變部署及故障恢復等。
在云環境中，由于業務的高低峰值經常需要能實現快速靈活、彈性的伸縮應用，以及不可控的硬件因素等，應用可能隨時會發生故障，因此應用在架構設計上需要盡可能無狀態，應用能隨時隨地拉起，也能隨時隨地銷毀，同時保證進程最小啟動時間和架構的可棄性，也可以提供更敏捷的發布及擴展過程。
必須縮小本地與線上差異，確保環境的一致性，保持研發、測試和生產環境盡可能相似，這樣可以提供應用的持續交付和部署服務。
在容器化應用中，通過文件構建的環境運行能做到版本化，因此保證各個不同環境的差異性，同時還能大大減少環境不同帶來的排錯等成本溝通問題。
每一個運行的進程都會直接標準輸出（stdout）和錯誤輸出（stderr）事件流，還可以將日志當作事件流作為數據源，通過集中服務，執行環境收集、聚合、索引和分析這些事件。
日志是系統運行狀態的部分體現，無論在系統診斷、業務跟蹤還是后續大數據服務的必要條件中，Docker提供標準的日志服務，用戶可以根據需求做自定義的插件開發來處理日志。
管理或維護應用的運行狀態是軟件維護的基礎部分，比如數據庫遷移、健康檢查、安全巡檢等，在與應用長期運行的程序相同環境中，作為一次性程序運行。
在應用架構模式中，比如Kubernetes里面的Pod資源或者dockerexec，可以隨著其他的應用程序一起發布或在出現異常診斷時能通過相關的程序去管理其狀態。
云原生的內容非常廣泛，目前沒有系統的說明和完整的定義，上文介紹了云原生應用的基礎組件和相關特點，可能讀者對云原生應用的邏輯還存在一些困惑。為了更清楚地進行說明，我們總結了其依賴關系，如圖所示。
首先，為了抓住商業機會，業務需要快速迭代，不斷試錯，因此，企業需要依賴擁有持續交付的能力，這些不僅包括技術需求還包括產品的需求，如何能擁有持續交付的能力，大而全的架構因為效率低下，顯然是不合適的。于是演變出微服務架構來滿足需求，通過把系統劃分出一個個獨立的個體，每個個體服務的設計依賴需要通過12要素的原則來規范完成。同樣，如果系統被分成了幾十個甚至幾百個服務組件，則需要借助DevOps才能很好地滿足業務協作和發布等流程。最后，DevOps的有效實施需要依賴一定的土壤，即敏捷的基礎設施服務，現實只有云計算的模式才能滿足整體要求。通過上述梳理，我們總結出面向云原生應用的3個不同層次的特點。
高可用設計（Design for Availability），依據應用業務需求，高可用分為不同級別，比如不同區域、不同機房（跨城或同城）、不同機柜、不同服務器和不同進程的高可用，云原生應用應該根據業務的可用性要求設計不同級別的架構支持。
可擴展設計（Design for Scale），所有應用的設計是無狀態的，使得業務天生具有擴展性，在業務流量高峰和低峰時期，依賴云的特性自動彈性擴容，滿足業務需求。
快速失敗設計（Design for Failure），即包括系統間依賴的調用隨時可能會失敗，也包括硬件基礎設施服務隨時可能宕機，還有后端有狀態服務的系統能力可能有瓶頸，總之在發生異常時能夠快速失敗，然后快速恢復，以保證業務永遠在線，不能讓業務半死不活地僵持著。
通過上面的基本描述及云原生應用的組成或特點，與容器技術相比可以得知，容器的特性天生就是按這些原則進行設計的。隨著互聯網業務的架構不斷演進，從單體應用到分布式應用，甚至微服務架構應用中，12要素較好地為構建互聯網化應用提供了統一的方法論和標準化，具有強大的生命力，每一條原則都是應用開發的珠璣。當然，在實踐過程中，每一個原則也不是一成不變的，隨著新的理念和技術出現，原有的因素會得到延伸和發展，會出現新的原則和應用，這套理論也適用于任意語言和后端服務（數據庫、消息隊列、緩存等）開發的應用程序，因此也作為云原生架構應用的基本指導原則之一.
軟件設計有兩個關鍵目標：高內聚、低耦合，圍繞這2個核心目標，又提出了單一職責、開閉原則、里氏替換、依賴導致、接口隔離、最少知識等設計原則。
軟件工程師一直都在為這兩個目標而努力奮斗，以求把軟件編寫得更加清晰、更加健壯、更加易于擴展和維護。
但后來，人們發現有更多的訴求，希望開發軟件變得更簡單、更快捷，程序員希望更少編寫代碼，非專業人員也希望能開發程序，于是，更多的更傻瓜的編程語言被發明出來，更多的編程技術和編程思想被發明出來，比如庫、組件、云基礎設施。
于是很多技術變成了屠龍之技，比如匯編，時代變了，建國后動物不能成精了，沒有龍可以宰了，然后很多軟件工程師搖身一變成了調參工程師、Call API磚家、用庫包能手、拼組件達人，這是效率分工的結果，也是技術發展的使然。
縱觀近二十年的科技互聯網發展歷程，大的趨勢是技術下沉，特別是近些年，隨著云計算的發展和普及，基礎設施越來越厚實，業務開發變得越來越容易，也越來越沒有技術含量，而之前困擾小團隊的性能、負載、安全性、擴展性問題都不復存在，這不禁讓互聯網行業的油膩大叔們噤若寒蟬，仿佛分分鐘就要被卷入歷史洪流而萬劫不復。
雖然不可否認技術的重要性在降低，但也還不至于那么悲觀。遙想PC時代，當VB、Delphi、MFC出現的時候，也有類似論調，所見即所得，點點鼠標，就可以開發PC桌面程序，是不是很高端？
那時候碼農的擔心相比現在恐怕是只多不少吧，但后來隨著互聯網興起，出現了后端開發這個工種，碼農很快找到了新的戰場，網絡、分布式、數據庫、海量服務、容災防錯，于是又玩出一堆新花樣。
如果說PC時代的基礎設施是控件庫，互聯網時代的基礎實施是云，那AI時代基礎設施是什么？又有什么高端玩法？
Kubernetes是容器編排系統的事實標準
在單機上運行容器，無法發揮它的最大效能，只有形成集群，才能最大程度發揮容器的良好隔離、資源分配與編排管理的優勢，而對于容器的編排管理，Swarm、Mesos和Kubernetes的大戰已經基本宣告技術，kubernetes成為了無可爭議的贏家。下面這張圖是Kubernetes的架構圖，其中顯示了組件之間交互的接口CNI、CRI、OCI等，這些將Kubernetes與某款具體產品解耦，給用戶最大的定制程度，使得Kubernetes有機會成為跨云的真正的云原生應用的操作系統。
Kuberentes架構（圖片來自網絡）
隨著Kubernetes的日趨成熟，“Kubernetes is becoming boring”，基于該“操作系統”之上構建的適用于不同場景的應用將成為新的發展方向，就像我們將石油開采出來后，提煉出汽油、柴油、瀝青等等，所有的材料都將找到自己的用途，Kubernetes也是，畢竟我們誰也不是為了部署和管理容器而用Kubernetes，承載其上的應用才是價值之所在。
云原生的核心目標
Cloud Native Core target
云已經可以為我們提供穩定的可以唾手可得的基礎設施，但是業務上云成了一個難題。Kubernetes的出現與其說是從最初的容器編排解決方案，倒不如說是為了解決應用上云（即云原生應用）這個難題。包括微服務和FaaS/Serverless架構，都可以作為云原生應用的架構。
但就2017年為止，kubernetes的主要使用場景也主要作為應用開發測試環境、CI/CD和運行Web應用這幾個領域，如下圖TheNewStack的Kubernetes生態狀況調查報告所示。
Workloads running on Kubernetes
另外基于Kubernetes的構建PaaS平臺和Serverless也處于爆發的準備階段，如下圖中Gartner的報告中所示：
當前各大公有云如Google GKE、微軟Azure ACS、亞馬遜EKS（2018年上線）、VmWare、Pivotal、騰訊云、阿里云等都提供了Kuberentes服務。
微服務
微服務——Cloud Native的應用架構
下圖是Bilgin Ibryam給出的微服務中應該關心的主題，圖片來自RedHat Developers。
Microservices concerns
微服務帶給我們很多開發和部署上的靈活性和技術多樣性，但是也增加了服務調用的開銷、分布式系統管理、調試與服務治理方面的難題。
當前最成熟最完整的微服務框架可以說非Spring莫屬，而Spring又僅限于Java語言開發，其架構本身又跟Kubernetes存在很多重合的部分，如何探索將Kubernetes作為微服務架構平臺就成為一個熱點話題。
就拿微服務中最基礎的服務注冊發現功能來說，其方式分為客戶端服務發現和服務端服務發現兩種，Java應用中常用的方式是使用Eureka和Ribbon做服務注冊發現和負載均衡，這屬于客戶端服務發現，而在Kubernetes中則可以使用DNS、Service和Ingress來實現，不需要修改應用代碼，直接從網絡層面來實現。
兩種服務發現方式
Cloud Native
DevOps——通向云原生的云梯
CNCF（云原生計算基金會）給出了云原生應用的三大特征：
容器化包裝：軟件應用的進程應該包裝在容器中獨立運行。
動態管理：通過集中式的編排調度系統來動態的管理和調度。
微服務化：明確服務間的依賴，互相解耦。
Microsoft Azure Compute Service Categories
Figure 2 Azure Cloud-Native Application Framework
In addition to the compute services already described, Azure offers a range of other managed services to enable development of end-to-end applications.
Specialised or more advanced apps can make use of additional services for Artificial Intelligence, Analytics and Event driven architectures (such as IoT) and integration for hybrid scenarios.
Putting all of this together, figure 2 shows a framework for building cloud-native applications on Azure. Other cloud platforms do provide similar offerings. If you are not using Azure, hopefully this article has given you some things to look out for on your cloud platform to build cloud-native apps that respond to change and enable you to work at the pace your business demands.
https://www.jianshu.com/p/a37baa7c3eff
http://blog.itpub.net/31558019/viewspace-2285476/
https://blog.csdn.net/enweitech/article/details/90178181
https://developer.aliyun.com/article/722745
http://www.sohu.com/a/211846555_617676
https://capgemini.github.io/cloud/cloud-native-apps-on-azure/
國內第一Kotlin 開發者社區公眾號，主要分享、交流 Kotlin 編程語言、Spring Boot、Android、React.js/Node.js、函數式編程、編程思想等相關主題。
越是喧囂的世界，越需要寧靜的思考。
