摘要：云原生的概念，由來自的于年首次提出，被一直延續(xù)使用至今。比如，一個優(yōu)雅的互聯(lián)網(wǎng)應(yīng)用在設(shè)計過程中，需要遵循的一些基本原則和云原生有異曲同工之處。

歡迎訪問網(wǎng)易云社區(qū)，了解更多網(wǎng)易技術(shù)產(chǎn)品運營經(jīng)驗。

云原生（Cloud Native）的概念，由來自Pivotal的MattStine于2013年首次提出，被一直延續(xù)使用至今。這個概念是Matt Stine根據(jù)其多年的架構(gòu)和咨詢經(jīng)驗總結(jié)出來的一個思想集合，并得到了社區(qū)的不斷完善，內(nèi)容非常多，包括DevOps、持續(xù)交付（Continuous Delivery）、微服務(wù)（MicroServices）、敏捷基礎(chǔ)設(shè)施（Agile Infrastructure）和12要素（TheTwelve-Factor App）等幾大主題，不但包括根據(jù)業(yè)務(wù)能力對公司進(jìn)行文化、組織架構(gòu)的重組與建設(shè)，也包括方法論與原則，還有具體的操作工具。采用基于云原生的技術(shù)和管理方法，可以更好地把業(yè)務(wù)生于“云”或遷移到云平臺，從而享受“云”的高效和持續(xù)的服務(wù)能力。

顧名思義，云原生是面向“云”而設(shè)計的應(yīng)用，因此技術(shù)部分依賴于在傳統(tǒng)云計算的3層概念（基礎(chǔ)設(shè)施即服務(wù)（IaaS）、平臺即服務(wù)（PaaS）和軟件即服務(wù)（SaaS）），例如，敏捷的不可變基礎(chǔ)設(shè)施交付類似于IaaS，用來提供計算網(wǎng)絡(luò)存儲等基礎(chǔ)資源，這些資源是可編程且不可變的，直接通過API可以對外提供服務(wù)；有些應(yīng)用通過PaaS服務(wù)本來就能組合成不同的業(yè)務(wù)能力，不一定需要從頭開始建設(shè)；還有一些軟件只需要“云”的資源就能直接運行起來為云用戶提供服務(wù)，即SaaS能力，用戶直接面對的就是原生的應(yīng)用。

應(yīng)用基于云服務(wù)進(jìn)行架構(gòu)設(shè)計，對技術(shù)人員的要求更高，除了對業(yè)務(wù)場景的考慮外，對隔離故障、容錯、自動恢復(fù)等非功能需求會考慮更多。借助云服務(wù)提供的能力也能實現(xiàn)更優(yōu)雅的設(shè)計，比如彈性資源的需求、跨機(jī)房的高可用、11個9（99.999999999%）的數(shù)據(jù)可靠性等特性，基本是云計算服務(wù)本身就提供的能力，開發(fā)者直接選擇對應(yīng)的服務(wù)即可，一般不需要過多考慮本身機(jī)房的問題。如果架構(gòu)設(shè)計本身又能支持多云的設(shè)計，可用性會進(jìn)一步提高，比如Netflix能處理在AWS的某個機(jī)房無法正常工作的情況，還能為用戶提供服務(wù)，這就是“云”帶來的魔力，當(dāng)然，云也會帶來更多的隔離等問題。如圖1-4所示，目前業(yè)界公認(rèn)的云原生主要包括以下幾個層面的內(nèi)容。

圖1-4 云原生的內(nèi)容

敏捷基礎(chǔ)設(shè)施
正如通過業(yè)務(wù)代碼能夠?qū)崿F(xiàn)產(chǎn)品需求、通過版本化的管理能夠保證業(yè)務(wù)的快速變更，基于云計算的開發(fā)模式也要考慮如何保證基礎(chǔ)資源的提供能夠根據(jù)代碼自動實現(xiàn)需求，并實現(xiàn)記錄變更，保證環(huán)境的一致性。使用軟件工程中的原則、實踐和工具來提供基礎(chǔ)資源的生命周期管理，這意味著工作人員可以更頻繁地構(gòu)建更強(qiáng)可控或更穩(wěn)定的基礎(chǔ)設(shè)施，開發(fā)人員可以隨時拉取一套基礎(chǔ)設(shè)施來服務(wù)于開發(fā)、測試、聯(lián)調(diào)和灰度上線等需求。當(dāng)然，同時要求業(yè)務(wù)開發(fā)具有較好的架構(gòu)設(shè)計，不需要依賴本地數(shù)據(jù)進(jìn)行持久化，所有的資源都是可以隨時拉起，隨時釋放，同時以API的方式提供彈性、按需的計算、存儲能力。

