那么多微服务识别方法,究竟该怎么选?
一般比较流行的微服务识别方法有业务角度、IT角度和数据角度。
业务角度从业务功能的角度拆分,每个微服务是一个自包含的独立的业务处理单元,遵循原子性原则、单一职责原则,即高内聚低耦合。所谓原子性,即微服务应是一个自包含的独立个体,不依赖于任何其它微服务即可独立运行;所谓单一职责,即微服务只做一件事情,从外部看微服务功能没有二义性。
IT角度从IT管理与运维的角度出发,关注IT技术与运维管理的需要,例如通过流量入口、内外网、水平扩展需求等因素来划分微服务。
数据角度从数据管理的角度出发,关注数据治理需求,例如按数据分区、按数据敏感度、按数据冷热等需求来划分微服务。
除了最常见的这三个角度,有些微服务方法还提出了更多的角度,比如按团队分工,甚至还用到了评分表或优先级象限,以综合多个因素来决定微服务划分是否合理。
该如何选择呢?在我看来,多原则等于无原则。微服务设计的方法越多越混乱,越无法把控。思考角度越多越复杂,结果就越无道理可讲。角度不同立场就不同,要么鸡同鸭讲,要么吵半天得出一个妥协的结果,从哪个角度看都不满意。所以我的选择就只有一个——业务角度,任何其它角度都不用。
我们应当这么来理解,微服务是一个业务单元,它是面向需求、向用户提供价值的。否则为什么称为服务呢?以终为始,我们设计微服务是为了建设一个业务系统,微服务的集合代表了该业务领域的需求。如果是给IT提供管理价值的,给数据治理提供管理依据的,那么这个微服务集合到底是业务系统,还是IT的管理控制台,亦或数据管理员的数据管理平台呢?
所以微服务集合应当单纯的代表业务需求,不应参杂其它因素。只不过为了让微服务服务运行得更好、更快、更稳定,我们使用了一系列的IT技术、工具与管理方法,但它们是IT的事儿,是非功能性需求,与业务无关;同理,如何管理数据,提供更优的性能,是数据管理员的事儿,是非功能性需求,也与业务无关。不应当用IT管理需求或数据管理需求去倒推业务架构。不能因为装修工具不同,就逼着客户接受不同设计的装修结果,而是要根据客户装修设计去选择适合的工具。
从且仅从业务角度去设计微服务,遵循自包含、独立性、原子性与单一职责原则。简单、清晰、明了、无歧义的设计才是最好的设计。至于IT管理需求与数据管理需求甚至团队管理需求都与业务无关,应另立专题领域讨论。
相关文章
- 聊聊一致性Hash算法代码实现
- Go 语言如何实现字符串切片反转函数
- PROGENy: Pathway RespOnsive GENes for activity inference(一)
- Go 真实项目的性能案例研究
- 重大发现,AQS加锁机制竟然跟Synchronized有惊人的相似
- 【Go微服务】一文带你玩转ProtoBuf
- 通过一个插件来了解Neovim的Winbar属性
- scRNA-seq 多发性硬化症的CSF白细胞及其来源组织进行特征分析
- 表观遗传分析5 HI-C
- Go 十年了,终于想起要统一 log 库了!
- Liftoff:基因组注释映射工具
- 通路反应基因活性推断工具:PROGENy(二)
- 【集群管理神器】Golang竟然可以做出那么惊艳的系统
- 深入理解 Go 语言的一等函数及其应用
- 如何进行批量差异分析并绘制其火山图及拼图
- 十个高级 TypeScript 开发技巧
- 文献分享——乳腺癌肝和脑转移瘤内异质性的单细胞景观和免疫抑制微环境
- 精华文稿|在非理想输入下NeRF的重建
- 安装教程arcgis10.2
- 为什么 Vite 的请求有时候是相对路径,有时候是 /@fs/ + 绝对路径?