微服务和API网关-实现(11.30)

这篇思考下对于微服务或API网关，对我们当前的自研ESB服务总线的调整思路。

首先对于微服务网关时候，我们注册接入和管理的核心将变化为Http Rest接口服务，而原来我们的ESB总线更多的是管理SOAP WS服务为主。这是最大的一个变化点。其次就是原来更多的是基于服务规范和契约先行的思路进行服务封装和接入，而在微服务网关下，则不用太关注该问题。

服务的注册和接入

服务注册接入本身分为两个层面，一个是已有服务的注册接入，一个是需要适配后的服务发布。在设计的时候需要考虑到两个方面的需求。

对于已有服务的存代理接入最简单，即只需要提供业务系统的Rest接口服务地址即可，在接入的时候，对相关的日志，安全，流控，负载均衡等策略进行配置，配置完成后即完成服务接入和注册。同时对于路由服务接入需要单独考虑，对于路由服务在接入的时候可以适配到多个原始业务系统的接口服务地址。

服务发布是对原来我们服务适配功能的一个改进，即直接从底向上的进行服务发布，而不需要实现定义服务元数据或模型，制定服务契约格式等，在服务发布完成后再生成相关的基础数据到服务元数据库即可。对于服务发布参考服务适配的能力，我们可以考虑如下场景下的需求。

1. 将一个已有的SOAP WS服务发布和注册为一个Http Rest接口服务。

2. 将一个数据库表，或存储过程发布为一个Http Rest接口服务。

3. 将一个JMS消息接口发布为一个Http Rest接口服务。

4. 将一个JAR包中的API接口方法或函数发布为一个Http Rest接口服务。

对于服务发布而言，如果不仅仅是微服务网关能力，而是一个微服务支撑或微服务快速开发平台的话，还可以提供完整的服务开发和设计能力。即在微服务平台首先定义数据或对象模型，然后将对象模型转换为Http Rest中的资源对象，并发布对应的Get , Post各种Http Rest接口服务。

对应发布的接口服务可以直接在微服务平台上进行拦截，模拟生成相关的输入或输出数据。当然也可以直接将数据模型对象生成到对应的数据库，同时将微服务API接口的实现生成对应的Java代码框架并给出参考实现。而我们剩余的工作，仅仅是填充代码逻辑即可。通过这种方式可以极大的提高我们进行微服务架构开发的速度。

当然也可以考虑到微服务网关如何直接和已有的类似SpringCLoud等微服务架构进行对接，直接将各类配置好的API接口进行注册和读入。即实现SpringCLoud框架中Zuul的功能和能力，实现微服务框架中接口的自动发现和注册，而不需要人为再去处理和干预。类似网上提到的一些实践做法，可以直接将SpringBoot的配置信息直接读入到微服务支撑平台中，而不需要开发人员做任何的修改。

当然你也可以保留Zuul的能力，而只是Zuul网关暴露的Http Rest接口再一次注册和接入到你自己的API网关中，实现这些API接口的统一管理和监控。

服务的安全，日志，路由等各种配置

注意，在服务注册和接入的时候，可以对服务的安全，日志，路由，流控等各种信息进行配置。同时在服务接入并发布后，我们在后期还可以通过单独的配置功能对这些配置信息进行动态的修改。

对于安全，一个是对 OAuth 2.0 Authentication 的支持，一个是对Token令牌安全的支持，还有就是对IP访问控制和授权，这些都是最基本的安全控制策略。在一个微服务架构的实施过程中，实际上我们可以约定一种标准的安全控制方式，比如对于Token的生成和校验规则约定等。

对于日志，一个方面是可以配置是否记录日志，日志记录到什么程度。另外就是还可以继续优化当前的日志记录方式，即可以配置具体记录日志的时间段，也可以配置针对那些IP请求或消费端系统记录日志，哪些不记录日志，那么这样日志记录和审计功能就更加强大。

对于IP，除了最基本的IP访问授权配置外，还需要提供IP白名单，黑名单配置，在我们当前的ESB设计实现中，发现黑白名单的设计很有用，因为有些特殊情况往往并不能简单的启用IP控制。同时有了IP黑白名单配置功能后，还可以通过该功能快速的对某个消费系统进行服务访问控制和限流。

支持什么样的流控策略

实际上对于微服务网关，设计合理的流量控制策略，处理好限流和断流熔断的关系是最难的。

大并发异常访问是经常需要进行控制的一个点，如何控制，实际上你没有办法控制调用并发量，只能够是控制分配给该服务的最大线程数，而不是让该服务调用占有完所有的可用线程池资源。在某个服务的线程池大小受到控制后，那么服务就会在外进行排队，由并行改为串行，这种方式减小了服务网关的压力，同时造成的影响就是消费端的系统接口调用可能会出现长时间等待并超时。

如果一个服务有多个消费方在消费和调用，那么这种线程池大小的控制还需要细分到每个消费方，否则就直接导致A系统的大并发调用影响到B系统对同一个接口服务的消费。

异常熔断是另外一个场景场景，即对于一个服务调用出现大量的异常的时候进行熔断，这种异常一方面可能是消费端调用输入有关，也可能是提供端本身服务出现异常或问题导致。在这种情况下我们可以考虑单位时间内如果异常错误大于某个阈值就出发熔断机制。

接口服务调用异常，最怕的是由于异常导致的服务调用超时，而这个超时时间本身设置的又比较大，比如10分钟，那么就会导致这个连接一直会被占用10分钟，因此这个服务如果是大并发在调用可想而知，会很快的消耗完所有的可用连接和线程池资源，而影响到整个微服务网关的运行，因此这种情况必须处理。

在我们ESB服务总线的实现中，我们最近增加了一个大数据报文限流，这个功能本身也很有用，即当我们发现输入的报文或输出的报文大于我们设定的某一个阈值后，就直接断开连接并抛出异常。通过这种限流设计，可以防止微服务网关的JVM内存被快速的耗尽而导致的内存溢出，整个Server宕机的问题。

日志监控和报文记录

对于日志监控和报文记录，是微服务网关和治理平台的一个关键能力。在注册和接入的基本都是Http Rest API接口后，我们发现日志的查询不能是简单的实例号ID，而必须支撑关键字查询能力，能够实现对输入和输出报文的全文检索能力。

在这里可以看到，对于微服务网关平台，启用Solr全文检索是必须的，同时要启用类似Redis，MongDB或Hdfs等Key-Value数据库或分布式文件存储系统对报文数据进行存储和记录。一个方面是方便对存储库进行动态弹性扩展，一个方面是方面后期全文检索的实现。

当然，对于是否能够完全使用Solr，既实现持久化存储，又实现全文检索，还需要进一步分析。

其它一些辅助功能的实现

Http API接口的在线测试功能是必须的，提供这些API接口的在线测试能力。类似当前的Open API平台，基本都提供这种API接口服务的在线测试功能。

帮助文档的自动生成，参考输入样例的自动生成，任何一个API接口服务接入后，都需要提供帮助文档的生成能力，也方面消费方在使用和消费该接口服务的使用和查看。当然对于生成的为帮助文档，还可以进行手工的修改，包括接口服务的使用场景说，字段的详细描述说明，使用建议等。

如果考虑更好的实现业务系统的自服务，那么最好还提供具体的服务调用和消费代码示例片段，以方便业务系统的开发和实现，这也是当前主流OpenAPI平台的做法。