转载

去中心化的微服务网关

在微服务架构的实现过程中可以看到，由于增加了微服务网关，又会导致在整个微服务架构中出现了中心化的节点。虽然在微服务架构的实现过程中可以看到控制流和实际的数据流分离，但是对于控制层面的实现仍然存在中心化节点的问题。

在所有的去中心化的架构实现中我们都可以看到几个重点，其一是所有节点本身既充当Client的角色，同时又充当Server的角色。其二是多个节点相互之间互为备份和冗余，即任何单个节点的故障都不会影响到整个架构的高可用性；其三则是为了保证变更信息在各个节点之间的实时同步，需要有一种高性能的消息中间件来处理消息的分发。

从以上三个重点可以来考虑下一个完全去中心化的微服务网关在实现时候的重点。

首先微服务网关需要以内置SDK包的模式在所有微服务模块中嵌入并部署，该SDK包自然需要实现Client端和Server端的两个部分功能。对于SDK包本身需要有元数据管理能力，当然在这里不需要专门的数据库进行管理，我们可以将元数据持久化到配置文件里面即可。对于元数据必备的即使服务目录清单数据和访问鉴权数据，这两部分数据相当来说本身也较轻量。

其次对于Client端可以看到需要实现的核心能力即提供服务目录库和负载均衡能力，首先是微服务在client端发起调用和消费请求的时候，通过本地的SDK包需要返回具体可用的目标服务地址和访问信息。然后client端再根据目标地址发起对微服务的调用。

最后对于Server端来讲，其中一个核心能力是服务请求和服务输出的Log能力，对于这部分日志信息仍然是存储在本地微服务模块，但是在我们配置了消息中间件后，该部分信息会以异步的方式写入到消息中间件中再进行结构化存储。由于本身是异步方式，该消息中间件已经可以实现和整体微服务架构的完全解耦。

在整个去中心化架构的实现过程中，最难的还是服务网关模块在整个架构里面的消息实时分发和同步更新。以一个新的微服务注册机制来讲。

当在微服务模块ModelA中注册了一个新的MicroService1的时候，首先在模块A内部调用注册API自然可以实时的更新模块A内置的微服务网关内的元数据。而微服务网关在该元数据有变化的时候，一个核心就是需要有类似实时消息分发的机制将该元数据分发到所有的微服务模块并完成该微服务的注册。即我们需要准实时的保证各个微服务模块中的元数据的一致性。

微服务模块相互之间需要互相监听状态，即当发现某个微服务模块出现故障的时候，代表该模块提供的所有微服务都无法使用，在这种场景下仍然需要有一种机制来保证其它可用的微服务模块能够准实时的将服务可用目录清单进行更新。

简单举例来说，一个可行的实现方式为，当模块A访问模块B中的MicroService2服务时候，如果出现无法访问，可以先进行重试，如果重试后仍然无法访问。则模块A会更新本模块中的可用服务目录清单，将该地址下模块B提供的微服务禁用，同时将该状态变更信息通过消息中间件实时的分发到所有的微服务模块。

原文 http://blog.sina.com.cn/s/blog_493a84550102wcmw.html

正文到此结束