云原生入门系列（背景和驱动力）

        做任何一件事，或者学习、应用一个领域的技术，莫过于先要想好阶段的目标和理解、学习它的意义是什么？解决了什么问题？ 

        这部分，就尝试来探讨下这个阶段需要理解并达成的目标以及践行云原生的意义在哪里。

1.历程

        任何阶段技术的出现，都会有一个基本背景作为起源，最初是从解决一些关键点的问题出发，逐渐的变成阶段的主流。技术领域沿着这条脉络，去尝试理解会更容易入门一些。

        这里尝试梳理一个非官方权威的演变阶段，来整理下云原生的基本脉络。

应用架构演变

1）商用IOE体系阶段

        这个不用说，在IT领域做的比较久的工程师们能理解，早期的电信、银行等领域的大型系统基本上都是老外企业提供的商用的产品搭建的，我们主要还是以开发业务级别的框架和代码为主。

        这里的IOE是一类昂贵的商用解决方案的代名词，商用的小型机、商用磁盘阵列存储、商用的Unix、商用的中间件、商用的数据库一系列的内容构建的系统。

        在这个阶段构建的系统，成本确实不低，所以这时候的构建的大型系统都是一些较大的行业去践行的事情。基本结构如下：

• 基础资源构筑，靠的是小型机、商用高端的存储、能力强劲的数据库（这个阶段主要几家美国的企业处于半垄断地位，相互竞争）
• 系统的分布式能力建设，依靠商用的中间级，那个时期商用的中间件研发投入也相对较大，所以基本上架设系统的核心体系都还是封闭的体系。

关注的问题：

• 成本高昂，一般中小型企业尤其是类似移动互联网前期的业务企业，都比较难以构建丰富的业务场景的系统，仅限于大企业应用。硬件的成本受限于商用小型机高昂的价格，软件成本受限于商用软件的授权费用，软件方面人员门槛等成本（成本）

• 基于这套体系构建的软件系统，稳定性相对高些，出问题的概率低，但是这些重要的基础设施其自身的维护相对昂贵、需要高成本的环境要求。稳定性相对高，但是成本也相对高昂，尤其应对更大规模的业务，所以基本聚焦在通信、金融等领域（稳定性）

• 基于这套体系，在构建的基础设施上，体系搭建的效率相对较低，每次容量的扩充，都对系统有较高要求的迁移或者割接升级，业务开发方面也难以快速的迭代，每次系统的升级都是规模性操作。（效率）

2）服务化单体（去IOE后的X86阶段）

        X86服务器很早也就诞生了，但是出于稳定、安全性等方面考虑没有大规模推广应用起来。根本原因还是网络化的分布式系统会因为网络等因素，导致在“差不多化”的体系中不够健壮、成熟、普及。（商用的产品搭建的分布式大型的系统成本还很高，这个后面也会说到上云考虑的成本、效率等问题）

        在后续的去除IOE的条件慢慢成熟后，最先去的就是小型机这个计算体系。在去小型机的路上，需要实现一套成本和稳定性都可控的分布式软件系统，这个阶段基本上都是要有相当投入，才可以做到，这个阶段自研和部分开源并存。 

• 这个阶段主要实现的是去除I，大规模启用X86服务器，随之而来的开源的Linux取代了商用Unix操作系统；

• X86化后，服务器数量增大，随着三层架构前后端解耦，引入负载均衡代理层（商用F5或者Nginx，Haproxy等）替换原先分布式中间件，实现分布式应用能力；

• 在原先重度依赖数据库的基础上增强了实时性，增加了缓存层，缓存领域也有很多自研和开源的实现出现，分层架构实现更清晰。

关注的问题：

• X86服务器算力不如小型机，迁移后的服务器数量成倍增加，增加运维的维护成本；另外自研相关分布式软件，拉高了投入门槛，增加了成本（这里机器本身的成本从小型机转变过来的同等的计算量会节省一部分，但是需要结合损耗比来看）。（成本）   

• X86服务器损坏率较高，因为相对廉价，因此具备冷备、热备等高可用能力要求增加，这部分也是非常考验投入保障稳定性要求的地方。（规模和稳定性）

• 机器分化成更小的计算单元，机器的规模就会增加很多，就开始需要开始管理这些机器，组合成共享的资源让应用在上面能够很快速的做部署和运行，提升效率。（效率）

3）服务化拆分（开源阶段）

        开源在整个应用架构的演变中让开发分布式应用变得普惠，在计算机语言不断高度抽象的进程中，开源盛行直接拉低了进入和应用分布式架构的门槛，承担着非常重要的角色。

• 原本存量的商用的中间件，技术框架等因为开源的盛行，尤其在国内的盛行，开始出现规模替代；

