从RPC到服务化框架( 三 ) _服务化框架

文章插图

耗时服务导致超时

我们使用netty作为服务框架的通信框架，实现的是从Reactor模型，在服务端获取到客户端请求后，会首先将其丢到一个队列中，由消费线程去异步处理请求，如果某个服务耗时比较长，则会导致队列阻塞，影响其它的服务响应。这个问题在其他的服务化框架中应该也是存在的。在新版服务框架中，我们可以将耗时服务独立到一个队列中进行执行，使该服务不会影响其他服务的正常调用。具体操作只需要在提供的界面做些配置就可以动态调整了。

文章插图

服务发布分散

在我们发布服务时，我们需要登录每个需要发布服务的机器，进行发布服务的操作。公司的运维平台提供了界面可以操作发布，不过它是个运维平台，而不是业务平台，发布完成后如何确认服务都注册成功了呢？新版服务框架中提供了管理中心，实现在一处发布所有的服务。流程如下：

管理中心通知需要发布服务的节点，将需要发布的服务信息发送给节点
节点收到信息后，从Maven仓库下载需要发布的服务，进行部署

缺少完善的服务治理

在服务发布完成后，如何确认服务都注册成功了呢？
举个例子：我们发布服务A，注册中心可以看到其下的服务接口1和服务接口2，当我们更新服务A后，注册中心只能看到服务接口1，那么请问，消失的服务接口2是注册失败？还是版本更新给删除了？这个问题目前的服务框架都没有处理。
在我们新版服务框架中，提供了基于元数据的服务监控与提醒，可以配置监控重要的服务接口，如果发布后服务接口消失，则通过监控来进行及时的提醒。
除了上面所说的问题，新版服务框架还提供了完善的服务治理，权重的动态调整，服务自动升降级，服务端管理，客户端管理等操作。
新版服务框架的架构如下：