數人云|兩個故事,看12要素如何助力亞馬遜和Netflix開啓雲原生大門

雲原生體系圖

應用開發的模式，不管是團隊仍是我的都在不斷的發展，開源爲軟件行業提供了不少工具、框架、平臺和操做系統，它們都愈來愈關注與靈活性和自動化，當今最流行的開源工具主要都集中在一些特性上，這些特性使得團隊可以在開發和運維的各類級別上，不斷地交付應用，較之以往，效率大爲提高。

亞馬遜的故事

從20世紀90年代初開始，一家總部位於西雅圖的在線書店開始成爲世界上最大的在線零售商，2015年，亞馬遜超越沃爾瑪成爲美國最具價值的零售商，關於它無與倫比的增加故事中，最有趣的部分能夠總結爲一個簡單的問題：做爲一個簡單的在線書店，一個網站如何轉變成爲世界上最大的零售商之一？

不難看出，在全球各地愈來愈多的企業介入互聯網，使電子商務的世界發生了改變和重塑，隨着我的電腦設備變得愈來愈小，智能手機、平板電腦，甚至智能手錶無處不在，在分銷渠道的可訪問性方面經歷了指數級增加，直接改變了世界商業的方式。

亞馬遜首席技術官Werner Vogels見證了亞馬遜從一家很是成功的在線書店到世界上最具價值的科技公司和產品零售商的這種技術衍變。2006年6月Vogels接受了計算機雜誌ACM的採訪：這是一項技術選擇的快速發展，這一技術爲亞馬遜的增加提供了動力，在採訪中，Vogles談到了背後的核心驅動力，在亞馬遜的技術發展中，有很大一部分是爲了實現這一持續的增加，在保持可用性和性能的同時，實現了超可擴展性。

對於亞馬遜來講，要實現這一能力，須要轉向不一樣的應用架構模式，其提到亞馬遜是一個單一的應用，隨着時間的推移，愈來愈多的團隊在同一個應用上運行，代碼庫全部權的界限開始變得模糊，Vogels說：沒有孤立的狀況，所以也就沒有明確的全部權。

Vogels指出，像數據庫這樣的共享資源，使其很難擴展整個業務，共享資源的數量越多，不管是應用服務器仍是數據庫，當將特性交付到生產環境時，控制團隊就越少。

他觸及了一個共同的主題：雲應用共享，團隊擁有他所構建東西的想法，他說：傳統的模式是，將應用開發出來，而後又將開發運維分離，開發將應用拋給運維就撒手無論了。

在一些全球最重要的軟件會議上，一些著名的演講嘉賓都引用了一句最經常使用的名言——You build it，you run it。這句話後來成爲了咱們今天所熟知的DevOps口號。

Vogels在2006年談到的許多實踐都是當今流行概念的影子，如DevOps和微服務這樣的實踐。儘管相似於亞馬遜這種大型互聯網公司正在開發相似的應用，但，圍繞這些想法的工具須要數年的時間才能開發併成熟爲一種服務。

2006年，亞馬遜推出了一款名爲Amazon Web Service（AWS）的新產品，其理念是提供一個與亞馬遜內部使用的平臺相同的平臺，並將其做爲服務發佈給公衆，亞馬遜迫切但願看到這個平臺背後的理念和工具的商業化，Vogels推出的許多想法都已經在亞馬遜的平臺上創建了，經過該平臺發佈爲公衆服務，亞馬遜將進入一個名爲「公有云」的新市場。

公有云背後的邏輯是合理的，虛擬資源能夠按需供應，而無需擔憂底層基礎設施，開發者能夠簡單地租用虛擬機來存放他們的應用，無需購買或管理基礎設施，這是一種低風險的自助服務，它將有助於提供公有云的吸引力，而AWS一直在採用方面保持着領先。

