本文要點

• 襪子商店應用始于一個簡單的演示應用，之后發現它十分有用，最終演化成一個完全容器化的、云原生參照應用。

• 該應用混合使用了Go、Java、Spring以及Node.js。它擁有完整的持續集成和發布管道，最終會發布到AWS上Kubernetes集群的準生產環境中。

• 其中的API使用了Open API的規范。并且使用了一個名為Dredd的工具，用其獲得swagger規范并且對在容器化的服務上的API進行驗證。

• 襪子商店可以使用獨立Docker、Docker Swarm、Kubernetes、Mesos/Marathon（或DC/OS）、Hashicorp的Nomad以及AWS ECS進行部署。

• 在合并兩個服務成為單個服務時會遇到遠超預期的麻煩。因此建議，在完全理清服務之前，盡量推遲對服務的拆分。

微服務、容器和編排框架是一個不斷變化的領域。每周都有新的工具、服務或產品出現，同時伴隨著新的概念、技術和流行語。為了達到在構建應用時“云端優先”的新興思想，就誕生了云原生（Cloud Native）一詞。然而，試圖確定云原生究竟意味著什么將是徒勞的，因為它所試圖定義的領域正不斷變化著。我們看到最近的一個動向就是云原生計算基金會（Cloud Native Computing Foundation）的成立。它歸屬于Linux基金會，是一個專注于常用技術和開源軟件的非營利性組織。

這看上去正朝著正確的方向發展，但還是沒有能幫我們定義云原生應用到底是什么。我們可以說出一些技術，如容器、編排框架，和一些最佳實踐，如短小、可擴展、靈活，但擁有一個具體的參照往往會更有幫助。這正是我們所一直在構建的。

這就是襪子商店應用，一個真實、完全容器化、采用微服務架構的云原生應用。

該項目一開始是作為DockerCon的一個小型演示應用而誕生的，用于展示由Weave Works開發的一些新服務。作為一家致力于為微服務和基于容器的應用構建產品和工具的公司，他們需要一個真實的應用來演示他們的服務。在兩周內，我們構建了一個大量使用微服務的應用，其中投入了各種技術、編程語言和數據存儲。

相關廠商內容

微信Android模塊化架構重構實踐蘑菇街分布式消息中間件Corgi的架構演進Serverless架構：一條SQL到一個服務有多遠？對抗復雜性，架構設計中可借鑒復用這些手段阿里：風控場景的模型平臺架構設計

相關贊助商

ArchSummit深圳2017，7月7-8日，深圳·華僑城洲際酒店，精彩內容搶先看

初次運行之后，我們看到了持續維護該項目的好處。它既可以作為容器和微服務集中工具的測試平臺，同時可以作為云原生系統的參照應用，這會非常有用。在接下來的幾個月中，我們致力于將此演示應用轉換為可以部署到生產的應用。我們對每個服務進行了徹底改進、按需替換數據存儲、合并高耦合的服務、并添加日志和監控等標準功能。我們還建立了完整的持續集成和交付管道，最終會發布到AWS上Kubernetes集群的準生產環境中。

微服務

云原生應用必須足夠靈活。我們需要快速而獨立地部署，從而讓我們在正確的時間做出正確的決定和變化。這能使組織架構變得敏捷。組織內部應該預期并鼓勵變化而不是極力規避變化。云原生應用注重服務的獨立性。系統的每一部分都不應該相互依賴，以避免造成級聯故障。最后，云原生應用應該是技術無關的。為系統的一個部分選擇編程語言，或者為特定數據集選型關系型數據庫，不應對系統的其他部分造成影響。

顯然，這些不是我們可以通過獨立應用架構來實現的。雖然不是所有情況下都必要，但是云原生應用還是應該構建在微服務之上。在襪子商店應用中，我們積極地在應用中使用“微服務”的理念。

