边缘设备、系统及计算杂谈(7)—云原生学习笔记_云原生主题学习心得

缘起

这是一篇很长的文章。是我系统学习《阿里云原生架构实践》一书的心得。当然，也结合了10个月左右时间的学习，思考。包括老板提的各种问题。简单来说，对云原生的学习还在继续。现在正在理论加代码学习。对云原生如何在边缘侧应用也在思考。简单说下，本文是我个人思考，我的起点是终端。

云原生为了什么？

云原生是云计算的进一步发展，或者是云计算的升级。云原生可能和我们做终端的不太一样。终端开发几乎没有太大变化。虽然我们在Android上做开发，但更多是偏底层，偏framework。作为一个鲜明的对比，Android系统上做应用开发，我们接触得少。而做应用开发，尤其是中大规模互联网应用，如微信，支付宝，甚至银行的手机银行APP，都是大团队作战，业务非常繁杂。做应用开发和做系统开发，这两者在技战术，工程管理方面的问题差别很大。就好像我们不关注应用，应用不care底层一样。

云原生不只是技术，还有很大一部分属于方法论。其目的还是为了更好的保障，提升企业经营效能。企业经营效能是一个非常抽象的词，我举一个比较能听懂的例子：民生银行牛新庄总经理2018年在云栖大会上分享的：https://developer.aliyun.com/article/654692。直销银行核心系统切换到分布式系统后，每账户的成本从2.2元降低到8分钱。这就是一个典型的企业经营效能提升的案例。当然，其中肯定也用到了云原生的一些技术。

 

云原生是什么？

Cloud Native Computing Foundation一词中，大家只看到了Cloud Native，其实最重要的是第二个C，即Computing。

有一个观点

• 底层软硬件技术出现后，上层应用往往要很长时间才能真正认识到新的软硬件的价值，才会开发新的软件架构以充分利用这些新软硬件的能力。例如x86 CPU/服务器出来20年后，CORBA,EJB, RPC才成为主流，而容器技术在2000年就由FreeBSD在jail中提出，但大规模应用是在2013年Docker之后。

这个观点在云计算里也得到了验证。我本人在2008年就有一段时间接触到云计算了。但2015年前，大多数应用只是把云当做计算的场所，应用放到云上去运行而已。

基本上是一对一的替换，应用的技术栈没有变化，软件的架构没有变化，只是软件运行的平台和运维的技术体系发生了变化。

所以，云原生对我们来说，就是要检查自己的应用是不是符合云原生要求的，是否能充分发挥云原生的价值。以前的东西放在云上跑并不一定是云原生应用。这一点要明确。云原生有自己的要求，自己的方法论。云原生经常提到的十二因素（https://12factor.net/zh_cn/），这个后续再说是什么。

现在看云原生的定义（CNCF修订，后续还会更新）“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统做出频繁和可预测的重大变更。”

对要实践云原生的公司来说，牢记“只有结合云原生所提供的云服务，改造应用的架构，才能够更好地使用云原生技术，更好地构建弹性、稳定、松耦合的分布式应用，并解决分布式复杂性问题。此外，对架构的改造还意味着相关的开发模式、交付方式、运维方式等都要随之改变，比如，采用微服务架构重写应用，用声明式API和自动化工具升级运维方式，等等。简单来说，云原生使得整个软件的生产流水线都发生了巨大的变化，而具体的变化程度又取决于企业对云原生的使用情况”。

要正确实施云原生这一新计算模式，还需要企业的IT决策者、架构师、开发人员与运维人员正确理解和应用云原生的理念，利用合适的云原生技术及产品。有太多的反例可以证明，仅靠单边的技术升级是很难让云原生升级产生价值的。

与云原生有关的概念如下：

这里有个概念，现代化应用。现代化应用和云原生应用的特征非常接近。但现代化应用可以不和云相关，也可以相关。云原生应用则和云相关。

 

云原生是云计算的升级

