戳藍字“CSDN云計算”關注我們哦！

過去幾年來，“微服務架構”這個術語出現了，它描述了一種將軟件應用程序設計為可獨立部署的服務套件的特定方式。近幾年微服務吵的也比較火，那么為什么微服務會受到這么多的關注？今天，我們就來看看有關于微服務的精華問答吧

1

Q：微服務的主要作用是什么？

A：微服務被用來創建一些復雜的系統，這些系統由小型且自治的服務構成，而這些服務通過各自的API接口進行數據交換，同時有相應的有界上下文明確它們的范圍，一定程度來說，微服務就是面向對象編程方法所期待的東西。

2

Q：微服務應該如何拆分？

A：服務拆分有3個層次：

第一，是把技術性功能拆分出來比如，短信服務、郵件服務；這是最簡單的沒有大的難點；無非是接口管理優化一下。

第二，是把并行的無交集的業務流拆分出來；如果業務庫拆分了，則難點是跨庫表連接如何處理。一般只能把需要連接的數據進行同步。

第三，是將某業務流中串行的業務節點拆分出來；業務節點分別在不同jvm中運行，則難點是分布式事物。

跨jvm的分布式事物，可以用micro-datasource解決。

3

Q：如何把應用分成若干個小服務？

A：第一，按業務功能分解，將應用分解成能產生業務價值的最小單元。第二，對于跨多個業務的類（如訂單會被訂單管理、訂單交付多個服務用到）用領域驅動設計（DDD），使用子域和邊界上下文的概念來著手解決。

4

Q：在微服務, 前后端分離的場景下，服務端的設計的接口應該是復合性的接口還是原子性的接口？例如:?一個web首頁, 需要展示帖子列表、推薦帖子、活動信息等多個模塊，那么服務端應該分別提供 查詢帖子列表，查詢推薦帖子列表，查詢活動信息列表等多個原子性接口。還是給前端提供一個復合接口, 一次性返回所有數據?

A：在微服務的系統架構體系內，倡導的是解耦！從后端的角度看，業務系統的設計（或者說數據庫設計）應該遵循領域建模的原則，給前端提供的接口，無非是對模型（表）的CRUD，那么對于活動信息、帖子信息等，明顯不屬于一個領域模型。如果做耦合會不利于后面的

業務擴展。http接口的定義要與實際的交互相結合，在滿足架構設計的原則下，也需要和前端進行溝通，一起制定。

5

Q：現在有個微服務項目，項目框架搭建中，多個微服務創建的過程中會用到一些spring boot常用的依賴，比如spring-boot-starter-web，spring-cloud-starter-eureka-server等必須的依賴，難道每個服務的pom文件中都要有這樣的依賴嗎，如果每個pom文件都這樣，后期jar升級是不是很麻煩，于是做了一個共通的jar，把所需要的共通依賴加載進來，可是后面發現好像會有jar沖突的現象，不知道有什么好的解決方案？

A：第一步，創建一個maven工程作為父工程(此工程放子工程公共依賴);第二步，把Packaging標簽改為pom并保存；第三步，點擊Overview視圖找到Modules標簽,標簽右邊有兩個按鈕一個Add,一個Create)；第四步，點擊Create標簽創建子工程,子工程自動依賴父工程pom,子工程特殊依賴只要在子工程pom加入即可。

---------------- ?完? --------------

1.微信群：

添加小編微信：color_ld，備注“進群+姓名+公司職位”即可，加入【云計算學習交流群】，和志同道合的朋友們共同打卡學習！

2.征稿：

投稿郵箱：liudan@csdn.net；微信號：color_ld。請備注投稿+姓名+公司職位。

推薦閱讀

• 云計算到底是怎么玩的？

• 企業云存儲建設之路

• AI in 美團：吃喝玩樂背后的黑科技

• 開除“野狗”式程序員，團隊的效率提高了
  

• Windows 成“棄子”，Linux 終上位？

• 可替代Android的6大開源移動操作系統

• 程序員求助：被領導強行要求寫Bug該怎么辦？網友的回答讓我笑翻

點擊“閱讀原文”，打開 CSDN App 閱讀更貼心！

喜歡就點擊“好看”吧！

總結

以上是生活随笔為你收集整理的有问有答 | 你真的理解微服务架构吗?的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。