AWS將須要數年時間才能造成一套用於構建和運行應用的服務以及模式，這些應用都是在公有云上運行的，雖然許多開發人員都涌向這些服務去構建新的應用，但對於不少公司來講，遷移是一大難題，由於現有的應用不是爲了可移植性而設計的，此外許多應用仍然依賴於與公有云不兼容的遺留工做負載。

爲了讓大多數公司可以利用公有云，他們須要改變開發應用的方式。

平臺

平臺，是時下常被說起的一個詞。

當討論計算的平臺時，一般討論的是一組幫助構建或運行應用的能力，平臺最能歸納的是，它們對開發者如何構建應用施加了約束。

平臺可以自動完成對應用的業務需求不十分重要的那些任務，這使得開發團隊更加靈活，由於他們只支持那些有助於區分業務價值的特性。

任何編寫過Shell腳本或已標記的容器和虛擬機來實現自動化部署的團隊都已經構建了一個平臺，問題是：這個平臺能保證什麼？爲持續交付新應用所需的大多數（甚至所有）的需求須要作多少工做？

當構建平臺時，其實正在構建一個工具，能夠自動化一組可重複的實踐。實踐是由一組將有價值的想法轉化爲計劃的約束所制定的。

想法：平臺的核心理念是什麼？爲何它們具備價值？
約束：將平臺的想法轉化爲實踐的比較條件是？
實踐：將約束自動化到一組可重複的實踐中？
每一個平臺的核心都是簡單的想法，當實現時，經過使用自動化工具來增長不一樣的業務價值。

以亞馬遜平臺爲例，Vogels說，經過增長應用組件之間的隔離，團隊能夠對他們的交付特性進行更多的控制。

想法：

• 經過增長應用組件之間的隔離，可以快速且獨立地交付系統的一部分。

經過將這個想法做爲平臺的基礎，咱們能夠將其變成一組約束，約束以一種觀點的形式出現，關於核心理念是如何在自動化的實踐中創造價值的，下面的語句是關於如何提升組件隔離性的一些限制。

約束：

• 應用組件將做爲獨立的可部署服務構建。
• 服務中全部業務邏輯都封裝在它所操做的數據中。
• 從服務外部沒法直接訪問數據庫。
• 服務將發佈一個Web接口，該接口容許從其餘服務訪問其業務邏輯。

有了這些限制，對於如何在實踐中增長應用組件的隔離性有了必定的認知，當自動化到實踐時，這些約束的Promise將爲團隊提供更多的控制，以控制特性是如何交付的生產的？下一步是描述如何將這些約束捕獲到一組可重複的實踐中。

從這些約束中派生出來的實踐應該做爲Promise的集合來聲明，經過將實踐表述爲Promise，咱們對平臺的用戶保持了對他們如何構建和操做應用的預期。

實踐：

• 向團隊提供了一個自助服務接口，容許提供操做應用所需的基礎設施。
• 數據庫以服務的形式提供給應用程序，並使用自助服務接口進行供應。
• 應用是做爲環境變量提供給數據庫的憑證，但前提是在聲明與數據庫的明確關係做爲服務綁定以後。
• 每一個應用都提供了一個服務註冊表，該服務註冊表被用做在何處定位外部服務依賴項的清單。

上面列出的每一個實踐都以向用戶Promise的形式呈現，這樣，平臺核心思想的意圖就會被用於應用的約束來實現。

雲原生應用是創建在一組約束的基礎上的，這些約束能夠減小在進行無差別的繁重工做時所花費的時間。

AWS首次向公衆發佈時，亞馬遜不強迫用戶遵循相同的約束，他們在內部用於Amazon.com.Staying Amazon Web服務名稱，AWS自己不是一個雲平臺，而是獨立的基礎設施服務的集合，能夠組合成自動化工具相似於一個平臺的Promise，在AWS的第一次發佈後的幾年裏，亞馬遜開始提供一系列管理平臺服務，從物聯網到機器學習。

