1.可以實現真正的前後端解耦，前端伺服器使用nginx。

前端/WEB伺服器放的是css，js，圖片等等一系列靜態資源（甚至你還可以css，js，圖片等資源放到特定的檔案伺服器，例如阿里雲的oss，並使用cdn加速），前端伺服器負責控制頁面引用&跳轉&路由，前端頁面非同步呼叫後端的介面，後端/應用伺服器使用tomcat（把tomcat想象成一個數據提供者），加快整體響應速度。

（這裡需要使用一些前端工程化的框架比如nodejs，react，router，react，redux，webpack）

2.發現bug，可以快速定位是誰的問題，不會出現互相踢皮球的現象。

頁面邏輯，跳轉錯誤，瀏覽器相容性問題，指令碼錯誤，頁面樣式等問題，全部由前端工程師來負責。

介面資料出錯，資料沒有提交成功，應答超時等問題，全部由後端工程師來解決。

雙方互不干擾，前端與後端是相親相愛的一家人。

3.在大併發情況下，我可以同時水平擴充套件前後端伺服器，比如淘寶的一個首頁就需要2000+臺前端伺服器做叢集來抗住日均多少億+的日均pv。

（去參加阿里的技術峰會，聽他們說他們的web容器都是自己寫的，就算他單例項抗10萬http併發，2000臺是2億http併發，並且他們還可以根據預知洪峰來無限拓展，很恐怖，就一個首頁。。。）

4.減少後端伺服器的併發/負載壓力

除了介面以外的其他所有http請求全部轉移到前端nginx上，介面的請求呼叫tomcat，參考nginx反向代理tomcat。

且除了第一次頁面請求外，瀏覽器會大量呼叫本地快取。

5.即使後端服務暫時超時或者宕機了，前端頁面也會正常訪問，只不過資料刷不出來而已。

那麼只要透過一些程式碼重構，也可以大量複用介面，提升效率。（多端應用）

7.頁面顯示的東西再多也不怕，因為是非同步載入。

8.nginx支援頁面熱部署，不用重啟伺服器，前端升級更無縫。

9.增加程式碼的維護性&易讀性（前後端耦在一起的程式碼讀起來相當費勁）。

10.提升開發效率，因為可以前後端並行開發，而不是像以前的強依賴。

11.在nginx中部署證書，外網使用https訪問，並且只開放443和80埠，其他埠一律關閉（防止駭客埠掃描），

內網使用http，效能和安全都有保障。

12.前端大量的元件程式碼得以複用，元件化，提升開發效率，抽出來！

1.便於單個服務的擴容。哪一個服務在執行過程中發現使用頻率高、壓力大，那麼就可以建立這個api的多個例項，橫向擴充套件來實現擴容減壓削峰。

2.便於程式程式碼更新維護。多人協作開發，每個人負責的服務都不一樣。為了釋出某個服務時不影響其他線上正常執行的服務，一般每個服務都有自己的git庫，開發、部署都是獨立的，因為一個大系統被拆分成n個小服務，所以開發維護起來也方便。

3.符合微服務各司其職，服務間低耦合高內聚的理念。微服務，服務間就是要保持高度的無關性、單一性，服務不建議跨職責。那麼api分離以後使得專案結構更清晰，呼叫鏈路更明瞭，出問題後跟著鏈路排查更方便快速。

4.程式碼複用。一個小的微服務專案中，可能有common、spi、provider、consumer、cache、mq這幾個公用模組，他們是為api提供服務的，那麼如果以後想加其他的api模組（比如back是給後臺管理系統的前端介面使用的），那麼就可以直接依賴spi或者provider，他們就會互相引用依賴，來實現面向前端介面的api模組共用一套基礎模組系列。

首先微服務本就是由一個個的服務組成，每個服務基本都是以API的形式對外/內提供服務的

拆分的粒度

根據公司規模，pv，uv的不通，拆分的多少也不同，

