这才是云原生(Cloud Native)！

云原生，Cloud Native，毫无疑问是现在技术圈最火热的词之一，但Cloud Native其实还只是个概念，或者说思想，每个人的眼中可能都有个不一样的Cloud Native，这篇文章来说说我认为的什么才是Cloud Native。

Cloud Native我认为是一个架构思想，和分布式架构、异地多活架构都一样，是一个指导业务系统如何构建的思想。

为什么业务系统的架构需要演进为Cloud Native，我觉得主要是以下两种情况：

1. 成本/业务灵活度

对于一些有突发高峰的业务而言，云的弹性价值是非常明显的，对于这种类型的业务，如何设计好业务系统的架构充分发挥云的弹性价值很值得。

对于无突增高峰的业务而言，云提供的丰富的IaaS、PaaS服务，可以带来非常低的试错和人员投入成本，所以设计好能充分发挥云价值的系统架构也非常重要。

还有对于国际化、游戏等需要灵活部署的场景而言，云的多地Region很好的提供了这个灵活度，自己要去构建这样的部署灵活度要付出的代价还是不小的。

2. 业务打通/数据统一等

还有一些业务其实是需要去打通业务，统一数据，这种其实是需要在上面的基础上演进为分布式架构，而同样基于云提供的各种中间件服务、数据产品服务是非常有助于完成这个演进的。

Cloud Native是指基于云计算来构建业务系统，所以其实Cloud Native涉及到两端，一端为云计算厂商，一端为构建业务系统的研发团队，只有这两端的团队共同努力，才能让Cloud Native落地。

对于构建业务系统端的团队而言，如何基于云产品的能力来合理设计自己的业务系统，而不是由于一点点的特殊需求，就自研相应领域的产品，我觉得这是系统是否是Cloud Native的关键识别点，如果我们去看国外诸如Netflix、Printerest等等一堆的近几年发展起来的业务的架构，会看到他们的设计中都是充分的去使用了云产品服务来设计自己的系统。

这件事其实在真正落地上大厂更难，大厂通常在多年的发展后，都形成了一套基于自己技术体系的业务系统，而要把这些完全为自己场景定制的技术体系切换为相对更为通用的云产品技术体系，通常是需要对业务系统做一些改造的，这个执行的难度可想而知，而对于新起步的很多业务，反而直接Cloud Native是更容易做到的。

对于云计算厂商的团队而言，从上面可以看到一个状况，如果业务系统越来越基于云产品服务设计，那么vendor lock-in这个就成为了核心问题，所以如何做到云产品的API标准化就是各个云计算厂商的关键，但我同样不认为这些API标准会是一个什么标准委员会制定出来，然后各厂商遵循，这些API标准一定是抢占出来的事实标准，例如k8s API、Hadoop API、TensorFlow API等。

除了云产品API标准化外，还有一个点也是云计算厂商支持Cloud Native很重要的一个点，就是如何让业务系统端越来越容易粗粒度的部署到云上，例如现在看到的Helm、Terraform这些。

根据上面这样的来看呢，我觉得现在基本上也不太存在真的完全Cloud Native的case，因为两端都还在演进中，但从大的趋势上来说，Cloud Native一定是大势所趋，所以我强烈建议在有条件做Cloud Native的情况下应该尽量去推进。

欢迎有具体实践的同学们来留言探讨探讨你眼中的Cloud Native，以及具体落地时碰到的各种坑。

封面图片来源：

https://i.ytimg.com/vi/NoFu_rpM7EQ/maxresdefault.jpg

欢迎关注我的公众号hellojavacases，

聊聊编程能力的高级进阶，

聊聊系统设计，

聊聊技术方向，

聊聊职业生涯的发展。