注明：这里说的云原生，是指的以 k8s 为基础的狭义云原生。
从微服务到云原生，是随着软件行业分工的细化，通用能力的下沉，基础设施的向上抽象，产生的软件架构的又一次演进升级。
- 微服务，更像是一个开发框架，开发者是使用框架来开发服务。
- 云原生，则是将包含框架在内的底层基础设施，标准化，向上抽象为了平台服务，开发者开发的时候，不需要关心框架的实现，使用平台服务来发布，管控服务。
微服务框架提供了什么
当从单体应用，拆分为微服务之后，需要配套的基础能力，来支撑整个微服务架构。
比如：
- rpc 框架，来完成服务之间的调用
- 注册中心，用于注册和发现服务
- 配置中心，用于提供中心化的配置能力
- 限流组件，用于保护服务的稳定性
- API 网关，用于对外暴露服务接口
诸如此类，在微服务体系下，相对通用的能力，都可以抽象为一个组件，通过 sdk/接口的方式，让开发者来集成/对接。
比如，对于分布式事务场景的业务，还可以使用分布式事务组件，来简化业务代码的编写。
给开发者的体感，比较接近于单体应用时期的开发框架，比如 PHP 的 Laravel/CodeIgniter。
云原生的变化
云原生是微服务之后的进一步演进，一开始，大家体感比较多的是，向下抽象了硬件资源，微服务不需要部署在物理机上，而是打包成镜像，部署在 pod 里面了；并且，开发者只需要通过 deployment 申明最终的部署形态，k8s 来负责自动完成部署，这是一个很好的向下抽象模型。
另外，我觉得云原生还有一层，它也在向上抽象，将微服务框架的能力进行标准化，基础能力被抽象为标准的模型，最终以申明式的资源形式，暴露给开发者。
效果就是，应用，作为云原生时代的基本单元，所需要的能力模型，愈加的完善，标准。
我们可以通过 deployment 为应用部署，通过 service 来暴露服务，通过 configmap 来申明配置，通过 ingress/k8s gateway api 来构建对外的服务。
标准化，是云原生的一个重要特征，标准化之后，开发者不再需要集成/对接开发框架，在开发应用的时候，可以简单的依赖标准化的能力，减少了一些对接的工作。因为开发框架，通常是跟实现强相关的，不同的框架，实现和能力会有差异。
协作关系的变化
由此，带来了更深层的是变化，是协作关系的变化。
之前写过一篇，云原生是一场协作关系变革，那里重点讲述的是开发者和基础平台的协作关系。
今天，想聊聊另外一个协作关系，是基础平台各个组件的协作关系。
以前各个基础组件，是相对独立的发展思路，只有部分强相关的组件，会有协作关系，比如注册中心和 rpc 框架，协作的实现，也比较依赖于两个组件的对接实现，比如通过接口调用。
当这些组件，都被抽象为标准化资源之后，那么协作关系就变得简单了，可以不依赖接口调用，可以直接在申明式资源上，进行协作。
此时，k8s 的 api server 就成为了一个集中式数据库，各个组件，可以通过一套统一的 watch api，来监听资源的变化，从而实现协作，这也是 k8s 作为基础平台的价值。
举一个简单的例子，当应用扩容的时候，api 网关可以监听到新的 pod 产生，从而更新路由规则，将流量导入到新的 pod 上。
当然，这种协作方式，也有其局限性，至少目前看起来，k8s api server 这个集中式数据库，由于承接了很多组件资源的写入，变更，订阅，所以会有比较大的性能压力，目前的 k8s 单集群规模是受限的，常见是，5000 个节点，100000 个 pod。
最后
当前云原生还是一个发展期，标准化的能力还在不断完善，从我个人的体感来看，向下抽象的能力，相对比较完善了，向上抽象的能力，还有很大的提升空间。
当能力完善之后，应用开发者的体验会更好，应用开发可以更好的发展；基础平台的开发，反倒会进入一个稳态。
不过呢，基础平台也还会继续向上抽象，比如 FaaS。相对于 PaaS 时期，应用作为基本单元，FaaS 的抽象粒度更细，函数作为了基本单元，向上包装了更多的基础能力。向上抽象，估计就是基础平台一直可以吃的饼。