云原生几个核心概念（21.12.30）

今天聊一下云原生一些核心技术概念。首先谈一下微服务，简单理解为服务的核心就是传统大的单体应用拆分成更小的组织或者模块，这个组建或模块就是为服务。这个拆分是一个纵向的拆分，需要做到枞底层的IT设施，到数据库，到应用中间件到软件程序部署包，都能够做到完全独立独立，可以从单独从需求、设计、开发、打包不熟完全独立，实现各微服务之间彻底的松耦合。同时各个微服务之间又能够通过轻量的HTTP REST接口进行交互和系统。因此，微服务的核心本质就两点，一是大的单体要拆小，二是拆小的微服务之间通过HTTP REST 接口进行交互。

Devops的核心可以理解为持续集成和持续交付。需要将软件生命周期过程中从需求开始到设计程序的开发，编译构建，打包部署，从测试环境到生产环境整个过程能够实现全部的自动化，这是Devops核心之一。同时基于Devops本身的发展， 又进一步和敏捷研发和自动化测试相关的一些最佳实践做了协同和集成，这是Devops另外一个核心内容。

接着是云原生的另外一个重要概念“容器云“。容器云有两个核心，一个是Docker容器，一个是Kurernetes的容器资源调度和编排。如果单纯谈Docker容器，他实际上还是一个Iaas资源层的内容，容器本身是比虚拟机更轻量化的一个资源隔离单位。简单来讲，虚拟机是独享具体的操作系统，但是容器本身是架在操作系统之上，多个容器可以共享同一个操作系统。这个是容器跟虚拟机最大的一个区别。也正是这个原因，容器本身的体积比虚拟机小。容器本身的创建、销毁、调度的速度也比传统的虚拟机更快，最是容器最大的特点。但是因为容器本身是Iaas层的内容，所以容器必须要结合Kurbenetes容器的资源调度和安排来向上层提供Paas层的服务能力。Kurbernetes也是当前主流的做容器编排的的技术。

另外还有三个比较核心的概念。

第一个是我们常说的服务网格，简单来将服务网格是一个去中心化的服务治理框架。原来我们需要对微服务，对API接口进行管控，我们会用ESB总线或API网关将API接口接入或注册到API网关。由于API网关本身是一个中心化的架构，所以所有的请求，流量都可以i通过API网关。此时，API网关就很容易对流量进行拦截，同时对拦截后的流量进行安全、日志、限流熔断、链路监控等各种管控治理能力。当在去中心化的架构下面就没有这种集中化流量管控点，所以对于流量的拦截，就从ESB总线或者API网关下沉到各个微服务里面了。这就是常说的需要在微服务端增加代理包，通过代理包做流量拦截，同时实现对流量的管控。当前在服务网格的微服务治理里面也是采用同样的思路。对应到开源的Istio微服务治理，你就可以看到他会在微服务端下放一个Envoy的边车代理，通过这个代理来实现流量拦截和管控，这个是服务网格下微服务治理的一个核心。去中心化的微服务治理仍然会有一个控制中心，控制中心仍然是中心化的，但实际的控制流和接口数据访问消息流本身实现了分离，控制流只关服务注册和发现。实际接口调用和服务访问不通过控制中心，同时即使控制中心宕机也不会影响业务服务的调用。

第二个概念是severless无服务器架构，这是一个比较难以理解的概念。简单来讲就是在云原生发展到后期，因为我们一直在强调云原生核心是实现从资源到服务不断向上抽象，在这个抽象的过程中你会发现，你越来越不会接触到底层的it基础设施，你只会接触到各种技术服务能力，所以这些技术和服务能力在severless里面就叫Baas，后段能力及服务，这是severless强调的很核心的一个点，我们彻底不接触底层资源，底层it基础设施，这是无服务器化强调的重点。

实际我们在云原生的时候在前调Paas能力，Paas服务平台，强调从资源层到服务层。SeverLess带来的另一个变化是，在传统云原生架构下面开发，我们基于Devops，基于微服务和容器开发一个应用的时候，我们仍然会选择一个开发框架，开发一个底层的基础平台。你仍然会涉及到应用时候的数据层、逻辑层，上层的展现，但到了severless无服务器架构后，开发框架，开发环境都需要抛弃，任何功能实现都是同构代码片段组合来实现功能。因此在severless里面对应到Faas层，及功能函数及服务。通过这样解释可以看到Severless只包含两个层面内容，一个Baas和Faas，当Baas能力足够完善后，我们的开发就只需要聚焦于函数和代码片段的编写。