基于CSE/ServiceComb的微服务工程实践-多微服务框架演进

开发团队选择同样的开发框架能够更好的进行经验积累和知识共享，从而提高开发效率。在实际项目中，这个过程经常被打破。团队需要根据用户需求的变化，选择更好的开发框架来解决面对的新问题。每个开发团队都不得不采取“持续迭代演进”的方法，来改造旧系统，开发新系统。

在[单体应用微服务改造实践]( https://bbs.huaweicloud.com/blogs/17ad483f325f11e9bd5a7ca23e93a891)中，分享了一种单体应用“持续迭代”改造微服务的方法。本文结合在改造过程中多微服务框架并存问题，描述一下使用CSE的开发实践。

本文假设应用已经采用网关搭建可持续演进的架构，如下图。这个架构由多种开发框架构建的基于REST的微服务组成。

本文提供的示例项目代码托管在[github](https://github.com/huaweicse/cse-java-chassis-samples/tree/master/multi-framework) 。

1      网关转发规则开发

CSE提供的edge service默认提供的转发规则对于采用CSE开发的微服务最简单，功能也最强大。根据配置的URL规则，将请求转发到对应的微服务，只是网关核心功能之一。当edge service将请求转发到CSE的微服务的时候，还具备如下功能：

·实例发现和动态更新。网关可以通过微服务名称从服务中心发现实例列表，并在实例列表变化的时候，自动更新。

·实例隔离和重试。当微服务存在多个实例的时候，如果一个实例出现故障，那么可以进行一次重试，将请求转发到其他实例；如果一个实例多次出现故障，需要在后续请求中将该实例隔离一段时间，避免频繁失败。

·支持灰度发布。网关可以结合请求参数规则，或者版本规则，将请求转发到符合规则的实例上面去。比如将请求参数count>20的请求转发给v2版本的实例，count<=20的请求转发给v1版本的实例。

·支持AZ亲和。网关需要结合微服务部署的数据中心信息，将请求转发给就近的数据中心，以提高效率。

·支持流量控制。可以针对微服务、微服务的某个接口进行流量控制。

·自动按照接口兼容性转发。这个场景指的是如果微服务存在多个版本，比如v1存在接口/a/b/c，v2新增了接口/x/y/z，那么当用户请求/x/y/z的时候，能够自动将请求转发给v2，而不需要做任何配置。

·支持故障注入。故障注入用于模拟故障，这个在开发测试阶段比较有用。通过模拟延时等情况，能够测试网关在异常情况下是否正常工作。

上面列的功能是edge service的部分功能，这些功能都是开箱即用，无需用户开发的。此外，CSE提供handler的机制，还实现了其他大量的开箱即用功能，在上述列表中没有给出。下面的例子实现了一个edge service转发给CSE服务的Dispatcher，CSE也默认提供了几个Dispatcher，本例子参考了默认的Dispatcher代码，定制了转发的URL。

 

<span style="color:#000000">public class DefaultCseDispatcher extends AbstractEdgeDispatcher {
  @Override
  public void init(Router router) {
    // Dispatcher patterns. This dispatcher only forward requests to store.
    router.routeWithRegex("/store/(.*)").handler(CookieHandler.create()