作者:孤独烟 引言近几年传统应用架构已经逐渐朝着微服务架构演进。那么随着业务的发展,微服务越来越庞大,此时服务配置的管理变得会复杂起来。为了方便服务配置文件统一管理,实时更新,配置中心应运而生。
那么配置中心可以简单理解为是封装了对这些介质进行操作的接口,供客户端拉取使用。 由于我们采用的是Spring-Boot的架构,因此当时自然而然会考虑到Spring-Cloud中提供的配置中心Spring-Cloud-Config,但是当时做完调研以后,觉得并不能直接用。 正文OK,我们当时做配置中心的选型的时候。第一选择是Spring-Cloud- Config。 Git的权限控制是个坑Git的权限管理是说控制用户能不能Push或者Delete分支,或者能不能Push代码,而不是能不能访问某个目录的文件。
于是,可能会有如下情形发生
当然,你可以禁止研发直接登陆Git改配置。然后呢,基于Git研发一套配置管理系统,在上面做权限控制,但是又有几个公司这么做呢?因为,这可能带来第二个问题。 粒度问题将配置信息放在Git中,有一个致命问题:粒度太粗了! 那么,当时我们最理想的存储介质就是数据库,将配置信息放在数据库里有两个好处
因此,我们采用数据库作为存储介质。庆幸的是,这一点在Spring-Cloud-Config中是支持的。在该组件下,只需要设置 spring.profiles.active=jdbc 就能够激活jdbc模式。
因为一个配置中心应该要能够做到,配置发生改动的时候,项目能够自动感知,自动更新配置才对。在Spring-Cloud-Config中,这套机制是借助一些代码仓库(SVN、Github等)提供的Webhook机制加上Spring-Cloud-Bus来实现的。 OK,那么问题又来了! 所以,笔者认为这套刷新机制并不是很尽如人意,需要进行修改。因此,我们很自然而然的想到了利用长轮询来改写Spring-Cloud-Config的刷新机制! 长轮询是什么既然有长轮询,那必定有短轮询,我顺便讲讲短轮询是什么!
那么,如果采取短轮询就是在客户端(js)中不断访问后台,后台接到请求马上返回最新的库存数,然后刷新到这个页面当中。 因此,自然就有了长轮询的出现! 注意了,长短轮询对于客户端来说是没有区别的,就是不断的轮询。但是对于服务端,区别就比较大了。在短轮询情况下,服务端对于每次请求不管有没有变化都会立即返回结果。而长轮询情况下,如果有变化才会立即返回结果。而如果没有变化,服务端则不会再立即给客户端返回结果,直到超时为止。 怎么实现那么,我们在项目中采用Spring的DeferredResult来实现。在Servlet3.0以后引入了异步请求之后,Spring封装了一下提供了相应的支持,也就是DeferredResult,能够极大的提升吞吐量。 缺点很明显啦 ,业务逻辑线程和servlet容器线程是同一个,一般的业务逻辑总得发生点IO,比如查询数据库,比如产生RPC调用,这个时候就会发生阻塞,而我们的servlet容器线程肯定是有限的,当servlet容器线程都被阻塞的时候我们的服务这个时候就会发生拒绝访问,从而吞吐量上不去! 在异步Servlet中,业务线程有自己的线程池进行处理,并不会占用Tomcat中的线程,从而提升了吞吐量! 那么,怎么利用DeferredResult怎么实现长轮询呢?流程如下 最后一个问题:如何有效快速的监听出配置表的数据发生了变动? 一个疑问采用长轮询技术来实现配置刷新,客户端和服务端需之间需要一直保持TCP连接进行通信。可能有些朋友会担心,到底服务端能撑多少的连接?可能觉得对性能有影响? 总结最后这套配置中心,我基于原有的Spring-Cloud-Config,改写其中的刷新机制,更加符合我们的业务场景!现已将改写思路说清,大家可以自行尝试! |
|
来自: liang1234_ > 《springCloud》