那么多微服务识别方法，究竟该怎么选？
source link: https://www.51cto.com/article/716523.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
那么多微服务识别方法，究竟该怎么选？-51CTO.COM
一般比较流行的微服务识别方法有业务角度、IT角度和数据角度。
一般比较流行的微服务识别方法有业务角度、IT角度和数据角度。
业务角度从业务功能的角度拆分，每个微服务是一个自包含的独立的业务处理单元，遵循原子性原则、单一职责原则，即高内聚低耦合。所谓原子性，即微服务应是一个自包含的独立个体，不依赖于任何其它微服务即可独立运行；所谓单一职责，即微服务只做一件事情，从外部看微服务功能没有二义性。
IT角度从IT管理与运维的角度出发，关注IT技术与运维管理的需要，例如通过流量入口、内外网、水平扩展需求等因素来划分微服务。
数据角度从数据管理的角度出发，关注数据治理需求，例如按数据分区、按数据敏感度、按数据冷热等需求来划分微服务。
除了最常见的这三个角度，有些微服务方法还提出了更多的角度，比如按团队分工，甚至还用到了评分表或优先级象限，以综合多个因素来决定微服务划分是否合理。
该如何选择呢？在我看来，多原则等于无原则。微服务设计的方法越多越混乱，越无法把控。思考角度越多越复杂，结果就越无道理可讲。角度不同立场就不同，要么鸡同鸭讲，要么吵半天得出一个妥协的结果，从哪个角度看都不满意。所以我的选择就只有一个——业务角度，任何其它角度都不用。
我们应当这么来理解，微服务是一个业务单元，它是面向需求、向用户提供价值的。否则为什么称为服务呢？以终为始，我们设计微服务是为了建设一个业务系统，微服务的集合代表了该业务领域的需求。如果是给IT提供管理价值的，给数据治理提供管理依据的，那么这个微服务集合到底是业务系统，还是IT的管理控制台，亦或数据管理员的数据管理平台呢？
所以微服务集合应当单纯的代表业务需求，不应参杂其它因素。只不过为了让微服务服务运行得更好、更快、更稳定，我们使用了一系列的IT技术、工具与管理方法，但它们是IT的事儿，是非功能性需求，与业务无关；同理，如何管理数据，提供更优的性能，是数据管理员的事儿，是非功能性需求，也与业务无关。不应当用IT管理需求或数据管理需求去倒推业务架构。不能因为装修工具不同，就逼着客户接受不同设计的装修结果，而是要根据客户装修设计去选择适合的工具。
从且仅从业务角度去设计微服务，遵循自包含、独立性、原子性与单一职责原则。简单、清晰、明了、无歧义的设计才是最好的设计。至于IT管理需求与数据管理需求甚至团队管理需求都与业务无关，应另立专题领域讨论。
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK