3. Architecture

转至元数据结尾
转至元数据起始

* Architecture

总体架构描述:

    Venus Service Framework提供服务器端开发SDK以及客户端SDK。它们之间采用Venus自定义的私有协议。encoder、decoder采用多种序列化方式,客户端根据自己的语言选择一种序列化方式。

目前提供3种序列化方式:0:表示JSON, 1:表示BSON , 3:表示JAVA对象序列化(仅限于java语言)。

    Venus为让开发人员只专注服务开发而努力,开发人员在设计接口的时候只需要按照java的接口设计原则进行设计,把接口、接口中使用的参数对象类、接口异常类封装成API包即可对外提供。

而Venus则承担协调沟通客户端服务器端的通讯框架。

* Architecture-Client(动态代理)

描述信息:

    下图是描述venus的java语言客户端的实现,采用动态代理技术,让远程调用变成透明的本地服务接口调用。开发人员无需关心与远程服务器端如何通讯,仅仅通过配置即可完成服务调用

* Architecture-NIO

描述信息:    

Venus通讯框架采用了NIO技术,服务端可支撑100,000以上的并发连接数,网络读写线程与服务执行线程分离,尽量保证网络通讯层不受业务层影响。

* Architecture-Interceptor

描述信息:

Venus 提供可一套可进行定制开发的拦截器,目前已经开发完成的拦截器有:validator、Monitor、CacheProvider等实现,可供服务端使用。

Unable to render embedded object: File (Architecture-Interceptor.PNG) not found.


* 服务过载保护

主要背景:
一般框架无法预测服务内部的执行情况,当某个服务出现延迟比平时严重,此时如果还是按照正常的逻辑去分配执行线程,
那么很可能在大量请求下,执行线程将全部分配到这个延时严重的服务上,由于执行线程数量有限,因此其他服务往往无法正常得到执行,
从而影响服务相应时间。
venus 为解决这种情形而设计一个multiple Queue


工作原理:
1、multiple queue 是一个内置多队列的 BlockingQueue ,内部队列根据请求的目标endpoint动态创建(endpoint真实存在)
2、“内置队列”记录一段时间的服务延时时间(latency)、用于执行本队列的线程数(current)、自身的队列长度(size)、最大可分配的执行线程数(max)
3、Multiple Queue 内置一个LinkedList用于存放可被执行线程分配的“内置队列”,只有 current < max , size >0 的情况“内置队列”才能存在于该LinkedList中。
4、执行线程从MultipleQueue的LinkedList头部领取一个“内置队列”,并且从中获取一个entry(该任务可能是“内置队列A”的一个entry)。
   领取之后,A的current数字增加1,执行完成以后current数字减少1。如果current < max,size > 0 则 A 会重新放入到LinkedList的尾部,继续提供entry。
5、MultipleQueueManager负责监视“内置队列”的延时时间。定期协调它们的max值。

Enter labels to add to this page:
Please wait 
查找标签? 在此录入。

匿名用户 replies:

你还没有登录。你所做的任何更改会将作者标记为匿名用户。 如果你已经拥有帐户,请登录。 你也可以注册一个新帐户。
验证码图片