微服務的出現在技術領域，尤其是DevOps圈子反響強烈。這也難怪，因為它完美詮釋了雲端計算交付樣式的優勢。但是，如同任何一個快速發展的新生事物一樣，要區別哪些是炒作，哪些是真正的微服務也絕非易事。
對於準備學習微服務，想瞭解一些實戰經驗的人來說，以下的文章希望能對你有所啟發。
微服務是軟體開發中把一個單一的應用拆分成一系列微服務的架構方法。每一個服務都有其獨特且定義良好的角色，有自己的行程，並透過HTTP API或者訊息進行通訊。在同一應用中，每個微服務可以獨立於同級其他的服務，進行部署、升級、擴充套件和重啟。它們通常由自動化系統進行編排，使得在不影響終端使用者的情況下，對實時應用程式的頻繁更新成為可能。
對於這一切，我們早已不再陌生。想一下：現在，普通雲使用者（包括非技術性人員）很容易，且自然而然地使用多種微產品和微應用（他們沒有稱之為“The App Store”）。一般的企業會使用至少十幾種不同的軟體產品和整合：一種用於記錄業務費用的工具，另一種用於跟蹤計劃，還有一種用於工資管理，等等。
微服務用更加緊湊，有效的工具更好的完成工作，且可擴充套件為企業級。
微服務類似樂高積木，可以拼在一起搭建一個標準模型。首先，開發人員需要識別專案需要哪些單獨的服務，例如搜尋，認證，訊息傳遞，銷售處理等。然後，他們從開源到成套的企業解決方案之間做選擇，最後把所有東西整合成一個應用。
“微服務”和“容器”經常一起出現，但兩者並不是一碼事。微服務可以在容器內執行，也可以作為完整的虛擬機器執行。也就是說，像Docker和Kubernetes這樣基於容器的開源系統，是開發、部署和管理微服務的一種非常有效的方式。圍繞容器產生的眾多成熟和強大的工具、平臺及各種服務，使得容器化天生就適合微服務應用。
“這非常簡單：微服務使開發人員不必在已經解決的技術問題上再浪費時間，重覆造輪子。” Container Solutions的聯合創始人兼執行長Jamie Dobson說。小型自治團隊獨立開發、部署和擴充套件各自的服務，Dobson繼續說，微服務本質上是“並行開發” – 加速生產週期，使其成指數增長。
此外，Dobson指出，持續整合和開發基本上已被納入微服務架構。他說：“微服務減少了基礎設施給專案帶來的風險。隨著對基礎設施的淡化，微服務團隊可以進行小時級的快速迭代，這在帶來價值增長的同時降低了“錯誤功能”持續的風險。”
換句話說，微服務下，團隊中的每個開發人員只需專註自己那部分工作，無需關註底層的基礎架構。如果在生產中，拼在一起的各個模組不能很好的工作，則很容易將它們隔離，拆開並重新配置，直到可以為止。是不是很像樂高？
相對於傳統的單一應用，微服務顯然更具優勢。但和其他技術的發展過程一樣，早期使用微服務的曲線會非常陡峭。所以目前，像Netflix和PayPal之類的大公司更易擁抱微服務，因為它們有強大的內部資源和工程師團隊。
“如果是一個非常龐大，資源豐富的企業，每個團隊都能夠管理每項服務，並確保其可重用和可發現，這真是太棒了，” Matt Biilmann說。Biilmann是Netlify的CEO兼聯合創始人。Netlify是面向Web專案開發和自動化的一體化平臺，它最近新增了一個微服務閘道器。他補充說，Netlify已經註意到這對於開發人員的吸引力，“小專案中玩微服務——主要是因為它們很有趣！”
但是，Biilmann說，對於任何人而言，痛苦是真實存在的。擺脫集中式單體架構，意味著放棄了將部分合成一個整體的固有的工作流程。
“由於我們將單一應用拆分成微服務，導致我們面對的是一個碎片化的系統。開發人員需要花費大量的時間和精力將服務和工具整合在一起，並且這個過程，缺乏跨專案間的通用樣式和平臺。”他說，“雖然前景美好，但要想真正用好它，我們希望能提供可一鍵式安裝配置的工具。”
舉個例子，Biilmann提到LAMP。Linux，Apache，MySQL和PHP等免費提供的工具，為Web開發提供了新的可能——但當公司在為像WordPress，Drupal和Joomla之類的專案開發整合工具的時候，才考慮到架構問題。“你不會透過配置Apache、MySQL資料庫來啟動WordPress。你期望看到一個面板，然後在上面點選一個按鈕，寫著‘開始一個新的WP專案。’ 之所以能夠這樣是因為在某個時間點，業界才有足夠的能力去實現這些，使一鍵式配置成為可能。這對於任何一項技術的推廣都至關重要。”
幸運的是，微服務正在經歷同樣的飛速發展。許多公司不僅著眼於微服務本身，還包括使微服務能夠無縫銜接的工具、平臺和框架，大家都希望能儘早佔有一席之地。
現在去評估這些新事物，是否是最佳實踐抑或可以存活多久為時尚早。更別說微服務還需要提高測試的複雜度，且有可能消耗更多的記憶體/計算資源。所以，儘管有諸多優點，但該領域的專家們認為並不是所有的專案都適合微服務。
一位專註於傳統企業應用轉型的資深顧問表示，在特定場景下，他仍然是集中式單體架構的粉絲。“當你執行的是同一服務的多個實體時，不一定需要微服務。一個精心打造的單體架構系統適用於某些特定的場景。”
另外，他還說，也有可能辛苦創建出的微服務最後無法擴充套件。“這一切都取決於你如何運用基本原則。在沒有考慮成熟的情況下，好多人就盲目購買一堆微服務。”
真正的微服務，只執行你所需要的那部分服務 —— 不多不少。這是一個技術活，因為服務之間只有在編排後才能相互感知。最近，許多中小企業才感到這種實施和編排已經超出了它們的能力範圍。
從圍繞微服務的基礎設施和技術支援來看，我們正處於臨界點。
“微服務架構更快、更安全、更便宜 —— 很多時候，這確實是更好的辦法。” Chris Bach，Netlify的另一位聯合創始人說，“下一步是可訪問 —— 可靠的工作流程。我們正在見證它的發展，直到某天，發現一切都已準備就緒。”
這意味著微服務，現在還只是開發人員的一個開發工具。
原文連結：https://thenewstack.io/microservices-101/
本次培訓內容包括：Docker容器的原理與基本操作；容器網路與儲存解析；Kubernetes的架構與設計理念詳解；Kubernetes的資源物件使用說明；Kubernetes 中的開放介面CRI、CNI、CSI解析；Kubernetes監控、網路、日誌管理；容器應用的開發流程詳解等，點選識別下方二維碼加微信好友瞭解具體培訓內容。
3月23日開始上課，還剩最後3個名額，點選閱讀原文連結即可報名。
長按二維碼向我轉賬
![]()
受蘋果公司新規定影響，微信 iOS 版的贊賞功能被關閉，可透過二維碼轉賬支援公眾號。
知識星球