若是每一個公司都須要從頭開始構建本身的平臺，那麼在應用程序中交付價值的時間就會被延遲，直到平臺徹底組裝好，早期採用AWS的公司須要將一些相似平臺的自動化設備組裝在一塊兒，每家公司都必須在一系列的Promise中進行，這些Promise抓住瞭如何開發和交付應用的核心理念。

最近，每一個雲平臺都應該有一套基本且共同的Promise，經過使用開源平臺做爲服務（PaaS）雲計算，這些Promise將在本文中獲得探索，雲計算背後的核心動機是提供一個平臺，它封裝了一套用於快速構建和操做的通用Promise，雲計算公司作出了這些Promise，同時還提供了許多個不一樣的雲基礎設施提供商之間的可移植性。

這本書的主題是如何構建雲原生Java應用，咱們將主要關注工具和框架，經過利用雲平臺的有點和Promise，幫助減小未分化的繁重工做。

模式

如何運用新模式去開發應用，會令人更深刻地思考應用在生產中的行爲，開發和運維都更增強調他們的應用如何在生產中運行，在失敗的狀況下更少的保證複雜性將如何破解。

與Amazon.com的狀況同樣，應用開始遠離大型的且單一的模式，如今架構的重點是在不犧牲性能和可用性的狀況下實現超可伸縮性，經過分解一個龐然大物的組成部分，工程組織正在努力分散變動管理，爲團隊提供更多的控制，使它們可以更好地控制產品的生產方式，經過增長組件之間的隔離，開發團隊開始進入分佈式系統開發的世界，重點是構建更小、更專一的服務，並具備獨立的發佈週期。

雲原生利用了這一組模式，讓團隊在向生產交付特性時更加敏捷，隨着應用的分佈愈來愈分散（爲了向擁有應用的團隊提供更多的控制所必須的隔離的結果。）在應用組件通訊方式中失敗的集成會成爲了一個重要的關注點，隨着應用程序轉變爲複雜的分佈式系統，操做失敗是不可避免的。

雲原生架構提供了超可伸縮性的好處，同時仍然保證了應用的整體可用性和性能，儘管如亞馬遜這樣的公司在雲計算中得到了超可伸縮性的好處，但普遍使用的用於構建雲原生應用的工具還沒有浮出水面，這個工具和平臺最終將做爲一個由公有云早期開拓者維護的開源項目的集合而被開發出來：Netflix。

可靠性

團隊之間（開發、運維、測試等）自薦創建的指望是契約，這意味着提供或使用某種級別的服務，經過觀察團隊在開發應用過程當中如何爲彼此提供服務，咱們能夠更好地理解通訊中的失敗是如何致使風險從而失敗的。

建立團隊之間的服務協議是爲了減小爲業務帶來價值的總體功能意外行爲的風險，團隊之間的服務協議是要明確的，以保證行爲與預期的運營成本一致，經過這種方式，服務可使業務單元最大化其總輸出，應用業務的目標是經過成本——咱們稱之爲可靠性的成本去預測價值的創造。

業務的服務模型與構建應用時使用的模型相同，這就是如何保證系統的可靠性，不管是在生產應用中自動化功能，仍是在培訓的人員執行手工操做的狀況下。

敏捷性

由於再也不是隻有一種開發和運維應用的方法，在採用敏捷方法和將應用做爲服務（SaaS）業務模型的推進下，愜意應用堆棧正變得愈來愈分佈式，開發分佈式系統是一項複雜的任務，向公司提供更分佈式的應用架構的作法，是因爲須要更快地交付應用，而且減小了失敗的風險。

注意項

最近有一些人在盛傳敏捷已死這種理念，但正如咱們所說，敏捷其實指的是一種以組織爲單位的熱情來傳遞新的價值以及快速響應的想法，條條大路通羅馬，本文不關心你所信奉的管理實踐，關鍵是要明白敏捷是一種價值，而不是目標。

現代應用定義業務尋求重組其開發過程，以使應用項目更快地交付，並將應用持續地部署到生產中，不只是公司想要提升應用的開發速度，並且還要增長他們建立和運維應用的數量，以服務於一個組織的各類業務單位。

