最近公司技术架构需要改造升级，实现分布式服务中心、分布式日志系统以及统一的后台任务管理系统，当时接到这些任务，心里是犹豫的，主要有以下几点考虑（这里考虑的任务是分布式服务中心，其他两个任务还是比较好改造的）。
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之上扩展出新的功能，路由、鉴权等功能结合服务注册中心，适配新的方案，这样就能写很少的代码，花很低的成本过度了这几个问题。新功能的开发后端不要去对接网关，网关代码量的增长也就停止了，后面新接口的请求，网关直接通过服务注册中心zookeeper或者consul获取地址转发，原来的那些老接口不需要做任何改动，走原来那一套服务发现和转发策略，互不影响。这还是没有从根本上解决问题，老服务的那些代码还在网关里面，还在用原来那套服务发现机制，这个问题确实不是一两天能解决的，但是至少整个架构在往新的方案迁移，而且成本最低，对现有开发团队的工作没有丝毫影响，非常丝滑。原来gateway里面的那些对接老代码，后期哪个同事需要对老服务开发新的功能，再把这个服务之前跟网关对接的代码删掉就好，只要删掉原来对接的代码，再把这个老服务注册到服务中心就行（这里说明一下，我们所有服务都是基于DDD领域设计划分业务边界的，所以每个服务的粒度很细业务代码也不多）。还有最后一个问题，gateway里面还有很多聚合业务的代码，针对这个问题的处理方案就是在gateway后面设计出了一个聚合服务，后续开发人员碰到了，再把它平移到聚合服务，到最后这些工作迁移的差不多了，再把网关平移到ocelot或者envory等专业的网关产品上面。
第三个任务相对来说比较简单，就这样吧。