有人说过，不充分了解就下判断是不负责任的，我深表同意。在探讨云原生这个问题之前，有必要先搞清楚什么是云原生。
首先，云原生（CloudNative）的概念在国内是由阿里在2019年首次提出，鉴于阿里技术体系在国内的分量，所以普遍认为2019年是国内云原生元年。
什么是云原生？
目前广泛认可的云原生由四个部分组成，分别是：
CI/CD（持续集成/发布）
DevOps（开发/运维）
Microservices（微服务）
Containers（容器）
这四个部分拆开来说，或多或少都有耳闻，有些同学或许已经实装到项目。从概念上把这四个部分顺序缕一缕。
CI/CD（持续集成/发布）
这一块简单来说，就是自动打包、编译、部署、运行。现在商业模式越来越多，越来越快，按照业务倒逼技术发展的思路，也自然就会导致程序需要更高频的更新，好把模式快速变成落地应用。如果只是一个单机程序，更新成本很小，但如果有几百台服务器在线，要更新的成本就直线飙升。这其实是考验持续交付的能力，如果你交付的成本足够低，那就等于给了商业模式足够的自由，就更容易走出来的同时，自然也就更受市场重视。有些同学认为这是运维的事，但开发掌握这方面的技能（比如Jenkins）会更有竞争力。
DevOps（开发/运维）
这一块意思就是开发运维不分家，大家既负责开发，又负责运维、测试。从这个角度来看，它更像是项目管理方面的倡导（开发部、运维部、测试部三合一，成本骤降，老板狂喜）。个人觉得对一家公司来说，部门墙是很致命的，就以这三个部门来讲，开发部代码写完提交给测试，测试部流程走完放给运维部，这个过程中但凡是出现一次测试不通过、运维失误之类的，那上线时间就不知道要滞后多久。除了Task没完成影响绩效，还有可能造成损失。到时候三方拉人一起开会，三个和尚没水喝的故事就生动演绎了。对公司来说简直要命。
Microservices（微服务）
说到这一块大家就熟得多（各大网课起手微服务高并发什么的），也可能大家已经了解的很多了，但咱还是严谨点：微服务可以使我们的程序高内聚、低耦合，具体做法是根据业务和调度资源对程序进行分拆，被分拆的程序会变为一个个微小的服务，不同的服务不会相互影响。更细致的就不讲了，一来主题不是它，二来目前水平还没到，讲不好。
Containers（容器）
也可以叫它“容器化”，这方面代表的就是docker了。通过docker完成容器化，可以忽略各种环境配置的恶心活，如果又集群，还可以无差别维护，极大降低出错的概率。如果一个开发到现在还没有上手docker，个人认为已经out了，要抓紧了。这部分同学可以翻一下我之前的文章。
全局来讲，个人觉得云原生应该属于那种“下一代”的技术，是一种技术发展的方向。可以感觉到，随着市场的发展，社会节奏的加快，更稳更快的技术交付已经成为判断技术力的新指标，究其根本还是业务倒逼技术发展。如果没有出现双11、限时秒杀，可能高并发、分布式锁等各种解决方案还得晚几年公知；如果手机没有语音助手、全面屏没有人脸识别，可能机器学习、人工智能的理论仍然藏在某个研究所的档案室里。云原生发展如何不好预测（阿里中台火不火？一样拆），但至少多学点没错。
