>原創文章，歡迎轉載。轉載請註明：轉載自IT人故事會，謝謝！
>原文鏈接地址：『高級篇』docker容器來說微服務優勢和不足（四）來看看微服務有哪些優勢和不足。
優勢
-
獨立性
從構建部署，擴容收容，容錯，數據庫都是單獨管理的。每個服務之間都是單獨管理。一個微服務出現問題，只會影響他自己。並不會影響整個服務。每個都獨立的數據庫。
-
敏捷性
對於使用者來說微服務暴露的接口相對簡單，因爲他們的功能都很單一，清晰的api，同時也可以很快的應對變化，針對新需求很快的找到需要修改的微服務，去修改就可以。
-
技術棧靈活
api接口不變就可以了，服務重構。
- 高效團隊
每個團隊只負責自己的微服務，做些架構調整，架構變化，幾個人開個小會就可以了。
不足
沒有最好的架構，只有最適合的。
-
額外的工作
服務的拆分，其實服務的拆分是一門非常深的學問。
-
數據的一致性
單體一個數據庫，很容易做到一致性，微服務都有自己的服務，雖然我們在微服務儘量減少連表操作，儘量在同一個微服務，也難免出現這樣或者那樣的關聯關係。
- 溝通成本
api的改變，單體架構中，想改一個接口可以將調用這個接口的地方順便改掉，但是在微服務中，你想改的地方不是你負責，推動其他人其他組來修改。如果其他人或者其他組比較多的溝通成本就很明白了。
瞭解DDD（領域驅動設計）
-
軟件開發 VS DDD
一般軟件設計或者說軟件開發分兩種：瀑布式，敏捷式。
-
前者一般是項目經理經過大量的業務分析後，會基於現有需求整理出一個基本模型，再將結果傳遞給開發人員，這就是開發人員的需求文檔，他們只需要照此開發便是。這種模式下，是很難頻繁的從用戶那裏得到反饋，因此在前期分析時就已經默認了這個業務模型是正確的，那麼結果可想而之，數月甚至數年後交付的時候，必然和客戶的預期差距較大。
-
後者在此基礎上進行了改進，它也需要大量的分析，範圍會設計到更精細的業務模塊，它是小步迭代，週期×××付，那麼獲取客戶的反饋也就比較頻繁和及時。可敏捷也不能夠將業務中的方方面面都考慮到，並且敏捷是擁抱變化的，大量的需求或者業務模型變更必將帶來不小的維護成本，同時，對人（Developer）的要求也必然會更高。
- DDD則不同：它像是更小粒度的迭代設計，它的最小單元是領域模型(Domain Model)，所謂領域模型就是能夠精確反映領域中某一知識元素的載體，這種知識的獲取需要通過與領域專家(Domain Expert)進行頻繁的溝通才能將專業知識轉化爲領域模型。領域模型無關技術，具有高度的業務抽象性，它能夠精確的描述領域中的知識體系；同時它也是獨立的，我們還需要學會如何讓它具有表達性，讓模型彼此之間建立關係，形成完整的領域架構。通常我們可以用象形圖或一種通用的語言(Ubiquitous Language)去描述它們之間的關係。在此之上，我們就可以進行領域中的代碼設計(Domain Code Design)。如果將軟件設計比做是造一座房子，那麼領域代碼設計就好比是貼壁紙。前者已經將房子的藍圖框架規劃好，而後者只是一個小部分的設計：如果牆紙貼錯了，我們可以重來，可如果房子結構設計錯了，那可就悲劇了。
PS：微服務的要求是分析的足夠小的顆粒，項目分析的透徹。