微服務架構宜緩行
前不久，ThoughtWorks首席科學家Martin Fowler發表了一篇 博文 ，探討MonolithFirst策略。他寫道：
除非你的系統太復雜，作為單體應用會很難管理，否則不要考慮微服務。絕大多數軟件系統都應該構建為單體應用。要注重在單體應用中實現良好的模塊化，但不要試圖將其拆分成單獨的服務。
Tyler Treat是來自 Workiva 的一名軟件開發人員，同時也是咨詢公司 Clarion Media 的創建者。近日，他發表了一篇博文《 非面向服務的架構 》（DOA）。文中，他對Fowler的觀點表示了贊同，同時他指出，團隊迫不及待地采用微服務架構，一個原因是像Fowler所說的那樣，他們不了解微服務的 固有開銷 ，另外一個原因是他們只看到了像Netflix公司這樣的成功案例，卻沒有意識到那些公司并不是從微服務開始的，也就是說，是“ 微服務妒羨（microservice envy） ”導致團隊作出了那樣的選擇。
微服務確實有許多優點：“反脆弱性（anti-fragility）”、容錯、獨立部署與擴展、架構抽象、技術隔離。但并不是說采用了微服務就自然地具備了這些特性。比如，要具備反脆弱性，需要充分考慮分布式系統的不確定性，清楚異步、網絡劃分、節點故障、平衡可用性與數據一致性等問題。同樣地，要具備可維護性和可擴展性，首先要有恰當的基礎設施和組織結構。理論上講，微服務可以提高開發速度，但在創建組織依賴時，“ 微服務傭金（MicroservicePremium） ”可能會降低開發速度。所以，采用微服務架構需要具備一些先決條件，包括恰當的持續發布管道、能勝任的DevOps和Ops團隊、審慎的服務邊界等等。此外，周密的測試和集成模式也很重要。
而提到“單體（monolith）”，人們就會想到不可擴展、不可維護、缺乏彈性。但實際上，只要規模合理，單體系統也可以具有模塊化、可維護、容錯等特性。
因此，Treat認為，自下而上的方法是一種更好的微服務實施策略。像Fowler所說的那樣，從單體或一個粗粒度服務的小集合開始，在有了足夠的服務維護和部署經驗后，再逐步分離出更細粒度的服務。
總之，微服務需要很高的組織和系統成熟度。否則，匆忙采用只能創建出一個“非面向服務的架構（disservice-oriented architecture）”。