例如:有幾塊業務，每天uv也就那麼幾個幾十個，pv幾千不過萬，並且可預見的未來也不會上漲，那就沒必要每個業務一個微服務，完全可以合併成一個;

再比如:有一個介面，併發量過千上萬，那麼，這一個介面就可以獨立出來一個服務

按業務劃分

對內api服務，對外api服務，業務a服務，業務b服務，等等，當然這些服務結合實際情況也可以合併成一個，直到達到某種條件之後，再分離出來.

另外某一塊業務，長期內需要經常性的變動發版，為了不影響其它功能，也可以獨立出一個服務，待到時機成熟後，再合併到其它服務中

總結

微服務並不是說越多越好，需要結合公司內部情況，量力而行，關於業務劃分亦是如此。因此。api模組單獨分離出來對公司對業務的好處在那裡？這是一個需要深思的問題。並不是說大佬公司分離了，我們也要分離

現在的軟體開發模式和傳統的有很多差別，傳統的開發模式耦合度較高，隨著技術的發展越來越多的開發模式被應用，比如微服務架構模式。其實很多開發語言都有自己的微服務解決方案，如Java系的Spring Boot、Spring Cloud等。但在實際專案開發中，即使是在微服務開發模式下，依舊有很多人喜歡單獨抽離出一個api模組，這是為什麼呢？

什麼是微服務？

其實“微服務”並不是一種新的技術，而是一種新興的架構模式。簡單的說就是將一個服務拆成多個顆粒度小、易複用的子服務，這樣做的好處就是：

應用/服務解耦，避免了單個業務過於複雜；每個微服務獨立開發和部署，擴充套件性更強，可以實現服務高可用；服務元件化，易複用。後端微服務開發時為什麼還要單獨抽離API模組？

既然我們是以微服務模式來開發專案的，為什麼很多開發者還習慣性的建立一個API模組出來呢？

其實開發微服務時，可以採用單模組模式來開發，而很多人採用多模組來開發是因為遵循了“高內聚、低耦合”的設計模式，這樣做的優點就是：

1、邊界清晰、易於管理

一箇中型專案在開發時會有很多業務和模組，它們分散在各個包中，這樣就很混亂。如果有些API是希望對外公開的，有些API只允許內部訪問或有限訪問，那就有必要將公開的API單獨抽離到一個單獨的API模組中，這樣管理起來更方便。

2、各模組間更容易聚合

把專案拆成多模組來開發，我們可以透過maven等來解決依懶關係，可以很方便的實現模組間的聚合，各個模組也可以單獨使用。

比如將工程拆分為這幾個模組：公共模組、對外API模組、管理和監控模組、業務模組等。

API是一個比較特殊的層，前面對接客戶端，後面對接微服務，一般來說，API承擔閘道器的角色，需要暴露在公網，最好部署在DMZ區域（可以理解為特殊隔離區），功能上除了處理業務請求外，還要承擔鑑權，限流，熔斷，服務降級等全域性任務，所以一般會單獨拎出來，作為一個獨立模組開發和運維

不單單java提倡後端api單獨模組拿出來呼叫，現在程式語言同樣都提倡如此。

那麼，我們為什麼要這樣做呢？有什麼好處嗎？

首先，我們說說目前對於web應用有哪些使用場景。一般而言，一個web應用，必定有個後臺管理，其次可能會有入口網站，或者小程式，或者h5，再或者安卓和iOS。這麼多端，這多的對接，如果我們每套都做對應介面那後端人不煩死了？

所以我們會想著方便，統一用一套標準，這個就是所謂的前後端分離。

這樣下來我們後端開發就可以省很多時間。可以做更多其他事情。

前後端分離可以起到程式不必過於依賴某一塊程式碼，咋們寫的程式看起來也不會太過冗餘。評判一個程式碼寫的好壞，我們會從程式碼的簡潔，可複用的程度，變數命名是否言簡意賅等。

所以努力做個優秀開發者，不要只做碼農，好好創造，你是最優秀的程式設計師喲。

覺得我說的還馬馬虎虎的，給個關注。