一般比較流行的微服務識別方法有業務角度、IT角度和數據角度。

業務角度從業務功能的角度拆分，每個微服務是一個自包含的獨立的業務處理單元，遵循原子性原則、單一職責原則，即高內聚低耦合。所謂原子性，即微服務應是一個自包含的獨立個體，不依賴于任何其它微服務即可獨立運行；所謂單一職責，即微服務只做一件事情，從外部看微服務功能沒有二義性。

IT角度從IT管理與運維的角度出發，關注IT技術與運維管理的需要，例如通過流量入口、內外網、水平擴展需求等因素來劃分微服務。

數據角度從數據管理的角度出發，關注數據治理需求，例如按數據分區、按數據敏感度、按數據冷熱等需求來劃分微服務。

除了最常見的這三個角度，有些微服務方法還提出了更多的角度，比如按團隊分工，甚至還用到了評分表或優先級象限，以綜合多個因素來決定微服務劃分是否合理。

該如何選擇呢？在我看來，多原則等于無原則。微服務設計的方法越多越混亂，越無法把控。思考角度越多越復雜，結果就越無道理可講。角度不同立場就不同，要么雞同鴨講，要么吵半天得出一個妥協的結果，從哪個角度看都不滿意。所以我的選擇就只有一個——業務角度，任何其它角度都不用。

我們應當這么來理解，微服務是一個業務單元，它是面向需求、向用戶提供價值的。否則為什么稱為服務呢？以終為始，我們設計微服務是為了建設一個業務系統，微服務的集合代表了該業務領域的需求。如果是給IT提供管理價值的，給數據治理提供管理依據的，那么這個微服務集合到底是業務系統，還是IT的管理控制臺，亦或數據管理員的數據管理平臺呢？

所以微服務集合應當單純的代表業務需求，不應參雜其它因素。只不過為了讓微服務服務運行得更好、更快、更穩定，我們使用了一系列的IT技術、工具與管理方法，但它們是IT的事兒，是非功能性需求，與業務無關；同理，如何管理數據，提供更優的性能，是數據管理員的事兒，是非功能性需求，也與業務無關。不應當用IT管理需求或數據管理需求去倒推業務架構。不能因為裝修工具不同，就逼著客戶接受不同設計的裝修結果，而是要根據客戶裝修設計去選擇適合的工具。

從且僅從業務角度去設計微服務，遵循自包含、獨立性、原子性與單一職責原則。簡單、清晰、明了、無歧義的設計才是最好的設計。至于IT管理需求與數據管理需求甚至團隊管理需求都與業務無關，應另立專題領域討論。