其他分享
首页 > 其他分享> > 聊下系统改造

聊下系统改造

作者:互联网

最近公司技术架构需要改造升级,实现分布式服务中心、分布式日志系统以及统一的后台任务管理系统,当时接到这些任务,心里是犹豫的,主要有以下几点考虑(这里考虑的任务是分布式服务中心,其他两个任务还是比较好改造的)。   1. 人力不够,后端本来人手就几个,一个萝卜一个坑,不可能全部调动来做这个事,毕竟公司需要拓展新的业务赚钱。 2. 工作量太大,目前公司至少有50+的服务在线上跑,每个服务都跟网关发生了关系,而且原来就有一套服务发现机制,更麻烦的是还有同事在网关里面直接聚合业务逻辑,没有完全抽象出来网关层,这就意味着,这个活不好做,周期太长,费力不讨好,很简单因为老架构在跑,有对比。 3.成本太高,这么多工作需要迁移,不可能短时间内就能一步到位,期间肯定会出现新老架构的协作问题,原本就比较复杂的架构势必会变的更复杂,到那时候我就吃不了兜着走了。困难再大,工作还是要做,下面简单聊下我这边的改造方案,不涉及技术。   第一个任务,目前公司有很多后台任务,没有统一的方案,开发人员各写各的,各自发布,技术方案也是满天飞,有hangfire、有quartz,有while循环等等。最严重的问题就是出了问题连服务都找不到在哪里。统一后台任务管理,需要把这些服务全部统一管理起来,我这边的方案就是参考jenkins,基于net6mvc,alc机制实现一个最基本的web插件系统,支持热插拔并且提供dashboard对插件进行管理,插件与框架之间基于约定的方式实现,最终的效果就是,服务还是各自开发,但是需要遵循框架的约定,提供插件信息描述文件,配置路由和view试图以及日志log,开发完通过dashboard上传到框架,进行简单任务配置,最后启用任务。   第二个任务,目前碰到的几个问题,1. 外部请求被转发到gateway网关,网关需要写一份对应的转发代码,包括请求参数和返回参数还有对应的方法(这个工作很费时间,参数需要对齐,效率很低),2. 网关代码量越来越庞大,性能也会越来越差,后期维护越来越难,3. 网关里面直接编码聚合了业务,4. 还有服务发现的问题等等。基于以上问题,我这边最开始的想法就是拿掉这个伪gateway,直接上ocelot或者envory,后面果断放弃了,原因前面写了,工作量太大,两套架构并行,无疑是加大工作量和复杂度,而且周期太长。干不掉它那就妥协,我这边最终的方案就是还用原来的gateway,兼容原来的工作,再在此gateway之上扩展出新的功能,路由、鉴权等功能结合服务注册中心,适配新的方案,这样就能写很少的代码,花很低的成本解决1、2、4这几个问题。新功能的开发后端不要去对接网关,网关代码量的增长也就停止了,后面新接口的请求,网关直接通过服务注册中心zookeeper或者consul获取地址转发,原来的那些老接口不需要做任何改动,走原来那一套服务发现和转发策略,互不影响。这还是没有从根本上解决问题,老服务的那些代码还在网关里面,还在用原来那套服务发现机制,这个问题确实不是一两天能解决的,我的方案是,如果哪个同事需要对老服务开发新的功能,这就好办了,把这个服务之前跟网关对接的代码删掉就好(这里说明一下,我们所有服务都是基于DDD领域设计划分业务边界的,所以每个服务的业务代码本来就不多)。还有最后一个问题,gateway里面还有很多聚合业务的代码,针对这个问题的处理方案就是在gateway后面设计出了一个聚合服务,后续开发人员碰到了,再把它平移到聚合服务,到最后这些工作迁移的差不多了,再把网关平移到ocelot或者envory等专业的网关产品上面。   第三个任务相对来说比较简单,就这样吧。  

标签:方案,网关,服务,改造,代码,系统,插件,聊下,gateway
来源: https://www.cnblogs.com/adair-blog/p/16290880.html