从中国封建历史的发展来理解云雾边缘计算以及云原生之间关系

　　前言
　　互联网的快速发展，带来了一大批新的名词，这次名词的更新换代的速度也是快得惊人，往往一波未平一波又起，使得大家不能墨守成规，必须不断学习才能赶得上科技和技术的发展潮流。
　　计算机行业更是如此，可能真的要实践活到老学到老的古训了。精通一个技术然后躺着赚钱是不存在的，因为可能几年后这项技术就被淘汰无人问津了。所以千万别再说计算机的高薪如何的不合理。计算机行业只能算门槛不低且付出和产出相对成正比的行业。
　　回到本文的标题，如果问大家这几个名词你听说过吗？大部分人肯定会说：＂Yes，I do!＂。但是如果让你说清楚他们都是什么以及他们之间的关系，可能不少小伙伴就要挠头了。这些概念可能很多人都知道一点，但又说不清楚。
　　本文通过讲述中国历史上的部分制度和组织形式来类比这几个概念的关系，网上的抽象定义我也就不过多讨论了，而是通过形象比喻的方式另辟蹊径，从其他角度让大家了解下这些概念，能达到基本明了不求甚解的目的。如果还是不懂，可以直接找作者，作者负责搞定你的问题或者搞定你~ 云vs云计算：中央集权下的资源管理
　　春秋战国时期，国家的军队和资源都分散在全国各地，大家各自为政，自负盈亏。好处就是管理好自己的一亩三分地就好。但是缺点也很明显，大家各自为政，自立为王，不听国家和天子的号令。然后各个诸侯之间也通过铸造自己的货币，流行自己的文字，推广自己的度量衡等方式人为的设置壁垒。这种情况下，国家的内耗十分严重，严重影响整个社会的发展。
　　映射到远古时代的软件行业，一个大公司可能有多个机房，这些机房之间的资源都是一台台的物理机。这些资源基本上都是隔离的，比如做数据库的部门需要使用小型机这种高性能设备，你把行政部门的2C4G的PC给到数据库部门，他们也用不上，在加上部门之间的资源之争，更是这种资源隔离情况雪上加霜。公司很难高效地管理这些资源。最后的结果是员工很痛苦，公司高层很苦恼，怎么破？云就在这种情况下产生了。
　　再回到历史，秦始皇的出现解决了这一切。随着六国的灭亡，秦国一统天下。紧接着秦始皇就发布了＂车同轨、书同文、币同制以及统一度量衡＂的操作，使得全国的资源统一管理。
　　再回到云的问题上，后续公司高层决定将所有的服务器都集中到一起进行管理，资源在资源池进行管理。各个用户按照需求进行资源的申请，再也不会出现服务器用不了的情况，硬件资源的使用率和管理效率空前提高，大家都很开心。
　　由于当前的用户获得的资源不再是实体的物理机，而是虚拟的资源单元，所有的物理机资源都被屏蔽了不会和终端用户直接交互，就好像在云端一样，这也是云或者云平台的由来。而基于云平台上的各种计算分析以及分配管理就组成了云计算的雏形。 云计算vs雾计算vs边缘计算：将在外，军令有所不受
　　中央集权成立后，资源终于可以有效地组织和使用了，下面就来看看效果吧。
　　有一天，中原王朝的老对手匈奴来骚扰秦朝了。草原民族的铁骑轻松碾压了秦朝的步兵，就算偶尔获胜也是残胜。于是秦朝开始在北方构建长城，形成以长城为基础的兵营据点群来防止匈奴的入侵。
　　咋一看好像很不错的计划，但是古代没有电话和无线电，如何传递消息和请示行动计划呢？这是个大问题。
　　想象下面这个场景，匈奴如果大举入侵该如何应对？当前有两个最直接的方案： 在长城地区长期维护大量的常规部队以应对某天匈奴的大举进攻：这种方案能及时地应对匈奴的大队入侵，但是在长城地区维护这么大规模的常备军成本将会是天文数字，更不用说边境地区能不能养得活这么多军队。这种方案显然不是长久之计。 在长城地区只维持适量的常规部队，大量的部队在国家的腹地等匈奴来进攻的时候在出动去迎击敌人：这种的好处就是平时的成本很合理，战时也能有军队支援，性价比很高。但是这里会有一个问题，如果边境的常规军无法坚持到朝廷援军的到来就被攻破了，或者报信的传令兵在传令的途中遇到不测，那么这场战争同样输定了。
　　这也不行那也不行，那怎么办呢？
　　其实方法也很简单，那就是在朝廷和边境之间增加一些行政和军事节点来解决问题。即在第二条方案的基础上进行改进：军队和战略物资不仅在朝廷和首都有，在朝廷和边境之间加上州郡来分级管辖和处理边境上报的事务。每个级别的机构都有对应的权限和能力参与到整个资源的请求和管理中。
　　这样整个的流程就变成这样：边境的常备军将军被授予假节钺的权利，可以根据敌人入侵的规模来判断该如何应对这场战争。如果常备军能解决，则直接解决；如果常备军解决不了，则向就近的郡县调动军队和资源来参与战争；如果还不能解决，则向再上一级的州府调动资源；如果匈奴举国入侵，州府一级也无法应对了，那么就将请求发送到朝廷，使用最高规模的战争动员来应对国运之战。
　　从上面的例子可以看出，战争动员会根据战争的规模来决定在哪一级别的组织解决这个问题。毕竟战争时期时间成本和运输成本是最重要的。
　　试想，如果因为事事都要从朝廷要资源，那么可能不等资源到位，战争就输了；亦或者从朝廷将军队派往边境，还没等军队到边境，补给就快用光了，那后续的仗还怎么打？这件事情如果不理解，可以去问问当年北伐屡败屡战的诸葛亮。
　　上面就是从历史角度来说明的云计算、雾计算和边缘计算的使用场景。回到当前的数据处理场景，如自动驾驶场景，业务会要求如下的需求： 如果出现险情，需要快速地处理，防止车祸的发生。 自动驾驶传感器产生的数据量巨大，尽量较少带宽等资源的消耗，控制成本。
　　上述的需求决定了不可能所有的计算分析和操作控制都放在云端的数据中心。因为巨大的数据传输量以及可能存在的网络延迟都是上面两个需求所不能容忍的；而把所有的处理都放在客户端，客户端的硬件成本以及整体的可实现性也不允许这样做。
　　所以在这种情况下，就需要将部分计算按需求和能力下放到离客户端较近的地方，通过各级计算节点的特点来将客户端需要计算和处理的问题分拆到合适的计算节点进行计算，以满足不同的场景和需求。
　　所以，当前的常规方案就是分场景解决不同的问题： 首先在汽车传感器和云平台之间增加一到两级的计算中心 如果发生紧急的事情，比如紧急刹车这种需要紧急处理的事情，车载芯片或者计算机就可以直接处理，已达到快速解决的目的 如果想获取附近的地图信息或者就近的线路规划，可以将数据和计算放在汽车附近的基站，加快数据传输以及处理速度 针对其他基站无法完成的计算，如行驶模式推荐或者整车状态分析等数据则需要云端的数据中心并结合历史的规则和大数据经验进行数据汇总和计算分析 数据每一层上报都会进行数据的筛选以及聚合汇总，然后处理一部分，继续上报一部分，大家各司其职，配置完成各种复杂的操作
　　举个不恰当的例子，上面的云端的数据中心对应的就是云计算，而附近基站以及车载芯片以及电脑就对应着雾计算以及边缘计算。这样类比可能不是很恰当，但是可以帮助大家快速理解他们的概念，理清他们之间的关系。
　　云计算vs雾计算vs边缘计算
　　而在实际技术落地的过程中，雾计算和边缘计算是有部分重叠的。在很多业务不是很复杂，层级不是很高的场景下，雾计算和边缘计算其实可以认为是重叠的，都是为了在减少成本降低数据延迟而将计算下放到离客户端很近的地方。 云计算vs云原生：三公九卿制vs三省六部制
　　最后来说说云计算和云原生的关系。 虚拟化阶段
　　最早的云计算其实就是分配给你你需要的硬件资源，大多数就是各种类似虚拟机的资源，你在这上面想干什么就干什么，云平台并不关心。
　　这就好比要打仗了，将军领命后，朝廷只给了你一群人，一堆铁器和很多给养。你需要自己练兵，自己打造兵器，自己管理给养。虽然经过一段时间也能训练好部队，然后带兵打仗。但是这样做的短板很明显： 军队的水平完全取决于将军的实力，效果不可控。真正实践了兵熊熊一个，将熊熊一窝的古训 打仗的准备周期太长，可能不等你训练好军队，敌人已经把你灭了
　　回到软件的世界，翻译成软件用语就是： 系统搭建效果不可控，完全取决于运维人员的技术水平 系统搭建周期较长，多环境部署的话，重复工作量大 容器化阶段
　　这些问题出现后，大家很快都开始寻找其他方式能解决上述的问题。秦朝时候发扬光大的三公九卿制登上了历史舞台。首先，权力机关已经按照功能划分成三公，三个人分管不同的事务。回到上文的例子，此时兵已经按照兵种和规模编排成不同的队伍，三公之一的太尉会组织相关人员根据经验针对不同的战争规模给予不同的资源搭配。这样战争到来之后太尉根据战争情况直接将打包好的资源搭配给到领兵将军，将军带兵直接去打仗就好了。
　　三公九卿制
　　这样子一下子就解决了练兵的问题，还会根据不同的情况使用不同的资源搭配直接就解决问题了，真是太爽了，从此妈妈再也不用担心我打仗的问题了。
　　但是真的就万无一失了吗？慢慢的新的问题又来了： 我们在变，敌人也在变，每次来打仗的敌人都和上次的规模组成不一样，导致我们需要准备很多套方案，慢慢的，维护这些方案就变得难以承受了。 针对很多相似的战争场景，本来可以通过某些搭配的微调就可以达到目的，但是由于这些方案都是事先定好的。所以需要向朝廷重新申请，而改变了一点，那么他相关的点也会影响很大，可能需要重新评估这套方案的可行性，耗时费力。
　　回到软甲的世界，这就是容器的时代，这个时代的佼佼者就是docker，docker容器使得很多资源都被封装成一个一个容器。在安装部署期间直接使用容器就可以部署好一个服务，使得安装部署对运维人员的要求降低了很多。另外基础容器之间可以通过组合的方式打包成高级的容器用来部署复杂的服务，使得一键部署复杂服务变成可能。
　　这么看起来docker已经解决了上面的两个痛点。虽然这样，但是docker仍然面临两个问题： 如果复合容器中的一层发生变化，影响同样很大。docker容器和洋葱一样，是一层一层的，如果想要修改中间的一层，那么需要剥开这一层外面的所有层才能达到目的，这会带来很多不必要的工作和消耗。 如果跨容器配合的话，docker缺乏有效的容器编排机制，虽然docker swarm充当了这个角色，但是很快就被其他竞争者超越，而超越它的就是我们接下来要说的云原生技术。 云原生阶段
　　历史上三公九卿制发展了很多个朝代，虽然不断优化，但是还是没能完美的解决问题。直到三省六部制的出现才算彻底的解决了问题。三省六部制是将权利在三公九卿制的基础上进一步细化，做到精确计算，灵活组合。
　　三省六部制
　　比如打仗这件事情不再是一个人或者一个部门说的算，而是由尚书省下的兵部、户部以及工部协同负责。那么战争准备就会变成下面这样： 带兵的将军根据战争实际情况提出自己的需求和预期 兵部会根据兵员的需求提供不同数量不同兵种的兵员 户部负责根据战争周期预期准备这些兵员所需的粮饷补给 而工部则会根据不同的兵员兵种提供不同的武器弹药
　　从上面来看，大家各司其职，按照标准给出不同的资源，共同汇集成了这次战争的准备。由于是职责划分清楚且标准统一，所以这样子给出的资源往往是比较合理的，效果也比较好。就算出问题了，也很好追责；追责之后一个部人员更换，由于标准统一，按照标准办事也不会影响到其他人从而避免影响整个战争准备。
　　回到软件的世界，让我们来简单看一看云原生的东西： 云原生都做了什么
　　云原生的主要目标DevOps：自动化管理，持续集成，开发和运维人员配合快速的部署以及解决问题 持续集成：不断的集成，快速迭代，快速解决问题 微服务：保证各个服务独立部署，独立管理，任何一个服务都可以单独升级，单个服务故障也不会影响整体服务的运行 容器化：资源的封装以及集成，屏蔽底层的使用细节，降低运维人员使用门槛和成本 云原生都用了什么
　　云原生的主要技术容器：k8s+docker为主(k8s之前默认的容器载体，1.24版本以后containered已经成为新的标准，可以预见以后K8s的容器选择会变得多样化)，docker负责容器封装，k8s负责容器编排调度。 服务网格：service mesh（Istio），配合k8s进行流量以及安全管理，通过Sidecar（边车）模式可处理服务之间通信的任何功能，比如负载均衡、服务发现等。 微服务：一个大型应用程序按照功能模块拆分成多个独立自治的微服务，每个微服务仅实现一种功能，具有明确的边界，通过REST等形式的标准接口进行通信和数据交换，这是一种松耦合的交互形式 不可变基础设施：一个基础设施环境被创建以后不接受任何方式的更新和修改。这个基础设施也可以作为模板来扩展更多的基础设施。带来的好处就是能提升应用交付效率，能快速、可靠地水平扩展且能保证基础设施的快速更新和回滚 声明式API：相对于过程式设计API，过程式是每一个操作都必须正确完成才能达到最终的目标。而声明式API则是指定了目标，系统则不断通过调整向目标靠近，最终达到目标。 总结
　　从上面的描述我们可以看出来，上面四个概念，其实可以分为两组： 横向：云计算、雾计算以及边缘计算其实都是云计算，只是为了满足不同的需求以及场景而导致的计算位置不同而已。 纵向：云计算以及云原生，云原生只是在云计算的基础上发展而来，云原生将云计算的优点保留，缺点完善，形成了一个灵活、完整、扩展性和可靠性极强的超级云计算，而云原生也代表了未来云计算的发展方向。
　　本文到这里告一段落，本文是想让大家通过形象的例子达到管中窥豹，略见一斑的目的。
　　这些概念都很大，随便一个展开都能写个几万字，我这里就简单的从一个角度上说说就得了，大家感兴趣可以自己研究下，或者我在后续的文章中再详细说明下。
　　云平台出现后，曾经有人说＂一切皆可上云＂；再后来元宇宙出来后又有人说＂一切皆可元宇宙＂。元宇宙能不能一切皆可我不确认，但是我还是相信＂一切皆可云原生＂的，起码软件可以是这样的！
　　文章到这里就结束了，如果想一起入门学习K8S的小伙伴，欢迎点赞转发加关注，下次学习不迷路！