Go语言云原生与微服务（一）云原生架构

Hello，我是普通Gopher，00后男孩，极致的共享主义者，想要成为一个终身学习者。专注于做最通俗易懂的计算机基础知识类公众号。每天推送Golang技术干货，内容起于K8S而不止于K8S，涉及Docker、微服务、DevOps、数据库、虚拟化等云计算内容及SRE经验总结
=======================
初次见面，我为你准备了100G学习大礼包：
1、《百余本最新计算机电子图书》
2、《30G Golang学习视频》
3、《20G Java学习视频》
4、《90G Liunx高级学习视频》
5、《10G 算法（含蓝桥杯真题）学习视频》
6、《英语四级，周杰伦歌曲免费送！》
路过麻烦动动小手，点个关注，持续更新技术文章与资料！
本人在学习云原生与微服务架构中的总结资料，参考书籍《Go语言高并发与微服务实战》
仅以此文记录学习过程。
云原生架构之前（即传统飞云原生应用），底层平台负责向上提供运行资源，而应用需要满足业务需求和非业务需求。为了更好地使代码复用，通用性好的非业务需求的实现，往往会以类库和开发框架的方式提供。在SoA、 微服务时代，部分功能会以后端服务的方式存在，在应用中被简化为对其客户端的调用代码，然后应用将这些功能连同自身的业务实现代码一起打包。而云的出现，可以在提供各种资源之外，还提供各种能力(如基础设施，以及基础设施的中间件等)，从而帮助应用，使得应用可以专注于业务需求的实现。随着云原生技术理念在行业内进一步实践发展，云原生架构完成了IT架构在云计算时代的进化升级。以CI/CD、DevOps和微服务架构为代表的云原生技术，以其高效稳定、快速响应的特点引领企业的业务发展，帮助企业构建更加适用于云上的应用服务。对企业而言,新旧IT架构的转型与企业数字化的迫切需求也为云原生技术提供了很好的契机，云原生技术在行业的应用持续深化。

1.1 云计算的历史

云计算的发展分为三个阶段：虚拟化的出现、虚拟化在云计算中的应用以及容器化的出现。云计算目前在高速发展。

1.1.1 云计算的基础：虚拟化技术

云计算的历史事实上需要追溯到60多年前的计算机远古历史：

1955年，John McCarthy（备注：John McCarthy是Artificial Intelligence/人工智能一词的提出者）创造了一种在用户群中共享计算时间的理论。

1959年6月，在国际信息处理大会上克里斯托弗Christopher Strachey发表了《Time Sharing in Large Fast Computer》论文，提出了虚拟化概念。该文被公认为虚拟化技术的最早论述。

1965年8月，IBM推出System/360 Model 67 和 TSS 分时共享系统（Time Sharing System），通过虚拟机监视器（Virtual Machine Monitor）虚拟所有的硬件接口，允许多个用户共享同一高性能计算设备的使用时间，也就是最原始的虚拟机技术。

在20世纪60年代中期，美国计算机科学家 JCR Licklider 提出计算机互联系统(an interconnected system of computers)的想法。

1969年，在 JCR Licklider 的革命性创意的帮助下，Bob Taylor 和 Larry Roberts 开发了互联网的前身 ARPANET（Advanced Research Projects Agency Network），允许不同物理位置的计算机进行网络连接和资源共享。

1972年，IBM发布了名为VM（Virtual Machine）的操作系统。在90年代，虚拟机的使用开始流行

1974年，Popek和Goldberg发表了《Formal Requirements for Virtualizable Third Generation Architectures》提出了虚拟化准备的充分条件，指出满足条件的控制程序可以被称为虚拟机监视器Virtual Machine Monitor （VMM）：（1）一致性：一个运行于虚拟机上的程序，其行为应当与直接运行于物理机上的行为基本一致，只允许有细微的差异如系统时间方面；（2）可控性：VMM对系统资源有完全的控制能力和管理权限；（3）高效性：绝大部分的虚拟机指令应当由硬件直接执行而无需VMM的参与。

1978年，IBM获得了独立磁盘冗余阵列（Redundant Arrays of Independent Disks，RAID）概念的专利。该专利将物理设备组合为池，然后从池中切出一组逻辑单元号（Logical Unit Number，LUN）并将其提供给主机使用。虽然该技术直到1988年IBM才与加利福尼亚州立大学伯克利分校联合开发了第一个实用版本，但该专利第1次将虚拟化技术引入存储之中。

