微服務資料庫設計

A. 什麼是微服務

什麼是微服務

微服務架構的系統是一個分布式的系統，按業務進行劃分為獨立的服務單元，解決單體系統的不足，同時也滿足越來越復雜的業務需求。

一.單體架構

1.1什麼是單體架構

在軟體設計的時候經常提到和使用經典的3層模型，即表現層，業務邏輯層，數據訪問層。雖然在軟體設計中劃分了3層模型，但是對業務場景沒有劃分，一個典型的單體架構就是將所有的業務場景的表現層，業務邏輯層，數據訪問層放在一個工程中最終經過編譯，打包，部署在一台伺服器上。此時服務架構如圖：

1.2單體架構存在的不足

在小型應用的初期，訪問量小的時候這種架構的性價比還是比較高的，開發速度快，成本低，但是隨著業務的發展，邏輯越來越復雜，代碼量越來越大，代碼得可讀性和可維護性越來越低。用戶的增加，訪問量越來越多單體架構的應用並發能力十分有限。可能會有人想到將單體應用進行集群部署，並增加負載均衡伺服器，再來個緩存伺服器和文件伺服器，資料庫再搞個讀寫分離。這種架構如圖：

這種架構雖然有一定的並發能力，及應對一定復雜業務，但是依然沒有改變系統為單體架構的事實。大量的業務必然會有大量的代碼，代碼得可讀性和可維護性依然很差。如果面對海量的用戶，它的並發能力依然不夠。基於以上單體架構系統的不足，提出了微服務架構。

二.微服務

2.1什麼是微服務

說了這么多現在來看看到底什麼是微服務。微服務最初是由Martin Fowler提出來的他的理解如下：

微服務架構就是將單一程序開發成一個微服務，每個微服務運行在自己的進程中，並使用輕量級的機制通信，通常是HTTP RESTFUL API。這些服務圍繞業務能力來劃分，並通過自動化部署機制來獨立部署。這些服務可以使用不同的編程語言，不同資料庫，以保證最低限度的集中式管理。

1

總結起來微服務就是將一個單體架構的應用按業務劃分為一個個的獨立運行的程序即服務，它們之間通過HTTP協議進行通信（也可以採用消息隊列來通信，如RoocketMQ，Kafaka等），可以採用不同的編程語言，使用不同的存儲技術，自動化部署（如Jenkins）減少人為控制，降低出錯概率。服務數量越多，管理起來越復雜，因此採用集中化管理。例如Eureka，Zookeeper等都是比較常見的服務集中化管理框架。

2.2微服務的優勢

1）將復雜的業務拆分成多個小的業務，每個業務拆分成一個服務，將復雜的問題簡單化。利於分工，降低新人的學習成本。

2）微服務系統是分布式系統，業務與業務之間完全解耦，隨著業務的增加可以根據業務再拆分，具有極強的橫向擴展能力。面對搞並發的場景可以將服務集群化部署，加強系統負載能力。

3）服務間採用HTTP協議通信，服務與服務之間完全獨立。每個服務可以根據業務場景選取合適的編程語言和資料庫。

4）微服務每個服務都是獨立部署的，每個服務的修改和部署對其他服務沒有影響。

2.3微服務和SOA的關系

SOA即面向服務的架構，SOA是根據企業服務匯流排（ESB）模式來整合集成大量單一龐大的系統，微服務可以說是SOA的一種實現，將復雜的業務組件化。但它比ESB實現的SOA更加的輕便敏捷和簡單。

B. 微服務架構是什麼

微服務架構，主要是中間層分解，將系統拆分成很多小應用（微服務），微服務可以部署在不同的伺服器上，也可以部署在相同的伺服器不同的容器上。當應用的故障不會影響到其他應用，單應用的負載也不會影響到其他應用，其代表框架有 Spring cloud、Dubbo 等。
微服務 Microservices 之父，馬丁.福勒，對微服務大概的概述如下：就目前而言，對於微服務業界並沒有一個統一的、標準的定義（While there is no precise definition of this architectural style ) 。但通常在其而言，微服務架構是一種架構模式或者說是一種架構風格，它提倡將單一應用程序劃分成一組小的服務，每個服務運行獨立的自己的進程中，服務之間互相協調、互相配合，為用戶提供最終價值。服務之間採用輕量級的通信機制互相溝通（通常是基於 HTTP 的 RESTful API ) 。每個服務都圍繞著具體業務進行構建，並且能夠被獨立地部署到生產環境、類生產環境等。另外，應盡量避免統一的、集中式的服務管理機制，對具體的一個服務而言，應根據業務上下文，選擇合適的語言、工具對其進行構建，可以有一個非常輕量級的集中式管理來協調這些服務。可以使用不同的語言來編寫服務，也可以使用不同的數據存儲。
六種常見的微服務架構模式：
1、聚合器微服務設計模式
聚合器調用多個服務實現應用程序所需的功能。它可以是一個簡單的Web頁面，將檢索到的數據進行處理展示。它也可以是一個更高層次的組合微服務，對檢索到的數據增加業務邏輯後進一步發布成一個新的微服務，這符合DRY原則。另外，每個服務都有自己的緩存和資料庫。如果聚合器是一個組合服務，那麼它也有自己的緩存和資料庫。聚合器可以沿X軸和Z軸獨立擴展。
2、代理微服務設計模式
這是聚合模式的一個變種，在這種情況下，客戶端並不聚合數據，但會根據業務需求的差別調用不同的微服務。代理可以僅僅委派請求，也可以進行數據轉換工作。
3、鏈式微服務設計模式
這種模式在接收到請求後會產生一個經過合並的響應，在這種情況下，服務A接收到請求後會與服務B進行通信，類似地，服務B會同服務C進行通信。所有服務都使用同步消息傳遞。在整個鏈式調用完成之前，客戶端會一直阻塞。因此，服務調用鏈不宜過長，以免客戶端長時間等待。
4、分支微服務設計模式
這種模式是聚合器模式的擴展，允許同時調用兩個微服務鏈。
5、數據共享微服務設計模式
自治是微服務的設計原則之一，就是說微服務是全棧式服務。但在重構現有的「單體應用（monolithic application）」時，SQL資料庫反規范化可能會導致數據重復和不一致。因此，在單體應用到微服務架構的過渡階段，可以使用這種設計模式，在這種情況下，部分微服務可能會共享緩存和資料庫存儲。不過，這只有在兩個服務之間存在強耦合關系時才可以。對於基於微服務的新建應用程序而言，這是一種反模式。
6、非同步消息傳遞微服務設計模式
雖然REST設計模式非常流行，但它是同步的，會造成阻塞。因此部分基於微服務的架構可能會選擇使用消息隊列代替REST請求/響應。