一般比较流行的微服务识别方式有业务视角、IT视角和数据视角。业务视角是从业务功能的角度拆分出来的。每个微服务都是一个自成一体的独立业务处理单元，遵循原子性和单一职责原则，即高内聚低耦合。所谓原子性，是指微服务应该是一个自包含的独立实体，可以独立运行，不依赖任何其他微服务；所谓单一职责，就是微服务只做一件事，微服务的功能从外部来看是没有歧义的。从IT管理和运维的角度，关注IT技术和运维管理的需求，比如根据流量入口、内外网络、横向扩展需求等因素划分微服务。从数据管理的角度，关注数据治理需求，如根据数据分区、数据敏感度、数据冷热等划分微服务。除了最常见的三个角度之外，一些微服务方法还提出了更多的角度，比如团队分工，甚至使用评分表或者优先级象限来综合多种因素来判断微服务划分是否合理。如何选择？在我看来，多原则等于无原则。微服务设计的方法越多，越混乱，越不可控。思维角度越复杂，结果就越不合理。不同的观点导致不同的立场。你可以和鸭子说话，也可以争论很长时间，然后得出一个妥协的结果。无论从哪个角度，你都不满意。所以我只有一个选择——业务视角，没有用到其他视角。我们应该这样理解。微服务是一个以需求为导向，为用户提供价值的业务单元。不然为什么叫服务？我们从头开始设计微服务构建业务系统，微服务的集合代表了业务领域的需求。如果它为IT提供管理价值，为数据治理提供管理依据，那么这个微服务集合到底是业务系统、IT管理控制台，还是数据管理员的数据管理平台？因此，微服务的集合应该只是代表业务需求，不应掺杂其他因素。只是为了让微服务运行得更好、更快、更稳定，我们使用了一系列的IT技术、工具和管理方法，但它们是IT的事情，是非功能需求，与业务无关；如何管理数据并提供更好的性能是数据管理员的业务，不是功能需求，与业务无关。不应使用IT管理要求或数据管理要求向后推断业务架构。不能因为装修工具不同而强行让客户接受装修效果的不同设计，而是要根据客户的装修设计选择合适的工具。从且仅从业务角度设计微服务，遵循自包含、独立性、原子性和单一责任的原则。简单、清晰、明确、不含糊的设计才是最好的设计。至于IT管理需求、数据管理需求，甚至团队管理需求，都与业务无关，应该单独开话题区讨论。