哪些地方升级了？

 

研发流水线升级，软件交付模式升级

• 重塑研发流水线：指CI/CD。可做到7*24小时发布。这个和行业有关。终端，甚至移动端应用开发无法做到7*24小时发布。因为发布渠道不在自己手里。比如苹果应用商店，app上架有非常严格的审核流程。我一直在思考之前也提到过的问题，终端开发（包括Android系统，应用开发）为什么很少谈快速部署之类的事情。我后来想到一个可类比的场景。以蔬菜生产为例，后端开发就好比在生产基地生产蔬菜，厂家完全可控，规模生产，规模化效应，精细化管理，孜孜不倦得提升提高生产效率和运营效率。而蔬菜生产后，进入流通领域时，比如在菜市场卖菜，需要检测，需要满足菜市场的要求。这些不是厂家完全可控的，甚至无法控制。所以，在这个流通领域内，谈7*24是无利的,部署越多,所需成本越高(而且，还增加了菜市场审核的成本)。所以，在流通领域，尽量做到少bug，无bug，功能丰富才是最重要的。最好是装一个APP，以后都不用发版了（银行类APP大量业务功能是通过前端页面发布的，无需上架APP，就和PC看网页一样，系统更新，页面就更新）。

  • 思辨：当移动应用、终端ROM在开发过程中，实际上是有CI的，即持续集成。这个早在多年前就有了。一旦有patch提交，gerrit就会集成编译，如果发现有错误则不能提交。但CD（继续部署）是没有的。如上面所说，因为进入流通渠道后，我们没法掌控。所有bug最好的方式就是在发布前解决。

• 重新定义软件交付模式：我们先看个图。所谓的传统软件交付模式：

针对这一条，如果没做过后台系统开发的话很难理解。我给个实际的例子。下面是我之前做的POS机应用数据采集系统上线前要准备的材料：二进制在代码仓库上，由运维人员下载，然后按照下面的部署手册去安装和部署。部署过程中如有问题，还有回退步骤。

部署内容包括什么呢？下面是两个部署文档。后台业务逻辑往往涉及不止一个系统。系统之间的关联关系，数据库表的格式，网络访问关系等在升级之前都要做非常完备的计划。并且在准生产环境中要做多次演练。

所以，一次系统变更是一件非常麻烦的事情。每次变更都要前后端的人陪着搞到夜里。运维也很痛苦，不想接这种活。

那云原生能否解决问题？看起来可以。相当于研发把容器都做好了（容器内包括交付物所依赖的二进制，配置关系），运维只要把容器部署上去就行。但我觉得数据库表修改，网络访问关系可能不太容易搞定。

• 声明式API：这一条和现在流行的声明式编程有关系，即declarative programming，是一种编程范式。在UI开发里也很常见,例如React，Flutter，SwiftUI都采用了这种范式。声明式编程刚接触不太好理解，因为我们长久以来的编程方式是写代码逻辑——即要把功能怎么实现都写出来。但声明式编程的思维更抽象，它不关注实现，只告诉你要最终达到的效果。这种范式的出现来源于生产力的需求以及多核的出现。把思路聚焦在更好的满足业务需求上，而不是细抠里边的实现。极大简化了开发。并且，让专业的人士能更好得得聚焦在如何实现上。

• 思辨：声明式编程在JS、UI开发里用得比较多。而内核开发，C/C++开发领域（即使Java也是到Java8才引入的Stream）则较少有这种情况很少。这一方面和语言本身特性有关（不得不说，JS这些语言发展速度非常快，为了提升开发效率，生产效率，新的思想层出不穷），一方面和它们要解决的问题有关（业务领域里的需求真是百花齐放）。

• 尽量采用OpenAPI做为系统间的集成方式：注意，OpenAPI是一个规范。用于解决服务调用之间的文档，规范等问题。

 

运维模式升级

