近年来，云原生在整个开源社区中正在成为越来越流行的概念。那么云原生究竟是什么？架构？平台？又能影响什么？系统安全？开发效率？所以我们今天就刨根问底，理一下到底什么是云原生。
要理解什么是云原生，就要从云原生的名字说起，云原生的英文名是cloud native, 很显然，其含义就包含云和原生两部分。云就是说应用是运行在云上，而非本地。原生，就是说应用要以最适合云的方式去运行，而不是仅仅从本地迁移到应用上。
那么，什么样的应用才是适合云的呢？其实就是能最大化利用云的能力，发挥云的优势。
而云计算的核心优势，其实无非就是将更多的资源集中管理，统一调配，也就更方便按需灵活配置资源，提高资源利用率。
类比一下，相信很多人用过storm等流式框架，它们的优势是什么呢？其中一个重要的因素就是可以将一个复杂的流程拆解成若干个子节点，每个节点可以根据其需求配置不同的并发度，并发需求高的节点可以获得更多资源。这样，资源利用率也就提升了。
对微服务来说，也是类似，将不同功能拆分成不同的服务，就可以单独对更小粒度的功能单独做扩缩容。
值得注意的是，拆分不仅包含拆分不同的业务，也包括将业务代码、三方软件（第三方库）、非功能特性（高可用、安全、可观测性等三类代码进行分离。
单纯业务的拆分，实际上从软件开发的非常早期的阶段就在进行了。而伴随着云原生概念兴起的趋势，正是将云应用中的非业务代码部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特性（如弹性、韧性、安全、可观测性、灰度等），也就是所谓的service mesh.
由于云上的资源和应用并不是强绑定的，为了能更方便的利用资源，我们需要一种更通用的运行形势，让应用可以和运行环境有一定程度的解耦。这就是容器技术。容器提供了一种逻辑打包机制，以这种机制打包的应用可以脱离其实际运行的环境。利用这种脱离，不管目标环境是私有数据中心、公有云，还是开发者的个人笔记本电脑，您都可以轻松、一致地部署基于容器的应用。容器化使开发者和 IT 运营团队的关注点泾渭分明 - 开发者专注于应用逻辑和依赖项，而 IT 运营团队可以专注于部署和管理，不必为具体的软件版本和应用特有的配置等应用细节分心。
另一方面，服务更小粒度的拆分之后，系统本身的复杂度显然会有所提升，比如本地调用变成了网络请求，调用链也无法通过代码结构体现。因此，运维上需要更加智能化和自动化，要保障单个服务更强的稳定性；同时需要一个强大的监控系统，要能够分析出各个微服务之间的依赖关系，还要快速检测出系统中的异常。
同时，在单个服务规模更小，且监控数据很完善的前提下，我们有可能去更频繁的去部署，甚至每次更改之后直接部署到生产环境。如果部署有问题，我们可以通过监控及时的发现，从而将损失控制在更小的程度。而小规模的部署，也让我们更容易去定位问题或者回滚。
从上边的分析中，我们可以整理出和云原生相关的一些关键词，比如服务化、弹性、可观测、韧性、自动化等等，这些关键词可以被总结成4类，即微服务、DevOps、持续交付和容器化。
这4类的关键特征如下：
微服务：可被独立部署、更新、重启、scale
DevOps: 自动化、快速、开发运维协同
持续交付：频繁发布、快速反馈
容器化：逻辑打包机制
上边讲了很多理论上的知识，那么，要采用云原生的话，有什么具体的执行路径呢？可以从以下几个方面考虑：
- 业务服务的拆分：这是软件开发中非常基础的一件事，拆分需要满足SOLID原则等基础的设计原则。
- 完善的监控体系: 包括log, trace, metric, alert几个维度的信息都要收集起来，其中log侧重于记录代码运行过程中的信息，trace主要用于追踪同一请求在不同服务下的流转，metric是针对系统运行状况的监控，alert则是针对异常状态的报警。业界也已经有了很多开源的实现，比如prometheus, jaeger等等
- 容器及容器编排： 这一部分基本就是 docker和k8s
- 中间件mesh化： 即业务应用中只保留很薄的一层client, 中间件的主要逻辑放在在mesh层
- DevOps和持续交付：这个主要是开发流程、和开发运维协作上的很多流程的事。在云环境下，我们更推崇小批量、频繁发布、快速反馈的模式。
我是流沙，希望通过这篇文章，可以让大家更清晰的理解云原生究竟是什么。其实，云原生说起来很简单，就是采用各种方式去更好的利用云上的资源。而具体说起来，它又是一套非常庞大的体系，涵盖了从开发到运维的方方面面。欢迎大家关注我的公众号(Mobility) ，或者个人网站, 我会在后续的文章里逐渐展开讲讲云原生的方方面面。
原文地址: https://lichuanyang.top/posts/42843/