技術(shù)人員部署服務(wù)器、管理服務(wù)器模板、更新服務(wù)器和定義基礎(chǔ)設(shè)施的模式都是通過代碼來完成的，并且是自動化的，不能通過手工安裝或克隆的方式來管理服務(wù)器資源，運維人員和開發(fā)人員一起以資源配置的應(yīng)用代碼為中心，不再是一臺臺機(jī)器?；A(chǔ)設(shè)施通過代碼來進(jìn)行更改、測試，在每次變更后執(zhí)行測試的自動化流程中，確保能維護(hù)穩(wěn)定的基礎(chǔ)設(shè)施服務(wù)。

此外，基礎(chǔ)設(shè)施的范圍也會更加廣泛，不僅包括機(jī)器，還包括不同的機(jī)柜或交換機(jī)、同城多機(jī)房、異地多機(jī)房等，這些內(nèi)容也會在后續(xù)章節(jié)中逐一進(jìn)行部分討論。

持續(xù)交付
為了滿足業(yè)務(wù)需求頻繁變動，通過快速迭代，產(chǎn)品能做到隨時都能發(fā)布的能力，是一系列的開發(fā)實踐方法。它分為持續(xù)集成、持續(xù)部署、持續(xù)發(fā)布等階段，用來確保從需求的提出到設(shè)計開發(fā)和測試，再到讓代碼快速、安全地部署到產(chǎn)品環(huán)境中。持續(xù)集成是指每當(dāng)開發(fā)人員提交了一次改動，就立刻進(jìn)行構(gòu)建、自動化測試，確保業(yè)務(wù)應(yīng)用和服務(wù)能符合預(yù)期，從而可以確定新代碼和原有代碼能否正確地集成在一起。持續(xù)交付是軟件發(fā)布的能力，在持續(xù)集成完成之后，能夠提供到預(yù)發(fā)布之類系統(tǒng)上，達(dá)到生產(chǎn)環(huán)境的條件，持續(xù)部署是指使用完全的自動化過程來把每個變更自動提交到測試環(huán)境中，然后將應(yīng)用安全地部署到產(chǎn)品環(huán)境中，打通開發(fā)、測試、生產(chǎn)的各個環(huán)節(jié)，自動持續(xù)、增量地交付產(chǎn)品，也是大量產(chǎn)品追求的最終目的，當(dāng)然，在實際運行的過程中，有些產(chǎn)品會增加灰度發(fā)布等環(huán)境?？傊?，它更多是代表一種軟件交付的能力，過程示例請參考圖1-5。

圖1-5 持續(xù)交付流程

DevOps
DevOps如果從字面上來理解只是Dev（開發(fā)人員）+Ops（運維人員），實際上，它是一組過程、方法與系統(tǒng)的統(tǒng)稱，其概念從2009年首次提出發(fā)展到現(xiàn)在，內(nèi)容也非常豐富，有理論也有實踐，包括組織文化、自動化、精益、反饋和分享等不同方面。首先，組織架構(gòu)、企業(yè)文化與理念等，需要自上而下設(shè)計，用于促進(jìn)開發(fā)部門、運維部門和質(zhì)量保障部門之間的溝通、協(xié)作與整合，簡單而言組織形式類似于系統(tǒng)分層設(shè)計。其次，自動化是指所有的操作都不需要人工參與，全部依賴系統(tǒng)自動完成，比如上述的持續(xù)交付過程必須自動化才有可能完成快速迭代。再次，DevOps的出現(xiàn)是由于軟件行業(yè)日益清晰地認(rèn)識到，為了按時交付軟件產(chǎn)品和服務(wù)，開發(fā)部門和運維部門必須緊密合作?？傊鐖D1-6所示，DevOps強(qiáng)調(diào)的是高效組織團(tuán)隊之間如何通過自動化的工具協(xié)作和溝通來完成軟件的生命周期管理，從而更快、更頻繁地交付更穩(wěn)定的軟件。

圖1-6 DevOps強(qiáng)調(diào)組織的溝通與協(xié)作