这一块我没法评论。不同行业，企业的运维要求不一样。以金融行业为例，监管要求银行的运维和开发必须分开，各司其职。开发绝对不能去做运维的事情。从安全角度看，有很多信息是掌握在运维手里，如果信息接触面扩大，泄露的风险也大，对客户资金安全会造成严重影响。这个往往不是技术问题，而是安全的流程管理。例如，POS机里密码键盘里的主密钥，是需要两个不同的人，乘坐不同的交通工具，在线下各带一段密码去工厂里灌入的。我只是想说，我们在提技术方案的时候，尤其是给业务壁垒较深的行业，一定要先摸清楚行业背景，行业规则。先成为行业专家，然后再去卖方案。

 

应用架构升级

应用变成云原生应用有两种方式：

• Re-platform：这种方式是在不重构代码或不重写代码的情况下，尽量采用云原生技术，比如，使用容器对应用进行打包和部署，把Kafka替换为云服务，把MySQL替换为RDS（Relational DatabaseService，关系型数据库服务），等等。

• Re-build：这种方式需要重构甚至完全重写应用，比如，把单体架构（Architecture）改为微服务架构，实施存储状态分离，业务实现采用Serverless技术编写，采用事件驱动架构。

  • 思辨：这里没有把re-host放进来，是因为re-host只是做计算、存储、网络的一对一迁移，整个系统的运维模式、软件打包方式都没有发生变化，也没有采用PaaS替换原来的服务，所以可以认为re-host不是一种云原生升级方式

比较re-platform与re-build，两者最大的差别是前者没有进行架构升级，这样就很难构建更好的现代化应用。从现代化应用特征的角度来说，基于容器、可管理、认证和鉴权等的云原生架构确实不需要re-build，微服务、无状态应用、API会优先选择应用重构，而弹性、可观测性、高可用、自动化等在应用重构的情况下会做得更好

 

组织结构升级

从我个人经验来看，我们好像很难理解为什么云原生会扯到企业文化上。这里有一个重要原因，是因为我们在ROM开发上早就是大团队作战，已经有比较成熟的组织结构和管理经验。因为ROM开发和管理流程早在几年前就稳定，成熟，所以这么多年一直没有什么变动。所以大家没什么感觉。

但对很多公司/行业来说，他们要么起步很早，有大量技术债要清偿（从我们对SOA、微服务架构的讨论来看，IT这几年发展相当迅速。那些电子化早的行业，如银行，通信企业，到现在都背负了很沉重的技术债务），要么就是快速发展的企业（即使像XX这样的头部互联网企业，其后台开发能力也不被阿里的研发人员瞧得上），其IT建设无论从制度还是能力上都跟不上业务需求。

所以，对这些企业来说，云原生的升级还会涉及IT文化的升级以及IT组织结构的升级。一个企业中的IT文化，实际上是开发、运维等IT人共同认可和遵守的工作流程、知识体系、工具集的总和。云原生作为一种全新的计算模式，带来了工具集的升级、知识体系的更新和工作流程的改变，也变更了企业的IT文化。在这个过程中，可能会出现很多问题，比如，有人会因为不愿意接受改变而产生抵制情绪（惯性），因为对新知识掌握不牢而导致各种失误，从瀑布模型到DevOps不适应，产生新的技术债务，甚至部分岗位会被淘汰（如大机运维人员）和产生新的岗位（如SRE，Site Reliability Engineer，网站可靠性工程师），等等。这些变化都可能会对企业的IT部门产生巨大的影响。

书中的建议如下：

 

现代化的应用

先说明，这个应用是指云端的应用，也就是服务类应用。“老”应用的类选包括单体应用，瘦客户端应用，富客户端应用，大型机或小型机应用。这些应用不具备互联网架构，不具备云原生架构，没有使用云计算技术等。

现代化应用的特点：

