暂无图片
暂无图片
暂无图片
暂无图片
暂无图片
首页 / 开源技术栈上的云原生之花

开源技术栈上的云原生之花

OpenTEKr 开源星系 2022-06-01
302


shi
我们可以为今天欢呼，但昨天并没有远去。
它还会在将来的某一天，张开血盆大口等着我们的路过。
也许，那就是宿命！

—— 以此纪念 SH 这一段疫情时光 


作者 | 狄安

May 31, 2022

3,235 字 | 大约需要 6 min



技术时代永远不缺少概念，从虚拟化、云计算、公有云、私有云和混合云，到SaaS、IaaS、PaaS、DaaS、CaaS、FaaS 再到 Serverless，这一路发展下来似乎永远不缺各种眼花缭乱的名词和技术导入。而时下流行的云原生，作为在开源技术栈上绽放出的一朵鲜艳的花，随着云时代的降临，一时间惊艳天下。


到了今天，感觉只要一谈到云计算技术，如果不贴上“云原生”的标签，不搬出一下和 CNCF 基金会的渊源，就好像自己的技术落伍了。那么，就让我们来聊一聊这个云原生到底是什么？在开源技术栈上，又究竟是怎样产生云原生的？



1

 云原生是什么？

按照百度百科的词条定义如下：云原生是基于分布部署和统一运管的分布式云，以容器、微服务、DevOps等技术为基础建立的一套云技术产品体系。

究其出处，“云原生”这个词实际上是2015 年由 Pivotal 公司的一个技术经理 Matt Stine 所写的《向云原生应用架构迁移（Migrating to Cloud Native Application Architectures）》一书中提出的一个概念：Cloud Native。一方面，这是 Pivotal 公司为了推销自己Cloud Foundry平台产品而建立了一个新的概念；另一方面，Matt Stein作为产品经理确实发现随着互联网和移动互联网应用的兴起，需要更加快速，更加安全，更加容错，更加可视化，发生故障可隔离，可以自动恢复，可以弹性扩展的新型的应用发布方式。基于此，他提出了一套新型的技术最后才是适应云原生的一套技术路线和技术框架。

这再次验证了：一个优秀的产品经理设计产品，一个卓越的产品经理设计的是理论。在此技术路线下，他展开阐述了一系列去适应云时代的技术方法。形成了以下这些对于云原生特性的定义：

1. 云原生的十二要素特征

2. 开发运维一体化（Devops）

3. 微服务 （MicroService）

4. 持续交付 （Continuous Delivery）

5. 敏捷基础设施（Agile Infrastructure）

（注：云原生的12要素特征主要指代码库，依赖，配置，后端服务，编译发布运行，进程，端口绑定，并发，可任意处置性，开发平等，日志，管理进程）


不仅如此，除了上述的这些定义之外，Matt还选择一套康威定律（Conways Law）来提出对于组织的要求，以及根据业务变化可以对公司进行组织和业务重塑的能力要求。


企业要想云原生建设成功，需要的不仅是一套可以实现云原生核心价值的技术架构，更需要进行满足云原生目标的一次组织变革。那么云原生的组织目标是什么呢？对此，早在半个世纪前，有个工程师叫 Melvin Conway，提出了一个论断：

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.
Conways Law


其中文意思可以解释为：那些设计系统的组织，其产生的设计最终会被限制在等同于其组织之内、组织之间的沟通结构。说白点就是：有什么样的组织结构就只能设计出什么样的技术架构。而后来这个论断被Brooks在他写的同时每个程序员都应该值得去拜读的《人月神话》（1975年版）中总结为“康威定律”。


所以，云原生究其本质，与其说是一种技术体系，不如说是一个技术理念。简而言之，我们身处什么样的环境，就应该采用和那个环境所相适应的方法来存在。从IT基础架构的角度来讲，在云计算成为这个时代的普遍选择之后，每一个企业就该采用和云时代相一致的技术架构，同时进行和云匹配的IT治理及开发方法，让一切IT应用生而为云。


云原生既包含技术（微服务，敏捷基础设施），也包含管理（DevOps，持续交付，康威定律，组织和业务重组等），还是企业管理方法的集合。而关于云原生的核心价值主要体现在于以下四个方面

  1. 开源软件栈实现了基于任意公有云私有云或混合云的部署，从而避免了单一供应商依赖；


  2. 从原来电脑上的几个用户节点，可扩展到数以万计的自愈式（自诊断，自恢复）多租户节点它的核心基石经历了：服务器，虚拟机，构建包，容器，集群化容器等阶段，从而实现无限且弹性扩展的可能性；


  3. 通过将应用分解为已明确说明依赖性的一系列微服务来提升灵活性,可维护性，增强灵活性与可维护性，从而让应用发布随需而变。


  4. 通过一个集中编排的动态管理和治理微服务的过程，从而使资源的使用更加来优化和高效。


