搜索 | 会员  
微服务拆分的原则、方法和误区
来源: twt社区   作者:CIO之家的朋友  日期:2020/5/6  类别:架构设计  主题:综合  编辑:Dolores
在设计微服务系统的时候,如何拆分微服务是每个微服务系统设计的时候都需要面临的问题。微服务拆分是否合理,不仅影响到应用系统的效率,有时还会影响系统的成败。以下内容整理自社区相关问答,

1、微服务的拆分原则问题?

【问题描述】按一般原则来讲,微服务的拆分是应该从横向角度进行拆分。但是在一些业务流程中,如果想从纵向角度进行拆分,如何能够更好的实现合理拆分,并且不影响系统的响应时间等性能指标?

@尘世随缘 上海某互联网金融公司  技术总监:

如何拆分微服务,这个目前没有一个原则或者标准可以参考,但是大致可以看到:

1、单一职责、高内聚低耦合:简单来说一张表划分为一个服务

2、服务粒度适中:服务不要太细(有的团队甚至一个接口一个服务)

3、 以业务模型切入:比如产品,用户,订单为一个模型来切入

4.、演进式拆分:刚开始不要划分太细,可以随着迭代过程来逐步优化

5.、避免环形依赖与双向依赖:尽量不要做服务之间的循环依赖

@gavin_zhang 某股份制银行 系统架构师:

一楼的回答应该已经很全面了,我来补充几点实践的:

1、服务分层,将系统的功能进行分层,服务归属于前后中台,层间单向调用,有效控制调用深度

2、数据耦合,对于需要跨机事务的拆分,要重点分析,是否可以通过服务功能的调整避免(如将两段式提交变成数据副本的最终一致性),如果确实不行,对拆分的必要性进行确认。

@狄俄尼索斯 UProject 软件架构设计师:

接着2楼的再补充一点:按照功能重要程度拆分。


2、微服务拆分如何平衡拆分粒度?

【问题描述】目前很多传统的单体应用再向微服务架构进行升级改造,如果拆分粒度太细会增加运维复杂度,粒度过大又起不到效果,改造过程中如何平衡拆分粒度?

@尘世随缘 上海某互联网金融公司 技术总监:

1、高内聚低耦合,服务粒度适中

2、以业务模型切入

3、演进式拆分

4、阶段性合并

总的原则: 拆分的大原则是当一块业务不依赖或极少依赖其它服务,有独立的业务语义,为超过 2 个的其他服务或客户端提供数据,那么它就应该被拆分成一个独立的服务模块。

@我爱大锅饭 银行 系统运维工程师:

关于这个问题,引用 Spring Cloud Alibaba成员姬望(彭文杰)的一篇采访内容,核心的观点及段落内容如下:

微服务解决的本质问题是团队分工:

SOA 也好、微服务也好,解决的根本问题是团队分工问题,详见康威定律,这是大型软件发展的必然,不因为人的喜好而改变。当你读懂康威定律,就会发现“服务拆分粒度难以准确把握”根本不是本质问题。你有几个 2 pizza 团队,最好就拆成几个微服务。举一个现实的例子:只有一个开发人员时,尽量就做单体应用,不要没事找刺激拆成 10 个微服务,最终这个开发人员还会把他合成一个。微服务要求纵向的 2 pizza 团队(无数个小团队,包含开发、测试、运维),当然我们也实施过一些传统大型企业,但团队还是处在横向结构的场景下(开发、运维、测试各是一个团队),拆分微服务让他们很痛苦,尤其是运维团队。

这里面的概念可以网上查下,我个人觉得说的还是非常有道理的。我辖内的系统就经历了单体应用向微服务拆分的过程,拆分的背景是行内一个秒杀内的业务需要调用辖内系统应用,传统的架构性能不满足要求,故进行容器化改造,对此业务场景涉及的业务进行微服务拆分。乍看下来是业务驱动,但实际上这个系统的开发团队也因此做了拆分,安排专人服务微服务模块的开发、测试,运维方面暂未拆分。但是如果拆分的范围进一步扩大,运维团队拆分也是必然。


