睡觉
/**
* 分发一个服务模版,从而启动一个服务实例, 单总数不能超过参考的上线。
* @return
*/
protected boolean createSingleServiceInstance() {
//不能在这里做服务实例数量相关的策略控制,因为这个地方取不到比较准确的运行中的服务实例的数量值,取到的只是一个参考值。
//等等~!!!此处必须控制一下~!!!!因为,当该组件可支配的运行资源枯竭的时候(服务实例数量到上限的时候):
//取决于具体服务组件的资源扩容策略,此方法很有可能会被“高频调用”,而dispatcher的dispatch操作会诱导
//产生“高消耗”的逻辑运行比如threadPool会产生新的线程等等,
//同时serviceInstanceKeeper内部逻辑也会在组件高负荷下陷入高并发运行状态,因为最终的数量控制在serviceInstanceKeeper中还有一道以确保
//组件不会多占用资源。这违背了serviceInstanceKeeper低并发的生命周期控制场景的设计预期。
//以上两方面会在服务组件满负荷的情况下产生灾难性的性能开销,所以必须预先检查一下,可支配资源是否已经枯竭,以避免无用功
//另外,在满负运行场景,所取到的“服务实例”数量理论上应该是稳定的。 所以很有参考意义的,
//应当避免在极端情况下,情况向更复杂的方向灾变。
//另外定要注意他可能所在的运行场景是会变化的,一定要把这些可能的场景都想想,再权衡利弊。
//代码不再是“静态”的代码,多假设下在不同的可能运行场景,他的行为会影响些什么。有些场景是否真的被屏蔽掉了。
//对了,另外一定要对系统中的大开销行为心中有数并尽量明确统一管理,进行保护----这点做的不够抽象啊~~!!!!。
//以下校验是十分必要的。不能因为里面有校验这里就不要了,行为场景不一样。
//threadPool的资源只能被“服务组件”分享,其他的不能随便往里面抛任务~!!!!!!
//注意这个场景~!!对于“任务潮涌”这个根本防不住啊~!!怎么办,也是高频场景,看来只能加强serviceInstanceKeeper的耐受力和性能了。~!!!!
//首先我要明确“任务潮涌”的最大威胁是什么,是内存溢出,还是性能枯竭,俄,最终肯定是内存溢出死掉。
//所以对“潮涌”要迅速的加资源,又不能反应过于敏感,造成运行资源的浪费。
if (this.getServiceInstanceCount() < this.getMaxServiceInstances()) {
return dispatch(serivceTemplate);
}
return false;
}