應用正日益成爲企業的競爭優點，更快和更好的工具能讓業務專家打開新的收入來源，或者以促進快速創新的方法優化業務功能。這場運動的核心是雲計算，當談論雲計算時，咱們討論的是一組很是具體的技術，這些技術使開發和運維可以利用現有的Web服務來提供和管理虛擬計算基礎設施。目前的企業正開始走出數據中心，進入公有云階段，Netflx，正式一家流行的基於訂閱的流媒體公司。

Netflix的故事

目前，Netflix是世界上最大的按需流媒體服務公司之一，在雲服務中運營期在線服務，Netflix於1997年在加州由Reed Hastings 和 Marc Randolph創立，最開始Netflix提供了一種在線DVD租賃服務，容許用戶每個月付費訂閱無限制的電影，而不收取其餘任何費用。

2008年，Netflix經歷了一場嚴重的數據庫故障，使得該公司沒法將任何DVD郵寄給客戶，當時，Netflix剛剛開始向客戶提供流媒體視頻服務，其流媒體團隊意識到，相似的服務中斷將對其將來業務形成毀滅性的打擊，所以，Netflix作出了一個相當重要的決定：採起一種不同凡響的方式開發和運行應用，確保客戶永遠都是使用服務。

所以它們決定放棄垂直規模的基礎設施和單一的失敗點，實現是數據庫損壞的結果，這是使用錘石伸縮的關係數據庫結果，Netflix將其客戶數據遷移到一個分佈式的NoSQL數據庫，是一個名爲Apache Cassandra的開源數據庫項目。這也被視爲「雲原生」公司的開始，將全部的應用做爲高度分佈式和彈性的服務在雲中運行，Netflix公司經過向其應用和數據庫中添加冗餘來增長其在線服務的健壯性，並在一個擴展的基礎設施模型中增長了冗餘。

做爲遷移到雲端的一部分，Netflix決定將其龐大的應用部署遷移到高度可靠的分佈式系統上，但這面臨着一個重大的挑戰：Netflix的團隊將不得不從新架構應用，同時從一個內部數據中心轉移到公有云，2009年，Netflix開始向Amazon Web Service（AWS）遷移，並專一於三個主要的目標：可伸縮性、性能、和可用性。

很明顯，2009年初的需求將大幅度增長，事實上，Netflix的雲計算和平臺工程副總裁ury Izrailevsky在2013年的AWS大會上表示，自2009年依賴，該公司已經增長了100倍。

此外，他還指出，當考慮到期快速的全球擴張時，可伸縮性在雲計算中的優點變得更加明顯「爲了給咱們的歐洲客戶提供更好的低延遲體驗，咱們在愛爾蘭推出了第二個雲計算區，在不一樣的地區創建一個新的數據中心須要花費數月的時間和數百萬美圓的資金，這是一個巨大的投資。」

隨着Netflix開始在Amazon Web Service上託管應用，員工們在Netflix公司的博客上記錄了他們的學習經驗，Netflix的許多員工都在提倡一種新的架構，這種架構專一於軟件棧的各個層面的水平可擴展性。

John Ciancutii當時是Netflix的個性化技術副總裁，他在2010年的公司博客上寫道：雲環境是水平擴展機構的理想選擇，咱們沒必要猜想將來幾個月咱們的硬件、存儲和網絡需求將會是什麼樣子的，能夠經過編程方式從Amazon Web Service中的共享池中訪問更多資源。

Ciancutti所說的「以編程方式訪問」資源的意思是，開發和運維能夠經過編程的方式訪問由Amazon Web Service公開的某些管理API，以給客戶提供一個用於提供他們的虛擬計算基礎設施的控制器，RESTful API爲開發人員提供了一種構建管理和爲其應用提供虛擬基礎設施的應用的方法：

Ps：爲控制虛擬計算基礎設施提供管理服務是雲計算的主要概念之一，稱爲基礎設施即服務，一般稱爲IaaS。