3、服务之间的数据一致性对服务拆分有什么影响?

@Steven99 软件架构设计师:

数据一致性通常基于业务相关,需要考虑强一致性,弱一致性。弱一致性通常可以拆分为不同的服务,强一致性可以定义为一个微服务,但也要看业务的复杂性等因素

@gavin_zhang 某股份制银行 系统架构师:

数据一致性是服务拆分的时候的一个重要依据,对于强一致的数据,属于强耦合,理论上应该是放在一个服务中,但是有时会因为各种原因需要进行拆分,那就需要有响应的机制进行保证。另外,微服务设计时,可以尽量使用命令模式之类的设计模式,尽量减少需要强一致的数据范围。可以为后续的开发节省很多精力。


4、单体应用该如何按领域模型进行微服务化拆分?

@尘世随缘 上海某互联网金融公司 技术总监:

很多团队面临这样的问题,服务到底如何拆分,怎么样的拆分是合理的,拆分后新的微服务框架和老的系统如何做兼容运行,老系统如何逐步平滑过渡到微服务架构中,而且不影响线上业务运行,也不能影响正常的项目迭代。其实,业界没有标准的方式来指导如何做拆分,我们主要围绕“拆“ 与 ”合“来做服务的拆分,所谓拆就是按业务功能拆分,所谓”合“,就是拆分后的模块经过多次迭代后可以做合并处理。比如按用户维度,按订单维度,按产品维度等,比如订单维度拆分后订单服务变更还是非常多,改动非常大,那么订单继续拆分。


5、拆分微服务有没有方法论?

@Steven99 软件架构设计师:

我们觉得微服务定义和拆分都要基于业务来考虑,因为微服务最终是为了实现业务需求,所以不同的业务需求,微服务定义和拆分可能会不一样,可以看主数据管理,DDD 的书籍,具体的微服务拆分最好能通过咨询项目来做,可以少走弯路。

@gavin_zhang 某股份制银行 系统架构师:

拆分的方法论还是有的,比如 DDD , EventStorming 等。方法是死的,人是活的,再好的方法也需要人来执行,这块对整个业务流程要求非常的熟悉,最好是架构师和业务人员一起做这块的划分。

对于不是太复杂的系统,可以参考以下方法:

可以将系统的业务对象(这里的业务对象是业务人员的视角,不是开发人员的)进行归纳,记录每个业务对象之间的交互,对每个交互进行标注,那些是强一致的,那些是最终一致的。切分是,尽量找交互少的,支持最终一致性的关联进行切分。得到一个比较顶层的服务划分,再根据服务对象之间的数据共享进行梳理,提取公用的数据服务。


6、微服务拆分有哪些误区?

@gavin_zhang 某股份制银行 系统架构师:

第一个最常见的误区是划分服务的时候,按照业务流程的步骤进行划分,这是开发人员传统的面向过程的思维定势造成的。也可能是传统的SOA过度而来的一种划分方式。这种划分微服务的最大缺点在于,服务与服务之间存在很强耦合性,服务的优雅降级无从做起,而且还存在大量的跨机事务需要解决。

另外一个问题就是基础功能或是公共代码的问题,开始采用微服务架构时,很多项目喜欢将基础功能独立成为一个服务,这些基础功能不是业务功能,而是一部分公用的非独立的功能。在项目的初期,这种设计确实是提高了代码的复用,但是随着系统需求的变化,这些基础服务会被频繁修改,导致变得复杂难以维护。这种为了实现代码共享的基础服务,破坏了服务自治的约束,提高了部署和运维的难度,降低了系统的可用性。


德仔网尊重行业规范,每篇文章都注明有明确的作者和来源;德仔网的原创文章,请转载时务必注明文章作者和来源:德仔网;
头条那些事
大家在关注
我们的推荐
也许感兴趣的
干货
了解一下吧