我是靠谱客的博主 迷人悟空,最近开发中收集的这篇文章主要介绍浅谈最近关于微服务思考浅谈最近关于微服务思考,觉得挺不错的,现在分享给大家,希望可以做个参考。

概述

文章目录

  • 浅谈最近关于微服务思考
    • 原因
    • 出现的现象
    • 解决方法
    • 最简单的解决方法

浅谈最近关于微服务思考

最近发现微服务之后导致的问题:服务治理。

原因

这个问题很正常的,当单机性能出现瓶颈时,有了微服务概念,当服务中出现多个重复模块时,比如这个服务有产品功能,另一个服务又有产品功能,其中有很多相似的东西,就像在不断的造轮子。所以有了阿里提出的中台概念。

出现的现象

举个简单栗子:我这个模块有个抽奖功能,另一个模块也有抽奖功能,抽出来就是抽奖模块大家一起用。
业务中台概念:我这个项目有抽奖功能,你那个项目又有抽奖功能,既有相同又有不同,相同部分是不是在重复造轮子呢?所以有了类似抽奖的业务中台,只管抽奖,具体业务逻辑项目各自负责。
可是对于小厂来说,没有多余人力去完成这个类似中台的适配作用,其实中台只是个概念。当业务不断发展之后,就会出现类似我这个业务有抽奖,你那个业务也有抽奖,再继续下去就是n个抽奖功能。但是大家就是既有一样的功能,也有各种业务特有的功能,乱成炒米线

解决方法

个人思考的适配类解决方案:1. 在原本项目基础进行适配,很多接口都得改,另外由于多个项目耦合在一起,会引发其他一系列问题,比如不同平台不同的权限。2. 抽象出来类似业务中台,只管内容相关,不管业务逻辑。但是你原本的代码都和业务逻辑紧密结合,抽象出来需要时间跟人力的。这个出现一个问题,像大佬烟说的小厂哪有那么多闲人做适配,大厂才有人手去完成这个适配(类似业务中台),还能吹吹牛皮,蹭蹭kpi。最关键还是缺人手呀!

中台也有另一个问题,比如我原本只要两个小程序就能搞定的,现在需要两个小程序
外加各种业务中台。当然了这个是业务飞速发展才去搞类似中台的概念。

最简单的解决方法

所以最简单就是复制一份,改逻辑,不断的造轮子,这也是服务治理困难的原因吧?

最后

以上就是迷人悟空为你收集整理的浅谈最近关于微服务思考浅谈最近关于微服务思考的全部内容,希望文章能够帮你解决浅谈最近关于微服务思考浅谈最近关于微服务思考所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。

本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
点赞(55)

评论列表共有 0 条评论

立即
投稿
返回
顶部