微服務(wù)
隨著企業(yè)的業(yè)務(wù)發(fā)展，傳統(tǒng)業(yè)務(wù)架構(gòu)面臨著很多問題。其一，單體架構(gòu)在需求越來越多的時候無法滿足其變更要求，開發(fā)人員對大量代碼的變更會越來越困難，同時也無法很好地評估風(fēng)險，所以迭代速度慢；其二，系統(tǒng)經(jīng)常會因為某處業(yè)務(wù)的瓶頸導(dǎo)致整個業(yè)務(wù)癱瘓，架構(gòu)無法擴(kuò)展，木桶效應(yīng)嚴(yán)重，無法滿足業(yè)務(wù)的可用性要求；最后，整體組織效率低下，無法很好地利用資源，存在大量的浪費。因此，組織迫切需要進(jìn)行變革。隨著大量開源技術(shù)的成熟和云計算的發(fā)展，服務(wù)化的改造應(yīng)運而生，不同的架構(gòu)設(shè)計風(fēng)格隨之涌現(xiàn)，最有代表性的是Netflix公司，它是國外最早基于云進(jìn)行服務(wù)化架構(gòu)改造的公司，2008年因為全站癱瘓被迫停業(yè)3天后，它痛下決心改造，經(jīng)過將近10年的努力，實現(xiàn)了從單架構(gòu)到微服務(wù)全球化的變遷，滿足了業(yè)務(wù)的千倍增長（如圖1-7所示），并產(chǎn)生了一系列的最佳實踐。

圖1-7 Netflix微服務(wù)化支撐業(yè)務(wù)千倍增長

隨著微服務(wù)化架構(gòu)的優(yōu)勢展現(xiàn)和快速發(fā)展，2013年，MartinFlower對微服務(wù)概念進(jìn)行了比較系統(tǒng)的理論闡述，總結(jié)了相關(guān)的技術(shù)特征。首先，微服務(wù)是一種架構(gòu)風(fēng)格，也是一種服務(wù)；其次，微服務(wù)的顆粒比較小，一個大型復(fù)雜軟件應(yīng)用由多個微服務(wù)組成，比如Netflix目前由500多個的微服務(wù)組成；最后，它采用UNIX設(shè)計的哲學(xué)，每種服務(wù)只做一件事，是一種松耦合的能夠被獨立開發(fā)和部署的無狀態(tài)化服務(wù)（獨立擴(kuò)展、升級和可替換）。微服務(wù)架構(gòu)如圖1-8所示。

圖1-8 微服務(wù)架構(gòu)示例

由微服務(wù)的定義分析可知，一個微服務(wù)基本是一個能獨立發(fā)布的應(yīng)用服務(wù)，因此可以作為獨立組件升級、灰度或復(fù)用等，對整個大應(yīng)用的影響也較小，每個服務(wù)可以由專門的組織來多帶帶完成，依賴方只要定好輸入和輸出口即可完全開發(fā)，甚至整個團(tuán)隊的組織架構(gòu)也會更精簡，因此溝通成本低、效率高。根據(jù)業(yè)務(wù)的需求，不同的服務(wù)可以根據(jù)業(yè)務(wù)特性進(jìn)行不同的技術(shù)選型，是計算密集型還是I/O密集型應(yīng)用都可以依賴不同的語言編程模型，各團(tuán)隊可以根據(jù)本身的特色獨自運作。服務(wù)在壓力較大時，也可以有更多容錯或限流服務(wù)。

微服務(wù)架構(gòu)確實有很多吸引人的地方，然而它的引入也是有成本的，它并不是銀彈，使用它會引入更多技術(shù)挑戰(zhàn)，比如性能延遲、分布式事務(wù)、集成測試、故障診斷等方面，企業(yè)需要根據(jù)業(yè)務(wù)的不同的階段進(jìn)行合理的引入，不能完全為了微服務(wù)而“微服務(wù)”，本書第5章也會對如何解決這些問題提供對應(yīng)不同方案的權(quán)衡。

12要素
“12要素”英文全稱是The Twelve-Factor App，最初由Heroku的工程師整理起步，是集體貢獻(xiàn)總結(jié)的智慧，如圖1-9所示。根據(jù)基于云的軟件開發(fā)模式，12要素比較貼切地描述了軟件應(yīng)用的原型，并詮釋了使用原生云應(yīng)用架構(gòu)的原因。比如，一個優(yōu)雅的互聯(lián)網(wǎng)應(yīng)用在設(shè)計過程中，需要遵循的一些基本原則和云原生有異曲同工之處。通過強(qiáng)化詳細(xì)配置和規(guī)范，類似Rails的基于“約定優(yōu)于配置”（convention over configuration）的原則，特別在大規(guī)模的軟件生產(chǎn)實踐中，這些約定非常重要，從無狀態(tài)共享到水平擴(kuò)展的過程，從松耦合架構(gòu)關(guān)系到部署環(huán)境。基于12要素的上下文關(guān)聯(lián)，軟件生產(chǎn)就變成了一個個單一的部署單元；多個聯(lián)合部署的單元組成一個應(yīng)用，多個應(yīng)用之間的關(guān)系就可以組成一個復(fù)雜的分布式系統(tǒng)應(yīng)用。

圖1-9 12要素

下面簡要介紹圖1-9中的這些原則。相信很多開發(fā)者在實際開發(fā)工作中已經(jīng)很好地應(yīng)用了其中的一些原則，只是沒有意識到概念本身。對這些原則比較陌生的開發(fā)者，如果想了解更多的操作過程，請參閱《云原生時代下的12要素（12-Factor）應(yīng)用與實踐》一文。

基準(zhǔn)代碼
每一個部署的應(yīng)用都在版本控制代碼庫中被追蹤。在多個部署環(huán)境中，會有多種部署實例，單個應(yīng)用只有一份代碼庫，多份部署相當(dāng)于運行了該應(yīng)用的多個實例，比如開發(fā)環(huán)境一個實例，測試環(huán)境、生產(chǎn)環(huán)境都有一個實例。

實際上，在云計算架構(gòu)中，所有的基礎(chǔ)設(shè)施都是代碼配置，即Infrastructure as Code（IaC），整個應(yīng)用通過配置文件就可以編排出來，而不再需要手工的干預(yù)，做到基礎(chǔ)服務(wù)也是可以追蹤的。

依賴
應(yīng)用程序不會隱式依賴系統(tǒng)級的類庫，通過依賴清單聲明所有依賴項，通過依賴隔離工具確保程序不會調(diào)用系統(tǒng)中存在，但清單中未聲明依賴項，并統(tǒng)一應(yīng)用到生產(chǎn)和開發(fā)環(huán)境。比如通過合適的工具（例如Maven、Bundler、NPM），應(yīng)用可以很清晰地對部署環(huán)境公開和隔絕依賴性，而不是模糊地對部署環(huán)境產(chǎn)生依賴性。

在容器應(yīng)用中，所有應(yīng)用的依賴和安裝都是通過DockerFile來完成聲明的，通過配置能明確把依賴關(guān)系，包括版本都明確地圖形化展示出來，不存在黑盒。

配置
環(huán)境變量是一種清楚、容易理解和標(biāo)準(zhǔn)化的配置方法，將應(yīng)用的配置存儲于環(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)境變量使用。

后端服務(wù)
不用區(qū)別對待本地或第三方服務(wù)，統(tǒng)一把依賴的后端作為一種服務(wù)來對待，例如數(shù)據(jù)庫或者消息代理，作為附加資源，同等地在各種環(huán)境中被消耗。比如在云架構(gòu)的基礎(chǔ)服務(wù)中，計算、網(wǎng)絡(luò)、存儲資源都可以看作是一種服務(wù)去對待使用即可，不用區(qū)分是遠(yuǎn)程還是本地的。

構(gòu)建、發(fā)布、運行
應(yīng)用嚴(yán)格區(qū)分構(gòu)建、發(fā)布、運行這3個階段。3個階段是嚴(yán)格分開的，一個階段對應(yīng)做一件事情，每個階段有很明確的實現(xiàn)功能。云原生應(yīng)用的構(gòu)建流程可以把發(fā)布配置挪到開發(fā)階段，包括實際的代碼構(gòu)建和運行應(yīng)用所需的生產(chǎn)環(huán)境配置。在云原生應(yīng)用中，基于容器的Build-Ship-Run和這3個階段完全吻合，也是Docker對本原則的最佳實踐。

進(jìn)程
進(jìn)程必須無狀態(tài)且無共享，即云應(yīng)用以一個或多個無狀態(tài)不共享的程序運行。任何必要狀態(tài)都被服務(wù)化到后端服務(wù)中（緩存、對象存儲等）。

所有的應(yīng)用在設(shè)計時就認(rèn)為隨時隨地會失敗，面向失敗而設(shè)計，因此進(jìn)程可能會被隨時拉起或消失，特別是在彈性擴(kuò)容的階段。

