一、客戶在微服務化實踐過程中遇到的問題（源自真實案例）
- 某跨國領軍企業，以自上而下全新分析、設計爲思路，以識別的業務對象爲業務邊界識別微服務，以重新開發、數據遷移做爲手段實踐微服務，發現依然無法達到1-2weeks持續交付的目標，不同領域部門質疑其方法的合理性。
- 某金融業客戶，以SOA方法劃分微服務粒度，以微服務框架做爲實現手段，堅持保持傳統需求管理、瀑布方法，結果出現開發版本依賴、構建依賴、上線依賴等現象嚴重。
- 某互聯網公司，本想完全基於異步微服務實現，但由於分佈式事務組件不具備、開發量大、大大影響開發、調度效率，不得不第一步先改爲SOA方式才解決交付瓶頸。
- 某跨國領軍企業，由於數據模型過於滿足第三範式，導致數據模型無法解耦從而進一步進行有效的微服務切分，另在使用了微服務架構之後，發現性能反而下降。
二、爲什麼呢？
- 對於龐大複雜業務，按抽象的業務對象爲業務邊界是不夠的，粒度過粗。
- 以SOA將微服務分層、團隊之間也必然出現分層，架構依賴關係依然存大，微服務解耦是從業務到上線的垂直解耦，這是關鍵、關鍵、關鍵。傳統需求管理喜歡搞大版本需求，業務業務邊界沒有按微服務範圍解耦，需求人員沒有解耦，沒有建立獨立演進的機制。
- 沒有分佈式事務組件、分佈式跟蹤平臺、DevOps平臺的支撐，微服務的開發、調試、運維就快不起來。
- 數據模型是微服務化的關鍵，屬性未分層、未按分層拆表是無法微服務化的。