雲計算堆棧

Ciancutti在同一片博客文章中坦白，Netflix並不商場預測客戶的增加或設備的參與，這是雲原生企業背後的一個核心主題，雲原生是一種心態，它認可沒法可靠地預測什麼時候何地須要容量。

在Yury Izrailevsky 2013年的演講中，他說：在雲計算中，隨着流量的增長，咱們能夠在幾天內提升產能，當咱們成爲一家全球性公司的時候，咱們能夠依靠在世界各地的多個亞馬遜網絡服務區，不管他們在哪裏，都能給咱們的客戶提供一個很好的互動體驗。」

受益於AWS國際擴張的規模經濟也讓Netflix受益，隨着AWS向美國之外地區擴展了可用性區域，Netflix只使用AWS提供的管理API擴大了氣服務範圍。

Izrailevsky引用了企業雲計算的廣泛觀點：「固然，雲計算很是好，但對於咱們來講太貴了。」他對這一觀點的迴應是：「Netflix遷移到雲，運維成本降低了87%，所支付的費用，是以前數據中心支付的八分之一。」

Izrailevsky進一步解釋了爲何雲計算爲Netflix提供瞭如此巨大的成本節省：在不擔憂容量緩衝的狀況下，可以實現增加是頗有幫助的。隨着成長，又能夠擴大需求。

微服務

雲原生應用和微服務是齊頭並進的，構建微服務的主要思想之一是讓功能團隊圍繞特定的業務功能組織本身和應用，這種方法不管如何都不是特別新穎，從小型的分佈式組件中建立一個系統，這些組件能夠很好地工做，並以這樣的方式拆分，以儘量減小將單個特性交付到生產環境中的阻力，這幾十年來一直是可能的，那麼，爲何這種構建模式如今才流行起來？這和雲有什麼關係嗎？

構建應用之一都很困難，理智與行爲之間的區別每每是別人剝奪了你本身糟糕的選擇結果，昨天作出的技術決策將會妨礙你明天作出正確決策的能力。

理解一件小事很容易，但要理解它的缺失所帶來的影響則要困可貴多，若是咱們仔細研究一個設計良好的單片應用，咱們將看到相似的驅動，若是咱們在今天的微服務架構中看到的模塊化、簡單性和鬆耦合，固然，其中一個主要的區別是歷史，不難理解，選擇層如何將精心設計的東西變成了一個糟糕的東西。若是一我的在架構的一個可替換單元中作出了糟糕的選擇，那麼這個選擇就會隨着時間的推移而變得更容易分解，可是，若是同一我的在設計一個精心準備的龐然大物的多個獨立模式上工做，那麼額外的歷史可能會影響到其餘人之後作出理想選擇的能力，所以，最終不得不妥協，被迫在一些從未有機會作出的選擇上作出稍微更好的決定，而這些選擇是咱們從未有過的。

想要改變的應用就變成了一種生活的東西——老是被歷史所改變，永遠不會對生存之風的變化免疫，正因如此，必須以改變爲基礎，必須擁抱變革，同時抵制將來構建的誘惑，畢竟，將來的設計知識一種華麗的設計，把它裝扮成敏捷的開發，不管咱們多麼聰明，在預先設計完美的系統時，都沒法準確地預測它的功能在將來會發生怎樣的變化，由於一般狀況下，它不會由咱們來決定，市場傾向於決定產品的命運，正因如此，只能在頭腦中進行設計。

微服務只是一個想法，模式和實踐在一個流體狀態下仍然波動，而耐心地等待一個穩定的定義，他們在更普遍的垂直領域的擁抱——更好仍是更糟——還有待最終裁決。

有兩種主要的力量影響着架構變化的速度：微服務和雲計算，雲計算極大地下降了管理基礎設施所需的成本和工做量，目前，咱們可以使用自助服務工具爲應用程序提供基礎設施，由此，新的、創新的開始迅速地成爲現實，使咱們從新思考和重塑之前的管理，以前關於構建應用的真實狀況多是不真實的，在大多數狀況下，真相被是被掩蓋的，如今咱們發現本身須要在反覆無常的假設基礎上作出艱難的決定：服務器是物理的，而虛擬機是永久的，容器是無狀態的。

