云原生代表服务

▶ 微服务

微服务的定义:原有单体应用拆分为多个独立自治的组件，每个组件都可以独立设计、开发、测试、部署和运维,这个组件可以单独提供对外服务,我们称之为微服务。

例如:早期的LNMT WEB部署架构，使用微服务后，每一个组件都可以独立自治、运行、扩容、缩容等

各组件之间可通过轻量的Restful风格接口进行交互和协同。

▶ docker容器

Docker容器，容器属于it基础设施层概念，是比虚拟机更轻量化的隔离工具，是微服务最佳载体。

▷ Kubernetes资源调度与容器编排

使用kubernetes的资源调度与容器编排，可以实现Docker容器更优管理，进一步实现其PaaS层能力。

▶ 服务网络

服务网格存在的目的,就是去中心化的服务治理框架。

以往需要对微服务或对api接口去做治理和管控，一般会用类似于ESB服务总线或API网关，将API接口注册和接入到API网关，由于API网关本身是一个中心化的架构，所以所有的请求流量都可以通过API网关，由API网关实现对流星拦截，同时对拦截以后的流是进行安全，日志，限流熔断，链路监控等各种管控治理，去中心化以后就没有这种集中化的流呈管控点了，所以对流量的拦截就从ESB服务总线或API网关下沉到各个微服务中去了，这就是为什么我们需要在微服务端增加一个代理包的原因，通过这个代理包来做流量的拦截，同时实现对流呈的管控，当前在微服务网格中也是用同样的思路来对服务进行治理的。例如: istio服务治理，它会在微服务应用中添加一个边车容器(Envoy)来实现流量的拦截和管控。这个属于微服务服务网格治理的核心技术。

去中心化的服务治理依然有一个控制中心，而控制中心依然是中心化的，但实际的控制流和接口数据访问的消息流是实现分离的，控制中心仅处理服务注册发现，实际的接口调用、服务访问是不通过控制中心的，即使控制中心出现问题，例如控制中心服务不可用等，也不会影响实际服务接口调用。

▶ 不可变基础设施

传统开发过程中，做一个软件程序的部署，当它部署到一个生产环境，如果我们要做变更，不管是程序的变更还是配置的变更，都需要在原来的生产环境上面重新部署或对某一个配置直接进行修改，但是在云原生应用中，任何一个应用当你部署到生产环境中，形成一个容器实例以后，这个容器实例不应该再做任何变化，如果软件程序需要重新部署或修改配置时怎么办呢?可以利用基础容器镜像，重新生成一个新的容器实例，同时把旧的容器实例销毁掉,这个就是云原生技术中要求的不可变技术点。

申明式API

应用部署大体上分为两种执行方式：命令式和声明式。

• 命令式
  • 在命令行执行命令创建容器。
• 声明式
  • 使用yaml资源清单文件。
  • 在yaml文件中声明要做的操作、需要的配置信息有哪些、用户期望达到的状态。

IT基础设施获取声明式文件的后续操作

当IT基础设施获取到声明文件后，首先要解析声明式文件中声明的内容，再去后端做出相应的操作，操作完成后，把各个底层技术组件协调到应用需要的一个状态。

使用声明式APL，任何对生产环境、配置都不是操作一条命令来完成的，都需要先写声明，或配置文件，这些操作都可以纳入配置管理中进行集中管理,]这样有利于在生产环境出现问题时，能够快速了解前述操作，及对生产环境产生的影响，易于做版本回退、回滚等操作。

DevOps

借助于云原生相关技术，DevOps时代才真正地到来了。

• 实现开发、运维、测试协同全作
• 构建自动化发布管道，实现代码快速部署(测试环境、预发布环境、生产环境等)
• 频繁发布、快速交付、快速反馈、降低发布风险