单体应用向微服务架构的转型问题?

单体应用在进行拆分时需要注意哪些问题?耦合性强的应用是否可以转微服务架构?

参与4

1同行回答

尘世随缘尘世随缘  技术总监 , 上海某互联网金融公司
服务拆分我引入我写的书上的内容来答复 我们从高内聚低耦合、业务模型、读写模式、演进式拆分、阶段性合并这些角度再来介绍服务拆分原则。1.高内聚、低耦合高内聚、低耦合是软件工程中的概念,在软件设计中通常用耦合度和内聚度作为衡量模块独立程度的标准,这个标准在微服...显示全部

服务拆分我引入我写的书上的内容来答复
我们从高内聚低耦合、业务模型、读写模式、演进式拆分、阶段性合并这些角度再来介绍服务拆分原则。

1.高内聚、低耦合

高内聚、低耦合是软件工程中的概念,在软件设计中通常用耦合度和内聚度作为衡量模块独立程度的标准,这个标准在微服务拆分中同样适用。从功能粒度来看,高内聚指每个服务尽可能只完成一件事( 最大限度地 聚合);低耦合指减少外部服务依赖,尽量避免服务调用服务。从数据库角度来看,每个服务都需要单独使用独立的数据库,如果外部的服务需要使用数据,则必须通过接口方式来调用,杜绝外部服务通过直 连 数据库的方式获取数据。

2.业务模型

有了高内聚低耦合的前提,就可以通过业务模型维度来做服务拆分,比如将用户、商品、订单、评论都拆分为独立的服务,把相关的业务都聚合在同一个服务中,这样不仅可以避免 跨 数据库所引发的数据一致性问题,还可以减少调用外部服务。这种拆分在初期阶段粒度会较粗,可以通过后续的迭代频率或吞吐量大小来衡量是否需要继续拆分。

3.按读写模式拆分

当业务量达到一定阶段时,就需要考虑按读写模式拆分服务,即把同一类型服务的读和写操作拆分到不同的服务上。比如,在正常情况下 User 表会被划分为用户服务( user-service ),提供用户信息查询接口( UserReadService )和用户信息写入接口 (UserWriteService) ,假设线上用户的服务读写比例差距非常大,有 90% 的读操作和 10% 的写操作,此时可以考虑把 UserReadService 和 UserWriteService 分别拆分为独立的服务发布,同时增加 UserReadService 的副本数量,以保障服务的稳定性。

4.演进式拆分

微服务拆分是不可能一气呵成的,需要根据业务的发展来持续拆分和演进,称之为演进式拆分,在演进过程中一定要去积极了解业务及公司的发展方向。比如在微服务重构的初级阶段, App 首页的产品列表和搜索页的产品列表由同一个服务提供,在后续需求迭代中 App 首页的产品列表需求迭代非常频繁,如果仅仅将产品列表需求拆分成首页列表服务和搜索页列表服务是不行的,因为在后续迭代中需要首页列表服务做到个性化(即千人千面)的风格。所以,可以将产品列表服务拆分为如表 2-1 所示的服务。

最后,任何业务都可以转成微服务架构,只要做到合理的拆分。

收起
互联网服务 · 2022-08-07
浏览570

提问者

nkj827
nkj82711331
项目经理长春长信华天
擅长领域: 存储灾备服务器

问题来自

相关问题

相关资料

相关文章

问题状态

  • 发布时间:2022-08-02
  • 关注会员:2 人
  • 问题浏览:925
  • 最近回答:2022-08-07
  • X社区推广