『高階篇』docker容器來說微服務優勢和不足（四）

摘要： 來看看微服務有哪些優勢和不足。 優勢 獨立性 >從構建部署，擴容收容，容錯，資料庫都是單獨管理的。每個服務之間都是單獨管理。一個微服務出現問題，只會影響他自己。並不會影響整個服務。每個都獨立的資料庫。 敏捷性...

來看看微服務有哪些優勢和不足。

優勢

• 獨立性

  >從構建部署，擴容收容，容錯，資料庫都是單獨管理的。每個服務之間都是單獨管理。一個微服務出現問題，只會影響他自己。並不會影響整個服務。每個都獨立的資料庫。

• 敏捷性
  

  對於使用者來說微服務暴露的介面相對簡單，因為他們的功能都很單一，清晰的api，同時也可以很快的應對變化，針對新需求很快的找到需要修改的微服務，去修改就可以。

• 技術棧靈活
  

  api介面不變就可以了，服務重構。

• 高效團隊
  

  每個團隊只負責自己的微服務，做些架構調整，架構變化，幾個人開個小會就可以了。

不足

沒有最好的架構，只有最適合的。

• 額外的工作
  

  服務的拆分，其實服務的拆分是一門非常深的學問。

• 資料的一致性
  

  單體一個數據庫，很容易做到一致性，微服務都有自己的服務，雖然我們在微服務儘量減少連表操作，儘量在同一個微服務，也難免出現這樣或者那樣的關聯關係。

• 溝通成本
  

  api的改變，單體架構中，想改一個介面可以將呼叫這個介面的地方順便改掉，但是在微服務中，你想改的地方不是你負責，推動其他人其他組來修改。如果其他人或者其他組比較多的溝通成本就很明白了。

瞭解DDD（領域驅動設計）

• 軟體開發 VS DDD
  

  一般軟體設計或者說軟體開發分兩種：瀑布式，敏捷式。

• 前者一般是專案經理經過大量的業務分析後，會基於現有需求整理出一個基本模型，再將結果傳遞給開發人員，這就是開發人員的需求文件，他們只需要照此開發便是。這種模式下，是很難頻繁的從使用者那裡得到反饋，因此在前期分析時就已經默認了這個業務模型是正確的，那麼結果可想而之，數月甚至數年後交付的時候，必然和客戶的預期差距較大。

• 後者在此基礎上進行了改進，它也需要大量的分析，範圍會設計到更精細的業務模組，它是小步迭代，週期性交付，那麼獲取客戶的反饋也就比較頻繁和及時。可敏捷也不能夠將業務中的方方面面都考慮到，並且敏捷是擁抱變化的，大量的需求或者業務模型變更必將帶來不小的維護成本，同時，對人（Developer）的要求也必然會更高。

• DDD則不同：它像是更小粒度的迭代設計，它的最小單元是領域模型(Domain Model)，所謂領域模型就是能夠精確反映領域中某一知識元素的載體，這種知識的獲取需要通過與領域專家(Domain Expert)進行頻繁的溝通才能將專業知識轉化為領域模型。領域模型無關技術，具有高度的業務抽象性，它能夠精確的描述領域中的知識體系；同時它也是獨立的，我們還需要學會如何讓它具有表達性，讓模型彼此之間建立關係，形成完整的領域架構。通常我們可以用象形圖或一種通用的語言(Ubiquitous Language)去描述它們之間的關係。在此之上，我們就可以進行領域中的程式碼設計(Domain Code Design)。如果將軟體設計比做是造一座房子，那麼領域程式碼設計就好比是貼桌布。前者已經將房子的藍圖框架規劃好，而後者只是一個小部分的設計：如果牆紙貼錯了，我們可以重來，可如果房子結構設計錯了，那可就悲劇了。

PS：微服務的要求是分析的足夠小的顆粒，專案分析的透徹。

ofollow,noindex" target="_blank" href="http://zhanzhang.baidu.com/sitesubmit/index?sitename=https://idig8.com/2018/09/15/gaojipiandockerrongqilaishuoweifuwuyoushihebuzusi/">百度未收錄

>>原創文章，歡迎轉載。轉載請註明：轉載自IT人故事會，謝謝！

>>原文連結地址：