Spring Cloud課程幹貨總結第八期—微服務架構的設計政策

哈喽各位同學們大家好呀，小編今天帶着開發者學院中課程“微服務架構的設計政策 ”幹貨總結來了~一起學習新課程吧！

課程連結以及圖譜位址小編已經為大家指路了，搭配學習效果更佳👇

課程名稱：微服務架構的設計政策

課程位址：

https://developer.aliyun.com/learning/course/60/detail/1111

圖譜名稱：Alibaba Java 技術圖譜

圖譜位址：

https://developer.aliyun.com/graph/java

微服務架構的設計政策

咱們這節課重點關注如何進行微服務架構設計。第一階段我們主要是偏重理論體系和微服務相關的整個系統的重要概念原則，會給大家介紹打下堅實的基礎，為後面的實戰練習做鋪墊。 

學習分三大階段 

1. 微服務Microservice的設計原則 
2. 微服務架構的設計原則 
3. 微服務Microservice設計的關注點

首先大家來思考一個問題，如果讓你做微服務架構設計的話，你怎麼樣去設計微服務？你的微服務應該具備哪些特點的特性？ 

給大家總結重要的一點，我們記住一個問題，微服務架構本身也屬于分布式架構，隻不過它是更複雜的分布式架構。我們在講微服務概念的時候，咱們提到過微服務實際它是誕生于SoA時代是以它還具備SoA架構的一些特點，記住我們所有的架構設計有很重要的一個原則： 

需求第一：一定要以需求為出發點。所有的架構好與壞一定是相對的，相對他處的一個需求背景。因為微服務架構能夠在某些業務場景中具備優勢，是以它相比傳統的架構，他有一些優點但是同時也存在着缺點，它不完美。 

單一職責：我們的服務盡量是展現單一職責的思想，粒度不是越細越好，也不是越粗越好。 

協定統一：還有盡量去統一協定，不包括不得已的話，我們不引入其他協定像我們一般微服務的話，咱們講現在目前的協定主要是rest有可能會比如說有可能你會引入消費者的協定，或者引入其他的這種通訊協定，當然在我們說都是基于實際的需求 

獨立開發：獨立開發一般咱們這裡面提到的我們說的是子產品拆分以後開發人員一般是獨立我們按照子產品進行拆分，然後每個人負責一塊，每個人熟悉一塊代碼和邏輯業務邏輯這樣的話開發時間都會相對來說高很多 

獨立部署：獨立部署這也是微服架構的很重要的一個原則，咱們講了微服務架構拆分以後又會出現可能很多程式很多程序，而且每一個子產品不是所有的都更新隻需要疊代我那一塊就行了，就是展現了我們說叫分而治之的這樣一個思想，大家一起統一部署。 

微服務Microservice的拆分原則 

按照業務子產品拆分 

你找一個大概的服務，拆分力度的話一般的話還是基于業務。 

DDD思路可以借鑒，不能照搬 

DDD本身不是架構設計模式，DDD是一種但是在向對象設計的一個思想或者原則，它是用來解決複雜業務邏輯的一個拆分問題的，它本身并不解決整個架構層次的問題，它是解決業務層的，了解這一點。 

單一職責 Single Responsibility  

電商架構設計： 

• • 賬号子產品 
  • 商品子產品 
  • 訂單子產品 
  • 評論子產品 
  • 快遞子產品 
  • 短信子產品 
  • 支付子產品 
  • 卡券子產品 
  • 信用子產品 
  • 酒店子產品 

場景它本身就像個生态一樣，它裡面接入的功能子產品多，這裡面天生适合和足夠龐大的基礎上适合分人制快速疊代。微服務架構，新的業務誕生早期可能隻有兩三台伺服器，後面的話做起來可能上千台伺服器。包括遊戲也一樣前端很多平台是屬于導遊的模式，加入一個子產品進來，這個平台作為一個入口。拆分原則一般的話我們是基于業務進行拆分，或者你也可以說是DDD. 

微服務架構設計的關注點 

微服務Microservice設計的關注點 

微服務架構的新特性  

微服務Microservice設計的五大考量 

微服務架構設計的5大考量 

一個架構師它采用的微服務架構一定要說服别人需要給個合适的理由。服務架構裡面在做事物的話是比較難的，是以要注意一個資料一緻性問題。