微服務是什麼？
微服務就是一些協同工作的小而自制的服務。
無論現在的影響力如何，分佈式系統仍然是最容易被忽視的主題之一，至少在大學層面是如此。沒有多少學生理解諸如容器化和容錯等概念，你也永遠不會看到系統項目贏得黑客馬拉松。儘管如此，我認爲至少對今天的大規模系統如何工作有一個簡單的理解是非常重要的。
這個故事是針對初學者的系列中的第一個，例如接受 1 到 2 年級的普通計算機科學教育或者具有自學網絡開發經驗的人。前幾篇文章將對主要概念進行重點介紹，並深入探討技術細節。然後，我希望探索網絡相關的主題、Kubernetes ，以及我在研究中看到的有趣內容。第一個非常簡單，旨在解釋微服務背後的動機和基本概念。
分佈式系統維持着互聯網的運行
在過去，應用程序都是獨立的。可能應用程序包括Web服務本身和儲存系統被打包成只有一個或者兩個二進制文件。然後這些二進制文件上傳到服務器直接在機器上運行。在 80，90 年代這個系統是足夠的，但是如今 Google 每天都會收到 35 億次搜索查詢，沒有哪個服務器足夠強大到處理這些查詢。
過去，工程師購買更好的服務器，更好的電纜等等。隨着互聯網的發展和 摩爾定律 的終結, 這種方法很快變得不可行了，很明顯需要橫向拓展而不是縱向。取而代之，不再去買更好的更貴的硬件，而是去買大量便宜的服務器去分配這些負載。
最早的橫向拓展只是運行多個 Web 服務的副本。 然而隨着雲服務的發展，微服務架構很快主導了市場。微服務是指將一個大的應用拆分成獨立的組件，叫做服務，每個組件執行一項專門的任務。所以不是讓一個 Web 服務從頭到尾運行處理一個請求，開發人員將應用拆分成服務像用戶身份驗證, 頁面服務，API 服務，數據庫模型服務等等。
拆分一個獨立應用程序 (Source: Dzone)
每一個微服務有一個或者多個 微服務 組成。對於運行在 Django 上的網站，我們可以通過增加我們運行在 Django 服務器的副本數量來進行橫向拓展。這些副本是完全一樣的。如果我們運行一個數據庫，我們可以通過增加副本數量來增加副本，我們通常稱之爲分片 。 將分片視爲數據庫的一部分，你可以獨立運行並保留整體數據的一部分 。 通過增加分片數量，我們可以橫向拓展數據庫。這些副本可以在不同機器上運行。所以如果我們想在 100 臺機器上運行一個大的 Web 服務，我們可以讓 100 份副本單獨在每一臺機器上運行。
讓我們看一個完整的例子。負載均衡器可以接受谷歌搜索查詢，並將其轉發到 api 服務器的數千個副本之一。然後，api 服務器將請求同時轉發給索引器、ad 生成器和 ML 神經網絡。每個服務都可以運行數千個副本。這些單獨的服務完成它們自己的任務，每個任務都是整個原始請求的一部分，然後 api 服務器聚合結果並以搜索結果的形式返回給您。
聚合樣式的微服務體系結構 (Source: Arun Gupta)
有關微服務體系結構模式的更多信息，請訪問 Arun Gupta's Blog。他是 AWS 的首席技術專家。
優勢
下面是一些比較關鍵的優勢。 當然還有很多其它的優勢，但這四個最爲重要。
- 微服務框架最重要的不可否認的優勢是可以橫向拓展任何組件。 如果一個服務 （例如神經網絡） 負載很重， 你可以簡單的運行該服務的更多的副本。
- 服務是獨立的。 每個組件可以存在於獨立的庫中，並由專門的工程師團隊維護。 每個組件可以用最適合它的語言編寫，比如數據庫服務用 C 語言編寫 Web 服務用 Python 編寫。 組件的更新和新組件的編寫不會影響其它的服務。
- 架構是可插拔的。 基於服務獨立性構造的，但它帶來的是一個全新的境界。一個公司甚至不需要寫出所有的服務。第三方應用像 MySQL，Elasticsearch，Redis 全是可以很容易整合到你係統的微服務。
- 容錯 （通過錯誤隔離） 。 這種優勢只有在你的系統設計不合理時才得以體現。 一個副本的故障不會導致整個管線故障甚至停止服務。 同樣的，特定服務中的錯誤不會影響其它無關服務的正常運行。 這並不總是容易的，容錯是工業和研究裏的一個難題，特別是對分佈式數據庫和網絡。
當然，和所有事情一樣，微服務也有一些缺點。將請求從一臺服務器轉發到另外一臺服務器，這具有一定的開銷和複雜性。分佈式系統通常都存在依賴、複製和共享問題。隨着微服務的數量和複雜增加，部署和調試的難度也呈指數級增加。
好消息是，有大量的研究人員，公司和創業公司在一起合力研究這些問題。Jenkins，Spinnaker 和 Jaegertracing 等項目都是今天最流行的開源解決方案之一，每天在行業和學術中都有新的創新。
所以，分佈式系統仍可以說是相對比較新的，其影響力也在每日劇增。