時至今日，微服務相關的話題不勝列舉，上百次的會議，線上討論以及相關文章。你可以假設大家已經認識到其優點以及與之俱來的風險。然而，有很多組織沒有事先準備就邁入這個潮流了。自然，這也就導致了在架構實現過程中的失敗。

1. 從繪圖入手

比如，在一款圖書預覽應用中，其主要的功能就是比較不同的圖書。然而，也有許多其他功能需要開發，例如建立使用者履歷，評分，評論，圖書資料庫等。識別每個功能，是將它們轉為微服務的關鍵。

2. 微服務並不是組織結構

根據你所在公司的組織結構定義微服務，這似乎是很自然的。如果你正在構建單體（monolithic）應用，這或許真是一個恰當的解決方案。但是，在實現微服務架構時，它可能就是一個錯誤的決定了。

也許，這對於銷售部門或客戶服務是可行的，但是許多組織只有一個部門處理所有的資料庫。因此，為所有資料庫建立一個微服務將會導致單點故障。而沒有單點故障，則是微服務的關鍵特性之一。

你希望通過服務實現的一些功能可能會涉及幾個組織部門，或者，你可能將會需要為一個部門構建許多微服務。總結一下，你需要將架構聚焦於你想要提供的服務，而非你們公司的組織結構。

3. 建立合適的組織結構

轉變到一個全然不同的組織架構，能夠滿足公司在管控活動上變化的需要。之前2個步驟關注於應用的設計，以便能夠為終端使用者提供正確的功能。現在，是時候確保對於新的架構而言，你擁有恰當的運維支援了。

你將不得不放棄原有的部門結構，並使團隊關注於某個微服務。這意味著這些團隊將由擁有不同技能的成員組成，如系統分析師、UX/UI設計師、後端工程師、前端工程師等。如此一來，團隊就能夠徹底負責它們的專案（微服務）——從開發部署到運維、監控和管理。反過來，由於團隊覺得自己擁有這個產品，因此將提升其建立產品的積極性。

團隊的規模視公司/專案的總體人數而定；當然，根據專家的建議，比較理想的規模是每個團隊8-10人。和單體架構不同，微服務架構使得你能夠根據業務的增長來擴展團隊規模。

4. 效能和可靠性同樣重要