需要解决的问题
1、支持灰度发布：改bug或新功能上线时，让某一指定地区用户的请求全部打到某一个前店（已实现tengine+lua），然后将该前店的请求打到某一指定后场(注：所有后场注册到同一个zk)，目前这个还未实现。
2、支持在不停掉原有服务的情况下，起新的服务，避免不涉及修改的接口调用方服务会中断。
3、同一服务存在不同调用方，由于业务发展其中一个调用方需要调整原有的逻辑，而另一个调用方则不需要调整。具体举例说明：同一签名的接口method1(String)，存在多个调用方invoker1,invoker2，调用方invoker2需求变更，需要method1(String)调整逻辑。
解决方案一：
给接口引入版本，版本粒度控制到每个具体的方法，同一个类的不同方法直接可以配置不同的版本号，每个具体方法的版本都是独立的，相同签名的方法，通过部署的时候使用不同的版本，一方面可以达到支持灰度上线的目的，另一方面对于不同的业务调用方，可以支撑不同的使用逻辑。
问题：
1.每个类的每个方法都有自己的版本号，总共有200多个类，上万个方法，版本号的管理将面临比较大的挑战。
2.新部署服务的时候，如果原有服务不能停，新起一个jvm来部署，由于只有部分服务更改了版本号，所以有的服务在2个jvm中都存在，有的服务则在2个jvm中都存在。如果按照这种做法多换几次包，那么每个jvm中提供的服务可能都是不一样的，这样当jvm资源都用满了，要再次换包的时候，就要把一部分jvm下掉，要下掉哪个jvm，这个jvm上提供了哪些服务，这些服务是否还有客户端在调用，或者某个特定的服务，在该jvm下掉之后，还有几个jvm在提供服务，剩下的jvm负载是不是会承受不了，每个版本的服务跟jvm之间构成的多对多网状关系将会变得很复杂。
3、由于对于某个具体的方法而言，最新的代码上只保留了最后一版的逻辑，如果某个历史版本的代码发现了bug，只能找到这个版本对应的tag，将该tag代码检出，修复bug然后发布。如果bug涉及多个版本，那就要检出多个tag，修改多个tag，然后重新发布这多个tag。
解决方案二：
在方案一的基础上，对部署作出调整，开发出一个容器，能够动态加载多个不同版本的jar包，每个jar包只封装一个服务，200多个服务就打成200多个jar包。由于换版本不需要起停容器，而且可以精确地控制到每个服务的起停，不存在方案一中jvm资源耗尽时，要停掉某个jvm换包，导致的某些还在使用中的服务也不得不下掉的问题。
此外，基于容器的方案，版本可以只控制到类，即一个类就共用一个版本，如果有一个类中的方法调整了，那么就升级整个类的版本。版本号的管理相较于方案一，复杂度要降低一些。
问题：
1、由于代码中也是只保留了最后一次的调整的逻辑，所以方案一中的问题3依然存在。
2、需要研发容器，如果研发出来的容器性能和稳定性上存在问题，对项目来说风险较大。
3、虽然每个jar包中只封装了一个服务，但是其背后依赖的一整套sv，dao都是全量的，也就是说一个jar包中大部分是无效代码，有效代码只占到了1/200.每个服务中只封装跟该服务相关的sv,dao，这个也会对jar包打包机制和管理构成一个挑战。
解决方案三：
不引入dubbo多版本，接口逻辑变动了，如果对应的调用方只有一个，那么直接在原来接口上修改，如果存在多个调用方，其中一个调用方要增加新的逻辑，那么就通过新增接口的方式来支撑，也就是说统一业务的多种逻辑，全部都体现在一份代码中。如果出现了一个公共的bug，那么多种逻辑的代码都需要调整。
问题：
1、同一个业务的多种相似逻辑存在于同一份代码中，代码会变得臃肿。
2、由于不能依赖于多版本，所以在所有服务（不管新的还是旧的）都注册到同一个zk的前提下，得通过其它方式来实现灰度上线，比如基于dubbo路由扩展。这个其它方式还没有进行相关的探索，不知道最终是否可行，也存在风险。
不知道业界关于这个都是怎么处理和解决的。