摘要:云原生的概念,由來自的于年首次提出,被一直延續(xù)使用至今。比如,一個優(yōu)雅的互聯(lián)網(wǎng)應用在設計過程中,需要遵循的一些基本原則和云原生有異曲同工之處。
歡迎訪問網(wǎng)易云社區(qū),了解更多網(wǎng)易技術產(chǎn)品運營經(jīng)驗。
云原生(Cloud Native)的概念,由來自Pivotal的MattStine于2013年首次提出,被一直延續(xù)使用至今。這個概念是Matt Stine根據(jù)其多年的架構和咨詢經(jīng)驗總結出來的一個思想集合,并得到了社區(qū)的不斷完善,內容非常多,包括DevOps、持續(xù)交付(Continuous Delivery)、微服務(MicroServices)、敏捷基礎設施(Agile Infrastructure)和12要素(TheTwelve-Factor App)等幾大主題,不但包括根據(jù)業(yè)務能力對公司進行文化、組織架構的重組與建設,也包括方法論與原則,還有具體的操作工具。采用基于云原生的技術和管理方法,可以更好地把業(yè)務生于“云”或遷移到云平臺,從而享受“云”的高效和持續(xù)的服務能力。
顧名思義,云原生是面向“云”而設計的應用,因此技術部分依賴于在傳統(tǒng)云計算的3層概念(基礎設施即服務(IaaS)、平臺即服務(PaaS)和軟件即服務(SaaS)),例如,敏捷的不可變基礎設施交付類似于IaaS,用來提供計算網(wǎng)絡存儲等基礎資源,這些資源是可編程且不可變的,直接通過API可以對外提供服務;有些應用通過PaaS服務本來就能組合成不同的業(yè)務能力,不一定需要從頭開始建設;還有一些軟件只需要“云”的資源就能直接運行起來為云用戶提供服務,即SaaS能力,用戶直接面對的就是原生的應用。
應用基于云服務進行架構設計,對技術人員的要求更高,除了對業(yè)務場景的考慮外,對隔離故障、容錯、自動恢復等非功能需求會考慮更多。借助云服務提供的能力也能實現(xiàn)更優(yōu)雅的設計,比如彈性資源的需求、跨機房的高可用、11個9(99.999999999%)的數(shù)據(jù)可靠性等特性,基本是云計算服務本身就提供的能力,開發(fā)者直接選擇對應的服務即可,一般不需要過多考慮本身機房的問題。如果架構設計本身又能支持多云的設計,可用性會進一步提高,比如Netflix能處理在AWS的某個機房無法正常工作的情況,還能為用戶提供服務,這就是“云”帶來的魔力,當然,云也會帶來更多的隔離等問題。如圖1-4所示,目前業(yè)界公認的云原生主要包括以下幾個層面的內容。
圖1-4 云原生的內容
敏捷基礎設施
正如通過業(yè)務代碼能夠實現(xiàn)產(chǎn)品需求、通過版本化的管理能夠保證業(yè)務的快速變更,基于云計算的開發(fā)模式也要考慮如何保證基礎資源的提供能夠根據(jù)代碼自動實現(xiàn)需求,并實現(xiàn)記錄變更,保證環(huán)境的一致性。使用軟件工程中的原則、實踐和工具來提供基礎資源的生命周期管理,這意味著工作人員可以更頻繁地構建更強可控或更穩(wěn)定的基礎設施,開發(fā)人員可以隨時拉取一套基礎設施來服務于開發(fā)、測試、聯(lián)調和灰度上線等需求。當然,同時要求業(yè)務開發(fā)具有較好的架構設計,不需要依賴本地數(shù)據(jù)進行持久化,所有的資源都是可以隨時拉起,隨時釋放,同時以API的方式提供彈性、按需的計算、存儲能力。
技術人員部署服務器、管理服務器模板、更新服務器和定義基礎設施的模式都是通過代碼來完成的,并且是自動化的,不能通過手工安裝或克隆的方式來管理服務器資源,運維人員和開發(fā)人員一起以資源配置的應用代碼為中心,不再是一臺臺機器。基礎設施通過代碼來進行更改、測試,在每次變更后執(zhí)行測試的自動化流程中,確保能維護穩(wěn)定的基礎設施服務。
此外,基礎設施的范圍也會更加廣泛,不僅包括機器,還包括不同的機柜或交換機、同城多機房、異地多機房等,這些內容也會在后續(xù)章節(jié)中逐一進行部分討論。
持續(xù)交付
為了滿足業(yè)務需求頻繁變動,通過快速迭代,產(chǎn)品能做到隨時都能發(fā)布的能力,是一系列的開發(fā)實踐方法。它分為持續(xù)集成、持續(xù)部署、持續(xù)發(fā)布等階段,用來確保從需求的提出到設計開發(fā)和測試,再到讓代碼快速、安全地部署到產(chǎn)品環(huán)境中。持續(xù)集成是指每當開發(fā)人員提交了一次改動,就立刻進行構建、自動化測試,確保業(yè)務應用和服務能符合預期,從而可以確定新代碼和原有代碼能否正確地集成在一起。持續(xù)交付是軟件發(fā)布的能力,在持續(xù)集成完成之后,能夠提供到預發(fā)布之類系統(tǒng)上,達到生產(chǎn)環(huán)境的條件,持續(xù)部署是指使用完全的自動化過程來把每個變更自動提交到測試環(huán)境中,然后將應用安全地部署到產(chǎn)品環(huán)境中,打通開發(fā)、測試、生產(chǎn)的各個環(huán)節(jié),自動持續(xù)、增量地交付產(chǎn)品,也是大量產(chǎn)品追求的最終目的,當然,在實際運行的過程中,有些產(chǎn)品會增加灰度發(fā)布等環(huán)境。總之,它更多是代表一種軟件交付的能力,過程示例請參考圖1-5。
圖1-5 持續(xù)交付流程
DevOps
DevOps如果從字面上來理解只是Dev(開發(fā)人員)+Ops(運維人員),實際上,它是一組過程、方法與系統(tǒng)的統(tǒng)稱,其概念從2009年首次提出發(fā)展到現(xiàn)在,內容也非常豐富,有理論也有實踐,包括組織文化、自動化、精益、反饋和分享等不同方面。首先,組織架構、企業(yè)文化與理念等,需要自上而下設計,用于促進開發(fā)部門、運維部門和質量保障部門之間的溝通、協(xié)作與整合,簡單而言組織形式類似于系統(tǒng)分層設計。其次,自動化是指所有的操作都不需要人工參與,全部依賴系統(tǒng)自動完成,比如上述的持續(xù)交付過程必須自動化才有可能完成快速迭代。再次,DevOps的出現(xiàn)是由于軟件行業(yè)日益清晰地認識到,為了按時交付軟件產(chǎn)品和服務,開發(fā)部門和運維部門必須緊密合作。總之,如圖1-6所示,DevOps強調的是高效組織團隊之間如何通過自動化的工具協(xié)作和溝通來完成軟件的生命周期管理,從而更快、更頻繁地交付更穩(wěn)定的軟件。
圖1-6 DevOps強調組織的溝通與協(xié)作
微服務
隨著企業(yè)的業(yè)務發(fā)展,傳統(tǒng)業(yè)務架構面臨著很多問題。其一,單體架構在需求越來越多的時候無法滿足其變更要求,開發(fā)人員對大量代碼的變更會越來越困難,同時也無法很好地評估風險,所以迭代速度慢;其二,系統(tǒng)經(jīng)常會因為某處業(yè)務的瓶頸導致整個業(yè)務癱瘓,架構無法擴展,木桶效應嚴重,無法滿足業(yè)務的可用性要求;最后,整體組織效率低下,無法很好地利用資源,存在大量的浪費。因此,組織迫切需要進行變革。隨著大量開源技術的成熟和云計算的發(fā)展,服務化的改造應運而生,不同的架構設計風格隨之涌現(xiàn),最有代表性的是Netflix公司,它是國外最早基于云進行服務化架構改造的公司,2008年因為全站癱瘓被迫停業(yè)3天后,它痛下決心改造,經(jīng)過將近10年的努力,實現(xiàn)了從單架構到微服務全球化的變遷,滿足了業(yè)務的千倍增長(如圖1-7所示),并產(chǎn)生了一系列的最佳實踐。
圖1-7 Netflix微服務化支撐業(yè)務千倍增長
隨著微服務化架構的優(yōu)勢展現(xiàn)和快速發(fā)展,2013年,MartinFlower對微服務概念進行了比較系統(tǒng)的理論闡述,總結了相關的技術特征。首先,微服務是一種架構風格,也是一種服務;其次,微服務的顆粒比較小,一個大型復雜軟件應用由多個微服務組成,比如Netflix目前由500多個的微服務組成;最后,它采用UNIX設計的哲學,每種服務只做一件事,是一種松耦合的能夠被獨立開發(fā)和部署的無狀態(tài)化服務(獨立擴展、升級和可替換)。微服務架構如圖1-8所示。
圖1-8 微服務架構示例
由微服務的定義分析可知,一個微服務基本是一個能獨立發(fā)布的應用服務,因此可以作為獨立組件升級、灰度或復用等,對整個大應用的影響也較小,每個服務可以由專門的組織來多帶帶完成,依賴方只要定好輸入和輸出口即可完全開發(fā),甚至整個團隊的組織架構也會更精簡,因此溝通成本低、效率高。根據(jù)業(yè)務的需求,不同的服務可以根據(jù)業(yè)務特性進行不同的技術選型,是計算密集型還是I/O密集型應用都可以依賴不同的語言編程模型,各團隊可以根據(jù)本身的特色獨自運作。服務在壓力較大時,也可以有更多容錯或限流服務。
微服務架構確實有很多吸引人的地方,然而它的引入也是有成本的,它并不是銀彈,使用它會引入更多技術挑戰(zhàn),比如性能延遲、分布式事務、集成測試、故障診斷等方面,企業(yè)需要根據(jù)業(yè)務的不同的階段進行合理的引入,不能完全為了微服務而“微服務”,本書第5章也會對如何解決這些問題提供對應不同方案的權衡。
12要素
“12要素”英文全稱是The Twelve-Factor App,最初由Heroku的工程師整理起步,是集體貢獻總結的智慧,如圖1-9所示。根據(jù)基于云的軟件開發(fā)模式,12要素比較貼切地描述了軟件應用的原型,并詮釋了使用原生云應用架構的原因。比如,一個優(yōu)雅的互聯(lián)網(wǎng)應用在設計過程中,需要遵循的一些基本原則和云原生有異曲同工之處。通過強化詳細配置和規(guī)范,類似Rails的基于“約定優(yōu)于配置”(convention over configuration)的原則,特別在大規(guī)模的軟件生產(chǎn)實踐中,這些約定非常重要,從無狀態(tài)共享到水平擴展的過程,從松耦合架構關系到部署環(huán)境。基于12要素的上下文關聯(lián),軟件生產(chǎn)就變成了一個個單一的部署單元;多個聯(lián)合部署的單元組成一個應用,多個應用之間的關系就可以組成一個復雜的分布式系統(tǒng)應用。
圖1-9 12要素
下面簡要介紹圖1-9中的這些原則。相信很多開發(fā)者在實際開發(fā)工作中已經(jīng)很好地應用了其中的一些原則,只是沒有意識到概念本身。對這些原則比較陌生的開發(fā)者,如果想了解更多的操作過程,請參閱《云原生時代下的12要素(12-Factor)應用與實踐》一文。
基準代碼
每一個部署的應用都在版本控制代碼庫中被追蹤。在多個部署環(huán)境中,會有多種部署實例,單個應用只有一份代碼庫,多份部署相當于運行了該應用的多個實例,比如開發(fā)環(huán)境一個實例,測試環(huán)境、生產(chǎn)環(huán)境都有一個實例。
實際上,在云計算架構中,所有的基礎設施都是代碼配置,即Infrastructure as Code(IaC),整個應用通過配置文件就可以編排出來,而不再需要手工的干預,做到基礎服務也是可以追蹤的。
依賴
應用程序不會隱式依賴系統(tǒng)級的類庫,通過依賴清單聲明所有依賴項,通過依賴隔離工具確保程序不會調用系統(tǒng)中存在,但清單中未聲明依賴項,并統(tǒng)一應用到生產(chǎn)和開發(fā)環(huán)境。比如通過合適的工具(例如Maven、Bundler、NPM),應用可以很清晰地對部署環(huán)境公開和隔絕依賴性,而不是模糊地對部署環(huán)境產(chǎn)生依賴性。
在容器應用中,所有應用的依賴和安裝都是通過DockerFile來完成聲明的,通過配置能明確把依賴關系,包括版本都明確地圖形化展示出來,不存在黑盒。
配置
環(huán)境變量是一種清楚、容易理解和標準化的配置方法,將應用的配置存儲于環(huán)境變量中,保證配置排除在代碼之外,或者其他可能在部署環(huán)境(例如研發(fā)、展示、生產(chǎn))之間區(qū)別的任何代碼,可以通過操作系統(tǒng)級的環(huán)境變量來注入。
實例根據(jù)不同的環(huán)境配置運行在不同的環(huán)境中,此外,實現(xiàn)配置即代碼,在云環(huán)境中,無論是統(tǒng)一的配置中心還是分布式的配置中心都有好的實踐方式,比如Docker的環(huán)境變量使用。
后端服務
不用區(qū)別對待本地或第三方服務,統(tǒng)一把依賴的后端作為一種服務來對待,例如數(shù)據(jù)庫或者消息代理,作為附加資源,同等地在各種環(huán)境中被消耗。比如在云架構的基礎服務中,計算、網(wǎng)絡、存儲資源都可以看作是一種服務去對待使用即可,不用區(qū)分是遠程還是本地的。
構建、發(fā)布、運行
應用嚴格區(qū)分構建、發(fā)布、運行這3個階段。3個階段是嚴格分開的,一個階段對應做一件事情,每個階段有很明確的實現(xiàn)功能。云原生應用的構建流程可以把發(fā)布配置挪到開發(fā)階段,包括實際的代碼構建和運行應用所需的生產(chǎn)環(huán)境配置。在云原生應用中,基于容器的Build-Ship-Run和這3個階段完全吻合,也是Docker對本原則的最佳實踐。
進程
進程必須無狀態(tài)且無共享,即云應用以一個或多個無狀態(tài)不共享的程序運行。任何必要狀態(tài)都被服務化到后端服務中(緩存、對象存儲等)。
所有的應用在設計時就認為隨時隨地會失敗,面向失敗而設計,因此進程可能會被隨時拉起或消失,特別是在彈性擴容的階段。
端口綁定
不依賴于任何網(wǎng)絡服務器就可以創(chuàng)建一個面向網(wǎng)絡的服務,每個應用的功能都很齊全,通過端口綁定對外提供所有服務,比如Web應用通過端口綁定(Port binding)來提供服務,并監(jiān)聽發(fā)送至該端口的請求(包括HTTP)。
在容器應用中,應用統(tǒng)一通過暴露端口來服務,盡量避免通過本地文件或進程來通信,每種服務通過服務發(fā)現(xiàn)而服務。
并發(fā)
進程可以看作一等公民,并發(fā)性即可以依靠水平擴展應用程序來實現(xiàn),通過進程模型進行擴展,并且具備無共享、水平分區(qū)的特性。
在互聯(lián)網(wǎng)的服務中,業(yè)務的爆發(fā)性隨時可能發(fā)生,因此不太可能通過硬件擴容來隨時提供擴容服務,需要依賴橫向擴展能力進行擴容。
易處理
所有應用的架構設計都需要支持能隨時銷毀的特點,和狀態(tài)的無關性保持一致,允許系統(tǒng)快速彈性擴展、改變部署及故障恢復等。
在云環(huán)境中,由于業(yè)務的高低峰值經(jīng)常需要能實現(xiàn)快速靈活、彈性的伸縮應用,以及不可控的硬件因素等,應用可能隨時會發(fā)生故障,因此應用在架構設計上需要盡可能無狀態(tài),應用能隨時隨地拉起,也能隨時隨地銷毀,同時保證進程最小啟動時間和架構的可棄性,也可以提供更敏捷的發(fā)布及擴展過程。
環(huán)境等價
必須縮小本地與線上差異,確保環(huán)境的一致性,保持研發(fā)、測試和生產(chǎn)環(huán)境盡可能相似,這樣可以提供應用的持續(xù)交付和部署服務。
在容器化應用中,通過文件構建的環(huán)境運行能做到版本化,因此保證各個不同環(huán)境的差異性,同時還能大大減少環(huán)境不同帶來的排錯等成本溝通問題。
日志
每一個運行的進程都會直接標準輸出(stdout)和錯誤輸出(stderr)事件流,還可以將日志當作事件流作為數(shù)據(jù)源,通過集中服務,執(zhí)行環(huán)境收集、聚合、索引和分析這些事件。
日志是系統(tǒng)運行狀態(tài)的部分體現(xiàn),無論在系統(tǒng)診斷、業(yè)務跟蹤還是后續(xù)大數(shù)據(jù)服務的必要條件中,Docker提供標準的日志服務,用戶可以根據(jù)需求做自定義的插件開發(fā)來處理日志。
管理進程
管理或維護應用的運行狀態(tài)是軟件維護的基礎部分,比如數(shù)據(jù)庫遷移、健康檢查、安全巡檢等,在與應用長期運行的程序相同環(huán)境中,作為一次性程序運行。
在應用架構模式中,比如Kubernetes里面的Pod資源或者dockerexec,可以隨著其他的應用程序一起發(fā)布或在出現(xiàn)異常診斷時能通過相關的程序去管理其狀態(tài)。
云原生的內容非常廣泛,目前沒有系統(tǒng)的說明和完整的定義,上文介紹了云原生應用的基礎組件和相關特點,可能讀者對云原生應用的邏輯還存在一些困惑。為了更清楚地進行說明,我們總結了其依賴關系,如圖1-10所示。
圖1-10 云原生內容的依賴關系
首先,為了抓住商業(yè)機會,業(yè)務需要快速迭代,不斷試錯,因此,企業(yè)需要依賴擁有持續(xù)交付的能力,這些不僅包括技術需求還包括產(chǎn)品的需求,如何能擁有持續(xù)交付的能力,大而全的架構因為效率低下,顯然是不合適的。于是演變出微服務架構來滿足需求,通過把系統(tǒng)劃分出一個個獨立的個體,每個個體服務的設計依賴需要通過12要素的原則來規(guī)范完成。同樣,如果系統(tǒng)被分成了幾十個甚至幾百個服務組件,則需要借助DevOps才能很好地滿足業(yè)務協(xié)作和發(fā)布等流程。最后,DevOps的有效實施需要依賴一定的土壤,即敏捷的基礎設施服務,現(xiàn)實只有云計算的模式才能滿足整體要求。通過上述梳理,我們總結出面向云原生應用的3個不同層次的特點。
高可用設計(Design for Availability),依據(jù)應用業(yè)務需求,高可用分為不同級別,比如不同區(qū)域、不同機房(跨城或同城)、不同機柜、不同服務器和不同進程的高可用,云原生應用應該根據(jù)業(yè)務的可用性要求設計不同級別的架構支持。
可擴展設計(Design for Scale),所有應用的設計是無狀態(tài)的,使得業(yè)務天生具有擴展性,在業(yè)務流量高峰和低峰時期,依賴云的特性自動彈性擴容,滿足業(yè)務需求。
快速失敗設計(Design for Failure),即包括系統(tǒng)間依賴的調用隨時可能會失敗,也包括硬件基礎設施服務隨時可能宕機,還有后端有狀態(tài)服務的系統(tǒng)能力可能有瓶頸,總之在發(fā)生異常時能夠快速失敗,然后快速恢復,以保證業(yè)務永遠在線,不能讓業(yè)務半死不活地僵持著。
通過上面的基本描述及云原生應用的組成或特點,與容器技術(第2章將詳細介紹)相比可以得知,容器的特性天生就是按這些原則進行設計的。隨著互聯(lián)網(wǎng)業(yè)務的架構不斷演進,從單體應用到分布式應用,甚至微服務架構應用中,12要素較好地為構建互聯(lián)網(wǎng)化應用提供了統(tǒng)一的方法論和標準化,具有強大的生命力,每一條原則都是應用開發(fā)的珠璣。當然,在實踐過程中,每一個原則也不是一成不變的,隨著新的理念和技術出現(xiàn),原有的因素會得到延伸和發(fā)展,會出現(xiàn)新的原則和應用,這套理論也適用于任意語言和后端服務(數(shù)據(jù)庫、消息隊列、緩存等)開發(fā)的應用程序,因此也作為云原生架構應用的基本指導原則之一。
本文節(jié)選自《云原生應用架構實踐》,網(wǎng)易云基礎服務架構團隊著,全程詳解單體到分布式服務化架構的演進。更多精彩內容,敬請期待下期分享。
文/網(wǎng)易云基礎服務架構該團隊
網(wǎng)易云計算基礎服務為您提供容器服務,歡迎點擊免費試用。
文章來源: 網(wǎng)易云社區(qū)
文章版權歸作者所有,未經(jīng)允許請勿轉載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉載請注明本文地址:http://m.hztianpu.com/yun/25280.html
摘要:如何挑選合適的導航結構導航設計是應用設計的關鍵,設計規(guī)范以下簡稱規(guī)范中將導航元素分為對等層次和歷史導航等幾類,例如表和透視表導航窗格是對等導航元素,中心大綱細節(jié)屬于分層導航元素,返回則屬于歷史導航元素。 此文已由作者楊凱明授權網(wǎng)易云社區(qū)發(fā)布。 歡迎訪問網(wǎng)易云社區(qū),了解更多網(wǎng)易技術產(chǎn)品運營經(jīng)驗。 繼Windows 10系統(tǒng)發(fā)布之后,很多Windows用戶更新了系統(tǒng)。win10系統(tǒng)的發(fā)布,...
摘要:點擊訂閱云棲夜讀周刊精彩觀點通過開放管理混合云會更受大客戶歡迎,客戶傾向于用云存儲災備技術保障數(shù)據(jù)可靠性,和會成為業(yè)界主流,中國出現(xiàn)第一家真正全面云化的大型公司,云端計算在業(yè)務中應用的廣度和深度將成為未來十年衡量企業(yè)競爭力的新標尺等。【點擊訂閱云棲夜讀周刊】 精彩觀點:通過開放API管理混合云會更受大客戶歡迎,客戶傾向于用云存儲災備技術保障數(shù)據(jù)可靠性,Kubernetes和Kata Con...
摘要:事實上,這種快捷的發(fā)布周期需要配合一系列流程工具甚至是管理文化,從而共同支撐起一套安全且可靠的云原生應用程序運作機制。云原生框架云原生應用程序的一大關鍵性特質在于,其需要遵循一套設計契約以較大程度實現(xiàn)行為的可預測性。 擺脫臨時性自動化方案之定位,發(fā)揮優(yōu)勢以實現(xiàn)可預測功能。您能否以每周為單位向客戶發(fā)布各類新功能?甚至進一步達到以每天乃至每小時為單位?新晉開發(fā)人員能否在上班的第一天即進行代碼部署...
摘要:月日至日,高可用架構和聯(lián)合主辦的全球互聯(lián)網(wǎng)架構大會將于上海光大會展中心舉行。全球互聯(lián)網(wǎng)架構大會是高可用架構技術社區(qū)推廣的面向架構師技術負責人及高端技術從業(yè)人員的技術架構大會。本次大會共有大板塊方向,場技術專題,個互聯(lián)網(wǎng)架構案例。 showImg(https://segmentfault.com/img/bVZ3Vh?w=600&h=375);12月22日至23日,高可用架構和msup聯(lián)...
摘要:月日至日,高可用架構和聯(lián)合主辦的全球互聯(lián)網(wǎng)架構大會將于上海光大會展中心舉行。全球互聯(lián)網(wǎng)架構大會是高可用架構技術社區(qū)推廣的面向架構師技術負責人及高端技術從業(yè)人員的技術架構大會。本次大會共有大板塊方向,場技術專題,個互聯(lián)網(wǎng)架構案例。 showImg(https://segmentfault.com/img/bVZ3Vh?w=600&h=375);12月22日至23日,高可用架構和msup聯(lián)...
閱讀 2394·2021-11-23 09:51
閱讀 1604·2019-08-30 15:55
閱讀 1818·2019-08-30 15:44
閱讀 947·2019-08-30 14:11
閱讀 1332·2019-08-30 14:10
閱讀 1111·2019-08-30 13:52
閱讀 2843·2019-08-30 12:50
閱讀 828·2019-08-29 15:04