“Time-Sharing”的背景：自20世纪50年代，人类使用大型计算机系统来处理数据。而在早期，大型计算机体积庞大而且价格高昂。为了提高投资回报率，购买大型机的组织开始实施“分时调度（time-sharing）”，然后从没有处理能力的终端访问大型计算机。“分时”理论可以充分利用可用的计算时间，可以用于为无力购买自己的大型机的小公司提供计算时间。

这里便陆续出现了云计算的基本前提：共享计算能力和共享网络，并出现了虚拟机，虚拟网络和早期基础设施。

但是在2000年前后虚拟化技术成熟之前，市场处于物理机时代。当时如果要启用一个新的应用，需要购买一台或者一个机架的新服务器。

1.1.2 虚拟化技术成熟

在2000年前后，虚拟化技术逐渐发展成熟：

1998年，VMware成立并首次引入X86的虚拟技术，通过运行在Windows NT上的VMware来启动Windows 95。

1999年，VMWare推出可在X86平台上流畅运行的第一款VMware Workstation，从此虚拟化技术终于走下了大型机的神话。之后，研发人员和发烧友开始在普通PC和工作站上大量使用该虚拟化解决方案。

1999年，IEEE颁布了用以标准化VLAN实现方案的802.1Q协议标准草案，从而可以将大型网络划分为多个小网络，使得广播和组播流量不会占据更多带宽的问题；同时，可以利用VLAN标签提供更高的网络段间的安全性。

2000年，IEEE颁布了虚拟专用网（Virtual Private Network）VPN标准草案，从而使得私有网络可以跨公网进行建立。

2000年，Citrix桌面虚拟化产品正式发布。

2001年，VMware发布了第一个针对x86服务器的虚拟化产品ESX和GSX，即ESX-i的前身。

2003年10月，Xen虚拟化项目首次面世推出了1.0版本，此时仅支持半虚拟化Para-Virtualization。之后，基于Xen虚拟化解决方案陆续被Redhat、Novell和Sun等的Linux发行版集成，作为默认的虚拟化解决方案。

2003年，Microsoft收购Connectix获得虚拟化技术进入桌面虚拟化领域，之后很快推出了Virtual Server免费版。

2005年，Xen 3.0发布，该版本可以在32位服务器上运行，同时该版本开始正式支持Intel的VT技术和IA64架构，从而使得Xen虚拟机可以运行完全没有修改的操作系统。该版本是Xen真正意义上可用的版本。

2006年10月，以色列的创业公司Qumranet在完成了虚拟化Hypervisor基本功能、动态迁移以及主要的性能优化之后，正式对外宣布了KVM的诞生。同年10月，KVM模块的源代码被正式接纳进入Linux Kernel，成为内核源代码的一部分。备注：Qumranet在2008年被RedHat收购。

2009年4月，VMware推出业界首款云操作系统VMware vSphere。

云计算的重要里程碑之一是2001年VMWare带来的可用于X86的虚拟化计划。通过虚拟机，可以在同一台物理机器上运行多个虚拟机，这意味着可以降低服务器的数量，而且速度和弹性也远超物理机。

1.1.3 基于虚拟机的云计算

在虚拟化技术成熟之后，云计算市场才真正出现，此时基于虚拟机技术诞生了众多的云计算产品，也陆续出现了IaaS、PaaS等平台和公有云、私有云、混合云等形态：

2006年，AWS推出首批云产品Simple Storage Service (S3)和Elastic Compute Cloud（EC2），使企业可以利用AWS的基础设施构建自己的应用程序

2008年4月，Google App Engine发布，是 Google 管理的数据中心中用于 WEB 应用程序的开发和托管的平台。

2009年，Heroku 推出第一款公有云 PaaS （Platform-as-a-Service）

2010年1月，微软发布 Microsoft Azure云平台服务。备注：Microsoft Azure 于2008年宣布。

2010年7月，Rackspace Hosting和NASA联合推出了一项名为OpenStack的开源云软件计划

2011年，Pivotal推出了开源版PaaS Cloud Foundry，作为Heroku PaaS的开源替代品，并于2014年底推出了Cloud Foundry Foundation。

2013年底，Google 推出 Google Compute Engine （GCE）正式版。备注：GCE的测试版本于2008年发布，预览版于2012年发布。

