作者 | 莫無崖

導語

微服務（Microservice Architecture）是近幾年流行的一種架構思想，它的概念沒有很明确的指出。ThoughtWorks 公司的首席科學家 Martin Fowler曾經解釋過這個概念： 微服務架構風格是一種将單個應用程序作為一套小型服務開發的方法，每種應用程序都在自己的進程中運行，并與輕量級機制（通常是HTTP資源API）進行通信。這些服務是圍繞業務功能構建的，可以通過全自動部署機制獨立部署。這些服務的集中管理最少，可以用不同的編程語言編寫，并使用不同的數據存儲技術。（By 谷歌翻譯）

架構演進

為了更好的了解什麼是微服務，我們先來看看架構演進的過程

1、單體架構：對于早期的互聯網，由于處于萌芽時期，用戶量少，因此也就表示互聯網的需求還不多，也就導緻互聯網産品并發量低，往往隻需要一台服務器便可以滿足用戶。現在這種模式已經完全淘汰，原因也很簡單，随着互聯網的發展，一台服務器已經無法滿足日益增長的用戶，這種模式下，一旦服務出現了問題，往往需要進行停機才能進行修複，已經無法滿足用戶體驗。

2、垂直架構：這種架構是在單體架構的基礎上，以項目為單位進行劃分，将一個大項目拆分成一個單體項目，這種架構雖然一定程度上使開發變得容易，被劃分的項目不至于無限擴大，但是也帶來了諸多問題，如果項目比較大，這些被劃分的項目因為全部都集中在一個工程中，項目與項目之間會出現數據冗餘，後期擴展成本高，不易維護。而且往往一個服務沒有很好的公用性。

3、SOA架構：這種架構是對垂直架構的優化，它将重複公用的功能抽取成工具，提高了系統的重用性，服務之間通過注冊中心進行通信，但是由于服務的界限往往不明确，導緻系統與服務之間的耦合性增加，往往一個服務的宕機，會牽涉到其它服務。

微服務

微服務便是對SOA架構的進一步優化，實現服務之間的松耦合，微服務架構通過對業務進行劃分實現服務的組件化，并且可以獨立部署，實現獨立測試，使開發人員開發一個服務隻專注于該服務。一句話來說微服務就是一些可以協同工作并且擁有自治功能的服務。下面我們來做更多的解釋為微服務的概念。

微服務很小

微服務根據業務的邊界進行劃分，這樣做的好處使它隻專于業務邊界之内的開發，那可能有人會疑問，劃分到什麼程度才能算小呢？有沒有一個标椎？嚴格來說很難有人能說清，如果你在開發的時候認為某個服務似乎代碼庫有點大了，維護起來有點麻煩，這個時候或許就該考慮再一次進行劃分了，如果你的服務，交給另一個開發人員進行維護時，他可以在一兩天之内讀懂你的服務，或許這就是一個好的服務了。同時随着微服務劃分的越來越小，它的獨立性會越來越好，但是對于衆多服務的管理也會變得複雜，這是微服務的一個痛點，但是不要擔心，如今有很好的的技術可以對這些一個一個的服務進行了管理。

自治性

一個微服務就是一個獨立的個體，并且可以獨立運行，服務之間通過網絡進行通信。這裡的自治性，并不僅僅指服務可以自己獨立測試，更重要的是服務與服務之間如何更好的降低耦合性，如果你服務在進行修改的同時，會引起另一個服務發生了不好的改變，可以說，這就不是一個好的服務，另外，對于一個服務來說，應該懂得提供的什麼接口是可以通過API進行暴露，又有哪些是應該隐藏的，來提高我們服務的安全性。

隔離性

微服務由于進行了業務劃分的隔離，服務之間通過組合的方式構建項目，通信的方式通過網絡調用，使得服務往往隻需要對外暴露提供的API接口，對于調用的一方來說，不需要知道被調用的服務使用了什麼技術，這樣以來，我們的微服務可以用不同的語言進行開發，你可以讓一個風險小最小的服務采用新技術，這樣出現了問題也可以很好的處理。因此微服務也實現了技術的異構性，但是需要明白的是，對于一個團隊來說，最好統一語言，這樣會減少前期的溝通成本。

擴展性

對于單塊服務來說，擴展服務，往往需要對整個服務進行擴展，但是微服務不同，對于較多的且很小的微服務，隻需要對需要擴展的模塊擴展就可以了，因為服務之間相互獨立，幾乎不會影響到其它服務。最重要的是，我們可以把很多不同的服務，同時部署在很多的機器上，一台機器無法工作時，将有其它可工作的機器代替。

叠代周期短

微服務每一個都可以獨立部署，對于開發人員來講，隻負責幾個微服務時，升級更加快，對于如今互聯網的迅速發展叠代過程，很明顯微服務的部署速度順應了互聯網的潮流。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!