其他分享
首页 > 其他分享> > 微服务时代组件化和服务化的抉择

微服务时代组件化和服务化的抉择

作者:互联网

随着业务系统的复杂性越来越高,系统之间的调用也越来越多,在微服务拆分和迭代过程中,是不断的拆分出新的独立的服务还是封装独立的组件以jar包依赖的方式提供服务是我们经常需要面对的问题,本文将详细探讨这两种不同的方式区别、各自的优劣势及适用的场景,希望能够对大家有所启发。

 

一、组件化&服务化定义

随着公司互联网业务发展越来越迅速,系统的复杂性越来越高,系统之间的调用也越来越多,在微服务拆分和迭代过程中,经常会遇到两种场景问题:

针对以上两种场景,我们可以总结概括为组件化和服务化两种不同的服务提供形式:

组件化定义:即把系统内部的一些公共功能模块或者对外部系统调用的一些逻辑方法封装成一个独立jar包,有需要的系统直接依赖该jar包来使用相应的服务,在此我们称之为组件化;

系统内部公共功能模块组件化示例,服务A、B、C都独立依赖的组件D来使用相关功能。

图1-系统内部公共功能模块组件化示例

外部系统服务接口调用组件化示例,服务A、B、C都通过组件D去调用外部服务E

图2-外部系统服务调用组件化示例

服务化定义:即把系统内部的一些公共功能模块或者对外部系统调用的一些逻辑方法独立拆分为一个服务,该服务再对外暴露统一的接口供所有有需要的服务去调用,在此我们称之为服务化。

系统内部公共功能模块服务化示例,对应就是把示例图1中组件D独立拆分为服务D,服务D再提供接口给服务A、B、C去调用。

图片

图3-系统内部公共功能模块服务化示例

外部系统服务接口调用服务化示例,对应的就是把示例图2中的组件D独立拆分为服务D,服务A、B、C通过调用服务D去调用外部系统服务E。

图4-外部服务调用服务化示例

那么在实际工作中,面对不同的场景和问题,我们具体该选择哪一种方式呢?是否相关的参考标准,有哪些问题是需要我们特别关注和考虑的,接下来我们会详细介绍下组件化和服务化各自的优劣势及适用的场景。

二、组件化的优劣势及适用场景

组件化这种通过jar依赖的方式去调用第三方服务到底存在哪些优势和劣势呢?

2.1 组件化存在的优势

2.2 组件化存在的劣势

2.3 组件化适用的场景

那么具体哪些场景适合使用组件化的方式来部署呢?根据我们的经验来看,符合以下场景特点的建议使用组件化的方式:

2.4 使用组件化的案例

案例一
应用商店月活用户2.4亿,日活6000万+,对商店服务器性能要求非常高,商店内部很多服务都涉及到了大量的外部系统服务调用,比如CPD、游戏、DMP等等,在用户体验和性能优先的前提下,我们都是通过组件化的方式来集成对外部系统的调用,容忍一些在维护和升级上的不便。

图片

图5-外部服务调用组件化案例

2.5 组件化使用的反面案例

案例二
再分享一个商店使用组件化方式的一个反面案例,商店内很多服务模块都涉及到一些运营资源位的管理,很多服务都需要向客户端下发一些运营位的资源素材,在最初没有充分考虑各类场景问题,最明显的就是这些资源素材的获取都涉及到数据库资源的连接和调用,在使用组件化后会导致我们开发维护成本高,迭代效率低。

图6-组件化使用反面案例

三、服务化的优劣势及适用场景

3.1 服务化存在的优势

3.2 服务化存在的劣势

3.3 服务化适用的场景

那么哪些场景适合使用服务化的方式来部署呢?符合以下场景特点的建议使用服务化的方式:

3.4服务化使用案例

案例一
系统内部公共功能模块服务化的案例,应用商店各个模块在返回信息给客户端之前经常会有一些公共的过滤逻辑,而这些公共过滤逻辑的处理还涉及到跟mysql及redis进行交互,因此把这些公共过滤逻辑直接独立拆分为一个独立的服务,目前该服务不仅对项目内提供服务,还会给公司内其他部门很多业务使用。

可能有同学会有疑问,针对用户量大,对服务并发量和性能要求较高的服务,多拆分一个服务出来解决了数据资源隔离的问题,但是如何解决服务调用链路变长导致性能下降的问题,比如上文提到的那个运营资源组件化的反面案例(示例图6),针对这种我们可以通过在调用方增加缓存的方式来解决性能问题,因为这个业务场景对数据的实时性要求并不高。

图7-系统内部公共模块服务化案例

可能有同学会有疑问,针对用户量大,对服务并发量和性能要求较高的服务,多拆分一个服务出来解决了数据资源隔离的问题,但是如何解决服务调用链路变长导致性能下降的问题,比如上文提到的那个运营资源组件化的反面案例(示例图6),针对这种我们可以通过在调用方增加缓存的方式来解决性能问题,因为这个业务场景对数据的实时性要求并不高。

案例二
外部系统服务调用服务化案例,我们有一个开放平台系统,该系统主要是服务于开发者,对系统的性能要求不高,其中有一个需求涉及到外部系统服务调用,且开放平台系统内有多个工程都需要调用该外部系统服务,为了便于后续的服务维护和升级,就把对外部系统服务的调用逻辑统一封装到了一个专门用于外部系统调用的内部服务里,然后通过该内部服务来调用外部系统。

图8-外部系统调用服务化案例

四、总结

总结下组件化和服务化各自优劣:

 

_

组件化

服务化

开发效率

调用性能

可维护性

维护成本

机器成本

服务整体

稳定性

适用场景

不涉及数据库资源、服务并发量大对性能要求高

涉及数据库资源、服务并发量小对性能要求低

综上所述,组件化跟服务化两种方式没有绝对的好坏,各有优劣,具体该使用哪一种方式跟我们的真实的问题场景有关系,大家可以参考以上的分析,结合自己的实际项目情况去选择符合自己的方式,技术最终是要服务于业务,大多数情况下没有最完美的解决方案,只有最适合的解决方案。

作者: vivo 互联网服务器团队-Yao Wenyu

软化血管最好方法

更年期怎么办

中年人吃什么食物健康

标签:调用,服务,服务化,系统,抉择,场景,组件
来源: https://www.cnblogs.com/plus666/p/14752381.html