當專案確定好拆分的方向，是按照功能拆分，還是按照解耦來進行拆分的，這時候就會明白，需要實現的某個微服務的具體細節部分，比如說，現在需要實現一個消費捉拍機捉取到的圖片進行入庫的操作，這時候可能考慮到實際生產中的併發的問題，以及呼叫演算法庫進行人臉特徵識別的過程，如果考慮到併發的消費問題，我推薦使用rabbitMQ來實現服務隔離以及錯峰的功能，這是為了能讓服務在rabbitMQ的冪等性下得到有效的緩衝對資料庫的壓力，而演算法庫這邊就需要通過feign進行對服務介面的呼叫。因此大致的邏輯就出現了。從API到SQL最後到應用的解耦編碼，功能的細分。
所以這裡需要跟前端交接好需要提供的介面是什麼處理的資料是哪些json，是否需要非同步來處理，是否需要考慮高併發的情況，是否支援高可用的效能，這樣溝通好就可以進行開發。業務是其次，真正體現價值的是對高併發場景下的處理，比如這裡使用到的rabbitMQ就是為了這種高併發場景下的錯峰而使用，在後續的演進的過程中，對於redis的使用肯定也是會單獨的抽象成一個元件來提供給各個微服務進行呼叫，作為一個單獨的基礎層元件來提供快取的功能。
這就是大型的分散式系統使用微服務後期成熟的體現。由中介軟體抽象成單獨的元件作為基礎元件來提供服務。