精华内容
下载资源
问答
  • 产品的四个生命周期

    千次阅读 2020-01-22 10:32:24
    典型产品生命周期一般可分为四个阶段,即投入期、成长期、饱和期和衰退期 1.投入期。新产品投入市场,便进入投入期。此时,顾客对产品还不了解,只有少数追求新奇顾客可能购买,销售量很低。为了扩展销路,需要...

    典型的产品生命周期一般可分为四个阶段,即投入期、成长期、饱和期和衰退期

    1.投入期。新产品投入市场,便进入投入期。此时,顾客对产品还不了解,只有少数追求新奇的顾客可能购买,销售量很低。为了扩展销路,需要大量的促销费用,对产品进行宣传。在这一阶段,由于技术方面的原因,产品不能大批量生产,因而成本高,销售额增长缓慢,企业不但得不到利润,反而可能亏损。产品也有待进一步完善。

    2.成长期。这时顾客对产品已经熟悉,大量的新顾客开始购买,市场逐步扩大。产品大批量生产,生产成本相对降低,企业的销售额迅速上升,利润也迅速增长。竞争者看到有利可图,将纷纷进入市场参与竞争,使同类产品供给量增加,价格随之下降,企业利润增长速度逐步减慢,最后达到生命周期利润的最高点。

    3.饱和期。市场需求趋向饱和,潜在的顾客已经很少,销售额增长缓慢直至转而下降,标志着产品进入了成熟期。在这一阶段,竞争逐渐加剧,产品售价降低,促销费用增加,企业利润下降。

    4.衰退期。随着科学技术的发展,新产品或新的代用品出现,将使顾客的消费习惯发生改变,转向其他产品,从而使原来产品的销售额和利润额迅速下降。于是,产品又进入了衰退期。

    展开全文
  • SpringIoc容器管理Bean默认都是单例设计模式,即每Bean只有一实例化Bean对象存在于SpringIoc容器中,因此SpringIoc容器需要负责管理Bean的生命周期。 分类 Bean 的生命周期可以分为以下四类, (1)...

    引言

    SpringIoc容器管理的Bean默认都是单例设计模式的,即每个Bean只有一个实例化的Bean对象存在于SpringIoc容器中,因此SpringIoc容器需要负责管理Bean的生命周期。

    分类

    Bean 的生命周期可以分为以下四类,
    (1)Bean 的自身方法
    (2)Bean生命周期接口方法
    (3)容器级生命周期接口方法
    (4)工厂后处理器接口方法

    Spring生命周期各个阶段 相关接口及方法
    Bean 的自身方法 Bean本身业务的方法。 配置文件中init-method和destroy-method指定的方法
    Bean生命周期接口方法 InitializingBean接口,DiposiableBean接口,BeanNameAware接口 ,ApplicationContextAware接口,BeanFactoryAware接口等等
    容器级生命周期接口方法 InstantiationAwareBeanPostProcessor接口实现,BeanPostProcessor接口实现
    工厂后处理器接口方法 AspectJWWeavingEnabler ConfigurationClassPostProcessor,CustomAutowireConfigurer等

    Bean 的自身方法及Bean生命周期接口方法

    设计一个BeanLifeCycle类,继承相关接口

    package com.Bean生命周期;
    
    import org.springframework.beans.BeansException;
    import org.springframework.beans.factory.BeanNameAware;
    import org.springframework.beans.factory.DisposableBean;
    import org.springframework.beans.factory.InitializingBean;
    import org.springframework.context.ApplicationContext;
    import org.springframework.context.ApplicationContextAware;
    
    /**
     * Author:haozhixin
     * Func: Bean的生命周期
     * Date: 2019-08-05
     */
    public class BeanLifeCycle implements BeanNameAware,ApplicationContextAware,InitializingBean,DisposableBean{
    	/*
    	* 构造器
    	*
    	*/
    	public BeanLifeCycle(){
    		System.out.println("1.[Bean级别]构造器执行了");
    	}
    	/*
    	* BeanNameAware接口方法实现
    	*
    	*/
    	@Override
    	public void setBeanName(String name){
    		System.out.println("2.[Bean级别]setBean方法执行了]");
    	}
    
    	/*
    	* ApplicationContextAware接口方法实现
    	*
    	*/
    	@Override
    	public void setApplicationContext(ApplicationContext applicationContext) throws BeansException{
    		System.out.println("3.[Bean级别]setApplicationContext方法执行了]");
    	}
    	/*
    	* InitializingBean接口方法实现
    	*
    	*/
    	@Override
    	public  void afterPropertiesSet() throws  Exception{
    		System.out.println("4.[Bean级别]afterPropertiesSet方法执行了]");
    	}
    	/*
    	* init-method属性指定的方法
    	*
    	*/
    	public void lifeCycleInit(){
    		System.out.println("5.[Bean级别]lifeCycleInit方法执行了]");
    	}
    	/*
    	* bean中的业务方法
    	*
    	*/
    	public void sayHello(){
    		System.out.println("6.[Bean级别]syHello方法执行了]");
    	}
    	/*
    	* DisposableBean接口方法实现
    	*
    	*/
    	@Override
    	public void destroy() throws Exception {
    		System.out.println("7.[Bean级别]destroy方法执行了]");
    	}
    	/*
    	* destroy-method属性指定的方法
    	*
    	*/
    	public void lifeCycleInitDestroy(){
    		System.out.println("8.[Bean级别]lifeCycleInitDestroy方法执行了]");
    	}
    }
    
    

    bean_life_cycle.xml配置方法

    <?xml version="1.0" encoding="UTF-8"?>
    <beans xmlns="http://www.springframework.org/schema/beans"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xmlns:context="http://www.springframework.org/schema/context"
           xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd">
    
        <bean id="BeanLifeCycle" class="com.Bean生命周期.BeanLifeCycle" scope="singleton" init-method="lifeCycleInit" destroy-method="lifeCycleInitDestroy">
    
        </bean>
    </beans>
    

    测试类的写法

    import com.Bean生命周期.BeanLifeCycle;
    import org.junit.Test;
    import org.junit.runner.RunWith;
    import org.springframework.beans.factory.annotation.Autowired;
    import org.springframework.test.context.ContextConfiguration;
    import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
    
    /**
     * Author:haozhixin
     * Func: Bean的生命周期
     * Date: 2019-08-05
     */
    @RunWith(SpringJUnit4ClassRunner.class)
    @ContextConfiguration("classpath:bean_life_cycle.xml")
    public class BeanLifeCycleTest {
    	@Autowired
    	private BeanLifeCycle beanLifeCycle;
    	@Test
    	public void test(){
    		beanLifeCycle.sayHello();
    	}
    }
    
    

    测试结果:

    1.[Bean级别]构造器执行了
    2.[Bean级别]setBean方法执行了]
    3.[Bean级别]setApplicationContext方法执行了]
    4.[Bean级别]afterPropertiesSet方法执行了]
    5.[Bean级别]lifeCycleInit方法执行了]
    6.[Bean级别]syHello方法执行了]
    7.[Bean级别]destroy方法执行了]
    8.[Bean级别]lifeCycleInitDestroy方法执行了]
    

    我们可以看到执行顺序,即Bean自身方法和Bean声明周期接口方法生命周期为:
    Ioc容器–>Bean构造器->BeanNameAware->ApplicationContextAware–>InitializingBean->init-method->Bean中的业务方法->DisposableBean->destroy-method方法。

    容器级生命周期接口方法的执行次序

    容器级接口方法一般有InstantiationAwareBeanPostProcessor和BeanPostProcessor两个接口,一般也将其实现类称为后处理器。容器级生命周期接口的实现独立于SpringIoc容器中的Bean,其是以容器拓展的形式注册到Spring中的。无论SpringIoc管理任何的Bean,这些后处理器都会发生作用。因此后处理器的影响范围是全局的SpringIoc容器中的Bean。用户可以通过编写合理的后处理器来实现自己对Bean的加工逻辑。

    • BeanPostProcessor:可以对Bean的属性进行更改
    • InstantiationAwareBeanPostProcessor:此接口可以在bean的实例化之前,之后操作,也可以在实例化之后进行属性操作
    • InstantiationAwareBeanPostProcessorAdapter:适配器类

    代码实现:

    package com.Bean生命周期;
    
    import org.springframework.beans.BeansException;
    import org.springframework.beans.PropertyValues;
    import org.springframework.beans.factory.config.InstantiationAwareBeanPostProcessorAdapter;
    
    import java.beans.PropertyDescriptor;
    
    /**
     * Author:haozhixin
     * Func:
     * Date:
     */
    public class ContainerLifeCycle extends InstantiationAwareBeanPostProcessorAdapter{
    	/***
    	 * 构造器
    	 */
    	public ContainerLifeCycle(){
    		System.out.println("a.[容器级别]ContainerLifeCycle构造器执行了");
    	}
    
    	/***
    	 *接口方法和实例化bean之前调用
    	 */
    	@Override
    	public Object postProcessBeforeInstantiation(Class<?> beanClass, String beanName) throws BeansException {
    		System.out.println("b.[容器级别]postProcessBeforeInstantiation执行了,beanClass:"+beanClass);
    		return null;
    	}
    
        /***
         *设置某个属性时调用
         */
    	@Override
    	public PropertyValues postProcessPropertyValues(PropertyValues pvs, PropertyDescriptor[] pds, Object bean, String beanName) throws BeansException {
    		System.out.println("c.[容器级别]postProcessPropertyValues执行了,beanName:"+beanName);
    		return pvs;
    	}
    
    
    	/***
    	 *接口方法和实例化Bean之后调用
    	 */
    	@Override
    	public boolean postProcessAfterInstantiation(Object bean, String beanName) throws BeansException {
    		System.out.println("d.[容器级别]postProcessAfterInstantiation执行了,beanClass:"+bean.getClass());
    		return true;
    	}
    
    
    }
    
    
    <?xml version="1.0" encoding="UTF-8"?>
    <beans xmlns="http://www.springframework.org/schema/beans"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xmlns:context="http://www.springframework.org/schema/context"
           xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd">
    
        <bean id="ContainerLifeCycle" class="com.Bean生命周期.ContainerLifeCycle" scope="singleton" >
    
        </bean>
    </beans>
    
    
    import com.Bean生命周期.BeanLifeCycle;
    import org.junit.Test;
    import org.junit.runner.RunWith;
    import org.springframework.beans.factory.annotation.Autowired;
    import org.springframework.context.support.ClassPathXmlApplicationContext;
    import org.springframework.test.context.ContextConfiguration;
    import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
    
    /**
     * Author:haozhixin
     * Func: Bean的生命周期
     * Date: 2019-08-05
     */
    public class ContainerLifeCycleTest {
    	public static void main(String [] args){
    		ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("classpath:bean_life_cycle.xml","classpath:container_life_cycle.xml");
    		BeanLifeCycle beanLifeCycle = context.getBean("BeanLifeCycle",BeanLifeCycle.class);
    		beanLifeCycle.sayHello();
    		context.close();
    	}
    }
    
    

    运行结果:

    a.[容器级别]ContainerLifeCycle构造器执行了
    b.[容器级别]postProcessBeforeInstantiation执行了,beanClass:class com.Bean生命周期.BeanLifeCycle
    1.[Bean级别]构造器执行了
    d.[容器级别]postProcessAfterInstantiation执行了,beanClass:class com.Bean生命周期.BeanLifeCycle
    c.[容器级别]postProcessPropertyValues执行了,beanName:BeanLifeCycle
    2.[Bean级别]setBean方法执行了]
    3.[Bean级别]setApplicationContext方法执行了]
    4.[Bean级别]afterPropertiesSet方法执行了]
    5.[Bean级别]lifeCycleInit方法执行了]
    6.[Bean级别]syHello方法执行了]
    7.[Bean级别]destroy方法执行了]
    8.[Bean级别]lifeCycleInitDestroy方法执行了]
    

    工厂级生命周期接口代码实现

    话不多说,直接上代码

    package com.Bean生命周期;
    
    import org.springframework.beans.BeansException;
    import org.springframework.beans.factory.BeanNameAware;
    import org.springframework.beans.factory.DisposableBean;
    import org.springframework.beans.factory.InitializingBean;
    import org.springframework.beans.factory.config.BeanFactoryPostProcessor;
    import org.springframework.beans.factory.config.ConfigurableListableBeanFactory;
    import org.springframework.context.ApplicationContext;
    import org.springframework.context.ApplicationContextAware;
    
    /**
     * Author:haozhixin
     * Func: Bean的生命周期
     * Date: 2019-08-05
     */
    public class FactoryLifeCycle implements BeanFactoryPostProcessor{
    	/*
    	* 构造器
    	*
    	*/
    	public FactoryLifeCycle(){
    		System.out.println("一.[工厂级别]构造器执行了");
    	}
    
    	@Override
    	public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException {
    		System.out.println("二.[工厂级别]postProcessBeanFactory方法执行了");
    	}
    }
    
    
    <?xml version="1.0" encoding="UTF-8"?>
    <beans xmlns="http://www.springframework.org/schema/beans"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xmlns:context="http://www.springframework.org/schema/context"
           xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd">
    
        <bean id="FactoryLifeCycle" class="com.Bean生命周期.FactoryLifeCycle" scope="singleton" >
    
        </bean>
    </beans>
    
    import com.Bean生命周期.BeanLifeCycle;
    import org.springframework.context.support.ClassPathXmlApplicationContext;
    
    /**
     * Author:haozhixin
     * Func: Bean的生命周期(工厂级别,bean级别,容器级别)
     * Date: 2019-08-05
     */
    public class FactoryLifeCycleTest {
    	public static void main(String [] args){
    		ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("classpath:bean_life_cycle.xml","classpath:container_life_cycle.xml","classpath:factory_life_cycle.xml");
    		BeanLifeCycle beanLifeCycle = context.getBean("BeanLifeCycle",BeanLifeCycle.class);
    		beanLifeCycle.sayHello();
    		context.close();
    	}
    }
    
    

    执行结果是:

    一.[工厂级别]构造器执行了
    二.[工厂级别]postProcessBeanFactory方法执行了
    a.[容器级别]ContainerLifeCycle构造器执行了
    b.[容器级别]postProcessBeforeInstantiation执行了,beanClass:class com.Bean生命周期.BeanLifeCycle
    1.[Bean级别]构造器执行了
    d.[容器级别]postProcessAfterInstantiation执行了,beanClass:class com.Bean生命周期.BeanLifeCycle
    c.[容器级别]postProcessPropertyValues执行了,beanName:BeanLifeCycle
    2.[Bean级别]setBean方法执行了]
    3.[Bean级别]setApplicationContext方法执行了]
    4.[Bean级别]afterPropertiesSet方法执行了]
    5.[Bean级别]lifeCycleInit方法执行了]
    6.[Bean级别]syHello方法执行了]
    7.[Bean级别]destroy方法执行了]
    8.[Bean级别]lifeCycleInitDestroy方法执行了]
    

    好了,就这么多,大家如果有疑问可以去Spring5企业级开发实战(五)下载以下源代码。


    作者:select you from me
    来源:CSDN
    转载请联系作者获得授权并注明出处。

    展开全文
  • 后面尝试用四个参数PEAI(分别代表短期效益、短期效率、长期效益、长期效率)强弱来描绘企业各个生命周期的特征,感觉不够有新意,字面上好像是没有其他人提过,但是基本思想是很多人说过。另外这四个参数...

    前1/3篇幅分析企业生命周期,把企业生命周期分为:孕育期、婴儿期、学步期、青春期、壮年期、贵族期、官僚期,分别论述每个时期的特点,还有点意思。

    后面尝试用四个参数PEAI(分别代表短期效益、短期效率、长期效益、长期效率)的强弱来描绘企业各个生命周期的特征,感觉不够有新意,字面上好像是没有其他人提过,但是基本的思想是很多人说过的。另外这四个参数的含义非常不好记,书中也没给出各个字母的含义的由来,看起来比较累。

    排版有点乱,有些地方应该左对齐的变成居中了。

    以下是书中一些信息的摘抄,#号后面是kindle电子书中的页码:

    1:处于婴儿期的公司要做的是销售、销售,再销售。销售之所以如此重要,是因为如果不能收回资金,新创办的年轻公司将无法活下去。即使如此,我依然发现许多处于婴儿期的公司不善于销售。#821

    2:处于婴儿期的公司有以下特点:●以行动为导向,受机会驱动。●几乎没有任何制度、规章、政策。●行为前后不一致。●问题无法得到及时解决而演变为危机,导致公司总是在处理一个又一个危机,这使它们变得十分脆弱。●领导者事必躬亲,不愿意授权给他人。●创始人的承诺不断被考验,而创始人的承诺对公司的生存十分关键。#873

    3:婴儿期公司常常抱怨资金不足,但在它们努力获得资金的过程中,常常会犯一些基本的错误。●借入短期货款,但在长期内才能产生效益。●通过打折来促进销售,以获取资金,但经常发生的情况是,折扣太大,以至于销售收入包不住变动成本。●向风险投资人出售股权,但这些风险投资人并不与创始人拥有共同的愿景或利益。#898

    4:许多咨询师、观察家批评婴儿期配偶的领导者,说他们不放权、工作太拼命、过于固执己见,他们的配偶也会这么说,但是只是因为自己创建了公司,他们才有了这些行为特征。#989

    5:为什么处于婴儿期的公司需要专制型领导,还有一个原因,那就是危机管理。由于婴儿期公司在努力着生存下去,所以它们不能延误任何决策。#996

    6:有些处于学步期的公司成了小型的集团公司,这是致命性的问题。它们参与很多相干的和不相干的业务。#1129

    7:别指望学步期的领导者会去参加什么会议,他们很少参加,即使参加的话,他们也会把控会议的进程,而且其他人就再也没有机会说任何有实质性内容的话了。#1189

    8:让员工崩溃的另一个因素是创始人的时间观念。在估计完成一件工作所需要的时间方面,学步期领导者的能力是极其不靠谱的。#1206

    9:更糟糕的是,处于学步期公司的领导者,大部分都无法清晰地陈述他们的想法,员工在听了之后常常会感到莫名其妙:“他到底想要我去做什么?”#1212

    10:学步期公司围绕人而不是围绕任务来进行组织管理。它们的发展是没有计划的,它们总是对出现的机会做出回应,而不是预先做好计划、组织并确定好自己的定位,以便利用好自己创造的未来机会,它们不去控制环境[34],而是任由环境来控制它们。#1296

    11:而对于学步期公司来说,如果不能开发出自己的管理体系,并使领导力制度化,它就会陷入创始人陷阱。#1329

    12:什么是海鸥综合征?创始人在婴儿期和学步期那种掌控一切、事事亲力亲为的热情,现在(学步期)已经变成阻碍公司继续成长和发展的阻碍。创始人本人也深有挫败感。#1376

    13:你是否注意到学步期复杂的情况了?创始人期盼能摆脱日常管理工作,但是他们又不打算放弃控制。他们一方面逐渐抽离,另一方面又难以放权,这就造成了一种遥控现象,而这或许是最糟糕的局面。创始人离开了,但是其他人都没有权力、没有胆量、没有勇气做出决策。#1388

    14:由于没有正式的运转良好的控制制度,学步期公司的领导者只能依靠流言以及随机的信息来进行管理。尽管公司里充满了相互怀疑的气氛,但这些充满激情的企业家不满足于已有的成就,依然想大干一番。#1432

    15:可以通过以下方面来识别一家公司是否处于青春期。●我们和他们——“旧时期的老人和新时代的新人”思维方式。●目标多变。●薪酬和激励制度多变。#1557

    16:为什么从学步期到青春期的转变如此困难?因为这个转变面临三个主要的挑战:●授权。●领导的改变。●目标的转换。#1561

    17:处于壮年早期的公司具有以下特点:●有清晰的愿景和价值观——“言必行”。●制度化的管理流程。●有控制和被鼓励的创造力。●综合性目标。●知轻重,分缓急。●运转良好的制度和组织结构●可预期的卓越表现。●销售额和边际利润双增长。●繁殖力强。●内外的凝聚力、整合力强。#1869

    18:壮年期公司喜欢重复成功的气氛。具有自我约束力的管理层甚至会把坏的结果也看成成功,因为事情或许不能做得更好了,并且公司已经有了切实可行的计划来应对这种局面,而这才是最重要的。#2213

    19:在壮年期之后,财务和法律部门获得了职权和权力,而责任却依然在营销和销售部门身上,这使得职权与责任分离开来。#2448

    20:等到公司已经衰退的时候,它的行政管理体系、政策、先例、规章和方针等左右着它的行为。无论管理层如何努力以显现出是他们在进行控制,但决定公司行为的却是以往的决策和奖励制度。#2477

    21:对于一家处于衰退中的公司来说,找那些不愿冒失去客户风险的咨询师来帮忙是错误的,这些咨询师所能起到的最好作用也就是缓解某些症状。衰退阶段的公司所需要的是某个能改变其权力结构的人,我把这种人叫作冒犯者,他们属于那种不怕引起疼痛和失去生意的咨询师。#2554

    22:处于贵族期的公司有以下特点:●发展的欲望降低了。●对于征服新市场、新技术和开辟新领域兴趣不大。●重视过去的成就,而不是未来的发展前景。●对变化产生了怀疑情绪。●奖励顺从者、让干什么就干什么的人……#2759

    23:贵族期公司所设计的会议室通常都会让人惊讶于它的与众不同。在一个典型的会议室里,几乎可以肯定你会看到一张巨大的、闪闪发光的黑色木质桌子,围着一圈与之配套的豪华椅子。#2794

    24:等公司到了贵族期,形式压倒了功能,仅仅是它那空荡荡的走廊就足以满足好几个婴儿期公司的需要。总裁套房的租金——具有私人浴室、餐厅和秘书办公室——可能就会超过在学步期时公司为所有设施所付的租金。#2816

    25:正常情况下,贵族期公司会去购买学步期的公司。对于贵族期公司来说,在一个正在增长的市场上,学步期公司及其新技术很有吸引力;而对于学步期公司来说,它们对靠自己努力走上正轨并实现发展感到厌倦,因此更容易接受大公司的收购请求。#2914

    26:在贵族期晚期,公司的产品线已变得落伍,顾客知道这一点,销售人员知道这一点,甚至首席执行官也知道这一点。但是,没有人针对这个问题做些什么,人们不停地发出抱怨,而管理层则没完没了地开着那些毫无结果的会议。一句话,每个人都在等待别人去做些什么。#2940

    27:处于官僚早期的公司,在行为上有以下特点:●人们关注的是谁导致了问题的产生,而不是关注应该对问题做些什么。会司变得对人不对事……。#3019

    28:官僚期公司的特点如下:●制度繁多,但很少是为了提高工作效率。●与环境脱节,它关心的是自己。●缺少控制意识。●顾客不得不想出各种办法来绕过制度构成的阻碍。#3070

    29:官僚期的公司是支离破碎的。没有任何一个人了解公司应当做的全部事情,每个人都只知道一小部分必要的信息,而客户必须自己把分离的信息归纳到一起。#3094

    30:壮年期是分权的最佳时机。对学步期公司来说,因为还没有建立健全的控制系统和表述清晰的公司使命,分权可能很危险,甚至会导致失去控制的灾难。#5726













    本文转自左其盛博客园博客,原文链接:  http://www.cnblogs.com/zuoqs/p/7716405.html  ,如需转载请自行联系原作者


    展开全文
  • 一、pod的生命周期 Pod 是 kubernetes 系统基础单元,是由用户创建或部署最小组件,也是 kubernetes 系统上运行容器化应用资源对象 pod可以包含多容器,应用运行在这些容器里面,同时pod也可以有一或多...

    一、pod的生命周期

    在这里插入图片描述Pod 是 kubernetes 系统的基础单元,是由用户创建或部署的最小组件,也是 kubernetes 系统上运行容器化应用的资源对象
    pod可以包含多个容器,应用运行在这些容器里面,同时pod也可以有一个或多个先于应用容器启动的init容器。、

    二、init容器介绍

    Pod 可以包含多个容器,应用运行在这些容器里面,同时 Pod 也可以有一个或多个先于应用容器启动的 Init 容器。

    Init 容器与普通的容器非常像,除了如下三点:

    它们总是运行到完成。
    Init 容器不支持 Readiness,因为它们必须在 Pod 就绪之前运行完成。
    每个 Init 容器必须运行成功,下一个才能够运行。
    

    如果 Pod 的 Init 容器失败,Kubernetes 会不断地重启该 Pod,直到 Init 容器成功为止。然而,如果 Pod 对应的 restartPolicy 值为 Never,它不会重新启动。

    Init 容器作用

    Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。
    
    Init 容器可以安全地运行这些工具,避免这些工具导致应用镜像的安全性降低。
    
    应用镜像的创建者和部署者可以各自独立工作,而没有必要联合构建一个单独的应用镜像。
    
    Init 容器能以不同于Pod内应用容器的文件系统视图运行。因此,Init容器可具有访问 Secrets 的权限,而应用容器不能够访问。
    
    由于 Init 容器必须在应用容器启动之前运行完成,因此 Init
    容器提供了一种机制来阻塞或延迟应用容器的启动,直到满足了一组先决条件。一旦前置条件满足,Pod内的所有的应用容器会并行启动。
    
    

    init容器实验

    [root@server1 manifest]# vim init.yaml
    [root@server1 manifest]# cat init.yaml 
    apiVersion: v1
    kind: Pod
    metadata:
      name: myapp-pod
      labels:
        app: myapp
    spec:
      containers:
        - name: myapp-container
          image: myapp:v1
      initContainers:
        - name: init-container
          image: busybox
          command: ["/bin/sh", "-c", "until nslookup myservice.default.svc.cluster.local; do echo waiting for myservice; sleep 2; done"]
    
     
    

    其中init容器种执行的命令是用来检测default 命名空间的解析,这个解析需要一个service,即init容器在运行时会检测service,若果service没有运行的话就会一直处于初始化状态。

    我们先来运行一下这个pod:

    [root@server1 manifest]# kubectl create -f init.yaml 
    pod/myapp-pod created
    [root@server1 manifest]# kubectl get pod
    NAME        READY   STATUS     RESTARTS   AGE
    myapp-pod   0/1     Init:0/1   0          83s
    
       
    

    可以看出pod一直处于初始化状态。

    现在进入容器内部查看解析:

    [root@server1 manifest]# kubectl exec -it myapp-pod -c init-container -- sh
    / # nslookup myservice.default.svc.cluster.local
    Server:		10.96.0.10
    Address:	10.96.0.10:53
    
    ** server can't find myservice.default.svc.cluster.local: NXDOMAIN
    
    ^C
    / # 
    

    可以看出果然没有解析。

    接下来我们创建一个service:

    [root@server1 manifest]# vim service.yaml 
    [root@server1 manifest]# cat service.yaml 
    kind: Service
    apiVersion: v1
    metadata:
      name: myservice
    spec:
      ports:
        - protocol: TCP
          port: 80
          targetPort: 9376
    
    [root@server1 manifest]# kubectl create -f service.yaml 
    service/myservice created
    [root@server1 manifest]# kubectl get svc
    NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
    kubernetes   ClusterIP   10.96.0.1        <none>        443/TCP   2d4h
    myservice    ClusterIP   10.109.148.189   <none>        80/TCP    9s
    

    创建service成功,之后再查看pod状态:

    [root@server1 manifest]# kubectl get pod -o wide
    NAME        READY   STATUS    RESTARTS   AGE   IP            NODE      NOMINATED NODE   READINESS GATES
    myapp-pod   1/1     Running   0          53s   10.244.2.18   server3   <none>           <none>
    

    可以看出已经处于运行状态,同样我们可以访问它:
    [

    root@server1 manifest]# curl 10.244.2.18
    Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>
    

    之后再进入容器查看解析:

    [root@server1 manifest]# kubectl run test -it  --image=radial/busyboxplus
    If you don't see a command prompt, try pressing enter.
    / # nslookup myservice.default.svc.cluster.local
    Server:    10.96.0.10
    Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local
    
    Name:      myservice.default.svc.cluster.local
    Address 1: 10.109.148.189 myservice.default.svc.cluster.local
    / # 
    

    果然解析成功。

    因此可以验证如果 Pod 的 Init 容器失败,Kubernetes 会不断地重启该 Pod,直到 Init 容器成功为止。

    实验完成后删除:

    [root@server1 manifest]# kubectl delete pod test
    [root@server1 manifest]# kubectl delete pod myapp-pod 
    [root@server1 manifest]# kubectl delete svc myservice
    

    三、探针

    理解探针

    容器探针用来检测主容器的运行状态。

    在pod生命周期中可以做的一些事情。主容器启动前可以完成初始化容器,初始化容器可以有多个,他们是串行执行的,执行完成后就退出了,在主程序刚刚启动的时候可以指定一个post start 主程序启动开始后执行一些操作,在主程序结束前可以指定一个 pre stop 表示主程序结束前执行的一些操作。在程序启动后可以做两类常用检测 liveness probe(存活性探测) 和 readness probe(就绪性探测)

    探针是由 kubelet 对容器执⾏的定期诊断。 要执⾏诊断, kubelet 调⽤由容器实现的 Handler。

    有三种类型的探测方式:

    ExecAction: 在容器内执⾏指定命令。 如果命令退出时返回码为 0 则认为诊断成功。
    TCPSocketAction: 对指定端⼝上的容器的 IP 地址进⾏ TCP 检查。 如果端⼝打开, 则诊断被认为是成功的
    HTTPGetAction: 对指定的端⼝和路径上的容器的 IP 地址执⾏ HTTP Get 请求。 如果响应的状态码⼤于等于200且⼩于400, 则诊断被认为是成功的。
    

    每次探测都将获得以下三种结果之一

    成功:容器通过了诊断。
    失败:容器未通过诊断。
    未知:诊断失败,因此不会采取任何行动。
    

    Kubelet 可以选择是否执行在容器上运行的两种探针执行和做出反应:

    livenessProbe:指示容器是否正在运行。如果存活探测失败,则 kubelet 会杀死容器,并且容器将受到其 重启策略的影响。如果容器不提供存活探针,则默认状态为 Success。
    readinessProbe:指示容器是否准备好服务请求。如果就绪探测失败,端点控制器将从与 Pod 匹配的所有 Service 的端点中删除该 Pod 的 IP 地址。初始延迟之前的就绪状态默认为 Failure。如果容器不提供就绪探针,则默认状态为 Success。
    startupProbe: 指示容器中的应用是否已经启动。如果提供了启动探测(startup probe),则禁用所有其他探测,直到它成功为止。如果启动探测失败,kubelet 将杀死容器,容器服从其重启策略进行重启。如果容器没有提供启动探测,则默认状态为成功Success。
    

    重启策略

    PodSpec 中有一个 restartPolicy 字段,可能的值为 Always、OnFailure 和 Never。默认为 Always。

    livenessProbe存活探测示例

    编辑以下yaml文件:

    [root@server1 manifest]# vim liveness.yaml
    [root@server1 manifest]# cat liveness.yaml 
    apiVersion: v1
    kind: Pod
    metadata:
      name: liveness-http
    spec:
      containers:
        - name: myapp
          image: ikubernetes/myapp:v1
          imagePullPolicy: IfNotPresent
          livenessProbe:
            tcpSocket:
              port: 8080
            initialDelaySeconds: 1
            periodSeconds: 3
            timeoutSeconds: 1
    

    以上使用tcpsock检测容器8080端口,若liveness探针没有检测到8080端口则判定为不存活。由于我们运行的容器只暴露出来80端口,因此会检测失败。其中:

    initialDelaySeconds: 1表示pod运行1s后检测状态。
    
    periodSeconds: 3表示每3s检测一次。
    
    timeoutSeconds: 1表示检测1s后即超时进行下次检测
    

    之后运行并查看状态:

    [root@server1 manifest]# kubectl create -f liveness.yaml 
    pod/liveness-http created
    [root@server1 manifest]# kubectl get pod
    NAME            READY   STATUS    RESTARTS   AGE
    liveness-http   1/1     Running   0          10s
    [root@server1 manifest]# kubectl get pod
    NAME            READY   STATUS             RESTARTS   AGE
    liveness-http   0/1     CrashLoopBackOff   2          51s
    [root@server1 manifest]# kubectl get pod
    NAME            READY   STATUS    RESTARTS   AGE
    liveness-http   1/1     Running   3          54s
    [root@server1 manifest]# kubectl get pod
    NAME            READY   STATUS    RESTARTS   AGE
    liveness-http   1/1     Running   3          56s
    [root@server1 manifest]# kubectl get pod
    NAME            READY   STATUS    RESTARTS   AGE
    liveness-http   1/1     Running   3          61s
    

    可以看出检测失败一直在重启。

    接下来我们将检测端口改为80端口再运行:

    [root@server1 manifest]# kubectl delete -f liveness.yaml 
    
    [root@server1 manifest]# vim liveness.yaml
    [root@server1 manifest]# cat liveness.yaml 
    apiVersion: v1
    kind: Pod
    metadata:
      name: liveness-http
    spec:
      containers:
        - name: myapp
          image: ikubernetes/myapp:v1
          imagePullPolicy: IfNotPresent
          livenessProbe:
            tcpSocket:
              port: 80
            initialDelaySeconds: 1
            periodSeconds: 3
            timeoutSeconds: 1
    
    [root@server1 manifest]# kubectl create -f liveness.yaml 
    pod/liveness-http created
    [root@server1 manifest]# kubectl get pod
    NAME            READY   STATUS    RESTARTS   AGE
    liveness-http   1/1     Running   0          23s
    

    可以看出启动成功,在运行状态。

    实验后删除:

    [root@server1 manifest]# kubectl delete -f liveness.yaml 
    
        
    

    readinessProbe就绪检测示例:

    编辑测试文件:

    [root@server1 manifest]# vim reainess.yaml 
    [root@server1 manifest]# cat reainess.yaml 
    apiVersion: v1
    kind: Pod
    metadata:
      name: readiness-http
    spec:
      containers:
        - name: readiness
          image: nginx
          readinessProbe:
            httpGet:
              path: /test.html
              port: 80
            initialDelaySeconds: 1
            periodSeconds: 3
            timeoutSeconds: 1
    

    以上使用httpGet的方式使用readinessProbe进行探测,表示在容器运行后检测test.html发布文件内容,若返回200到400之间的状态码则检测通过为READY状态,其他为不通过。

    运行pod,并查看状态:

    [root@server1 manifest]# kubectl create -f reainess.yaml 
    pod/readiness-http created
    [root@server1 manifest]# kubectl get pod
    NAME             READY   STATUS    RESTARTS   AGE
    readiness-http   0/1     Running   0          51s
    [root@server1 manifest]# kubectl get pod
    NAME             READY   STATUS    RESTARTS   AGE
    readiness-http   0/1     Running   0          60s
    

    可以看出是运行状态但是并不是READY状态,可以看出检测没有通过。

     [root@server1 manifest]# kubectl describe pod readiness-http
    

    在这里插入图片描述查看日志:

    [root@server1 manifest]# kubectl logs readiness-http
    

    在这里插入图片描述
    此时我们进入容器添加test.html发布文件:

    [root@server1 manifest]# kubectl exec -it readiness-http -- sh
    # echo redhat > /usr/share/nginx/html/test.html
    # 
    

    查看pod状态:

    [root@server1 manifest]# kubectl get pod
    NAME             READY   STATUS    RESTARTS   AGE
    readiness-http   1/1     Running   0          2m37s
    

    可以看出已经是READY状态了。

    可以看出就绪探针的作用了,即指示容器是否准备好服务请求。

    实验后删除:

    [root@server1 manifest]# kubectl delete -f reainess.yaml 
    
    展开全文
  • 软件工程的生命周期

    千次阅读 2014-08-27 08:08:36
     生命周期的四个阶段需求分析、设计、实施、运行和审计: 1) 需求分析阶段 需求分析是确定企业需求并把这种需求反映到信息系统需求说明书中。 需求分析阶段主要是满足用户需求的新系统逻辑模型。 需求分析工作...
  • 基于全生命周期的思想,从设备的企业计划、采购、使用到最终报废四个方面构建了基于Web生命周期设备管理系统;在该系统中通过严格规范编码方法对设备做到惟一追踪,实现设备全生命周期中信息一致性、...
  • 宇宙中任何事物,都具有从出生到死亡的过程,大...企业的产品同样会经过投入期、成长期、成熟期和衰退期四个阶段;企业的设备资源会经过采购、使用、磨损、废弃等几个阶段;企业的员工会经过招募、入职、培训、提拔...
  • 《Maven—生命周期和插件()》 《Maven--多模块依赖实例解析(五)》 上几篇从应用角度来讲Maven,这篇还本着应用精神继续讲解,Maven最好玩的地方不是单单为你管理了jar这么简单,而是在他所定义的生命...
  • CRM三个级别和四个周期

    千次阅读 2002-07-10 09:19:00
    CRM三个级别和四个周期 2001-02-05· ·潘维民··中国计算机报 一个企业实施CRM主要目的是要达到提高竞争力并带来... 一个企业实施CRM成败关键问题有三个级别和四个生命周期。三个级别确定一个企业CRM项目
  • <声明:读书总结自《精通Spring 4.x 企业应用开发实战》 ... spring中bean实例化过程主要有四个关键点: Bean本身定义方法,如构造函数,静态代码块,属性设置器等 Bean级生命周期控制接口方法,如Be...
  • 为了稍稍区别于一般产品生命周期包含的“引进”“成长”“成熟”“衰退”四个阶段,我这里把互联网产品的生命周期分为以下四个阶段,如图所示:对于互联网产品来说,启动阶段就相当于一个企业的初创阶段,在
  • 我认为应该从稳定、可信、丰富、透明四个关键词入手。其中,稳定要求数据产出稳定、有保障;可信意味着数据质量要足够高;丰富是指数据涵盖业务面要足够丰富;透明要求数据构成流程体系是透...
  • 百分点数据科学实验室基于产品生命周期理论在多个行业的落地实践,总结了如何准确把握产品生命周期的四个阶段及识别方法论。 众所周知,一种产品在市场上的销售情况和获利能力并非是一成不变的,因此,任何一家...
  • 报告主题:基于软件生命周期的过程管理体系 嘉宾介绍:博士&MBA,副教授/硕导,信息系统管理师/系统分析师,信息监理师/软件评测师,ITIL Manager, ISO 27001主任审核员,ISO 20000主任审核员。 具有多年IT行业...
  • CRM特征和周期.doc

    2020-04-15 09:35:47
    一个企业实施CRM成败的关键问题有三个级别和四个生命周期三个级别确定一个企业CRM项目的大小使CRM充分满足不同规模企业的需求四个周期是CRM获得利润的主要来源通过对四个生命周期的管理企业可以充分优化活动或策略...
  • 主要管理思想基于应用最为广泛敏捷开发方法Scrum,同时又增加了Bug管理,测试用例管理,发布管理,文档管理等必需功能,覆盖了研发类项目管理核心流程,为IT企业或正在进行信息化的企业提供了一一体化集成...
  • 企业信息化尘埃落定为四个主要业务领域,由四种主要IT信息系统所代表。它们是: 企业资源规划(ERP)系统, 供应链管理(SCM)系统, 客户关系管理(CRM)系统 产品生命周期管理...
  • 企业生命特征是企业生命力的直接表现形式,是...运用主成分分析法处理数据并初步给出了研究样本生命特征的优劣排序,为企业全面评价其生命特征提供一定的参考,对处在任何生命周期中的企业的成长和发展都具有参考价值。
  • 四个生命周期正是解决了CRM怎么使用问题。 ​ 1.分析周期 分析是在数据集市基础上,利用数据挖掘技术来发现关键客户、确定客户风险级别等。分析是一个由数据抽样、转换和分析单元构成,然而一个流程...
  • 冯仑:民营企业的四大“天花板”

    千次阅读 2009-08-17 22:04:00
    冯仑:民营企业的四大“天花板”100多年以来,中国的民营企业一直长不大,活不长,生命周期无法突破15年这坎。直到今天,这周期率才被万科、联想、万通等企业打破,这些企业每多活一天,都多创造一天民营企业的...
  • 一、bean生命流程 Spring 是一轻量级 J2EE 开源框架,其目标是降低企业级应用开发难度,提高企业级应用开发效率。在日程开发中,我们会...在详细讨论 bean 生命周期前,先上一张图,后面也会围绕这张图展开...
  • 数据治理的四个阶段

    2021-03-02 09:53:03
    数据治理平台是以元数据为基础,实现数据产生、存储、迁移、使用、归档、销毁等环节数据生命周期管理。实现数据从源到数据中心再到应用端全过程管理,为用户提供了准确便捷的企业资产信息。数据治理平台也包括...
  • 企业移动信息化建设,需要有一生命周期规划概念。从最基础硬件架构到软件基础环境,再到软件解决方案、平台、业务应用,与此同时不断完善移动信息化安全构建,企业根据自身需求,对生命周期建设过程做...
  • 企业接口的生命周期状态很多:准备中、计划中、开发中、测试中、上线。。。 我们想了好久,终于找到4种状态来准确表示,再加上4种颜色,看上去非常完美: 业务域准备 开发中 已开发 已上线 种状态,...
  • 如何成为一名优秀的企业管理者

    千次阅读 2019-03-02 21:42:49
    企业的生命发展周期(Enterprise Life Cycle)主要包括四个发展阶段:幼稚期,成长期,成熟期,衰退期(参考图一)。在企业发展的整个生命周期中,企业的管理者对企业的存亡起着决定性的作用,因此如何成为一名优秀的...
  • 企业不能期望他产品永远地畅销,因为一种产品在市场上销售情况和获利能力并不是一成不变,而是随着时间推移发生变化,这种...典型产品生命周期一般可以分成四个阶段:引入期、成长期、成熟期和衰退期。
  • 4.1 Spring配置概述 4.1.1 Spring容器高层视图 Bean配置信息是Bean元数据信息,它由以下4方面组成: ...4、Bean行为配置,如生命周期范围及生命周期各个过程回调函数等。 Bean元数据信息在Spr
  • RPA开发教程丨RPA实施四大阶段

    千次阅读 2019-12-03 16:32:45
    阶段:RPA生命周期管理。 第一阶段:RPA机会评估 企业如何选择有影响力且易于RPA自动化流程?通常可从下面5方面来详细考虑流程筛选,确保在RPA自动化过程中产生最大投资回报率。 1、影响成本和收入流程...
  • 在上篇文章中,我们讲到了BPM的生命周期包括设计、建模、执行、监控和优化5阶段,本篇我们以住建行业预销售许可审批主线流程对BPM执行过程进行详细解剖。BPM中流程包括可执行流程和不可执行流程,不可...

空空如也

空空如也

1 2 3 4 5 ... 10
收藏数 188
精华内容 75
关键字:

企业的四个生命周期