2014年，AWS推出 Lambda，允许在AWS中运行代码而无需配置或管理服务器，即Faas/Serverless。
在这期间，出现了云计算的多个重要里程碑：

1. IaaS的出现：通过按时计费的方式租借服务器，将资本支出（Capex）转变为运营支出（Opex），这使得云计算得以大规模兴起和普及。
2. PaaS的出现
3. 开源IaaS的出现：云计算已经开始进入开源时代
4. 开源PaaS的出现
5. FaaS的出现

补充术语介绍，Capex Vs. Opex：
Capex = capital expenditure / 资本支出
Opex = operational expenditure / 运营支出

1.1.4 容器的兴起和编排大战

2013年，在云计算领域发生了一件影响深广的技术变革：容器。

容器技术可以说是过去十年间对软件开发行业改变最大的技术，而从虚拟机到容器，整个云计算市场发生了一次重大变革，甚至是洗牌。基于容器技术的容器编排市场，则经历了Mesos、Swarm、kubernetes三家的一场史诗大战，最终以kubernetes全面胜利而告终

2008年，LXC（Linux Container）容器发布，这是一种内核虚拟化技术，可以提供轻量级的虚拟化，以便隔离进程和资源。LXC是Docker最初使用的具体内核功能实现

2013年，Docker发布，组合LXC，Union File System和cgroups等Linux技术创建容器化标准，docker风靡一时，container逐步替代VM，云计算进入容器时代

2014年底，CoreOS正式发布了CoreOS的开源容器引擎Rocket（简称rkt）

2014年10月，Google 开源 kubernetes，并在2015年捐赠给 CNCF

2015年6月，OCI组织成立，旨在制定并维护容器镜像格式和容器运行时的正式规范，以便在不同的操作系统和平台之间移植

2015年7月，Google联合Linux基金会成立了CNCF组织，kubernetes 成为 CNCF 管理的首个开源项目

2015年，CNCF组织开始力推 Cloud Nativ ，完全基于开源软件技术栈，Cloud Native 的重要理念是：以微服务的方式部署应用，每个应用都打包为自己的容器并动态编排这些容器以优化资源利用

2017年9月，Mesos宣布了对Kubernetes的支持

2017年10月，Docker宣布将在下一版Docker，将同时支持自家调度引擎Swarm和来自Google的调度平台Kubernetes

2018年3月，Kubernetes 从 CNCF 毕业，成为 CNCF 第一个毕业项目

这里有两个重要的里程碑：

1. 2013年，Docker发布，容器逐步替代VM，云计算进入容器时代
2. 2017年底，Kubernetes 赢得容器编排的胜利，云计算进入 Kubernetes 时代
   在容器编排大战期间，以 kubernetes 为核心的CNCF Cloud Native生态系统也得以迅猛发展，云原生成为云计算市场的技术新热点。

1.1.5云计算演进总结

云计算的发展演进历史，有以下规律：

• 核心构建块的变化：

从早期的物理服务器，通过虚拟化技术演进为虚拟机，再摆脱机器的限制缩小为构建块，最后通过容器化技术演进为目前的container

• 隔离单元：无论是启动时间还是单元大小，物理机、虚拟机、容器一路走来，实现了从重量级到轻量级的转变

• 供应商：从闭源到开源，从单一供应商到跨越多个供应商

下图形象的概述了这二十年云计算的演进过程：从传统预制IT、托管到云，以及云的不同形态如IaaS、PaaS、SaaS等。

对于XaaS的一路演进，可以简单归纳为：

• 有了IaaS，客户不用关注物理机器
• 有了PaaS，客户不用关注操作系统
• 有了FaaS，客户不用关注应用程序

在这过去的二十年间，云计算几乎重新定义了整个行业的格局，越来越多的企业开始降低对IT基础设施的直接资本投入，不再倾向于维护自建的数据中心，而是开始通过上云的方式来获取更强大的计算、存储能力，并实现按时按需付费。这不仅仅降低IT支出，同时也降低了整个行业的技术壁垒，使得更多的公司尤其是初创公司可以更快地实践业务想法并迅速推送到市场。

1.2 云原生是什么

云原生是云计算的下半场，是否上云已经很少被提及，因为它已经成为一个热门话题，渗透到各行各业。进入到2017年之后，云计算已经不再是“新兴行业”了，换句话说，对于企业用户来说，云云计算技术成为企业发展“战术”的一部分了。