从 Pivotal 公司为了更好的销售它的产品包装出了云原生的概念并建立一系列的框架和标准，但这个概念也并不是一夜之间直接从地底下冒出来。而在各种纷繁复杂，有时令人无所适从的各类技术名词里，如此特别的云原生，它又经历过怎样的历史演变历程呢？就让我们且来看一下它的前世今生和未来。


2

云原生的历史回溯

实际上，这一切经历了从物理机，虚拟机，IT基础设施虚拟化服务（IaaS）到PaaS（平台即服务）后又经容器最后再到云原生，无论是技术还是理念都经历了一个漫长的演变和迭代过程，主要历程如下：

#1. 公元2000年之前，物理机即非虚拟化服务器时代 
当你需要启动一个新应用系统时，就需要去购买一批物理器，你的应用的基石是物理服务器；

#2. 公元2001年，VMware 发布虚拟机应用
VMware 在2001年服务器市场发布 virtual machines (VMs)使虚拟机应用普及化在一台物理机上可以运行多个虚拟机,意味着我们可以减少物理服务器购买数量。基于虚拟机构建我们的应用系统、架构的基石变为虚拟机。



#3. 公元2006年，亚马逊公司的AWS 首创了 the Infrastructure-as-a-Service（IAAS，IT基础设施即服务）的概念，开启了云时代的底座。

AWS (亚马逊公司旗下云计算服务平台)通过在2006年启动 Elastic Compute Cloud（弹性计算云EC2）来建立Iaas市场，那是贝佐斯领导的亚马逊提出了一个大胆的商业设想即将企业用于IT基础建设的资本性支出转化为日常运营性支出，当企业有需求时，可以在1小时内就可以租到企业所需要的服务器，架构的基石也是虚拟机(应用系统同样基于虚拟机)，称为Amazon Machine Image (亚马逊机器镜像AMI)

#4. 公元2009年，Heroku 提出了Platform-as-a-Service (PaaS)概念，平台即服务的一页由此被翻开。


Heroku 平台即服务PaaS架构的基石是Buildpack，并启用了容器化的12要素应用程序，构建容器的过程是非透明的。但是，部署一个新版本应用只需要使用GIT命令: git push heroku 就可以把代码Push到heroku上去。

#5. 公元2010年，OpenStack 开源 IaaS，试图用开源的理念来和其他对手进行竞争，不料一场轰轰烈烈的以开源为基础的技术革新在整个行业掀起。OpenStack 整合了一批非常杰出,多样化的供应商来构建开源的基础设施即服务（Iaas）它开始与AWS，VMWare进行竞争。基于虚拟机来构建应用系统,基石仍然是虚拟机。

#6. 公元2011年，Pivotal Cloud Foundry 开源 PaaS
硅谷的 Pivotal 公司在Cloud Foundry的架构上创建了开源 PaaS 来替代Heroku’s PaaS。l基于Garden容器技术（它可以承载Heroku buildpacks，Docker，甚至非Linux的操作系统）来构建应用系统。并包装出了一套云原生的标准体系。同年底Pivotal 启动了 Cloud Foundry 开源基金会，进行开源生态的运作。我们现在可以看到，这些都是极具技术远见和商业洞察的策略，只可惜他们因为各种原因，最后还是功亏一篑。但这些发方法和策略被随后跟进的谷歌全部吸收并进一步采用。


#7. 公元2013年，Docker开源容器技术
在容器技术层面，Docker 结合了 LXC（一种Linux内核虚拟化技术，可以提供轻量级的虚拟化，以便隔离进程和资源），Union File System（Docker联合文件系统），cgroups（Linux内核提供的一种可以限制单个进程或者多个进程所使用资源的机制）来创建了一个被全球开发人员所接受的容器标准。通过docker，它使整个软件行业拥有了有史以来最快的技术开发速度；并实现了隔离性、复用性，与不可变性。


8.  公元2015年，CNCF云原生时代
自Pivotal提出了云原生的标准和开设了基金会之后，云原生计算通过开源软件统筹的来实现了将应用分解为微服务，将应用每一部分装入属于其自己的容器。同时动态编排这些容器让让资源使用达到优化，这样的一些想法和思路深入人心。谷歌随后也发起并维护的基于 Docker 的开源容器集群管理系统Kubernetes（简称 k8s）。


