“軟件正在吞噬整個世界” ——Marc Andreesen

世界的現狀：

• 世界上最大的圖書商是軟件公司：Amazon
• 世界上最大的音樂商店也是軟件公司：iTunes，Spotify和Pandora
• 世界上最大的獵頭公司也是軟件公司：LinkedIn
• 世界上最大的營銷平臺也是軟件公司：Google
• 世界上增長最快的電信公司也是軟件公司：Skype

六十年前的計算機革命，四十年前的微處理器發明，二十年前的互聯網興起，所有這些技術最終都通過軟件來改變各個行業，並且在全球範圍內廣泛推廣。

互聯網快速發展數據表：

互聯網已經成為千家萬戶生活、學習和工作不可缺少的一部分了。在新的世界秩序中茁壯成長的公司擁有技術作為其核心競爭力。他們構建複雜的雲應用程序，不斷地為市場帶來新的功能和特性。儘管雲應用程序不斷迭代和更新，但這些軟件如磐石般可靠。他們如何實現這樣的靈活性和可靠性？

在過去的幾年裡，Amazon、Uber、Airbnb、Netflix、Yelp以及許多其他行業的革新者採用了一種新的模式來開發雲應用——微服務，微服務也使得軟件架構被提上議程。

不論你是否熟悉微服務，或者還未聽說過，都沒關係，這篇來自Richard Li(Datawire的聯合創始人兼首席執行官)的文章將向大家闡釋微服務的定義、作用，以及影響。

Lesson1 ： 什麼是微服務？

微服務這一概念出現於2012年，因敏捷開發方法創始人之一的Martin Fowler而流行，微服務架構是一項在雲中部署應用和服務的新技術。

微服務可以在“自己的程序”中運行，並通過“輕量級設備與HTTP型API進行溝通。”關鍵在於改服務可以在極致的程序中運行。

有些人將微服務描述為將單片軟件應用程序分割成更小的部分。這個解釋也不是特別完整，它還忽略了微服務的好處——每個開發團隊都可處理一個獨立的可交付的代碼單元。最好將微服務描述為“分佈式開發雲應用的體系結構”。

例如，最初的Amaozn只是一個單一的應用程序，由數百萬行C++組成。隨著時間的推移，Amazon已經將單片應用程序的功能拆分為更小的服務，因此有了一個單獨的服務用於推薦、付款、搜索等等。反過來，這些單獨的服務可能由幾十個較小的微服務組成。

Amazon初始架構中，推薦服務的bug修復需要更改單片應用程序中某些C++ ，等待其他組完成對單片應用程序的更改，並測試整個應用程序以進行發佈。在微服務體系結構中，推薦開發團隊可以對其微服務進行更改，並在未與其他功能團隊協調的之前下發布。

Yelp還採用了微服務架構，這個架構由數百個服務組成。僅僅加載Yelp主頁就會調用數十個微服務，例圖如下。

微服務作為一項雲中部署應用和服務的新技術，已成為當下最新的熱門話題。大部分為稍微服務的爭論都集中在容器或其他技術是否能夠很好地實施微服務。企業和服務提供商正在尋找更好的方法將應用程序部署在雲環境中，微服務被認為是未來的方向。通過將應用和服務分解成更小的、鬆散耦合的組件，它們可以更加容易升級和拓展。

Lesson2 ： 為什麼採用微服務？

微服務的六大主要好處:

1. 增強靈活性

微服務使開發組織能夠更快地響應市場和客戶反饋。無論它是一個改變遊戲規則的功能，還是一個使現有功能更加可用的調整，它的發佈都不會因為單一版本的時間表而推遲。相反，每個微服務都可以獨立發佈。

2. 組織規模

對於一個龐大體系，每增加一個開發人員，破壞代碼的風險就大大增加。這會降低開發速度，因為需要額外的測試、調試和集成來防止無意中出現的錯誤。在微服務體系結構中，每個團隊都在獨立的代碼基礎上工作，因此錯誤被隔離到單個微服務中。

3. 開發效率

整體式開發團隊被限制在一個通用的技術堆棧和過程中。Microservices 體系結構允許獨立的團隊為給定的服務選擇正確的流程和技術。例如，PCI 標準要求任何處理信用卡數據的代碼庫都必須接受遵從性審計。通過由單個或一組微服務微服務處理支付處理，範圍內的代碼量將大大減少。或者可以用Python編寫一個推薦引擎來使用TensorFlow機器學習庫，而其他服務則是用Java編寫的。

4. 具有成本效益的擴展

在一個傳統的單體，整個應用程序必須規模化時，它將達到其極限。例如，如果應用程序不能執行，則必須添加能夠運行獨立的其他實例的新服務器。在微服務體系結構中，每個微服務都可以單獨擴展。

因此，只有給定的微服務才會添加新的服務器，這是一個瓶頸。這種更細粒度的擴展方法使得計算模型更具成本效益。

5. 更快的入職

使用microservices，新工程師可以安全地開始在一個小型的microservice上進行編碼。對於一個工程師來說，沒有必要僅僅為了修復一個bug 而去學習一個單片代碼庫。

6. 吸引更多有才華的工程師

Microservices 使您能夠逐步採用和測試新技術——優秀的工程師希望使用最新的技術。

微服務並不適合所有人

雖然微服務微服務有很多好處，但並不適合所有人。特別是擁有小型工程團隊的組織應該考慮整體優先的方法。在這些組織中，開發團隊不具備同時獨立迭代多個特性的能力。 首先採用整體，然後隨著團隊的強大添加微服務，這通常是一個兩全的絕佳策略。

