應用開發的模式，無論是團隊還是個人都在不斷的發展，開源為軟件行業提供了很多工具、框架、平臺和操作系統，它們都越來越關注與靈活性和自動化，當今最流行的開源工具主要都集中在一些特性上，這些特性使得團隊能夠在開發和運維的各種級別上，不斷地交付應用，較之以往，效率大為提升。
亞馬遜的故事
從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——當當網的云原生之路》）