K8s为容器化的应用提供资源调度、部署运行、服务发现、扩容缩容等整一套功能，但它并非一个传统的 Paas，不限制应用运行环境，不区分应用和服务这两个概念，本质上可看作是基于容器技术的 mini-PaaS 平台，因为容器本身就是可移植的，所以 Kubernetes 容器集群也能跑在私有云、公有云或者混合云上面。Kubernetes 属于主从的分布式集群架构，包含 Master 和 Node：Master 作为控制节点，调度管理整个系统；Node 是运行节点，运行业务容器。


但作为最先出发的 Pivotal 由于在技术上沉迷于过于笨重的Cloud Foundry架构体系并且行动缓慢导致失去先发优势。而谷歌因为不满Cloud Foundry基金会的一些做法，也就在同一年于Linux基金会下发起建立了一个新的云原生基金会以开源的方式来运营整个生态。其使命就是创造和推动采用新的云原生模式，来助力企业在云计算模式下更好的构建可扩展的应用程序。这也就是当下已经成为云计算时代的主流且如日中天的 CNCF基金会。



CNCF基金会以开源的信仰和云原生的理念，一下吸引了各路全球的顶尖开发者、众多企业用户和软件厂商等参与其中。按其最新的网站数据显示，截至本文写作日已经由超过18.3万的社区参与者，15.9万的代码贡献者，810个企业会员，141个认证的Kubernetes平台，成为当之无愧的云原生领导者。而国内目前流行的云计算技术提供商几乎都是从开源Kubernetes技术获得技术灵感，并成为开源云原生下的技术套利者。



3

云原生时代离不了开源和开源软件栈

从上述一路发展过来的云原生历史来看，虽然 Pivotal 公司和其团队以其技术远见看到了云原生时代的到来，但却没能在 Cloud Foundry 这个技术架构下云原生的春天，不得不说是一个遗憾，而谷歌虽然作为一个后发者，但以其敏捷的行动力，并以开源基金会的形式，吸引了全球最优秀的团队加入生态，共同合作贡献。

由此，我们可以看到这样一个不争的事实：是开源软件栈成就了云原生，而云原生也成就了当今如火如荼的云服务时代。




云原生推动企业数字原生化

随着传统企业上云这个大势所趋下，企业为实现数字化转型，IT架构就要更好适应线上线下业务，无论硬件、软件、还是基础架构都在朝着敏捷和弹性的方向发展。 所以基于开源和云原生的软件应用是一个必然方向，而通过IT技术设施的云化弹性，应用的敏捷构建，将复杂的系统部署于云中，更好的弹性和容错机制等优点将彻底革新原来的软件开发方法和部署运维。


在这样的一个趋势下，对于企业来说，要做的也许不仅是数字化转型，而更是一个以云原生的理念来进行企业的数字原生化。 而不管技术如何迭代，我们也将始终看到康威定律是大多是企业的宿命。




注：本文采用知识共享署名-非商业性使用 4.0 国际许可协议进行许可。封面图和文中引用图片均来源于网络，侵删；此外，相关信息引用来源：1) Matt Stein 《Migrating to Cloud Native Application Architectures》；2) CNCF Cloud Native Computing Foundation (cncf.io)官网介绍


‍‍关于 OpenTEKr-Flossway 博客共同体


Flossway最初是由 Tisonkun 建立的一个有关开源内容的博客。2022年OpenTEKr 社区和 Flossway 共同发起博客创作共同体的‍‍倡议，进行和开源内容相关的图文原创。欢迎更多开源研究爱好者加入共同体来为开源而写作，讨论和宣传开源理念。


  • Github 地址: 

https://github.com/flossway/flossway

  • 微信公众号: Opentekr 开源星系

  • 网站地址: www.opentekr.org(尚在建设中)


期待大家的加入！邮件联系 contributor@opentekr.org 或者微信 OpenSourceGalaxy，开源内容共创，因你而更精彩！



/// 关于作者


狄 安

OpenTEKr 创始人 & 开源布道者

企业级软件领域的连续创业者，开源领域的独立观察者。现从事开源和数字化领域的研究和布道，及开源和商业结合的探索与实践。



/// 关于 OpenTEKr ///


OpenTEKr 是一家关于致力于开源技术和应用推广的社区，主要研究开源文化和现象，宣传开源理念，探索开源与商业结合的社区共同体。基于「众有、众享、众治」的信念，我们依循「自由与规则同在，免费与商业共生」的原则，憧憬科技普惠的美好未来，帮助个人和组织通过变革性的技术创新来成就其远大抱负。



云技术云计算移动互联网产品经理
文章转载自OpenTEKr 开源星系，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

评论