1.云原生技术
1.1 云原生
云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。
云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。
1.2 容器
容器镜像是一个软件的轻量级独立可执行软件包，包含运行它所需的一切：代码，运行时，系统工具，系统库，配置。
1.3 微服务
微服务架构是一种架构模式它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通(通常是基于HTTP的RESTfuIAPI)。每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。（--摘自马丁.福勒先生的博客）
微服务的本质是分工与协作。
1.4 云原生应用的理论——十二要素
- 基准代码：一份基准代码，多份部署。基准代码和应用之间总是保持一一对应的关系。所有部署的基准代码相同，但每份部署可以使用其不同的版本。
- 依赖：显示声明依赖关系。应用程序一定通过依赖清单，确切地声明所有依赖项。
- 配置：在环境中存储配置。将应用的配置存储于环境变量中。环境变量可以非常方便地在不同的部署间做修改，却不动一行代码。
- 后端服务：不区分本地和远端服务。不要把服务打包在应用中，通过绑定或是DNS寻址。
- 构建、发布、运行：严格区分构建、发布、运行这三个步骤，不要在运行中去改配置。
- 进程无状态：应用的进程必须无状态且无共享，任何需要持久化的数据都要存储在后端服务内，比如数据库。Session中的数据应该保存在诸如Memcached或Redis这样的带有过期时间的缓存中。
- 端口绑定：通过端口绑定提供服务。应用完全自我加载而不依赖于任何网络服务器就可以创建一个面向网络的服务。
- 并发：通过进程模型进行扩展，开发人员可以运用这个模型去设计应用架构，将不同的工作分配给不同的进程类型，每个进程均可以并发，可以弹性伸缩。
- 易销毁性：快速启动和优雅终止可最大化健壮性。应用的进程是可销毁的，意思是说它们可以瞬间开启或停止。
- 开发环境与线上环境等价：尽可能保持开发、预发布、线上环境相同。应用想要做到持续部署就必须缩小本地与线上差异。
- 日志：把日志当作事件流。应用本身考虑存储自己的输出流。不应该试图去写或者管理日志文件。
- 管理进程：基于某个发布版本运行。后台管理代码应该随其他应用程序代码一起发布。
2.应用系统上云路径
应用系统上云可分为三种路径：云原生方式、云原生+虚拟机方式、虚拟机方式。
云原生方式下，数据库上云和文件存储上云，应用程序容器化部署。应用程序满足云原生技术要求，具备无状态化、微服务、前后端分离技术特点，建议采用云原生方式上云 。
云原生+虚拟机方式下，数据库上云和文件上云，应用程序采取虚拟机方式。应用程序无法改造，不满足云原生技术要求，但文件系统或数据库可以迁移到云上。
虚拟机方式下，应用系统、数据库、文件存储均采用传统的虚拟机方式部署。应用系统的程序、文件存储、数据库无法按照云原生架构进行改造 。
2.1 路径一：云原生
适用场景：新研发的应用系统，或者可以按照云原生架构改造的应用系统。
应用系统采用微服务架构、前后端分离架构，天然满足云原生架构，应用程序、数据库、文件存储全部云部署，是彻底的云原生应用。
优点：
- 应用系统真正云原生化，可充分利用k8s的弹性伸缩、负载均衡、滚动更新等技术
- 数据和文件云化，去烟囱式数据库，省去安装部署工作，可利用海量数据存储、高可用的云特性
缺点：
- 存量系统改造工作量大
2.2 路径二：云原生+虚拟机
适用场景：对于存量应用系统，应用程序无法云原生改造，数据库采用oracle或mysql的可以迁移上云。
这是一种混合方式上云，是一种折中方案，优先考虑数据库和文件存储上云，应用程序采取虚拟机方式，为下一步全部云化打下基础。
优点：
- 存量系统无需改造或少量改造，实现局部迁移上云
- 数据和文件云化，去烟囱式数据库，可利用海量数据存储、高可用的云特性
缺点：
- 应用程序使用传统虚拟机方式上云，不是真正的云原生，无法轻量化弹性伸缩、滚动更新
2.3 路径三：虚拟机
适用场景：对于存量应用系统，应用程序、数据库、文件存储均无法云原生改造的，或者不适合上云的。
应用系统的应用程序、文件存储、数据库均使用传统虚拟机方式上云。
优点：
- 存量系统无需改造，对于业务应用保证一致性，没有迁移云的工作量和风险
缺点：
- 无法利用云的弹性伸缩、分布式存储、服务高可用的优势
