个人随笔
目录
架构设计感想20240819:微服务的好处和不足
2024-08-19 22:25:04

现在微服务很火,但是也有不足之处

一、好处

1、易于扩展

每个服务都是独立的模块,若某个服务处理能力不足,可以直接增加该服务的节点即可。

2、发布简单

只需要发布本模块涉及的功能,不需要跟单体架构一样,全量发布

3、技术异构

有些服务可能用java开发,有些适合用python,有些可能适合用go,不需要跟单体架构一样,绑定死一种开发语言。

4、便于重构

微服务单个模块的重构,不会影响其他模块的运行,可以比较方便快捷的进行重构。

5、提高业务需求迭代效率

改为微服务后,因为服务之间的功能影响较小,有新的需求人手不足只需要加人即可,快速上手,迭代新功能,但是之前单体架构的时候,新加人反而降低开发效率,毕竟还要花费很多时间去熟悉之前的架构代码。

二、不足

1、微服务职责划分

具体哪个功能拆分到哪个服务中,是让人头痛的事情,只能根据具体的业务需求和组织架构进行分析,没有完美的解决方案。

2、微服务粒度拆分

粒度的拆分也是让人头痛的问题,如果微服务拆分太细,不仅仅会导致服务之间的依赖调用变多,也会面临更多分布式事务的问题,粒度太细也会导致服务器资源耗费更多,所以这个也得是具体问题具体分析,如果人手不足,那么就不要拆分那么细,不然一个人维护几个微服务,效率反而变得低下。

3、没有人知道系统整体架构的全貌

之前单体架构的时候,几乎人人都知道所有功能的业务逻辑,有故障BUG,随便安排某个人都可以排查,但是改为微服务后,特别是几十个微服务,那么也就没有人能完全知晓系统的整体架构全貌了,进行设计的时候也避免不了相同的功能重复开发,毕竟设计人员只知道自己的一某三分地,为了追求进度快速实现需求。

4、重复代码多

毕竟每个服务模块可能都是由不同的开发人员设计的,没有人懂全貌,很多已有的功能或者算法设计人员并不知晓,最后会导致每个服务重复一份,就算有别的服务有了相关功能,另一个服务想用,也会面临相关依赖版本冲突等问题,所以最后没办法,还不如拷贝过来改改就好了。

5、耗费更多的服务器资源

这个肯定的啦,之前单体架构,后台可能只需要启动两个节点,用负载均衡即可支撑,现在假设拆分成三个微服务,为了保证高可用,最少都要6个节点才行。

6、分布式事务

很明显,因为每个服务有自己的数据库,就比如下单操作可能都要调用库存服务,订单服务,交易服务等等,如果有一个服务报错,另一个服务要不要回滚,回滚失败怎么办,这种情况,我们要根据业务场景来解决,大概有如下两种解决方案。

解决方案1、最终一致性,用MQ

用消息队列解决,可以保证事务一定执行成功,如果失败就用消息队列的重试,直到成功为止。

解决方案2、实时一致性,用TCC或者Seata的AT

这种方案增加了代码的复杂性和降低了效率,但是也没有办法的事情。
不管采取那种方案,反正都挺麻烦的。

7、服务之间的依赖

就跟类之间的依赖一样,你现在拆分为多个微服务了,一个功能的实现就可能依赖于多个服务,服务又依赖于更多的服务,无穷无尽,脑袋变成浆糊。所以我们可能需要新增API层,用统一的API层来处理业务逻辑。该API层不需要链接数据库,只负责如下几个功能。

  • 1、聚合:一个接口需要聚合多个后台服务返回的数据,并将数据返回给客户端
  • 2、分布式调用:一个接口可能需要依次调用多个后台服务,才能实现多个后台服务的数据修改
  • 3、装饰:一个接口需要重新装饰后台返回的数据
  • 4、多点适配:我们对不同类型的客户端提供不同的API接口。APP API;WEB API;H5 API;小程序API。

8、联调的痛苦

微服务联调起来就比较痛苦,明明一个业务功能,如果是单体架构,一个人就搞定了,但是拆分成微服务后,业务功能涉及的功能可能在另一个项目组负负责,开发完后需要等另一个项目组发布到联调环境,有可能另一个项目组没有时间,不鸟你,或者API接口定错了,或者接口字段不够什么的,千难万难。

9、部署的复杂性

微服务部署起来也很复杂,有可能一个项目涉及十多个微服务,然后每个微服务都部署在容器里面,如果想要在本地部署个全环境,基本不可能,电脑资源也不够,不向之前的单体项目,本地启动就好了。

10、数据的依赖

微服务恶心的一点是数据的依赖,我们查询订单,需要关联商品,可能我们先调用订单服务获取了这批订单的商品ID,然后商品服务提供接口用 in查询回商品信息,然后再组装数据返回。但是也有很多场景,数据量大,对于数据库来说in的数据量大概上限是1000条,超过1000条还要拆分来in,贼麻烦,次数我们不得不考虑数据的冗余方案。

解决方案1、数据冗余

我们可以在订单表直接把商品信维护上去,或者其他表维护,这样就不用去调用商品服务了,但是此时在商品服务维护商品的时候又要调用订单服务的服务进行商品更新,也是麻烦麻烦,又涉及了各种分布式事务的问题。这种方案觉得不是太好。

解决方案2、数据同步

我们可以用数据同步的方法,比如商品服务的商品表有修改,直接将整个表数据增量同步到订单服务数据库中,订单服务就直接查商品表了,当然订单服务对这些表业只有查询功能,对于表在不同的库同步,我们可以借助很多开源的产品即可,不过必须满足如下要求
开源中间件需要满足

  • 1、支持实时同步
  • 2、支持增量同步
  • 3、不用写业务逻辑
  • 4、支持MySQL之间的同步
  • 5、活跃度高

    三、总结

    微服务当然有好处也有痛苦的地方,具体用不用,用的层度,要具体业务具体分析,还要根据开发团队的规模,服务的投入资源大小来综合分析。本人建议,小公司就不要搞这些啦,lvs+nginx+tomcat+redis+mysql几乎打遍天下无敌手。
 20

啊!这个可能是世界上最丑的留言输入框功能~


当然,也是最丑的留言列表

有疑问发邮件到 : suibibk@qq.com 侵权立删
Copyright : 个人随笔   备案号 : 粤ICP备18099399号-2