书中对云原生架构的好处有几段介绍。根据我的经验，比较有感触的是微服务这一条：依托有强大算力的云基础设施，构建“小步快跑”的微服务化应用，实现模块化迭代和快速试错，同时将每次业务升级的负面影响降到最低；此外，自动化流水线、API集成、业务持续发布，可以帮助内部技术和业务团队之间形成更紧密的合作。目前，对于业务发布频率，最好的企业已做到了秒级发布，即基本上是按需发布，不受任何发布窗口、质量风险的限制，最大化了业务快速推向市场的能力。

思辨：

• 反复强调，进入流通领域的APP，ROM这样的交付物，要把问题消灭在上架之前。绝不能小步快跑。就好比汽车一样，召回是很麻烦的事情。

• 后台系统：这种方式需要提倡。

• 边缘系统：位于后台系统和流通领域之间。要看实际场景。

 

阿里巴巴云原生实践介绍

首先，阿里云原生的实践中，明显有一个迭代的升级的过程。并且， 这个升级确实是外部需求，挑战牵引的。

阿里巴巴为什么要做自己的云计算？除了马云的高瞻远瞩之外，还有一个非常现实的原因：作为一家业务飞速发展的电商公司，如果依赖传统的IT设施来支撑亿级并发、PB级数据处理的业务，那么“高昂的IT基础设施成本将拖垮阿里”（时任阿里巴巴首席架构师的王坚博士如是说）

为什么我要强调这一点呢？因为我在探索下一步做什么的时候（我自己的感受，体会），没有一个抓手，也就是不知道要解决什么问题。实际上这是没有真正站在客户立场考虑的问题，对客户的问题不能感同身受。这个问题是一个长期问题，需要耐心，持续投入和思考。

云原生架构的定义和原则

云原生架构和非云原生架构的对比图

这个图中的解释：

• 云原生架构可以最大化地剥离云应用中的非业务代码部分，从而让云设施接管应用中原有的大量非功能特性（例如，弹性、韧性、安全、可观测性、灰度等），使业务能够摆脱被非功能性业务中断的困扰，同时具备轻量、敏捷、高度自动化等特点。

• 云原生架构可以通过与基础设施深度整合与优化，将计算、存储、网络资源管理以及相应的自动化部署和运维能力，交由云基础设施执行，应用自身会因此变得更为灵活，且具有弹性和韧性，从而大大降低管理成本

如果我抓上述内容的重点的话，结论是这样的：

• 云原生将非业务功能（也就是基础功能，或者就是我们说的OS）下沉到IaaS或者PaaS。

  • 云端非业务功能包括：高可用能力、容灾能力、安全特性、可运维性、易用性、可测试性、灰度发布能力

  • 在现代的终端OS里，这一点已经比较常见了。比如Android的多媒体播放，MedisaService是真正提供播放能力的，而应用只要做好界面就行了。而以前Windows开发多媒体应用，播放，编解码都需要应用自己去处理。

• 部署和运维是云原生里非常重要的领域。降本增效中的降低运营成本体现在这个环节。

思辨：如果我们进入云原生领域，哪些是突破口？

• 大概率不是业务功能。如上所述，业务功能不属于IaaS或者PaaS。

• 如果是云原生OS的话，那是属于k8s，ServiceMesh，SDN这样的框架体系吗？感觉这个方向有难度。因为这些东西是支撑业务功能的，而我们对云业务的规模，所面临的问题知道的比较少。而且，这里有谷歌，RedHat等巨头级的玩家。

  • 国内有大量公司但其实都没有技术护城河。只是披着技术的皮，去帮助其它B端公司使用云原生技术。

  • 国内几大云已经在简化使用上下足了功夫。只不过现在很多企业还有不上云的考虑。这个考虑不见得全部是隐私的考虑，更可能是这些B端企业还没到数字化运营的阶段。

  • 后续国内企业数字化运营加速的话，这块留给其它厂商的空间会越来越小。之后会兴起提供多云，混合云服务的公司。

