文章目录
浅谈最近关于微服务思考
最近发现微服务之后导致的问题：服务治理。
原因
这个问题很正常的，当单机性能出现瓶颈时，有了微服务概念，当服务中出现多个重复模块时，比如这个服务有产品功能，另一个服务又有产品功能，其中有很多相似的东西，就像在不断的造轮子。所以有了阿里提出的中台概念。
出现的现象
举个简单栗子：我这个模块有个抽奖功能，另一个模块也有抽奖功能，抽出来就是抽奖模块大家一起用。
业务中台概念：我这个项目有抽奖功能，你那个项目又有抽奖功能，既有相同又有不同，相同部分是不是在重复造轮子呢？所以有了类似抽奖的业务中台，只管抽奖，具体业务逻辑项目各自负责。
可是对于小厂来说，没有多余人力去完成这个类似中台的适配作用，其实中台只是个概念。当业务不断发展之后，就会出现类似我这个业务有抽奖，你那个业务也有抽奖，再继续下去就是n个抽奖功能。但是大家就是既有一样的功能，也有各种业务特有的功能，乱成炒米线
解决方法
个人思考的适配类解决方案：1. 在原本项目基础进行适配，很多接口都得改，另外由于多个项目耦合在一起，会引发其他一系列问题，比如不同平台不同的权限。2. 抽象出来类似业务中台，只管内容相关，不管业务逻辑。但是你原本的代码都和业务逻辑紧密结合，抽象出来需要时间跟人力的。这个出现一个问题，像大佬烟说的小厂哪有那么多闲人做适配，大厂才有人手去完成这个适配（类似业务中台），还能吹吹牛皮，蹭蹭kpi。最关键还是缺人手呀！
中台也有另一个问题，比如我原本只要两个小程序就能搞定的，现在需要两个小程序
外加各种业务中台。当然了这个是业务飞速发展才去搞类似中台的概念。
最简单的解决方法
所以最简单就是复制一份，改逻辑，不断的造轮子，这也是服务治理困难的原因吧?
