百度網盤程序員
提取碼:qhhv docker
微服務
微服務解決的是咱們軟件開發中一直追求的低耦合+高內聚,記得有一次咱們系統的接口出了問題,結果影響了用戶的前臺操做,因而黎叔拍案而起,靈魂發問:「爲啥這兩個會互相影響?!」服務器
微服務能夠解決這個問題,微服務的本質是把一塊大餅分紅若干塊低耦合的小餅,好比一塊小餅專門負責接收外部的數據,一塊小餅專門負責響應前臺的操做,小餅能夠進一步拆分,好比負責接收外部數據的小餅能夠繼續分紅多塊負責接收不一樣類型數據的小餅,這樣每一個小餅出問題了,其它小餅還能正常對外提供服務。網絡
DevOps
DevOps的意思就是開發和運維再也不是分開的兩個團隊,而是你中有我,我中有你的一個團隊。咱們如今開發和運維已是一個團隊了,可是運維方面的知識和經驗還須要持續提升。架構
持續交付
持續交付的意思就是在不影響用戶使用服務的前提下頻繁把新功能發佈給用戶使用,要作到這點很是很是難。咱們如今兩週一個版本,每次上線以後都會給不一樣的用戶形成不一樣程度的影響。app
容器化
容器化的好處在於運維的時候不須要再關心每一個服務所使用的技術棧了,每一個服務都被無差異地封裝在容器裏,能夠被無差異地管理和維護,如今比較流行的工具是docker和k8s。負載均衡
因此你也能夠簡單地把雲原生理解爲:雲原生 = 微服務 + DevOps + 持續交付 + 容器化less
自進入雲計算時代後,大量的新概念、新技術如雨後春筍般的涌現出來,從早期的openstack、IAAS平臺,到中期的容器技術、微服務架構,再到如今的servicemesh服務網格技術、serverless無服務器架構、雲原生技術,可謂在雲計算的時代,咱們從未停下前進的步伐。而今天要給你們帶來的即是雲原生技術~運維
那麼什麼是雲原生呢?咱們將名詞拆成兩部分—雲、原生,這些是相對於本地應用來的,雲是相對於本地而言的,傳統的應用都是運行在本地機房的服務器上,而云的應用則是運行在雲端(如IAAS、PAAS、SAAS)。分佈式
咱們能夠這麼來定義雲原生:一套新的技術體系、一種新的工做方法論、雲計算髮生的必然導向。
雲原生應用要運行在雲平臺,那麼就必需要有云的特色,好比彈性伸縮、分佈式、快速部署、快速迭代、高效、持續。這可不止是簡單的把原先在物理服務器上的應用遷移到虛擬機裏,不止是基礎設施和運行平臺在雲上,應用架構、應用開發方式、應用部署方式、應用維護方式全都要作出改變。
微服務技術使得應用原子化,全部的應用均可以獨立的部署、迭代。DevOps使得應用能夠快速編譯、自動化測試、部署、發佈、回滾,讓開發和運維一體化。持續交付讓應用能夠頻繁發佈、快速交付、快速反饋、下降發佈風險。容器使得應用總體開發以容器爲基礎,造成代碼組件複用、資源隔離。接下來咱們就好好的侃侃這幾門技術~
微服務的定義是獨立部署的、原子的、自治的業務組件,業務組件彼此之間經過消息中間件進行交互,業務組件能夠按需獨立伸縮、容錯、故障恢復。
微服務架構的演變可從早期的單體式架構、中期的SOA架構、後期的微服務架構來看。客戶提出一個需求時,早期的作法是直接往現有的代碼包里加東西,客戶來一個需求,程序員們就寫一串代碼在裏面,來十個寫十串,來一百個寫100串,反正就是不斷的加,最後咱們的應用就變成了一個巨無霸應用,要往裏面再加東西很難,要保證全面測試無誤很難,要保證定期上線很難,要保證線上出現了問題快速解決也很難,由於牽一髮而動全身,即便是技術精湛的程序員也不敢輕易的下手作了。
新的解決方案是SOA架構(ServiceOrientedArchitecture面向服務的架構),即將業務服務化、抽象化,將整個業務拆分紅不一樣的服務,服務與服務之間經過相互依賴提供一系列的功能,經過網絡調用。經常使用的實現方式是使用ESB(EnterpriseServiceBus企業服務總線)來把各個服務節點,集成不一樣系統、不一樣協議的服務,經過ESB將消息進行轉化,實現不一樣的服務互相交互。這個方案很大程度上解決了巨無霸應用的問題,可是對於ESB的維護成本卻比較高。
雲計算時代的到來推進應用「高內聚,低耦合」,高內聚就是熟悉同一塊業務的人、提供用一個服務的模塊聚合在一塊兒,低耦合就是應用與應用之間沒有緊密強依賴關係,而高內聚低耦合的最佳實踐即是微服務架構。經過將服務拆分紅單獨的服務,小型團隊可專一於本身的功能開發上線,運維團隊也可根據服務的調用狀況彈性擴縮容,符合雲計算時代的特點,肯定是雲原生的特性之一了。
DevOps
DevOps的定義是研發運維一體化,經過自動化流程使得軟件過程更加快捷和可靠。它不是一個產品,而是一種新的團隊工做方式、新的技術理念。
一個軟件從0到1的最終交付包含以下階段:市場規劃、產品規劃、編碼設計、編譯構建、部署測試、發佈上線、後期維護。
早期的時候全由一我的完成了,這我的通常都是CEO了,他根據對市場的洞察感知有了好的idea,本身開發編碼,編譯打包,進行測試以後在雲廠商上買一兩臺服務器部署上應用就對外發布了,這就是瀑布式開發模型,確認好需求後就進入開發階段,直到完成上線。
而隨着使用人羣的增長,應用的總體維護開始變得艱難,由於CEO對外要去擴展業務、對內要繼續開發、繼續維護應用,一我的實在幹不過來了。
慢慢的團隊裏有了產品經理、開發人員、測試人員、運維人員的劃分,由產品經理負責需求的規劃、產品交互設計,研發人員負責編碼、構建包,測試人員負責功能測試和自動化測試、上線發佈,運維人員負責維護線上服務的正常運行、擴容縮容,這就是敏捷開發模型,在開發過程階段測試介入,快速驗證修改問題直到基本無誤後上線部署。這一切所帶來的問題是總體的交付週期變長了,團隊之間溝通合做成本變高了,所以DevOps應運而生。它將整個軟件開發測試運維過程變爲一體化,每完成一個小的需求點便測試上線部署,快速驗證需求,捕獲用戶,佔領市場。
所以DevOps的出現是一種組織架構的變革,一種開發模式的變化,團隊人員在需求規劃、代碼設計、編譯構建、測試部署、上線發佈、後期維護的過程全程參與,每一個人都對總體的方案瞭解清晰,可制定合適的系統架構、技術架構、運維部署方案。
雲計算時代的到來帶來了虛擬化、容器、微服務等新的技術理念,強調的是服務的拆分、精細化的分工,奠基了DevOps落地的基礎條件,只有當服務拆分的原子化了,整個團隊密切合做的成本纔會下降,才能實現雲上應用的快速迭代,符合雲計算時代的特點,肯定是雲原生的特性之二了。
持續交付
持續交付的定義就是一直在交付,敏捷開發和DevOps要求隨時都有一個合適的版本部署在生產環節上,頻繁發佈、快速部署、快速驗證,因此必需要持續交付。
持續交付出現的狀況是需求遲遲不能肯定從而縮短了開發時間,需求不能肯定所帶來的問題是在肯定的過程當中整個市場或用戶已經發生了變化,開發出來的內容早已不符合當下用戶的需求了。爲了快速的驗證需求,每每在生產環境上會部署多個版本,從而也產生了不一樣的發佈部署方式,好比灰度發佈、藍綠髮布。
所謂灰度發佈即是當新的需求開發完成後,將線上的版本只升級部分服務,讓一部分用戶繼續使用老版本,一部分使用新版本,若是用戶對新版本沒有意見,再遷移到新版原本,整個過程是運維人員從負載均衡上去掉灰度服務器,待服務升級成功後再加入負載均衡服務器列表,這時候有少許用戶訪問業務時流量到新版本,若是這小部分用戶使用沒有反對,逐漸擴大灰度範圍,最後升級剩餘服務器。
所謂藍綠髮布則是將應用從邏輯上分爲A、B兩組,升級時將A從負載均衡組裏刪除,進行新版本的部署,同時B組仍然繼續提供服務。當A組升級完成後,負載均衡從新接入A組,再把B組從負載列表摘除,進行新版本的部署。A組從新提供服務。最後B組升級完成,負載均衡從新接入B組。此時AB組版本都升級完成,而且都對外提供服務。保障整個過程對用戶無影響,出現問題及時回退上一個版本。
經過灰度發佈和藍綠髮布的方式,能夠快速的驗證用戶需求,頻繁的發佈,根據用戶狀況規劃產品演變方向,實現了雲計算時代的快速迭代,符合雲計算時代的特點,肯定是雲原生的特性之三了。
容器化
容器技術的定義就是一個單獨的應用程序進程、運行資源的高度隔離。早期的時候應用全運行在物理機上,這致使資源分配不均勻,即便是一個小的應用也要耗費一樣的計算存儲資源,中期的時候有了虛擬化技術將物理機劃分爲多個虛擬機,這樣在一臺物理服務器上能夠運行多個虛擬服務器,實現了資源利用率的較大提高,而云計算時代的到來,帶來了微服務、DevOps、持續集成持續交付等內容,要求應用要原子化、快速的開發迭代、快速的上線部署,劃分爲虛擬機的方式不能保障應用在每一個環境(Dev、Test、Pre、Prod)都一致,容易引發應用因環境的問題而產生Bug,容器的出現極好的解決了這個問題。
在容器出現以後,整個的流程變成了研發人員在將代碼開發完成後,會將代碼、相關運行環境構建鏡像,測試人員在宿主機上下載服務的鏡像,使用容器啓動鏡像後便可運行服務進行測試;測試無誤後運維人員申請機器,拉取服務器的鏡像,在一臺或多臺宿主機上能夠同時運行多個容器,對用戶提供服務。在這個過程當中每一個服務都在獨立的容器裏運行,每臺機器上都運行着相互不關聯的容器,全部容器共享宿主機的cpu、磁盤、網絡、內存等,即實現了進程隔離(每一個服務獨立運行)、文件系統隔離(容器目錄修改不影響主機目錄)、資源隔離(CPU內存磁盤網絡資源獨立)。
使用容器,研發團隊能夠將微服務及其所需的全部配置、依賴關係和環境變量移動到全新的服務器節點上,而無需從新配置環境,這樣就實現了強大的可移植性,實現了雲計算時代的資源最大化利用,符合雲計算時代的特點,肯定是雲原生的特性之四了。