話說最近幾年微服務可謂是生龍活虎，不亞于任何網紅明星(IT圈)，從各大互聯網公司都在相繼建設微服務，到現在就連幾個人的小公司也動不動就微服務，仿佛現在不搞點微服務相關的技術，就顯得很low了。

為了不讓廣大程序猿不被人看不起，能做一個可以昂首挺胸的程序猿，今天咱們就來談一談微服務。

互聯網技術架構演變

為了讓大家能夠更好的了解什么是微服務架構，那就得先了解下微服務的前世今生。

其實互聯網發展到今天的狀態，也是經歷了很多次迭代，從最初的單體架構到微服務架構其實是一個很漫長的旅程。

有幾次比較重要互聯網技術架構的演變的節點：單體架構-->集群架構-->分布式架構-->微服務架構，最終才到了現在的比較火的微服務架構。每一種技術架構的演進都伴隨著互聯網行業的發展，以及用戶數量的增加，同時也促進了技術的快速更新迭代。這其實也是一部互聯網的發展史。

單體架構

首先，咱們先來說下什么是單體架構。顧名思義，單體就是一個獨立的個體，也就是一個項目的所有的功能模塊(比如訂單模塊，用戶模塊，商品模塊等)都集中一個項目當中，最終打成一個war包，可以直接部署上線。

看似簡單粗暴，但是對于那個處于草莽時代的互聯網來說，這種可以快速上線滿足業務需求的方式無疑也是最高好的方式。因為在這個時期的用戶量很少，一個服務器就足撐起整個網站。

集群架構

如果說單體架構是一對一的單挑，那集群架構就是打群架了。因為隨著用戶量的增加，此時單一的服務器已經無法支撐起用戶的訪問，動不動就掛掉的網站肯定是沒有人愿意使用的。

所以此時為了解決這個問題，人們就開始想辦法，一個服務器撐不了，那我就搞一對；一對還不行，我就搞兩對...最終我們把同一個war包，同時部署到多個服務器上，終于搞定了，這就是我們的集群架構時代。

分布式架構

我們搞定的集群架構的項目終于可以支撐起當前用戶量了，但沒想到就在這個時期，也正是互聯網大爆發的時刻，用戶數呈指數級增長，原來的集群又面臨著挑戰。

這個已經不是簡單的增加服務器那么簡單的事兒了，因為這個時期，互聯網業務已經變的極其復雜。所以這次互聯網技術架構的演進是有了本質上的改變，即分布式架構：分布式結構就是將一個完整的系統，按照業務功能，拆分成一個個獨立的子系統。

在分布式結構中，每個子系統就被稱為“服務”。這些子系統能夠獨立運行在web容器中，它們之間通過RPC方式通信(阿里開源Dubbo框架)。說人話就是將訂單模塊單獨部署到一個服務器，用戶模塊單獨部署到一個服務器上，商品模塊也可以單獨部署到一個服務器上。

不僅如此，每一個模塊又可以進行集群部署，如下圖。此時的分布式架構是可以滿足現在的業務需求的。而各個模塊之間的是通過RPC(遠程服務調用)的方式來通信。

微服務架構

我們剛才說了，分布式架構是可以滿足現在大型互聯網的業務需求的，那為什么我們還要一個勁兒的非要搞什么微服務呢，所以我們不禁要這樣幾個問題：

1. 什么是微服務？

2. 為什么要用微服務？

3. 它有什么好處？

什么是微服務

微服務的概念源于2014年3月Martin Fowler（微服務的提出者）所寫的一篇文章Microservices。

微服務是一種架構風格，一個大型復雜軟件應用由一個或多個微服務組成。系統中的各個微服務可被獨立部署，各個微服務之間是松耦合的。每個微服務僅關注于完成一件任務并很好地完成該任務。在所有情況下，每個任務代表著一個小的業務能力。

上圖中每一個色塊都是一個服務，翻譯一下就是微服務架構是一種架構的風格，可以讓我們的業務模塊更加的細化。

如：商品模塊我們可以在細粒度的拆分，直到不可以拆分為止，那到底拆分的力度有多細，要根據自己的業務情況和團隊實力來評估。

這樣做的好處：

·不會牽一發動全身

可以對微服務架構中的每個組件服務進行開發、部署、運營和擴展，而不影響其他服務的功能。

這些服務不需要與其他服務共享任何代碼或實施。各個組件之間的任何通信都是通過明確定義的API進行的。

·各司其職每項服務都是針對一組功能而設計的，并專注于解決特定的問題(支付模塊就解決支付的問題)。

為什么要引入微服務

從生產力和系統的復雜性這兩個方面來看。公司一開始的時候，業務復雜性不高，這時候是驗證商業模式的時候，業務簡單，用單體服務反而生產力很高。

隨著公司的發展，業務復雜性慢慢提高，這時候就可以采用微服務來提升生產力了。而事實證明，微服務架構雖然對開發人員的要求提高了，但是從企業長久發展來看，無論從系統層面還是從成本控制都是非常有利的，這也為什么現在無論大小公司都是直接上微服務。

微服務有什么好處？

1.敏捷快速迭代

微服務讓若干小型獨立團隊形成一個組織，這些團隊負責自己的服務。并且可以更獨立、更快速地工作。縮短開發周期。

2.靈活擴展

通過微服務，您可以獨立擴展各項服務以滿足其支持的系統功能的需求。這使團隊能夠快速調整，準確功能成本，并在服務需求激增時保持可用

3.可重復使用的代碼

將軟件劃分為小型且明確定義的模塊，讓團隊可以將功能用于多種目的。專為某項功能編寫的服務可以用作另一項功能的構建塊。這樣應用程序就可以自行引導，因為開發人員可以創建新功能，而無需從頭開始編寫代碼。

這次主要是從互聯網技術架構的演進規律來給大家介紹了微服務的概念：

• 單體架構的演進

• 集群架構的演進

• 分布式架構的演進

• 微服務架構

大家可以理解成單體架構-->集群架構是一個聚合的過程，就是通過增加服務器等設備來解決問題。

而從集群-->分布式-->微服務是一個拆的過程，就是把原來的很多的模塊從一個大的項目中拆分出來，獨立部署。

所以其實微服務架構就是一種把業務功能模塊進行細粒度拆分的架構風格。