近几年，云原生火了起来，云元原生词已经被过度消费，很多软件都号称是云原生，云原生本身甚至不能称为是一种架构， 它首先是一种基础设施，运行在其上的应用称作云原生应用，只有符合云原生设计哲学的应用架构才叫云原生应用架构。在了解关于云历生的具体定义之前，我们首先介绍下云原生出现的背景和背后的诉求。

1.2.1 云原生出现的背景

移动互联网时代是业务高速发展的时期，不同于传统的应用，移动互联网提供了新的用户体验，即以移动端为中心，通过软件对各行各业的渗透和对世界的改变。移动互联网时代巨大的用户基数下快速变更和不断创新的需求对软件开发方式带来的巨大推动力，传统软件开发方式受到巨大挑战。面对业务的快速迭代，团队规模不断扩大降低沟通协作成本并加快产品的交付速度，为用户呈现更好的体验是各个互联网公司都在努力的方向。

这样的背景下，微服务和云原生的概念开始流行。康威定律是微服务架构的理论基础组织沟通的方式会在系统设计上有所表达，通过服务的拆分，每个小团队服务一个服务，增加了内聚性，减少了频繁的开会，提高了沟通效率；快速交付意味着更新的频次也高了，更新也容易造成服务的故障问题，更新与高可用之间需要权衡。云原生通过工具和方法减少更新导致的故障问题，保证服务的高可用。

企业在数字化转型中 普遍面临IT系统架构缺乏弹性，业务交付周期长，运维效率低，高可靠性低等痛点和挑战。将软件迁移到云上是应对这一挑战的 自然演化方式，在过去二十年间，从物理机到虚拟机到容器，从IaaS诞生到PaaS、SaaS、 Faas一路演进，应用的构建和部署变得越来越轻，越来越快，而底层基础设施和平台则越来越强大，以不同形态的云对，上层应用提供强力支撑。所以企业可以通过云原生的一系列技术，例如基于容器的敏捷基础设施、微服务架构等解决企业面临的这些IT痛点。

1.2.2 云原生的定义

自从云原生提出以来，云原生的定义就一直在持续地更新。这也说明了云原生的候念随着技术的发展而不断地被深刻认知。

