java微服务之我见

  • A+
所属分类:体育平台

java微服务之我见

最近这几年,微服务已经成为了主流,个人的理解,微服务这个东西,固然是有它的优点,但是如果你用不好,就会成为灾难。想要用好微服务,就一定要注意一下三点。

一,什么样的系统适合做微服务

微服务这个东西固然好,但是并不是所有的系统都适合做微服务,现在很多人有这样一个心理,看到一款技术框架很流行,大家都在用,那我为了追求时髦,我一定也要在项目里用一下。这种心理要不得,一定要去评估这款新的框架但适不适合你的系统的,如果不适合,你就会得到适得其反的效果。作为微服务来讲,一般来说如果项目不是特别大,访问量也没有那么大,就千万不要去做微服务。只有说你的系统大到一定程度了,在一个项目里很难维护了,这时候你再去考虑去做微服务。

二,微服务要依据什么样的选择对系统做拆分

系统拆分原则,这个并没有在业界形成统一的标准,每个人都有自己的想法,在这里我只是说一下自己总结的一些看法

1.如果两个子系统之间,需要保证事务的强一致性,那你就不要去拆了,因为现在没有任何一种方案,能保证事务的强一致性的,即便是阿里的seta,也不能保证强一致性,我们只能保证它的最终一致性,尽最大努力去减小数据不一致的时间,如果允许数据可以短时间的不一致,没太大影响,就可以做拆分,如果说数据段时间的不一致,也会带来很大损失,那就不要去拆了。

2.避免任意两个系统之间,特别频繁的调用。我第一次在做微服务的时候,拆分出了一个权限系统,这个系统负责用户的登录,权限分配,权限验证和session等等,但是考虑到,一个用户登录成功的,塔操作的所有功能,都要去调用这个系统去做session验证和权限验证,这样不仅仅会影响效率,也会给这个系统带来很大压力。后来的解决方案是,我们还是拆分出了这个权限系统,只不过我们在做session验证和权限验证时,不会直接去调用这个系统,而是用maven把对应的jar包依赖过,做本地调用。

3.在保证上面两点的基础上,尽量按照单一职责的原则去拆分,做到低耦合,高内聚。

三,分布式事务如何处理

这个现在没有一种方案,能做到事务的强一致性,我们只能尽最大努力减少数据不一致的时间,来保证它的最终一致性,这个上网去查,能查到很多方案,什么两阶段提交,三阶段提交,写回滚代码,等等,但是在真实写代码的过程中,没人会这么做的,因为它不仅性能差,而且会增加很多工作量。现在比较成熟的做法是用阿里的seta框架,它的原理就是记录了一张日志表,当需要做数据回滚的时候,就根据这张日志表的数据去做回滚,但是如果回滚的时候出现了网络问题,或者出现了脏写,依然会回滚失败,这种情况就需要人工处理。这也就是我说的阿里么seata并不能百分之百的保证事务强一致性的原因。

这只是我对微服务的一些个人看法,大家有什么看法或建议,欢迎评论区留言讨论[微笑]

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: