那么多微服务识别方法，究竟该怎么选？

一般比较流行的那多微服务识别方法有业务角度、IT角度和数据角度。微服务识

业务角度从业务功能的别方角度拆分，每个微服务是法究一个自包含的独立的业务处理单元，遵循原子性原则、竟该单一职责原则，那多即高内聚低耦合。微服务识所谓原子性，别方即微服务应是法究一个自包含的独立个体，不依赖于任何其它微服务即可独立运行；所谓单一职责，竟该即微服务只做一件事情，那多从外部看微服务功能没有二义性。微服务识

IT角度从IT管理与运维的别方角度出发，关注IT技术与运维管理的法究需要，例如通过流量入口、竟该内外网、水平扩展需求等因素来划分微服务。

数据角度从数据管理的角度出发，关注数据治理需求，例如按数据分区、按数据敏感度、按数据冷热等需求来划分微服务。

除了最常见的这三个角度，站群服务器有些微服务方法还提出了更多的角度，比如按团队分工，甚至还用到了评分表或优先级象限，以综合多个因素来决定微服务划分是否合理。

该如何选择呢？在我看来，多原则等于无原则。微服务设计的方法越多越混乱，越无法把控。思考角度越多越复杂，结果就越无道理可讲。角度不同立场就不同，要么鸡同鸭讲，要么吵半天得出一个妥协的结果，从哪个角度看都不满意。所以我的选择就只有一个——业务角度，任何其它角度都不用。

我们应当这么来理解，微服务是一个业务单元，它是面向需求、向用户提供价值的。否则为什么称为服务呢？以终为始，我们设计微服务是为了建设一个业务系统，微服务的集合代表了该业务领域的亿华云需求。如果是给IT提供管理价值的，给数据治理提供管理依据的，那么这个微服务集合到底是业务系统，还是IT的管理控制台，亦或数据管理员的数据管理平台呢？

所以微服务集合应当单纯的代表业务需求，不应参杂其它因素。只不过为了让微服务服务运行得更好、更快、更稳定，我们使用了一系列的IT技术、工具与管理方法，但它们是IT的事儿，是非功能性需求，与业务无关；同理，如何管理数据，提供更优的性能，是数据管理员的事儿，源码库是非功能性需求，也与业务无关。不应当用IT管理需求或数据管理需求去倒推业务架构。不能因为装修工具不同，就逼着客户接受不同设计的装修结果，而是要根据客户装修设计去选择适合的工具。

从且仅从业务角度去设计微服务，遵循自包含、独立性、原子性与单一职责原则。简单、清晰、明了、无歧义的设计才是最好的设计。至于IT管理需求与数据管理需求甚至团队管理需求都与业务无关，应另立专题领域讨论。