再谈云原生：我的看法

去年我有一篇采访稿，讲我对云原生的看法，最近正好参加了一次线上会议，也是讨论云原生相关的事情，讨论完之后，我重新梳理了一下我的观点，陈列于下:



1. 云原生不一定依赖于云供应商或者狭义的云设施(比如公有云、混合云、私有云)，比如我只用物理机和k8s也能做好云原生，只是我搭好的这套系统本身也是一种云了。

2. 云原生在单个无状态应用、多个应用的服务治理、以及有状态的服务上有不同的诉求。

3. 单个无状态应用方面，我比较认同《Beyond The 12 Factor App》的观点，这也算是这个时代无状态服务的一个最佳实践。这些最佳实践也应当是云原生原则的一部分。

4. 多个应用则必然存在服务治理的需求，服务治理这部分的诉求比较多，其中较大的一个诉求是去系统运维的需求，这也是云原生之前大规模应用的一个运维难点，线上系统的操作系统版本不一致、配置不一致带来了大量的问题，程序版本不一致和配置不一致也是比较常见的问题。这些都可以在 k8s 这个体系下得到很好的解决。在引入 k8s 和 spring cloud 等实践后，对于业务开发人员来讲，操作系统，计算资源这些概念都被很好地抽象了。服务治理本身又是一个很庞大的话题，这个话题诞生也远早于云原生这个概念，其他部分就不展开了。

5. 除了无状态应用，有状态的服务，包括数据库、缓存、消息队列等，也在提云原生的概念。在这之前，我们对有状态的服务的述求更多是高可用，也就是说任何单个节点损坏后数据不丢，服务正常，可以容忍短时不正常（MySQL的主从模式就是这方面的典型）。那么云原生对有状态的服务的新的诉求有哪些呢？其中一个点应该算是自愈，这里边既包括了像 TiDB 这种从架构设计方面就考虑了自愈的场景(TiDB里边的节点损坏接近于缩容），也包括了通过 operator 等自动化运维机制来实现的自愈。当然很多新的数据、中间件在设计时，就在考虑通过计算存储分离等手段，来实现更好的云原生品质。

6. 我仍然认为云原生是一种理念，是在以云为代表的这个时代，软件工程最佳实践以及最佳技术选型的一个合集。尽管他的边界很难确定，但我们可以很清晰地看到在系统运维、DEVOPS等层面跟之前时代的最佳实践有着很大的差异。