焦虑的程序员--动态增加一个服务实例

睡觉

/**
	 * 分发一个服务模版，从而启动一个服务实例, 单总数不能超过参考的上线。
	 * @return
	 */
	protected boolean createSingleServiceInstance() {
		//不能在这里做服务实例数量相关的策略控制，因为这个地方取不到比较准确的运行中的服务实例的数量值，取到的只是一个参考值。

		//等等~！！！此处必须控制一下~！！！！因为，当该组件可支配的运行资源枯竭的时候（服务实例数量到上限的时候）：
		//取决于具体服务组件的资源扩容策略，此方法很有可能会被“高频调用”，而dispatcher的dispatch操作会诱导
		//产生“高消耗”的逻辑运行比如threadPool会产生新的线程等等，
		//同时serviceInstanceKeeper内部逻辑也会在组件高负荷下陷入高并发运行状态，因为最终的数量控制在serviceInstanceKeeper中还有一道以确保
		//组件不会多占用资源。这违背了serviceInstanceKeeper低并发的生命周期控制场景的设计预期。
		//以上两方面会在服务组件满负荷的情况下产生灾难性的性能开销，所以必须预先检查一下，可支配资源是否已经枯竭，以避免无用功
		//另外，在满负运行场景，所取到的“服务实例”数量理论上应该是稳定的。 所以很有参考意义的，
		//应当避免在极端情况下，情况向更复杂的方向灾变。
		//另外定要注意他可能所在的运行场景是会变化的，一定要把这些可能的场景都想想，再权衡利弊。
		//代码不再是“静态”的代码，多假设下在不同的可能运行场景，他的行为会影响些什么。有些场景是否真的被屏蔽掉了。
		//对了，另外一定要对系统中的大开销行为心中有数并尽量明确统一管理，进行保护----这点做的不够抽象啊~~！！！！。
		//以下校验是十分必要的。不能因为里面有校验这里就不要了，行为场景不一样。
		//threadPool的资源只能被“服务组件”分享，其他的不能随便往里面抛任务~！！！！！！

		//注意这个场景~！！对于“任务潮涌”这个根本防不住啊~！！怎么办，也是高频场景，看来只能加强serviceInstanceKeeper的耐受力和性能了。~！！！！
		//首先我要明确“任务潮涌”的最大威胁是什么，是内存溢出，还是性能枯竭，俄，最终肯定是内存溢出死掉。
		//所以对“潮涌”要迅速的加资源，又不能反应过于敏感，造成运行资源的浪费。

		if (this.getServiceInstanceCount() < this.getMaxServiceInstances()) {
			return dispatch(serivceTemplate);
		}
		return false;
	}