Monolithic比較適合小項目，優點是：
開發簡單直接，集中式管理, 基本不會重複開發
功能都在本地，沒有分佈式的管理開銷和調用開銷。它的缺點也非常明顯，特別對於互聯網公司來說（不一一列舉了）：
開發效率低：所有的開發在一個項目改代碼，遞交代碼相互等待，代碼衝突不斷
代碼維護難：代碼功能耦合在一起，新人不知道何從下手
部署不靈活：構建時間長，任何小修改必須重新構建整個項目，這個過程往往很長
穩定性不高：一個微不足道的小問題，可以導致整個應用掛掉
擴展性不夠：無法滿足高併發情況下的業務需求
微服務架構
微服務是指開發一個單個小型的但有業務功能的服務，每個服務都有自己的處理和輕量通訊機制，可以部署在單個或多個服務器上。微服務也指一種種鬆耦合的、有一定的有界上下文的面向服務架構。也就是說，如果每個服務都要同時修改，那麼它們就不是微服務，因爲它們緊耦合在一起；如果你需要掌握一個服務太多的上下文場景使用條件，那麼它就是一個有上下文邊界的服務，這個定義來自DDD領域驅動設計。
相對於單體架構和SOA，它的主要特點是組件化、鬆耦合、自治、去中心化，體現在以下幾個方面：
一組小的服務
服務粒度要小，而每個服務是針對一個單一職責的業務能力的封裝，專注做好一件事情。獨立部署運行和擴展
每個服務能夠獨立被部署並運行在一個進程內。這種運行和部署方式能夠賦予系統靈活的代碼組織方式和發佈節奏，使得快速交付和應對變化成爲可能。獨立開發和演化
技術選型靈活，不受遺留系統技術約束。合適的業務問題選擇合適的技術可以獨立演化。服務與服務之間採取與語言無關的API進行集成。相對單體架構，微服務架構是更面向業務創新的一種架構模式。獨立團隊和自治
團隊對服務的整個生命週期負責，工作在獨立的上下文中，自己決策自己治理，而不需要統一的指揮中心。團隊和團隊之間通過鬆散的社區部落進行銜接。
我們可以看到整個微服務的思想就如我們現在面對信息爆炸、知識爆炸是一樣的：通過解耦我們所做的事情，分而治之以減少不必要的損耗，使得整個複雜的系統和組織能夠快速的應對變化。
我們爲什麼採用微服務呢？
"讓我們的系統儘可能快地響應變化" ——Rebecca Parson
讓我們的系統儘可能快地去響應變化。其實幾十年來我們一直在嘗試解決這個問題。如果一定要在前面加個限制的話，那就是低成本的快速響應變化。上世紀90年代Kent Beck提出要擁抱變化，在同期出現了諸多輕量級開發方法（諸如 XP、Scrum）；2001年敏捷宣言誕生，之後又出現了精益、看板等新的管理方式。如果說，這些是爲了儘快的響應變化，在軟件開發流程和實踐方面提出的解決方案，那麼微服務架構就是在軟件技術和架構層面提出的應對之道。
什麼時候該使用微服務架構呢？
服務之間如何通信呢
