来自twt社区同行交流,欢迎更多同行参与交流
微服务怎么拆分,有没有拆分标准,服务拆分粒度是什么?
问题来自社区会员,欢迎大家参与交流,各抒己见。
@尘世随缘 上海某互联网金融公司 技术总监
很遗憾,微服务拆分没有标准,更多是经验,以下内容是从我写的书籍上复制的。
我们从高内聚低耦合、业务模型、读写模式、演进式拆分、阶段性合并这些角度再来介绍服务拆分原则。
1.高内聚、低耦合
高内聚、低耦合是软件工程中的概念,在软件设计中通常用耦合度和内聚度作为衡量模块独立程度的标准,这个标准在微服务拆分中同样适用。从功能粒度来看,高内聚指每个服务尽可能只完成一件事( 最大限度地 聚合 ;低耦合指减少外部服务依赖,尽量避免服务调用服务。从数据库角度来看,每个服务都需要单独使用独立的数据库,如果外部的服务需要使用数据,则必须通过接口方式来调用,杜绝外部服务通过直 连 数据库的方式获取数据。
2.业务模型
有了高内聚低耦合的前提,就可以通过业务模型维度来做服务拆分,比如将用户、商品、订单、评论都拆分为独立的服务,把相关的业务都聚合在同一个服务中,这样不仅可以避免 跨 数据库所引发的数据一致性问题,还可以减少调用外部服务。这种拆分在初期阶段粒度会较粗,可以通过后续的迭代频率 吞吐量大小来衡量是否需要继续拆分。
3.按读写模式拆分
当业务量达到一定阶段时,就需要考虑按读写模式拆分服务,即把同一类型服务的读和写操作拆分到不同的服务上。比如,在正常情况下 User 表会被划分为用户服务( user-service ,提供用户信息查询接口( UserReadService 和用户信息写入接口 (UserWriteService) ,假设线上用户的服务读写比例差距非常大,有 90% 的读操作和 10% 的写操作,此时可以考虑把 UserReadService 和 UserWriteService 分别拆分为独立的服务发布,同时增加 UserReadService 的副本数量,以保障服务的稳定性。
4.演进式拆分
微服务拆分是不可能一气呵成的,需要根据业务的发展来持续拆分和演进,称之为演进式拆分,在演进过程中一定要去积极了解业务及公司的发展方向。比如在微服务重构的初级阶段, App 首页的产品列表和搜索页的产品列表由同一个服务提供,在后续需求迭代中 App 首页的产品列表需求迭代非常频繁,如果仅仅将产品列表需求拆分成首页列表服务和搜索页列表服务是不行的,因为在后续迭代中需要首页列表服务做到个性化(即千人千面 的风格。
@zhanghq1314 亿阳信通 系统工程师
正常拆分原则 1参考 AKF 扩展立方体 ;2前后端分离;3无状态原则;4 Restful 通信原则。
社区正在组织进行“微服务架构演变实战——企业应用如何从单体转型到微服务架构”线上交流(点击链接 可了解详情 ,任何相关问题均可前往向专家提问,和同行交流。
觉得本文有用,请转发、点赞 点击在看,让更多同行看到
/文章推荐
微服务拆分的原则、方法和误区
欢迎关注社区 “微服务”技术主题 ,将会不断更新优质 、文章。地址 http://www..com/Topic/95163
长按二维码关注
*本 所发布内容仅代表作者观点,不代表社区立场;封面图片由版权图库授权使用
Powered by 小羊羔外链网 8.3.7
©2015 - 2024 小羊羔外链网
您的IP:34.203.242.200,2024-03-28 22:53:39,Processed in 0.04689 second(s).