• 可能是云原生OS里单项优化方面的功能，如虚拟机技术，高效I/O技术，容器技术。这一块也契合我们在终端OS里的优势。尤其是ARM芯片开始往服务器领域里渗透，这是一个契机。而传统x86芯片在这一块已经优化得很不错了。

  • 还有边缘侧的系统：边缘侧的系统和云端差别很大。至少，边缘侧系统短期内不会追求可伸缩性，一定是物尽其用。因为买边缘设备实际上需要花费很大成本。

 

云原生架构的原则

书中一共列了7条原则

下面简单对其中的几条进行说明

• 服务化原则：这就是指的业务功能微服务化，分布式，分区（比如，在异地多个数据中心部署）

• 可观测：微服务化后导致调用链很长。这是单体应用微服务后必然的结果。下面是一个示意图

 

云原生架构中的常见模式

• Service Mesh：Service Mesh主要包含三种模式：

  • 第一种Sidecar模式，典型解决方案如Istio+Envoy，当然还有其他的实现方案，如Linkerd等

  • 第二种是服务注册和发现模式(Service Registry & Discovery)，典型解决方案如Spring Cloud

  • 第三种是中心化Broker模式，典型解决方案如RSocket Broker

Spring Cloud也是Service Mesh，只不过它比ServiceMesh概念出现得更早，覆盖的范围也更广

• Serverless模式：这一块我们接触得非常少，主要还是没有场景驱动，不知道能解决什么问题。Serverless和FaaS有重叠之处。但不完全一样。关于Serverless，可阅读https://blog.csdn.net/cc18868876837/article/details/90672971

  • 注意，Serverless：是指无服务器模式，不是无服务模式。无服务器模式是指不需要买服务器，而是按功能调用收费。这里先截图展示一个Serverless的案例：

serverless模式中，技术还有挑战。传统的基于docker的容器化服务性价比还不是很高，最理想的方式是应用进程本身就支持多租户。目前，serverless还没有成熟的通用技术。

思辨：

• Serverless和FaaS的关系：可参考https://www.jianshu.com/p/92632d6c2269

 

阿里DevOps实践

看两个图即可，第一个是精益产品开发流程图

下图是交付链路流程

 

微服务

这里提到了SOA。按文中所述，SOA思想并未过时，只不过实现SOA的技术路径由ESB转到微服务。

 

微服务架构的演化

• 2011年：在第一代微服务架构中，应用除了需要实现业务逻辑之外，还需要自行解决上下游寻址、通信及容错等问题。随着微服务规模的逐渐扩大，服务寻址逻辑的处理正变得越来越复杂，哪怕是同一种编程语言的另一个应用，上述微服务的基础能力也需要重新实现一遍

• 在第二代微服务架构中，旁路服务注册中心作为协调者完成服务的自动注册和发现，如图4-13所示。服务之间的通信及容错机制开始模块化，并形成独立的服务框架。但是，随着服务框架内功能的日益增多，复用不同编程语言开发的基础功能就显得十分困难，这也意味着微服务的开发人员将被迫绑定在某种特定语言之上，从而违背了微服务的敏捷迭代原则。

• 2016年出现了第三代微服务架构，即服务网格，如图4-14所示。原来被模块化到服务框架里的微服务基础能力，从一个SDK（软件开发工具包）演进成为一个独立的进程——Sidecar（边车）。这个变化使得第二代架构中的多语言支持问题得到了彻底解决，微服务基础能力演进和业务逻辑迭代彻底解耦。第三代微服务架构就是云原生时代的微服务（Cloud Native Microservice）架构，边车进程开始接管微服务应用之间的流量，承载第二代微服务架构中服务框架的功能，包括服务发现、调用容错以及丰富的服务治理功能，例如权重路由、灰度路由、流量重放、服务伪装等

