有人說過，不充分了解就下判斷是不負責任的，我深表同意。在探討雲原生這個問題之前，有必要先搞清楚什麼是雲原生。
首先，雲原生（CloudNative）的概念在國內是由阿里在2019年首次提出，鑑於阿里技術體系在國內的分量，所以普遍認為2019年是國內雲原生元年。
tips：雖然已經學到禿頭，但關於“下一代”還是有必要關注並且深入瞭解一下的。
什麼是雲原生？
目前廣泛認可的雲原生由四個部分組成，分別是：
CI/CD（持續整合/釋出）
DevOps（開發/運維）
Microservices（微服務）
Containers（容器）
這四個部分拆開來說，或多或少都有耳聞，有些同學或許已經實裝到專案。從概念上把這四個部分順序縷一縷。
CI/CD（持續整合/釋出）
這一塊簡單來說，就是自動打包、編譯、部署、執行。現在商業模式越來越多，越來越快，按照業務倒逼技術發展的思路，也自然就會導致程式需要更高頻的更新，好把模式快速變成落地應用。如果只是一個單機程式，更新成本很小，但如果有幾百臺伺服器線上，要更新的成本就直線飆升。這其實是考驗持續交付的能力，如果你交付的成本足夠低，那就等於給了商業模式足夠的自由，就更容易走出來的同時，自然也就更受市場重視。有些同學認為這是運維的事，但開發掌握這方面的技能（比如Jenkins）會更有競爭力。
DevOps（開發/運維）
這一塊意思就是開發運維不分家，大家既負責開發，又負責運維、測試。從這個角度來看，它更像是專案管理方面的倡導（開發部、運維部、測試部三合一，成本驟降，老闆狂喜）。個人覺得對一家公司來說，部門牆是很致命的，就以這三個部門來講，開發部程式碼寫完提交給測試，測試部流程走完放給運維部，這個過程中但凡是出現一次測試不通過、運維失誤之類的，那上線時間就不知道要滯後多久。除了Task沒完成影響績效，還有可能造成損失。到時候三方拉人一起開會，三個和尚沒水喝的故事就生動演繹了。對公司來說簡直要命。
Microservices（微服務）
說到這一塊大家就熟得多（各大網課起手微服務高併發什麼的），也可能大家已經瞭解的很多了，但我們還是嚴謹點：微服務可以使我們的程式高內聚、低耦合，具體做法是根據業務和排程資源對程式進行分拆，被分拆的程式會變為一個個微小的服務，不同的服務不會相互影響。更細緻的就不講了，一來主題不是它，二來目前水平還沒到，講不好。
Containers（容器）
也可以叫它“容器化”，這方面代表的就是docker了。通過docker完成容器化，可以忽略各種環境配置的噁心活，如果又叢集，還可以無差別維護，極大降低出錯的概率。如果一個開發到現在還沒有上手docker，個人認為已經out了，要抓緊了。這部分同學可以翻一下我之前的文章。
全域性來講，個人覺得雲原生應該屬於那種“下一代”的技術，是一種技術發展的方向。可以感覺到，隨著市場的發展，社會節奏的加快，更穩更快的技術交付已經成為判斷技術力的新指標，究其根本還是業務倒逼技術發展。如果沒有出現雙11、限時秒殺，可能高併發、分散式鎖等各種解決方案還得晚幾年公知；如果手機沒有語音助手、全面屏沒有人臉識別，可能機器學習、人工智慧的理論仍然蒼在某個研究所的檔案室裡。雲原生髮展如何不好預測（阿里中臺火不火？一樣拆），但至少多學點沒錯。