端口綁定
不依賴于任何網(wǎng)絡(luò)服務(wù)器就可以創(chuàng)建一個面向網(wǎng)絡(luò)的服務(wù)，每個應(yīng)用的功能都很齊全，通過端口綁定對外提供所有服務(wù)，比如Web應(yīng)用通過端口綁定（Port binding）來提供服務(wù)，并監(jiān)聽發(fā)送至該端口的請求（包括HTTP）。

在容器應(yīng)用中，應(yīng)用統(tǒng)一通過暴露端口來服務(wù)，盡量避免通過本地文件或進(jìn)程來通信，每種服務(wù)通過服務(wù)發(fā)現(xiàn)而服務(wù)。

并發(fā)
進(jìn)程可以看作一等公民，并發(fā)性即可以依靠水平擴(kuò)展應(yīng)用程序來實現(xiàn)，通過進(jìn)程模型進(jìn)行擴(kuò)展，并且具備無共享、水平分區(qū)的特性。

在互聯(lián)網(wǎng)的服務(wù)中，業(yè)務(wù)的爆發(fā)性隨時可能發(fā)生，因此不太可能通過硬件擴(kuò)容來隨時提供擴(kuò)容服務(wù)，需要依賴橫向擴(kuò)展能力進(jìn)行擴(kuò)容。

易處理
所有應(yīng)用的架構(gòu)設(shè)計都需要支持能隨時銷毀的特點，和狀態(tài)的無關(guān)性保持一致，允許系統(tǒng)快速彈性擴(kuò)展、改變部署及故障恢復(fù)等。

在云環(huán)境中，由于業(yè)務(wù)的高低峰值經(jīng)常需要能實現(xiàn)快速靈活、彈性的伸縮應(yīng)用，以及不可控的硬件因素等，應(yīng)用可能隨時會發(fā)生故障，因此應(yīng)用在架構(gòu)設(shè)計上需要盡可能無狀態(tài)，應(yīng)用能隨時隨地拉起，也能隨時隨地銷毀，同時保證進(jìn)程最小啟動時間和架構(gòu)的可棄性，也可以提供更敏捷的發(fā)布及擴(kuò)展過程。

環(huán)境等價
必須縮小本地與線上差異，確保環(huán)境的一致性，保持研發(fā)、測試和生產(chǎn)環(huán)境盡可能相似，這樣可以提供應(yīng)用的持續(xù)交付和部署服務(wù)。

在容器化應(yīng)用中，通過文件構(gòu)建的環(huán)境運行能做到版本化，因此保證各個不同環(huán)境的差異性，同時還能大大減少環(huán)境不同帶來的排錯等成本溝通問題。

日志
每一個運行的進(jìn)程都會直接標(biāo)準(zhǔn)輸出（stdout）和錯誤輸出（stderr）事件流，還可以將日志當(dāng)作事件流作為數(shù)據(jù)源，通過集中服務(wù)，執(zhí)行環(huán)境收集、聚合、索引和分析這些事件。

日志是系統(tǒng)運行狀態(tài)的部分體現(xiàn)，無論在系統(tǒng)診斷、業(yè)務(wù)跟蹤還是后續(xù)大數(shù)據(jù)服務(wù)的必要條件中，Docker提供標(biāo)準(zhǔn)的日志服務(wù)，用戶可以根據(jù)需求做自定義的插件開發(fā)來處理日志。

管理進(jìn)程
管理或維護(hù)應(yīng)用的運行狀態(tài)是軟件維護(hù)的基礎(chǔ)部分，比如數(shù)據(jù)庫遷移、健康檢查、安全巡檢等，在與應(yīng)用長期運行的程序相同環(huán)境中，作為一次性程序運行。

在應(yīng)用架構(gòu)模式中，比如Kubernetes里面的Pod資源或者dockerexec，可以隨著其他的應(yīng)用程序一起發(fā)布或在出現(xiàn)異常診斷時能通過相關(guān)的程序去管理其狀態(tài)。

云原生的內(nèi)容非常廣泛，目前沒有系統(tǒng)的說明和完整的定義，上文介紹了云原生應(yīng)用的基礎(chǔ)組件和相關(guān)特點，可能讀者對云原生應(yīng)用的邏輯還存在一些困惑。為了更清楚地進(jìn)行說明，我們總結(jié)了其依賴關(guān)系，如圖1-10所示。