Lesson3 ： 採用微服務架構的影響？

採用微服務架構會達到顯著的成效，但也會帶來相當大的變化。預計會有三種類型的變更：文化，部署基礎架構和開發人員基礎架構。

#團隊擁有更大的自主權

採用微服務微服務的最大變化可能是文化。為了提高敏捷性和效率，microservices 開發團隊做出以前無法控制的決策，比如發佈日期。許多組織還授權團隊定製他們的 QA 策略或技術棧。

重新分配決策權需要更變人員構成和培訓內容。將更多的交貨日期決定權以及技術和流程選擇的權利移交給團隊，需要至少一名能夠做出這些決定的團隊成員，或者在培訓和指導方面進行一些前期投資，以進一步發展這些技能。

如此一來，技術和流程的靈活性將會增加，評審過程將會對團隊的需求更加開放。

工程副總裁的角色也將發生重大變化。他們將協調更變企業文化、工作內容和培訓內容。他們將評估和實施下面描述的工具和基礎設施，他們還將改進指標。

工程吞吐量的衡量標準將不再是每個sprint的故事點，而是部署新功能和功能更新速度。應用程序的可靠性也將不再僅僅通過平均故障間隔時間來衡量，而是通過微服務的平均恢復時間來衡量。

#部署基礎設施實現完全自動化

在規模上，一個雲應用程序可能擁有數百個單獨的微服務，每個微服務可能由多個實例組成(為了可用性和可伸縮性)。此外，這些微服務將由各自的開發團隊獨立更新。快速增長的移動部件數量和更新的頻率要求一個完全自動化的部署工作流程和基礎設施。

雖然有許多技術選擇可以完全自動化部署工作流程，但是我們已經在所有微服務的成功使用過程中發現了部署基礎設施中的一些通用功能。

• 從代碼到客戶的全自動化。通常，一旦開發人員將代碼提交源代碼庫，就會有一個按鈕流程，自動獲取最新的源代碼，並將其打包到部署工件中，如容器或 AMI，然後將整個工件部署到登臺或生產環境中。這通常被稱為持續交付。
• 彈性縮放。微服務本質上是相當短暫的部署新版本，退出舊版本，並根據利用率添加或刪除新實例。支持彈性擴展的部署基礎設施，如 Amazon 的 Elastic Compute Cloud、 Docker Datacenter 或 Kubernetes。

雖然許多其他功能可以添加到部署基礎設施中，比如自動化迴歸測試 / 服務，但我們已經看到組織通過投資於自動化和彈性擴展成功地採用了微服務。

#Microservices 網絡的開發人員基礎設施

使用微服務的最後一個挑戰可能是對微服務瞭解不足。如果一個單體應用程序類似於一個在不同房間中具有不同特性的房子，那麼微服務應用程序更像是一個鄰居，每個鄰居都有一個微服務。

微服務社區的交流需要一種不同的模式。就像身在遠處的兩人在房屋裡通過電話交談(而不是在樓下大喊大叫)一樣，微服務通過網絡進行通信。這需要一組公共服務和使能技術。這些工具和技術是微服務編碼開發人員使用的，與 DevOps 工程師使用的部署基礎設施不同。

吞噬或被吞噬

鑑於微服務的好處需要新的投資和觸發變化，你可能會問，正如一位工程副總裁最近被問到“你為什麼從事微服務? ” 他回答說: “因為如果我們不這麼做，我們就會被激勵的競爭所吞噬。”

採用微服務的勢頭強勁，因為它有利於提高敏捷性、效率、新員工入職和招聘。數十家公司正在投資培訓、工具和基礎設施，以簡化微服務的使用過程。擁有微服務使用經驗的開發人員數量正在增長。

開發人員基礎設施的基本用例是提供一個公共協議，以便所有微服務可以相互連接。支持這些協議的庫需要在組織使用的每個技術堆棧中都可用。HTTP 是單片體系結構中常用的協議選擇，但是 HTTP 的同步本質會降低可靠性，因為你需要向網絡中添加更多的微服務。(使用 HTTP 連接在一起的 Microservices 類似於連續連接的聖誕樹燈。如果一個燈泡熄滅了，整串的燈泡都不亮了。更復雜的協議提供了串聯服務的能力。)

此外，在微服務體系結構中，典型的服務請求跨越多個微服務。例如，加載 Twitter feed 中所有 tweets 的過程會調用與廣告相關的微服務、顯示 tweet 的微服務(包括添加 hashtag 鏈接和圖片)以及顯示關注者 tweets 的微服務。在此場景中，專門用於跟蹤錯誤和性能到特定微服務的工具對於確保開發人員生產率非常重要。

微服務開發者基礎設施需要兩個基本功能:

• 啟用鬆散耦合的服務。服務需要定義良好的協議進行通信，並且依賴關係需要包含在每個微服務中。本 · 克里斯滕森(Ben Christensen)，Netflix 微服務的架構師之一，在他的演講《不要建立一個分佈式單塊體》中談到了這個挑戰。鬆散耦合的服務允許您更新單個微服務的代碼，而不會影響依賴於它的任何其他服務。開發人員基礎設施需要在所有微服務中提供這些協議的實現。
• 應用程序彈性。當一個微服務由於某種原因不可用時——軟件錯誤、網絡故障、機器故障——整個雲應用程序必須繼續運行並在最少的人為干預下恢復。服務可用性(例如負載平衡)、服務隔離(例如斷路器)和服務恢復(例如回滾)等技術是開發人員工具包的重要組成部分。

譯 | 蔣敏 編輯 | SaaS研究院