• 随着分布式技术栈从自研到开源的迁移，基本上奠定了大规模开发分布式应用的基础；

• 分布式应用开发变得简单，开源的生态繁荣，开源组合的系统变得更容易。

关注的问题：

• 尽管在资源层面从小型机到成本低下的x86架构，甚至虚拟化到容器进一步微化资源单元，但是成本随着应用规模、数据的规模随之提升，如何提升大规模资源共享情况下的利用率是逐渐需要解决的问题。（成本）

• 随着在线实时服务的不断增长，规模和稳定性的要求越来越高，双活、两地三中心、甚至多活成为线上业务必备能力，这些能力要求的同时都带来了应用和资源的规模增加，稳定性的要求越来越高。另外随着开源分布式技术栈规模运用，各种分布式集群化的要求也不断增长（规模和稳定性）

• 业务从需求到开发，部署上线的效率一直是企业的IT研发团队追求的主题，这个阶段如何构建一套从开发，应用构建到部署，发布，灰度等业务研发体系变得重要（效率）。

4）云计算的阶段

        从上面的演变过程，过去业务系统的开发和IT技术能力结合紧密，经常按照领域实现垂直建设（业务系统+专有IT技术能力）。随着企业关注的成本、效率、规模和稳定性支撑的深入，越来越需要把基础技术能力沉淀下来，让业务需求的开发和推出聚焦业务领域的软件开发工作。

        尤其在开源被普及化之后，搭建的每个IT能力部分都是服务化、分布式集群化的，更加需要相对统一的管理支撑体系。公有云和私有云就是在这样的背景下面，开始扩张的建设之路（云的概念很早提出，但是在最终被普及化的今天是需要一个漫长的过程）。

        催生了今天很多的云厂商商业模式，不管是企业自建的私有云还是提供专业服务的公有云，对于业务支撑体系来讲，“业务上云“成为核心的趋势和强烈的诉求。

2.意义

        那为什么要云原生呢？相信从上面企业级的业务支撑体系来看，基本上可以总结如下：

• 对于企业来讲，使用IT技术为业务支撑，赋能是数字化阶段的必然过程；企业在使用IT技术方面的考虑通常是上面尝试总结的那几个点：“成本、规模和稳定性、效率、安全等”

• 云是IT支撑演变到一定阶段的产物，是把上面演进过程中的通用、可复用的各种能力下沉下来，构筑可复用、按需的基础设施。（”业务上云“的架构其实就是云原生化的本质所在，就是业务应用建设，怎么有一套标准化的云上架构，更好的利用云上的核心能力，服务好业务，让业务开发不需要关注如下的特性，聚焦业务本身。）
  • 所有资源共享，追求极致的成本
  • 所有软件分布式化，追求更大规模，更稳定的环境
  • 所有软件部署、运维等自动化（追求高效率）
• 云原生是业界对这一切的思考，最终通过类似CNCF等这些组织沉淀和推广应用（代表集体的智慧）
• 在这个过程中，通过云原生技术使组织能够在“现代动态环境”中构建和运行可扩展的应用程序（这个现代运行环境当下指的是云或者其他不可变基础设施）

• 那么具体到当下的阶段，就是比如在公共、私有和混合云的环境下，构建容器、服务网格、微服务、不可变基础设施和声明性API就是实现云原生这种方法的例子。

        所以我们当下所谈的云原生的实践和应用，都是结合当前技术演变的基础之上，沉淀的一些最佳实践思路和技术构筑的一套支撑体系。这套技术体系中最核心的部分，就是围绕：容器化基础设施环境、微服务、服务网格等具体的标准化的开源技术栈。

3.目标

        理解了云原生的意义，​就能理解当下云原生架构的思路是建立在当前标准组织或者有影响力的组织（如CNCF）推行的标准化技术栈的体系基础之上的方法论实践。

        在当下的业务支撑体系，按照如下的技术演进思路进行组合。

• 结合容器和容器编排技术（Docker+k8s）构筑声明式架构的不可变基础设施，基础设施的标准化和灵活、稳定性对架设在异构的云环境中尤为重要；

• 结合云原生的相关服务网格、微服务相关的技术服务构筑标准化的业务架构，标准统一意味着成本、效率和稳定性的可控；

• 云原生的体系，随着标准组织在不断的扩充蓝图，覆盖到云上业务支撑的方方面面，同时结合敏捷化的Devops向开发者赋能。

        最终结合云原生的建设评估模型，来检验整个构筑的云原生支撑体系的成熟度。当然，我们IT支撑体系支撑的好不好，最终还是业务发展的情况来决定的，业务是最终企业运营聚焦的关键点。