Splitting the Monolith

Netflix列舉了從一個單一的龐然大物中遷移到分佈式架構的兩個主要好處：敏捷性和好處。

在使用雲以前，Netflix的架構包括一個單一的Java虛擬機（JVM）應用，雖然擁有一個大型的應用程序部署有不少優勢，但主要的缺點在於開發團隊因爲須要協調變動而減緩效率。

當構建和運維應用時，集中化下降了需求協調的成本增長的風險，協調須要時間，應用體系構建越集中，就月須要花費更多的時間去協調對其中任何一項的更改。

一體化也不太可靠，當組件在相同的虛擬機上共享資源時，一個組件中的故障可能會蔓延到其餘組件，從而致使用戶宕機，當團隊須要協調他們的變動時，在一個單一的塊中作出一個變動的風險會增長，在單個發佈週期中發生的變化越多，就越有可能形成宕機，經過將一個單一的塊分割成更小、更專一的服務，能夠在團隊的獨立發佈週期中使用較小的批處理大小來進行部署。

Netflix不只須要改變其構建和運營應用的方式，還須要改變其組織文化，Netflix轉向了一種名爲DevOps新的操做模式，在這個操做重視中，每一個團隊都變成了一個產品組，遠離了傳統的項目組結構，在一個產品中，團隊是垂直的，在每一個團隊中嵌入運維和產品管理，產品團隊會擁有他們所需的一切構建和運維應用。

Netflix OSS

隨着Netflix轉型爲一家雲計算公司，它也開始積極參與開源項目，2010年底，時任系統與電子商務工程副總裁的Kevin McEntee在一篇文章裏所：該公司將來將在開源領域發揮做用。他說，一個號的開源項目可以解決一個共同的挑戰，那就是它發展了本身的動力，而且在持續改進的良性循環中持續很長一段時間。

在這一宣佈以後的幾年間，Netflix開放了超過50個內部項目，每一個項目都成爲了Netflix戰略品牌的一部分。

2012年7月，Netflix的雲平臺工程主管Ruslan Meshenberg在公司的技術博客上發表了一篇文章，這篇博客的文章：《Netflix的開源》解釋了爲何Netflix纔去瞭如此大膽的舉措，開源瞭如此多的內部工具。

Meshenberg在博客中寫道：「Netflix是一個早期的雲採用者，將咱們全部的流媒體服務都在AWS的基礎設施上運行」。

Netflix爲開源社區和技術生態系統作出的文化動機被認爲與微觀經濟概念背後的原則緊密相關，即規模經濟，在被稱爲「雲時代」到來之際，Netflix發現它的先去不是如IBM或微軟這樣的科技公司，而是誕生在互聯網背後的公司，Netflix和亞馬遜都是始於90年代末的網絡公司，都是經過提供旨在與實體公司競爭的在線服務而起家。

目前，Netflix和亞馬遜都已經大大超過了同類型實體店的估值，隨着亞馬遜進入雲計算市場，它將本身的集體經驗和內部工具轉變爲一套服務，Netflix隨後也在亞馬遜的服務上作了一樣的工做，在此過程當中，Netflix開放了本身的經驗以及工具，轉型爲一家基於亞馬遜AWS提供的虛擬基礎設施服務的雲原生公司，這就是規模經濟推進了雲計算行業革命。

2015年初，據報道Netflix的第一季度財報顯示，該公司的估值達到了329億美圓。

雲原生Java

Netflix向軟件行業提供了豐富的只是，這是它成爲雲原生公司的結果，本文借鑑Netflix的經驗和開源項目，並將其做爲一套模式，其中有兩個主題：

