你的項目是否須要微服務？

微服務須要考慮的幾點內容, :)

團隊規模

團隊成員可否圍坐在一張桌邊？
Yes！ -- 你可能不須要微服務
好文檔和好設計能夠輕易解決部署等運維操做中遇到的挑戰。而微服務要解決的問題你尚未遇到。
No！ -- 微服務應該能幫到你！
團隊大到必定規模了、或者多個團隊同時工做，僅僅單靠好的設計已經不能保證組件之間有着清晰的邊界。這時將組件間的邊界強制變爲各獨立服務間的邊界會頗有幫助。

狀態

你的系統主要部分是不是無狀態的？
Yes！ -- 考慮無服務器架構（serverless）吧！
若是都是無狀態的，你可能能夠直接跳過微服務，直接使用無服務器架構——至少對你的部分系統使用。
No！ -- 微服務將帶來額外的複雜性
並非說不要使用微服務，而是要意識到它們對於實現管理來講並不重要，尤爲是當系統隨着時間推移而不斷變化的時候。

用戶

你的設計用於單個app或者服務嗎？
Yes！ -- 當心！可能會有模糊的域名
若是你的設計只服務於單一消費方（Consumer），你將會發現每次新增特性時都要同時更新許多個服務。微服務可能有效，但在設計域名時要千萬當心。
No！-- 微服務很是有價值
若是服務有多個不一樣的消費方，微服務就變得很是值得嘗試，它將容許你給新增的消費方快速帶來新特性。

依賴

服務是否有總體依賴？
Yes！ -- 性能是一個問題
這種場景下性能依賴於統一的被依賴方，所以獨立的/可擴展的服務沒什麼好處。設計服務邊界也是一個難題
No！-- 微服務頗有價值
若是不受限於一個總體的下游，你將能夠實現微服務有效擴展所需的高度獨立性。

專業知識

你是否有 容器、編排、devops 方面的專家？
Yes！ -- 微服務是有價值的
若是團隊中有專家，微服務是值得一用的。去處理它的複雜性並得到它的好處吧！
No！ -- 請先考慮實驗
若是沒有專家支持，或者正在devops中掙扎，直接上微服務將是一個巨大的挑戰。更現實的選擇是考慮一個小而簡單的服務做爲突破來驗證想法。首先在項目中學習微服務，而不是直面現實任務中的困難。