Pivotal是云原生应用的提出者，并推出了Pivotal Cloud Foundry 云原生应用平合有Spring开源Java开发框架，成为云原生应用架构中的先驱者和探路者。早在2015年，Pivotal公司的Matt Stine写了一本叫做(迁移到云原生应用架构》的小册子，其中探讨云原生应用架构的几个主要特征：符合12因素应用、面向微服务架构、敏捷架构、基于API的协作和抗脆弱性。而在Pivotal 的官方网站上，对云原生(Cloud Native)的介绍包括4个要点，包括: DevOps、 持续集成、微服务架构和容器化。

• DevOps
• Continuous Delivery
• Microservices
• Containers
  2015年CNCF建立，开始围绕云原生的概念打造云原生生态体系，起初CNCF对云原生的定义包含以下三个方面：

（1）应用容器化(software stack to be Containerized)
（2）面向微服务架构(Microservices oriented)
（3）应用支持容器的编排调度(Dynamically Orchestrated)

云原生包含了一组应用的模式，用于帮助企业快速，持续，可靠，规模化地交付业务软件。云原生由微服务架构，DevOps 和以容器为代表的敏捷基础架构组成。援引宋净超同学的一张图片来描述云原生所需要的能力与特征：

在2018年，随着社区对云原生理念的广泛认可和云原生生态的不断扩大，还有CNCF项目和会员的大量增加，起初的定义已经不再适用，因此CNCF对云原生进行了重新定位。

2018年6月，CNCF正式对外公布了更新之后的云原生的定义（包含中文版本）v1.0版本：
Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.
云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。
These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.
这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。
The Cloud Native Computing Foundation seeks to drive adoption of this paradigm by fostering and sustaining an ecosystem of open source, vendor-neutral projects. We democratize state-of-the-art patterns to make these innovations accessible for everyone.

云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。

新的定义中，继续保持原有的核心内容：容器和微服务，但是非常特别的将服务网格单独列出来，而不是将服务网格作为微服务的一个子项或者实现模式，体现了云原生中服务网格这一个新生技术的重要性。而不可变基础设施和声明式API这两个设计指导理念的加入，则强调了这两个概念对云原生架构的影响和对未来发展的指导作用。

可以通过访问 https://github.com/cncf/toc/blob/master/DEFINITION.md 查看。

1.2.3 云原生定义之外

从上面可以看到，云原生的内容和具体形式随着时间的推移一直在变化，即便是CNCF最新推出的云原生定义也非常明确的标注为v1.0，相信未来我们很有机会看到v1.1、v2版本。而且云原生这个词汇最近被过度使用，混有各种营销色彩，容易发生偏离。因此，云原生的定义是什么并不重要，关键还是云原生定义后面的理念、文化、技术、工具、组织结构和行为方式。

Joe Beda，Heptio 的CTO，指出：

There is no hard and fast definition for what Cloud Native means. In fact there are other overlapping terms and ideologies. At its root, Cloud Native is structuring teams, culture and technology to utilize automation and architectures to manage complexity and unlock velocity.
Cloud Native并没有硬性和牢靠的定义。实际上，还有其他重叠的术语和意识形态。从根本上说，Cloud Native正在构建团队，文化和技术，以利用自动化和架构来管理复杂性和解锁速度。
We are still at the beginning of this journey.
我们还处在这个旅程的开始阶段。
Christian Posta 指出：
“Cloud native” is an adjective that describes the applications, architectures, platforms/infrastructure, and processes, that together make it economical to work in a way that allows us to improve our ability to quickly respond to change and reduce unpredictability. This includes things like services architectures, self-service infrastructure, automation, continuous integration/delivery pipelines, observability tools, freedom/responsibility to experiment, teams held to outcomes not output, etc.

“云原生”是一个形容词，用于描述应用，结构，平台/基础设施和流程，这些共同促使我们以比较经济的工作方式来提高能力，实现快速响应变化和减少不可预测性。包括服务架构，自助服务基础设施，自动化，持续集成/交付管道，可观察性工具，实验的自由/责任，坚持结果而不是产出的团队等。

1.2.4 云原生和12因素

介绍

12-Factors 经常被翻译为12因素，符合12因素的应用则称为12因素应用。

背景

Heroku（HeroKu于2009年推出公有云PaaS）于2012年提出12因素，告诉开发者如何利用云平台提供的便利来开发更具可靠性和扩展性、更加易于维护的云原生应用。

为此还有一个专门的12因素网站： https://12factor.net/ ，以及这个网站内容的中文版本： https://12factor.net/zh_cn/ 。

援引12因素网站的介绍内容：

如今，软件通常会作为服务来交付，被称为web app，或软件即服务（SaaS）。12-Factor 为构建如下的 SaaS 应用提供了方法论：

• 使用声明式格式来搭建自动化，从而使新的开发者花费最少的学习成本加入这个项目
• 和底层操作系统保持简洁的契约，在各个系统中提供最大的可移植性
• 适合在现代的云平台上部署，避免对服务器和系统管理的额外需求
• 最小化开发和生产之间的分歧，实现持续部署以实现最大灵活性
• 可以在工具、架构和开发实践不发生重大变化的前提下实现扩展
• 12因素理论适用于以任意语言编写，并使用任意后端服务（数据库、消息队列、缓存等）的应用程序。

援引12因素网站的给出的12因素产生的背景：

本文的贡献者参与过数以百计的应用程序的开发和部署，并通过 Heroku 平台间接见证了数十万应用程序的开发，运作以及扩展的过程。
本文综合了我们关于 SaaS 应用几乎所有的经验和智慧，是开发此类应用的理想实践标准，并特别关注于应用程序如何保持良性成长，开发者之间如何进行有效的代码协作，以及如何 避免软件污染 。
我们的初衷是分享在现代软件开发过程中发现的一些系统性问题，并加深对这些问题的认识。我们提供了讨论这些问题时所需的共享词汇，同时使用相关术语给出一套针对这些问题的广义解决方案。

12因素的局限性

12因素创作于2012年左右，SaaS平台非常具有指导意义

12-factor为Web应用程序或SaaS平台的建立非常有用的指导原则，但它在有些地方并不适合微服务体系。

在标准的12个要素以外，还存在哪些因素， 正如Kevin Hoffmann 最近在 O’Reilly 出版的书上提到了超越 12 个因素的应用。

内容

12因素具体内容为：

Factor	描述
Codebase 基准代码	One codebase tracked in revision control, many deploys 一份基准代码，多份部署
Dependencies 依赖	Explicitly declare and isolate dependencies 显式声明依赖关系
Config 配置	Store config in the environment 在环境中存储配置
Backing services 后端服务	Treat backing services as attached resources 把后端服务当作附加资源
Build, release, run 构建，发布，运行	Strictly separate build and run stages 严格分离构建和运行
Processes 进程	Execute the app as one or more stateless processes 以一个或多个无状态进程运行应用
Port binding 端口绑定	Export services via port binding 通过端口绑定提供服务
Concurrency 并发	Scale out via the process model 通过进程模型进行扩展
Disposability 易处理	Maximize robustness with fast startup and graceful shutdown 快速启动和优雅终止可最大化健壮性
Dev/prod parity 开发环境与线上环境等价	Keep development, staging, and production as similar as possible 尽可能的保持开发，预发布，线上环境相同
Logs 日志	Treat logs as event streams 把日志当作事件流
Admin processes 管理进程	Run admin/management tasks as one-off processes 后台管理任务当作一次性进程运行

12因素在云原生架构中的体现：

1.3 云原生的基础架构

云原生是一系列云计算技术体系和企业管理方法的集合，既包含了实现应用云原生化的方法论，也包含了落地实践的关键技术。云原生应用利用微服务、服务网格、容器、DevOps和声明式API等代表性技术，来构建容错性好、易于管理和便于观察的松耦合系统。下面具体介绍这几个关键技术。

1.3.1微服务

为了解决单体的复杂度问题，我们引入微服务架构。在单体应用(也称为巨石应用)的时代，虽然开发简单，但随着业务复杂度的提升，单体应用的益处逐渐减少。它们变得更难理解，而且失去了敏捷性，因为开发人员很难快速理解和修改代码。

对付复杂性的最好方法之一是将明确定义的功能分成更小的服务，并让每个服务独立迭代。微服务是指将大型复杂软件应用拆分成多个简单应用，每个简单应用描述着一个小业务，系统中的各个简单应用可被独立部署。各个微微服务之问是松耦合的，这样就可以独立地对每个服务进行升级、部署、扩展和重新启动等，从而实现频繁更新而不会对最终用户产生任何影响。相比传统的单体架构，微服务架构具有降低系统复杂度、独立部署、独立扩展和跨语言编程等优点。

但是，从另一个角度来看，微服务架构的灵话、开发的敏捷也带来了运维的挑战和分布式系统的复杂性。单体应用可能只需部署至小片应用服务器集群， 而微服务架构则需要构建/测试/部署/运行数十个独立的服务，并可能需要支持多种语言和环境；微服务还引入了分布式系统的复杂性，如网络延迟、容错性、消息序列化、不可靠的网络、异步机制、版本化和差异化的工作负载等，开发人员需要考虑以上这些分布式系统问题。其他的问题，如微服务的可测试性、异步机制、调用链过长等，也需要在架构设计时考虑。

1.3.2 容器

为了解决微服务架构下大量应用部署的问题，我们引入容器，容器是一种轻量级的虚报化技术，能够在单一主机上提供多个隔离的操作系统环境， 通过系列的Namespace进行进程隔离，每个容器都有唯一的可写文件系统和资源配额， 容器技术分为运行时和编持两层，运行时负责容器的计算、存储、网络等，编排层负责容器集群的调度、服务发现和资源管理。

容器服务提供高性能、 可伸缩的容器应用管理能力，容器化应用的生命周期管理可以提供多种应用发布方式。容器服务简化了容器管理集群的搭建工作，整合了调度、配置、存储、网络等，打造云端最佳容器运行环境。

Docker是一个开源的应用容器引擎，使用容器技术，用户可以将微服务及其所需的所有配置、依赖关系和环境变量打包成容器镜像，轻松移植到全新的服务器节点上，而无得重新配置环境，这使得容器成为部署单个微服务的最理想工具。

仅仅有容器还是不够的，因为人力运维部署成本太大，为了解决容器的管理和调度问题，又引入了Kubernetes. Kubernetes 是Google 开源的容器集群管理系统，可以实现容器集群的自动化部署、自动扩缩容和维护等功能。

我们用Kubernetes去管理Docker集群，可以将Docker看成Kubernetes内部使用的低级别组件。另外，Kubermetes 不仅仅支持Docker,还支持Rocket等其他容器技术。

1.3.3 服务网格

微服务技术架构实践中主要有侵入式架构和非侵入式架构两种实现形式。侵入式架构是指服务框架嵌入程序代码，开发者组合各种组件，如RPC、负载均衡、熔断等，实现微服务架构。非侵入式架构则是以代理的形式，与应用程序部署在一起，接管应用程序的网络且对其透明，开发者只需要关注自身业务即可，以服务网格为代表。为了解决微服务框架的侵入性问题，引入Service Mesh。

Service Mesh 产品的存在和具体工作模式，对于运行于其上的云原生应用来说是透明无感知的，但是在运行时这些能力都动态赋能给了应用，从而帮助应用在轻量化的同时依然可以继续提供原有的功能。

Service Mesh 使得系统架构的技术栈下移，降低了整个微服务入门的门槛，对于开发者更加友好。Service Mesh提供了一一个方案，就是将整个服务间通信的解决方式以及整个中间件层的技术栈全部下移。从应用当中下移到底层的基础设施，通过加强基础设施的方式提供一个统一的解决方案。

Serice Mesh处理服务问请求响应的可靠传递，并可用于服务治理、遗留系统的零侵入接入以及异构框架开发的微服务。Service Mesh作为服务间通信的基础设施层，是应用程序间通信的中间层，实现了轻量级网络代理，对应用程序透明，解隅了应用程序的重试/超时、监控、追踪和服务发现。

除此之外，Serice Mesh提供了专业化的解决方案，其中所涉及的服务通信、容错、认证等功能，都是专业度极高的领城，这些领城应该出现工业级成熟度的制成品，这对于中小企业来说是一个降低成本的选择。

Service Mesh的开源软件包括Istio、Linkerd、 Envoy、 Dubbo Mesh等。同时，为了让Service Mesh有更好的底层支撑，我们又将Service Mesh运行在Kubernetes上，

1.3.4 DevOps

DevOps是一组过程、方法与系统的统称，用于促进开发(应用程序/软件工程)、术运营和质量保障(QA)部门之间的沟通、协作与整合。目前对DevOps 有太多的说法和定义，不过它们都有一个共同的思想:解决开发者与运维者之间曾经不可逾越的鸿沟，增强开发者与运维者之间的沟通和交流。

DevOps的出现是由于软件行业日益清晰地认识到:为了按时交付软件产品和服务，开发和运营工作必须紧密合作。市场瞬息万变，同时机会转瞬即逝。互联网公司要实现生存，必须拥有快速试错和迭代产品的能力。那我们有没有办法快速交付价值、灵活响应变化呢?答案就是DevOps, 它是面向业务目标，助力业务成功的最佳实践。DevOps其实包含了三个部分：开发、测试和运维。

与敏捷一样，DevOps将软件程序分解成更小的部分，以提高软件交付速度和质量。DevOp的一个标志是“持续”实践包括持续集成、持续测试、持续交付和持续部署，所有这些都有助于软件产品和软件相关实践的持续改进.DevOps的目标是缩短开发周期，增加部署频率，更可靠的发布。用户可通过完整的工具链，深度集成代码仓库、制品仓库、项目管理、自动化测试等类别中的主流工具，实现零成本迁移，快速实践DevOps.DevOps帮助开发者和运维人员打造了一个全新空间，构建了一种通过持续交付实践去优化资源和扩展应用程序的新方式微服务使DevOps团队能够并行开发独立的功能片段，跨功能团队协作构建、测试、发布、监控和维护应用程序。DevOps 和云原生架构的结合能够实现精益产品开发流程，适应快速变化的市场，更好地服务企业的商业目的。

1.4 总结

本文从云原生的发展史开始介绍云计算、虚报化、容器化等技术，随后结合云原生出现的背景介绍云原生的定义。云原生的定义也在不断变化，总得说来，云原生可以理解为应用原生被设计为在云上以最佳方式运行，充分发挥云的优势。最后介绍了云原生架构中涉及到的几个关键技术。

云原生应用可充分利用云平台服务优势，并快速构建部署到平台上，平台提供了简单快捷的扩展能力并与硬件解耦，提供了更大的灵活性、弹性和跨云环境的可移植性。云原生将云计算作为竞争优势，原生云意味着将云目标从IT成本节约转向业务增长引擎。

参考链接：https://skyao.io/learning-cloudnative/microservice/