Open d891320478 opened 1 year ago
具体情况是这样的，目前后端由c++、golang、java组成，最开始只有c++，c++那边自研了一套rpc的框架，后来java和go也接入到这套框架上，接下来又自研了网关服务，入口网关用的nginx，这样整体结构如下： nginx->自研网关->微服务 同时静态资源由nginx转发。
目前想要通过opensergo实现灰度发布，同时支持前端静态资源灰度和后端服务灰度，结合目前的情况想了以下几种方案，但是都存在一定问题： 1、将现有的nginx拆分成灰度和正式，在nginx之上再加一层网关，并且新加的网关原生支持opensergo，将流量分发到灰度或者正式的nginx，然后通过nginx打灰度标记，通过自研网关转发到灰度或者正式的微服务上。 考虑这种方案的原因是，原本已经做过一套灰度发布方案，注册中心支持区分灰度节点和正式节点，但是现有方案对于灰度规则的配置方式过于不合理，需要写配置文件，操作复杂，支持的规则只有一种，而且由于某些原因存在一定的业务侵入。 目前由于未找到nginx直接接入opensergo的相关文档，使用其它网关如springcloud等需要额外的调研和接入成本，但是看起来开发量更小。
2、基于方案1，在自研网关和rpc层面完全改造，支持opensergo的协议，并给nginx提供脚本，通过opensergo的配置规则识别流量。 这样的好处是规则相对配置更灵活且能够实时生效，缺点是改造量太大。
3、不考虑opensergo，重做一套用于配置和验证灰度规则的功能，再由nginx、网关做接入。 这样做的好处是成本可控，而且对于大多数采用docker compose部署的项目，方便接入，不像opensergo目前强依赖k8s，缺点是轮子越造越多，维护更困难。
目前思考出了这三种方案，想讨论一下哪种方式更合理，或者还有没有其它方式
具体情况是这样的，目前后端由c++、golang、java组成，最开始只有c++，c++那边自研了一套rpc的框架，后来java和go也接入到这套框架上，接下来又自研了网关服务，入口网关用的nginx，这样整体结构如下： nginx->自研网关->微服务 同时静态资源由nginx转发。
目前想要通过opensergo实现灰度发布，同时支持前端静态资源灰度和后端服务灰度，结合目前的情况想了以下几种方案，但是都存在一定问题： 1、将现有的nginx拆分成灰度和正式，在nginx之上再加一层网关，并且新加的网关原生支持opensergo，将流量分发到灰度或者正式的nginx，然后通过nginx打灰度标记，通过自研网关转发到灰度或者正式的微服务上。 考虑这种方案的原因是，原本已经做过一套灰度发布方案，注册中心支持区分灰度节点和正式节点，但是现有方案对于灰度规则的配置方式过于不合理，需要写配置文件，操作复杂，支持的规则只有一种，而且由于某些原因存在一定的业务侵入。 目前由于未找到nginx直接接入opensergo的相关文档，使用其它网关如springcloud等需要额外的调研和接入成本，但是看起来开发量更小。
2、基于方案1，在自研网关和rpc层面完全改造，支持opensergo的协议，并给nginx提供脚本，通过opensergo的配置规则识别流量。 这样的好处是规则相对配置更灵活且能够实时生效，缺点是改造量太大。
3、不考虑opensergo，重做一套用于配置和验证灰度规则的功能，再由nginx、网关做接入。 这样做的好处是成本可控，而且对于大多数采用docker compose部署的项目，方便接入，不像opensergo目前强依赖k8s，缺点是轮子越造越多，维护更困难。
目前思考出了这三种方案，想讨论一下哪种方式更合理，或者还有没有其它方式