Q: 什么是云原生?
网上有很多关于云原生概念的描述,虽然很全面但是都没有直击灵魂,只告诉了大家模样没有告诉大家判断云原生的原则。其实云原生的核心我觉得只有一句话可以总结“在云中生下来就具备的能力就叫云原生”。
做为人类,走路、吃饭、说话、算数这些对于我们来说不是原生的,因为这些我们生下来时候都不会,是通过后面训练慢慢掌握的。 但作为一个机器人,这些是造出来时就已经具备的能力,所以对于它们来说这是原生的。
云原生的意义就在于为这个机器人提供更多的出厂既具备的能力,而不是像我们人一样需要什么现学什么,这里的人其实就是应用开发者。
Q:云原生都包含哪些能力?
这个问题还可以换种问法,如果你的应用出生在云上,你希望你的应用自带什么能力。
首先必须要带的就是弹性扩展和容灾能力,而为了满足弹性扩容,发布模式必须是不可变基础设施,云上要配套不可变基础设施的持续部署能力,还要有对应的健康检查。
其次必须要有监控能力,以帮助我判断我的服务是否正常,充当我的眼睛和耳朵。
再其次需期望它具备微服务治理能力,服务发现、配置更新、熔断、降级、限流、全链路追踪等。
最后还希望能有高阶的运维能力,流量染色、链路压测、故障自愈、混沌工程等。
总之,云原生的能力不仅包含已经实现的部分,所有合理的共性的需求都应该被原生化。
Q:云原生一定要容器化吗?
不是,在云实例中提供这些原生能力也叫云原生,只不过通过容器化更容易实现而已。
拿弹性容错举例,云实例中通过弹性伸缩组可以提供弹性容错能力,k8s中通过ReplicaSet可以提供弹性容错能力,所以说只要具备了该有的能力就可以,至于是容器云还是实例云都无所谓。
Q:服务网格是云原生的发展方向么?
只能说目前来看服务网格是最理想的云原生实现的模型,但边车模式本身也存在一定的局限性,所以在系统架构上没有银弹,任何方案都有利有弊。在微服务治理上对每个组件的属性要求是不一样的,比如说可用性、延时、稳定性等,所以可能半容器化才是云原生最理想的解决方案吧。
Q: 哪些岗位随着原生化会被淘汰?
贯穿整个研发生命周期的所有岗位多多少少都有会被波及,由后向先,周期后段先被淘汰,然后中段,最后前段,因为云原生的原生化顺序也是先基础设施、再组件、再应用治理。
因为云原生的弹性容灾等基础设施相关能力,最先受影响的是运维;然后自动化测试、代码扫描等能力会将测试岗位弱化;最后微服务治理相关的原生能力会把软件架构师给消灭,留下的只有脚本开发工程师。所以未来只剩下两个相关的岗位:云平台工程师和业务脚本工程师,或者叫云内工程师和云外工程师。