微服務(wù)架構(gòu)的由來(lái)

微信號(hào)：GitShare
微信公眾號(hào)：愛(ài)折騰的稻草
如有問(wèn)題或建議，請(qǐng)公眾號(hào)留言[^1]

前沿

• 三層應(yīng)用架構(gòu)
  隨著面向?qū)ο蠓治?、面向?qū)ο笤O(shè)計(jì)、面向?qū)ο笤瓌t、設(shè)計(jì)模式、企業(yè)架構(gòu)模式等理念以及方法論的不斷發(fā)展，根據(jù)提供的功能和軟件結(jié)構(gòu)的不同，我們將應(yīng)用開發(fā)分為三層（表現(xiàn)層、業(yè)務(wù)邏輯層和數(shù)據(jù)訪問(wèn)層），俗稱三層架構(gòu)。

• 三層應(yīng)用架構(gòu)的優(yōu)勢(shì)
  三層應(yīng)用架構(gòu)的出現(xiàn)，解決了系統(tǒng)間調(diào)用復(fù)雜，職責(zé)不清晰的問(wèn)題，有效的降低了層與層之間的依賴關(guān)系，成為軟件架構(gòu)的經(jīng)典模式之一。

• 三層應(yīng)用架構(gòu)的劣勢(shì)
  三層應(yīng)用架構(gòu)只是將系統(tǒng)在邏輯上分為了三層，但它并不是物理上的分層。我們最終還是將所有的代碼都耦合在一起進(jìn)行編譯、打包、部署，運(yùn)行在同一個(gè)進(jìn)程中。
  隨著業(yè)務(wù)的不斷擴(kuò)大，需求功能的持續(xù)增加，單塊架構(gòu)已經(jīng)很難滿足業(yè)務(wù)快速變化的需求。一方面，代碼的殼維護(hù)性、擴(kuò)展性、靈活性在降低；另一方面，系統(tǒng)的修改成本、交付周期長(zhǎng)、技術(shù)選型成本高以及維護(hù)成本在顯著增加。

• 互聯(lián)網(wǎng)應(yīng)用特點(diǎn)
  互聯(lián)網(wǎng)時(shí)代的產(chǎn)品通常具有：創(chuàng)新成本低、需求變化快、用戶群體龐大的特點(diǎn)。 

微服務(wù)架構(gòu)

• 1、什么是微服務(wù)架構(gòu)模式
  微服務(wù)架構(gòu)是一種架構(gòu)模式，它提倡將單一應(yīng)用程序劃分成一組小的服務(wù)，服務(wù)之間相互協(xié)調(diào)、互相配合，為用戶提供最終價(jià)值。每個(gè)服務(wù)運(yùn)行在其獨(dú)立的進(jìn)程中，服務(wù)與服務(wù)間采用輕量級(jí)的通信機(jī)制互相溝通。每個(gè)服務(wù)都圍繞著具體業(yè)務(wù)進(jìn)行構(gòu)建，并且能夠獨(dú)立的部署到生產(chǎn)環(huán)境、類生產(chǎn)環(huán)境中。另外，應(yīng)盡量避免統(tǒng)一的、集中式的服務(wù)管理機(jī)制，對(duì)具體的一個(gè)服務(wù)而言，應(yīng)根據(jù)業(yè)務(wù)上下文，選擇合適的語(yǔ)音、工具對(duì)其進(jìn)行構(gòu)建。 ——摘自馬丁.福勒先生的博客。

• 2、微服務(wù)與SOA

• 3、微服務(wù)應(yīng)用架構(gòu)
  一個(gè)微服務(wù)一般完成某個(gè)特定的功能，比如下單管理、客戶管理等等。每一個(gè)微服務(wù)都是微型六角形應(yīng)用，都有自己的業(yè)務(wù)邏輯和適配器。一些微服務(wù)還會(huì)發(fā)布API給其它微服務(wù)和應(yīng)用客戶端使用。其它微服務(wù)完成一個(gè)Web UI，運(yùn)行時(shí)，每一個(gè)實(shí)例可能是一個(gè)云VM或者是Docker容器。 
  這種微服務(wù)架構(gòu)模式深刻影響了應(yīng)用和數(shù)據(jù)庫(kù)之間的關(guān)系，不像傳統(tǒng)多個(gè)服務(wù)共享一個(gè)數(shù)據(jù)庫(kù)，微服務(wù)架構(gòu)每個(gè)服務(wù)都有自己的數(shù)據(jù)庫(kù)。另外，這種思路也影響到了企業(yè)級(jí)數(shù)據(jù)模式。同時(shí)，這種模式意味著多份數(shù)據(jù)，但是，如果你想獲得微服務(wù)帶來(lái)的好處，每個(gè)服務(wù)獨(dú)有一個(gè)數(shù)據(jù)庫(kù)是必須的，因?yàn)檫@種架構(gòu)需要這種松耦合。
  

微服務(wù)架構(gòu)優(yōu)點(diǎn)

• 1、通過(guò)分解巨大單體式應(yīng)用為多個(gè)服務(wù)方法解決了復(fù)雜性問(wèn)題。
  在功能不變的情況下，應(yīng)用被分解為多個(gè)可管理的分支或服務(wù)。每個(gè)服務(wù)都有一個(gè)用RPC-或者消息驅(qū)動(dòng)API定義清楚的邊界。微服務(wù)架構(gòu)模式給采用單體式編碼方式很難實(shí)現(xiàn)的功能提供了模塊化的解決方案，由此，單個(gè)服務(wù)很容易開發(fā)、理解和維護(hù)。

• 2、這種架構(gòu)使得每個(gè)服務(wù)都可以有專門開發(fā)團(tuán)隊(duì)來(lái)開發(fā)。
  開發(fā)者可以自由選擇開發(fā)技術(shù)，提供API服務(wù)。當(dāng)然，許多公司試圖避免混亂，只提供某些技術(shù)選擇。然后，這種自由意味著開發(fā)者不需要被迫使用某項(xiàng)目開始時(shí)采用的過(guò)時(shí)技術(shù)，他們可以選擇現(xiàn)在的技術(shù)。甚至于，因?yàn)榉?wù)都是相對(duì)簡(jiǎn)單，即使用現(xiàn)在技術(shù)重寫以前代碼也不是很困難的事情。

• 3、微服務(wù)架構(gòu)模式是每個(gè)微服務(wù)獨(dú)立的部署。
  開發(fā)者不再需要協(xié)調(diào)其它服務(wù)部署對(duì)本服務(wù)的影響。這種改變可以加快部署速度。UI團(tuán)隊(duì)可以采用AB測(cè)試，快速的部署變化。微服務(wù)架構(gòu)模式使得持續(xù)化部署成為可能。

• 4、微服務(wù)架構(gòu)模式使得每個(gè)服務(wù)獨(dú)立擴(kuò)展。
  你可以根據(jù)每個(gè)服務(wù)的規(guī)模來(lái)部署滿足需求的規(guī)模。甚至于，你可以使用更適合于服務(wù)資源需求的硬件。