這給了我們諸多好處：我們能夠利用多種持久化技術，即在不同的服務使用不同的數據存儲。我們也可以為每個服務自由地選擇語言。但真正的好處在于開發的速度。由于這是一個開源社區項目，短期內有很多開發人員參與。通過對服務進行適當的隔離，大家可以很容易地融入社區并快速修復bug或在某一服務中添加功能，而無需了解整個架構。

過分微服務化
有觀點認為，一開始就使用微服務架構比轉換現有的獨立應用更加困難。其中一個原因是，在一個全新的項目中，服務之間的邊界并不總那么清晰。如果你的服務沿著錯誤的邊界進行劃分，最終服務間的交互就會過多，而且這可能難以糾正。在我們襪子商店應用早期開發中就遇到這個問題。由于我們激進地對服務進行了劃分，我們創建了一個登錄服務和一個顧客服務。在我們的后續開發中，就發現它們之間的耦合度太高，他們應該是一個服務，而將它們合并成單個服務的過程又比預期設想的要更復雜。所以建議，在完全理清服務之前，盡量推遲對服務的拆分。

容器

微服務的廣泛應用，在很大程度上是由于一些新興技術使我們可以更容易地將應用分割成小而獨立的部分。具體地說，就是容器技術。它為我們提供了輕量化的包裝和工具。

除了越來越多地采用微服務外，容器也是將應用從本地轉移到云端的關鍵。無論是在容器中運行的應用本身，還是應用運行所在的基礎架構，已經運行在容器上十多年的Google Cloud就是一個例子。容器是構成云的一磚一瓦，也是云原生應用的重要組成部分。

在襪子商店應用中，我們在各個部分都采用了容器。我們不光在docker容器上運行我們的服務，更研究了如何在集成和部署管道中利用容器的優勢。

一個例子就在我們的構建過程中。我們希望擁有一致、可重復的構建版本，但是我們不希望在服務的鏡像中包含不必要的工具使其變得臃腫。為了滿足這個需求，我們創建了單獨的鏡像來構建和運行我們的服務。構建的鏡像包含必要的工具，并在任何環境中提供了一致的可重復的生成文件。然后，我們將構建的二進制文件（或jar文件）復制到實際運行服務的最小部署鏡像中。（示例）

我們利用容器優勢的另一個方面是在測試中，這在微服務領域是有明顯不同的。我們的服務規模相當合理，因此可以輕松地測試內部功能。然而，我們的服務有更多的外部依賴，這為測試帶來了一些棘手的問題。

我們測試的一個重點是我們的服務API。因為這些是我們服務間相互通訊的契約。我們使用Open API規范（即Swagger）記錄了我們所有的API，該API規范具有諸多的工具。我們使用了一個名為Dredd的工具，它使用我們的Swagger規范，并在我們容器化的服務上對API進行驗證。當我們將其引入到持續集成管道中時，我們能對所有服務的API進行持續地驗證。所有這些都會在容器中運行，這為我們的操作帶來了可重復性，并且這個過程與運行的平臺無關。

我們創建了一個測試用的Docker鏡像，其中包含了我們的測試框架和Dredd工具。這個容器讀入API（Swagger）規范，并針對我們的真實服務進行API調用，對API規范進行完整的驗證。我們測試框架的生命周期是短暫的，每個測試案例都會自己創建并刪除獨立的環境，并且這個過程與運行環境無關。

編排

構建云原生應用的第三個支柱是編排（orchestration）。一旦我們創建、測試并部署完單個服務，接下來的困難就是管理我們的各個容器，以保持一個穩定而又靈活的運行環境。一旦你有多個容器，手動編排就變得難以管理，我們需要將其自動化。任何應用的主要部分包括運行服務的容器、服務器、存儲和網絡。從這組初始元素中，我們就有了一個理想的狀況：運行應用、服務的發現、容錯、資源的有效利用。理想情況下，這一切都應該在沒有任何手動干預的情況下完成。

