（一）、架構拆分方式

我們談架構，架構分為：服務和數據兩部分（DB、Cache、ES等等）。架構設計要適度，要能否滿足企業未來6-24個月的業務需求增長，避免過度設計。

接下來，我們先看單體應用。單體應用遵循MVC結構。典型的單體應用組網拓撲如下所示：

在單體應用中，有三個模塊，每個模塊都有各自的MVC層。同樣，在數據庫中，針對三個模塊，也會有三個表。如果單體應用能做到無狀態化，也能做到橫向擴展。

但是上面的應用將是一個“巨無霸”，我們無法對其中一個功能組件單獨升級。而且，如果想給單體應用增加新的功能模塊，需要重新開發，整體替換。因為，要對這個單體應用進行解耦。那么，單體應用如何解耦？

按照領域，對數據庫進行縱向切分，也就是分庫，如下圖所示：

隨著用戶數量化的增加，單一數據庫表已經不成了，需要分表。拆表的時候，以常用的列作為主鍵，例如UID，然后將表拆分，也就是數據庫水平拆分：

當然，我們可以使用NewSQL，屏蔽數據庫分庫分表的操作。

隨著業務訪量的繼續增加，需要拆分應用。

首先根據業務領域對應用進行垂直拆分，即把一個大的單體應用，拆成三個小的單體應用：

接下來，按照功能對小的單體應用按照功能進行水平拆分：

拆分后的應用變成了微服務架構。這時網關包含兩部分內容：網關業務邏輯、通信部分（限流、熔斷等）。而Service Mesh，相當于對微服務進行進一步拆分，將業務邏輯層和通訊部分拆開。

（二）、SOA的架構落地

1.多個單體服務 2、多個單體服務之前用ESB連接。

1.SOA

SOA的缺點是：僅按照垂直方向拆分業務，每個服務還是單體的。ESB實現服務間的異步調用。

那么，ESB與MQ有什么區別呢？

2.在微服務架構中，API網關都做什么事情？

（1）.請求鑒權

（2）.即通用參數檢查（只看參數填沒填）。

App到網關的通信協議是https、傳輸協議是Json。Json是放在Http body中的。傳輸數據包=定長header（占24個字節uid、cmd、sessionid、body length）+變長body（k1v1;k2v2）。
其中邊長body時候具體的語義，不需要API做檢查。定長header會被網關檢查，即通用參數檢查。

（3）. 協議轉換：將文本協議Json轉化為二進制協議，如PG，Mgmpak，hashmap（string,object）等。擴展性更好。

（4）.通信協議轉換：App到網關的http請求是一個短鏈接。網關將其轉化為TCP（如RPC）。

（5）.路由轉發

（6）.微服務治理（熔斷限流等）

3.數據訪問層的作用：

（1）、批量的CRUD接口

（2）、ORM

（3）、Sharding的工作（分布分表）。這步最難，如果用NewSQL就可以規避。

（4）、屏蔽底層DB差異性

（三）、微服務架構的異步實現

此外，如果我們要提升微服務的性能，可以在API網關和業務邏輯層之間增加MQ。這樣，雖然網關到MQ是同步調用、MQ到業務邏輯層是同步調用，但網關到業務邏輯實現也異步調用。這樣雖然增加了業務請求的延時，但大幅提升了吞吐量（即把同步方式對數據庫的隨機寫，變成異步方式的對MQ的順序寫）

需要注意的是，并不是所有的請求場景都適合異步，具體可以參照下圖：

我們將同步請求和異步請求用畫筆標識流量路徑