使用Spring和Netflix操做系統構建具備彈性的分佈式系統
使用雲計算，持續交付來操做本地雲原生應用

以及雲原生的12要素，12要素的方法是由Heroku雲平臺的建立者編寫的一套流行的應用開發原則。

雲原生12要素的核心思想：

爲安裝自動化使用聲明式格式，以最小化新開發人員加入項目的時間和成本
與底層操做系統有一個明確的契約，在執行環境之間提供最大的可移植性
適用於現代雲平臺上的部署，從而避免了服務器和系統管理的需求
最小化開發和生產之間的差別，從而實現最大敏捷性的持續部署
而且能夠在沒有對工具、架構或開發實踐進行重大更改的狀況下進行擴展

雲原生的12要素能夠幫助構建利用這些想法的應用，它是一套基本的約束，能夠用來構建雲原生應用，因爲這些因素涵蓋了全部現代雲平臺的常見實踐，所以構建12要素應用是雲本地應用開發的一個常見起點。

圖片摘自網絡

上圖是12條因素即12條軍規，這裏挑幾個重要進行講解：

Codebase：和整個測試環境有關，你們拉基線是爲了整個版本的穩定性。

依賴：要解決依賴的問題，若用Java的話，意義不大，原始上會有依賴管理，但電商公司有各類語言都很是原始，直接依賴於源代碼，若其版本發生變化，有些API就編譯不過去。

Configuration：Java和其餘語言很是衝突就在於此，作Java的同窗都知道配置通常都會打在根應用的生產日報裏，會有大量的配置文件，上到雲應用，讓底層人員運行做業炸包，首先就要配置文件，一切配置要麼走配置中心，連訪問配置中心的地址可能也是外部注入進來，不用再去配置上聲明整個中心是什麼；要麼是全部的配置都由平臺幫助注入，不能本身攜帶相關的Jap去作，原來整個構建，底下會有一些構建的模式，以前構建最先版本很是有意思，好比大了一個測試環境的炸包，若沒問題，便可交給運維，由於配置VI裏面徹底不同，會在應用和部署的公共機器時，有自動替換配置文件的動做，要替換的配置文件其實也是預先上傳到平臺上的，整個發佈平臺會幫助作一個配置文件的替換，方式很原始，不是運行它去改配置，由於包本質上是變化的，配置文件屬於包的一部分，所以它也是變更的，等於整個包的密封性被打破了，此時去上一個雲原生的平臺，首先要作的是滅配置文件，要經過環境變量或啓動平參數的模式去啓動應用，這時平臺能自動地把整個環境——生產、預發佈、測試、以及延長等環境，將不一樣的配置設置好，因此這一點對開發來講改動比較大，正常上這種雲應用，最難的是將配置問題解決，由於大量的Java配置都是在文件中進行，包括內部有框架的，特定的文件，將這些都清除掉。

Backing Services：即不要把依賴服務徹底寫死，依賴服務也是經過環境注入進來，如數據庫鏈接，能夠經過外部配置進來。

構建、發佈和運行：要流程化。

進程：進程是微服務的根基，應用應以進程的級別運行，跟原來的方式不一樣，不少功能都是達到一個進程，經過不一樣的線程運行，但有幾個很差的地方，相似於微服務，發佈可能會影響不該影響的一些部分，追蹤也不是很好作，好比噹噹最近在作內部的Tracing，目前只能作到進程間的Tracing，若是內部的線程Tracing須要改造，仍是有一些麻煩的。
端口：相似於一種端口的綁定解決方案，是由編排工具動態注入，要動態監聽一些要發佈的端口信息。

日誌：不該生成文件，而是經過服務的方式將其進行傳遞，整個管理平臺應有自動收集日誌的功能，這也達到了雲原生的態度，要將所要定位的信息不和應用綁在一塊兒，由於應用很快會啓動或註銷，那麼整個軌跡要持久化的保留。

（節選自高洪濤老師的《12條軍規說Dev，3大重點講Ops——噹噹網的雲原生之路》）