• 随着AWS Lambda的出现，部分应用开始尝试利用Serverless技术来构建微服务，第四代微服务架构出现，如图4-15所示。在第四代微服务架构中，微服务由一个应用进一步简化为微逻辑（Micrologic），这也对边车模式提出了更高要求，更多可复用的分布式能力从应用中剥离，并下沉到边车中，例如状态管理、资源绑定、链路追踪、事务管理、安全等。同时，开发侧开始提倡面向localhost编程的理念，并提供标准API屏蔽底层资源、服务、基础设施之间的差异，以进一步降低微服务的开发难度。第四代微服务架构就是目前业界提出的多运行时微服务架构（Multi-Runtime Microservice）。

 

云原生架构成熟度

云原生架构有对应的评价标准。

从传统应用迁移到云原生，也有对应的指导

 

云原生技术发展趋势

容器技术

k8s和Linux对比

下面这个图就是k8s为云原生OS的示意图，用它和Linux进行对比

分布式应用架构

 

阿里云云原生产品介绍

 

个人感受

• 虽然现在有云，但云上的服务器也是服务器，也有可能挂掉。那么，如果我们的服务在本地存储信息，在内存存储信息，程序的迁移就会比较麻烦。所以，尽量做成无状态的服务（stateless service）。即使要存储状态，也要存在本身已有分布式的存储上。还有。服务迁移是指在别的服务器上启动这个服务的实例。显然，这个服务实例最好是能快一点起来，要够轻量，这也是要求服务微化的原因。

• 当外部请求增大的时候，现有的硬件资源可能撑不住了（这其实很常见，也是推动大家换新手机，新PC的原因），一种解决办法是换一个性能更好的设备（对个人来说几乎第一选择）。另一种方法是搞多个设备来响应请求（这就是scaling out）。第二种方法就是scaling out。云上服务器资源很多。当请求变少时候，资源还可以scaling in，还回去。云上计费是按实际使用来收费的。不像宽带，用没有都要掏钱。

  • 对于web请求，其响应服务比较容易做到scaling out。因为每一个http会话都是相对独立的请求，彼此不怎么干扰。但不是所有服务都方便做scaling out。比如一些能控制系统的服务。如果有多个请求来处理，则会出现状态冲突的情况。

  • 做一个简单的对比的话。容易scaling out的情况就好像单机系统的程序里可以启动多个线程去处理互不相关的任务。而不适合scaling out的情况就是多个任务之间互相有依赖，比如都要改同一个状态变量。

  • 所以，当我们把视野放大来看，好像单机系统与分布式系统貌似碰到的问题类似。只不过我们从单机系统往上走到分布式系统的时候，很容易把分布式系统看成是一个更高维的，新的系统。但实际上站在“上帝视角”，把分布式系统中的各个计算机当做是一个巨大的CPU的核的话，分布式系统只不过是一个超级大的单机系统罢了......这是我个人体会。我的目的是以后在对终端系统的人解释分布式系统里的种种问题的时候，能让他们有共鸣。

• 另外，边缘侧系统是否存在scaling out的需求？好像不会。边缘侧的硬件一定是按需采购的，不可能买一堆空闲设备放那。边缘侧会有设备组网的需求吗？有。但我感觉是独立的，谈不上组网。比如有两个边缘盒子。彼此独立，各干各的。这个在家庭里不会出现。因为家庭是个人设备。一个人毕竟同时只能操作一个设备。

 

最后的最后

• 我期望的结果不是朋友们从我的书、文章、博客后学会了什么知识，干成了什么，而应该是说，神农，我可是踩在你的肩膀上的喔。

• 关于学习方面的问题，我已经讨论完了。后面这个公众号将对一些基础的技术，新技术做一些学习和分享。也欢迎你的投稿。不过，正如我在公众号“联系方式”里说的那样——郑渊洁在童话大王《智齿》里有一句话令我印象深刻，大意是“我有权保持沉默，但你说的每一句话都可能成为我灵感的源泉”。所以，影响不是单向的，很可能我从你那学到的东西更多。

神农和朋友们的杂文集

长按识别二维码关注我们