云原生是基于分布部署和统一运管的分布式云，以容器、微服务、DevOps等技术为基础建立的一套体系，云原生是云计算未来的发展方向，会逐步取代传统的本地开发应用。
云原生与数据中心密切相关。
数据中心的发展经历了三个阶段：
第一阶段：业务模式主要为场地出租，为客户提供服务器托管服务。在这个阶段的软件架构以单体架构软件为主
第二阶段：业务模式为提供场地、存储、以及互联网接入服务，为客户提供服务器托管和虚拟主机出租服务。在第二阶段的软件架构主要是分布式架构
第三阶段：业务模式为提供计算、存储、网络服务，提供可动态调度的算力服务。此阶段的软件架构发展到了微服务架构和容器化架构
数据中心各阶段的业务模式
第一阶段：提供场地与服务器托管、互联网接入服务
第二阶段：提供虚拟主机出租服务，基于类似vmware workstation的虚拟化软件
第三阶段：提供云平台服务包括云主机，容器云等，主要服务商有亚马逊，阿里云，华为云，天翼云等
软件架构
软件架构的发展过程微单体架构==>分布式架构==>微服务架构==>容器化架构
1、单体软件架构
全部功能打包在一个 WAR包里，部署在Tomcat等web运行环境中。
优点：
（1）开发简单，集中式管理
（2）功能都在本地，没有分布式的管理和调用消耗
缺点：
（1）效率低：开发都在同一个项目改代码，相互等待，冲突不断
（2）维护难：代码功能耦合在一起，新人不知道何从下手
（3）不灵活：构建时间长，任何小修改都要重构整个项目，耗时
（4）稳定性差：一个微小的问题，都可能导致整个应用挂掉
（5）扩展性不够：无法满足高并发下的业务需求
下面以电商平台为例，介绍软件架构的发展历程
在电商的早期阶段，采用的是LAMP架构，用PHP作为网站开发语言， Linux作为操作系统，Apache作为Web服务器，MySQL为数据库，以达到快速上线的要求。
当用户规模越来越大时，单机架构性能遇到瓶颈，可以通过负载均衡器部署多套单体架构服务副本，手动的实现一定程度的伸缩性，同时也会带来会话共享等类似的问题。
随着业务的快速发展，单体应用部署多套副本的方式也难以满足性能要求，需要对服务进行进一步的拆分，演变成为分布式架构。
二、分布式架构
分布式架构对单体架构做了一定改进，它将单体中不同的业务模块进行了纵向和横向的拆分，各个模块单独部署专人维护，并可以通过网络进行通信。纵向拆分：一个大应用分成几个小应用，每个小应用单独部署横向拆分：可以复用的业务拆分出来独立部署，其他应用通过消息传递与其交互。
优点：
（1）流量分散，提高并发量
（2）伸缩性变强，比如针对A业务采用CPU密集型服务器，而针对B业务采用IO密集型的服务器
（3）可以针对某个应用单独优化，减少因为一个改动影响整个系统的可能
（4）不同的应用运行在各自的进程中，A应用内存耗尽不会导致B应用内存不足挂掉
缺点：
（1）网络跨进程通信，随着业务的发展，应用间网络调用会愈发频繁，而网络本身是不可靠的
（2）如果存在异构应用，则可能存在协议兼容问题
（3）服务之间访问，需要将地址硬编码在代码中，如果地址改变则调用方也需要手动修改
（4）应用拆分后数据是分散的，存在数据一致性问题（5）每个应用都是集群部署，负载均衡管理较难
面向服务的架构
随着软件架构越来越大，引出了面向服务的架构（SOA） ，将业务中可重复利用的部分拆分出来下沉到服务层，并提供对外接口，供其他业务方调用，调用方可以通过服务组合来完成业务的处理。SOA 架构有两种实现模式：
（1） 以企业服务总线（ESB）为代表的中心化模式。
（2）以RPC实现为主的去中心化模式。
服务总线模式
RPC模式
优点
（1）服务松散耦合，屏蔽服务调用细节
（2） 服务的可重用性高
（3）轻量级通信协议 REST/RPC
（4） 高可靠性，高可用性，高可扩展性
（5） 拥有服务治理能力
缺点
（1） 服务粒度不好掌握，易导致服务数量膨胀
（2）易产生分布式事务问题
（3） 服务调用链路变长，易产生连锁反应，造成服务不稳定
微服务架构
三、微服务架构
由于分布式架构服务之间管理的紊乱，以spring cloud为代表的微服务架构体系解决了这一个难题。微服务是一种通过多个小型服务的组合，来构建单个应用的架构风格，这些服务会围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言、不同的数据存储技术、运行在不同的进程之中。服务会采取轻量级的通讯机制和自动化的部署机制，来实现通讯与运维。
微服务架构带来的问题
（1）微服务架构整个应用分散成多个服务，定位故障点非常困难。
（2）稳定性下降。服务数量变多导致其中一个服务出现故障的概率增大，并且一个服务故障可能导致整个系统挂掉。事实上，在大访问量的生产场景下，故障总是会出现的。
（3） 服务数量非常多，部署、管理的工作量很大。
（4）开发方面：如何保证各个服务在持续开发的情况下仍然保持协同合作。
（5） 测试方面：服务拆分后，几乎所有功能都会涉及多个服务。原本单个程序的测试变为服务间调用的测试。测试变得更加复杂。
四、云原生架构
在开发微服务项目时，会面临一些必须要考虑的问题，比如服务注册与发现，服务追踪，服务路由，负载均衡等等。之前受限于硬件资源的限制我们不得不在应用层面上想法解决，近些年得益于容器技术的发展，尤其是在Kubernetes这类容器管理系统的出现后，使得上述问题可以从软件层面剥离出来，转变成虚拟的基础设施。让软件开发只专注于业务。真正实现了，弹性伸缩扩容。云原生技术有利于各组织在云环境中，构建和运行可弹性扩展的应用。容器开发人员使用容器将微服务与其依赖打包在一起。通过容器化微服务，云原生应用程序独立于底层操作系统和硬件运行。
容器化架构的弹性伸缩特性使得硬件资源利用率得到了大幅提升，以下是单体架构、分布式架构、微服务架构以及容器化架构资源利用率使用情况
基础设施与软件形态进化