圖1-10 云原生內(nèi)容的依賴關(guān)系

首先，為了抓住商業(yè)機(jī)會，業(yè)務(wù)需要快速迭代，不斷試錯，因此，企業(yè)需要依賴擁有持續(xù)交付的能力，這些不僅包括技術(shù)需求還包括產(chǎn)品的需求，如何能擁有持續(xù)交付的能力，大而全的架構(gòu)因為效率低下，顯然是不合適的。于是演變出微服務(wù)架構(gòu)來滿足需求，通過把系統(tǒng)劃分出一個個獨立的個體，每個個體服務(wù)的設(shè)計依賴需要通過12要素的原則來規(guī)范完成。同樣，如果系統(tǒng)被分成了幾十個甚至幾百個服務(wù)組件，則需要借助DevOps才能很好地滿足業(yè)務(wù)協(xié)作和發(fā)布等流程。最后，DevOps的有效實施需要依賴一定的土壤，即敏捷的基礎(chǔ)設(shè)施服務(wù)，現(xiàn)實只有云計算的模式才能滿足整體要求。通過上述梳理，我們總結(jié)出面向云原生應(yīng)用的3個不同層次的特點。

高可用設(shè)計（Design for Availability），依據(jù)應(yīng)用業(yè)務(wù)需求，高可用分為不同級別，比如不同區(qū)域、不同機(jī)房（跨城或同城）、不同機(jī)柜、不同服務(wù)器和不同進(jìn)程的高可用，云原生應(yīng)用應(yīng)該根據(jù)業(yè)務(wù)的可用性要求設(shè)計不同級別的架構(gòu)支持。

可擴(kuò)展設(shè)計（Design for Scale），所有應(yīng)用的設(shè)計是無狀態(tài)的，使得業(yè)務(wù)天生具有擴(kuò)展性，在業(yè)務(wù)流量高峰和低峰時期，依賴云的特性自動彈性擴(kuò)容，滿足業(yè)務(wù)需求。

快速失敗設(shè)計（Design for Failure），即包括系統(tǒng)間依賴的調(diào)用隨時可能會失敗，也包括硬件基礎(chǔ)設(shè)施服務(wù)隨時可能宕機(jī)，還有后端有狀態(tài)服務(wù)的系統(tǒng)能力可能有瓶頸，總之在發(fā)生異常時能夠快速失敗，然后快速恢復(fù)，以保證業(yè)務(wù)永遠(yuǎn)在線，不能讓業(yè)務(wù)半死不活地僵持著。

通過上面的基本描述及云原生應(yīng)用的組成或特點，與容器技術(shù)（第2章將詳細(xì)介紹）相比可以得知，容器的特性天生就是按這些原則進(jìn)行設(shè)計的。隨著互聯(lián)網(wǎng)業(yè)務(wù)的架構(gòu)不斷演進(jìn)，從單體應(yīng)用到分布式應(yīng)用，甚至微服務(wù)架構(gòu)應(yīng)用中，12要素較好地為構(gòu)建互聯(lián)網(wǎng)化應(yīng)用提供了統(tǒng)一的方法論和標(biāo)準(zhǔn)化，具有強(qiáng)大的生命力，每一條原則都是應(yīng)用開發(fā)的珠璣。當(dāng)然，在實踐過程中，每一個原則也不是一成不變的，隨著新的理念和技術(shù)出現(xiàn)，原有的因素會得到延伸和發(fā)展，會出現(xiàn)新的原則和應(yīng)用，這套理論也適用于任意語言和后端服務(wù)（數(shù)據(jù)庫、消息隊列、緩存等）開發(fā)的應(yīng)用程序，因此也作為云原生架構(gòu)應(yīng)用的基本指導(dǎo)原則之一。

本文節(jié)選自《云原生應(yīng)用架構(gòu)實踐》，網(wǎng)易云基礎(chǔ)服務(wù)架構(gòu)團(tuán)隊著，全程詳解單體到分布式服務(wù)化架構(gòu)的演進(jìn)。更多精彩內(nèi)容，敬請期待下期分享。

文/網(wǎng)易云基礎(chǔ)服務(wù)架構(gòu)該團(tuán)隊

網(wǎng)易云計算基礎(chǔ)服務(wù)為您提供容器服務(wù)，歡迎點擊免費試用。

文章來源： 網(wǎng)易云社區(qū)