Registry 通过1个端口提供他所有的接口服务,
注册上的接口 是以实现类为核心注册的,同时他也要表名自己代表的是哪个接口
Micro-Service
Application1-----zkhost----[一个服务大厅必须要有1个中继服务商IP:PORT]
Services[可靠的云计算]----IP:port#codec#
com.calc.api.IAdd1----com.api.impl.v1.H1————class
com.calc.api.ISub2----com.api.impl.v1.H1————class
com.calc.api.IPow3----com.api.impl.v1.H1————class
Services[可靠的云存储]----IP:port
Com.db.api.save1------com.api.impl.v1.H1————class
Com.db.api.save2------com.api.impl.v1.H1————class
Com.db.api.update3----com.api.impl.v1.H1————class
Com.db.api.delete4----com.api.impl.v1.H1————class
Services[可靠的云服务]------IP:port
Com.cloud.api.vps------com.api.impl.v1.H1————class
Com.cloud.api.memory---com.api.impl.v1.H1————class
Com.cloud.api.cpu------com.api.impl.v1.H1————class
Services[可靠的云通知]------IP:port
Com.notify.api.sms------com.api.impl.v1.H1————class
Com.notify.api.email----com.api.impl.v1.H1————class
Com.notify.api.phone----com.api.impl.v1.H1———class
Application2-----zkhost2----[一个服务大厅必须要有1个中继服务商IP:PORT]
Services[可靠的云盾]------IP:port
Com.safe.api.check1------com.api.impl.v1.H1————class
Com.safe.api.check2------com.api.impl.v1.H1————class
当1个服务不可用时，整组挂掉.最好的选择,真正的fast_fail
对外的服务应该保持简单,1个接口1个实现类;内部再复杂也要让用的人 觉着简单
Product:
比如说当前 服务小组 做的业务叫 [可靠的云计算],那么当前服务小组就叫Service[可靠的云计算],自己新建一个首席注册官(),前去收集可靠服务接口,等这些接口都收集齐了,如果有拿得出手的服务(api_count>0),那么就把这些接口都提交申请给部门老大(这里不能有同样包的同样的版本的同一个接口,出现相同的就抛异常),同时把 当前IP和Port都给部门老大老A。
首席注册官,汇报完接口后就可以GC回收了
Consumer:
首席会告诉消费者，哪里有服务大厅,也就是application的地址.通过世界领先的6G手机(ZKClient)连接上 服务大厅 Application, 在服务大厅内罗列了各路 [可靠服务接口],当前大屏幕上罗列了:Service[可靠的云计算],Service[可靠的云存储],Service[可靠的云通知],Service[可靠的云服务].....
为了跟紧市场的发展和为客户打造7*24服务,我们的P2P网站可能需要 下面这俩个服务：
Service[可靠的快速计算],Service[可靠的快速存储]
那么在消费者那里,就 填写基本信息,准备申请 服务大厅的Service[可靠的快速计算],Service[可靠的快速存储],
<soap:zookeeper zkhost=”127.0.0.1:2182” >
<Services>
[可靠的云计算]
[可靠的云存储]
</Services>
</soap>
<soap:zookeeper zkhost=”127.0.0.2:2182” >
<Services>
[可靠的云认证]
</Services>
</soap>
<soap:zookeeper zkhost=”127.0.0.4:2182” >
<Services>
[可靠的云通知]
</Services>
</soap>
<soap:zookeeper zkhost=”127.0.0.3:2182” >
<Services>
[可靠的云验证]
[可靠的云认证]
</Services>
</soap>
当出现可以提供相同的业务接口的场景时,由中继服务商来路由,一般来说 拥有1个服务够用即可,当客户端请求队列满了时.就发送到第2个服务接口处;也可以是轮询的发送请求...(此次说法是个栗子)
你申请了哪几个服务,你就要领取相应的接口jar包.jar包的内容主要就是接口,也不排除含有实体Bean包含在里面.
Relay :
服务中继服务,名字这么绕,但丝毫不影响他做事雷厉风行的风格。
中继服务也有6G手机,而且该手机的信号是最好的,联系人里面是最全的,只要出现在服务大厅里的服务提供商,他都知道,因为不想错过与每位客户交(赚)流(钱)的机会. 他其实也是代理了下真实的服务,对于每一位客户,他都比较重视的,在记录了如下数据后:
客户(server-name)——调用服务——调用具体接口——消耗时间——成功|失败
相应的 至少会统计如下数据,(以便以后自己代理更可靠的服务,提高信誉度)：
客户(server-name)—调用服务—调用具体接口—平均消耗时间—总调用次数-失败次数
同时他还会与每个服务提供商 保持好联系,以便处理好自己的控制能力,避免消费者给自己差评.
[Delete]
每当有服务提供商要金盆洗手时,他就把该提供商信息从联系人名单中删除;
[Add]
有新服务提供商在服务大厅报名时,他也及时添加人服务商信息[IP-Port,掌握的接口列表];
[Disconnect]
当有服务商联系不上了,这不是玩失踪,1般情况下就是 服务倒闭了,从联系人名单中删除;
[Reconnect]
消失了的服务商又联系上了,原来是信号不好,还好还可以继续提供服务,继续加到联系人;
[Update]
服务商的接口能力提升,单位时间内能处理更多的订单了,要及时更新到联系人中信息;
当然 自己作为[中继服务商],掌握了这么多 提供商消息,
通过 getProviderList()让自己更踏实1点.更踏实的是,自己花钱买了1个侦探紧盯着服务大厅,这样自己就有了第一手资源了
中继服务商的6G手机是个Subject,为了及时的调整缓存的远程服务实例,要准备1个关注(实现) 了上面[event] 的接口的一个Observer,由Observer来辅助管理自己的本地缓存。
别看中继服务商这么风光,但是内部维护着 千奇百怪的服务.所以要做世界上最快的服务提供商也不是那么轻松的.
按编解码分组,可能有:
<probuff,List<Service>>,<kyro,List<Service>>
按协议分组,可能有:
<http,List<Service>>,<tcp,List<Service>>
按接口名分组,可能就:
<com.calc.api.IAdd,List<Service[0,1]> //0,1是指当前含有0,1 俩个版本
当是远程的http提供服务时,通过hessian的方式序列话
远程的一个接口实例对象到当前[中继服务商的spring容器中]来提供服务,在服务时可强转为接口去使用,然后视该服务是单例还是多例的情况,每次 消费者调用时,每次由 spring去提供一个 实现(具体scope由提供商注册的接口参数定义).
当客户端调用
RelayClient.execute(com.calc.api.IAdd1.class,”add2”,....);
RelayClient.execute(com.calc.api.IAdd1.class,codecInt,”add2”,....);
RelayClient.execute(com.calc.api.IAdd1.class,)
未完待续