幸運的是，有許多工具和平臺想要為我們管理這些。在襪子商店應用中，我們決定在盡可能多的編排平臺上部署我們的應用，而不是選擇某個特定的平臺進行部署。畢竟，作為一個參照應用，它不應該與某個特定的平臺綁定，而作為一個真正的“云原生”應用，它應該在任何編排平臺上都可以正常工作。這種方式的另一個好處是可以讓我們評估和比較不同的工具。在撰寫本文時，襪子商店應用已經可以部署在獨立Docker、Docker Swarm、Kubernetes、Mesos/Marathon（或DC/OS）、Hashicorp的Nomad和AWS ECS上。可以查看對應的文檔。

在大多數情況下，應用在這些平臺上“恰好可以正常工作”。我們只需要根據每個工具的語法調整配置文件就可以實現切換。由于我們所有的組件都是容器化的，部署就變得直截了當。主要需要關注的是網絡。我們使用了WeaveNet插件來滿足我們的容器網絡和DNS需求。在某些情況下這恰好可以滿足需求，但更多情況下這會與工具內置的現存DNS或網絡組件產生沖突。容器網絡接口將是未來的發展方向，但是目前它仍處于早期階段，還不能與所有工具完全集成。

回顧云原生

云原生應用有三個主要支柱：微服務、容器和動態編排。雖然其中經常涉及其他技術，但構建云原生架構應用總會伴隨著關注這三個方面。同時它們也是互補的技術。正如我們在襪子商店應用中看到的那樣，容器技術使構建、測試和部署微服務變得更加容易。添加了編排平臺更使我們能夠自信地大規模運行我們的應用。如果我們要手動管理每個服務的部署、重啟、擴展和調度，我們很快就會變得不堪重負，這樣就會使云原生應用所帶來的好處不足以彌補維持應用運行所需的額外工作。

對于構建云原生應用其他的重要部分包括連續交付管道、全面監控和日志以及追蹤，所有這些都在襪子商店應用中有所使用。

襪子商店應用的下一步發展

既然現在該應用處于穩定狀態，并且我們已經進行了必要的自動化和測試，接下來一個有趣的用例就是替換某些工具、語言、技術，來看看這會帶來什么樣意外的問題，以及這個過程是否能順利進行。微服務架構常提及的優點之一，我認為也是云原生應用的目標，就是模塊化。由于我們的應用的各種部件和基礎設施之間的低耦合，所以可以方便地使用等價的組件替換系統的任何部分。

一個有趣的例子就是我的一個同事使用.NET重新編寫了我們的一個服務。目前在Linux上的.NET Core還相對粗糙，除了由于這個因素所帶來編寫服務的一些挑戰之外，已經可以成功地將我們原來用Java編寫的訂單服務與.NET版本無縫切換。

作為一個稍稍極端的例子，我想嘗試著替換實際的容器運行時，如使用rkt來替代當前的Docker。這將大大有助于展示我們在“云原生”上的發展，并驗證開放容器計劃。

襪子商店應用的目標是成為一個云原生應用的參照，也可用作相關技術、模式和工具的測試平臺。它是一個完全由社區擁有和驅動的項目，建議大家可以瀏覽一下代碼、對應用進行測試、使用它來測試任何工具和新技術，并通過PR貢獻自己的代碼。

關于作者

Ian Crosby是一位經驗豐富的軟件開發人員、擁護者和倡導者。他起步于軍事防御系統的開發，并一直以來致力于發揮自己的能力。目前他在阿姆斯特丹的Container Solutions擔任高級工程師，他協助各企業進入新的云原生領域，同時與合作伙伴一起開發用于實現云端原生的工具。

原文地址：http://www.infoq.com/cn/news/2017/06/CSharp-7.1-a

---

.NET社區新聞，深度好文，微信中搜索dotNET跨平臺或掃描二維碼關注

總結

以上是生活随笔為你收集整理的袜子商店应用：一个云原生参照应用的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。