云原生计算能消除技术债务吗？
Posted c++服务器开发
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了云原生计算能消除技术债务吗？相关的知识，希望对你有一定的参考价值。
云原生计算可以将行业领域驱动的设计、GitOps和其他现代软件最佳实践汇总起来，如果企业实施得当，可以减少技术债务。
云原生计算是企业IT的一种新范式，它涉及现代技术的方方面面，从应用程序开发到软件架构，再到保持一切运转的底层基础设施。
云原生为企业提供了清理技术债务的机会。例如通过Kubernetes这样的“扫帚”，扫除现有技术的一些积满尘土的角落。因此，假设云原生最终会消除多年来累积的技术债务是合乎逻辑的。
这也许合乎逻辑，但并不现实。众所周知，技术债务将长期存在。此外，对于任何一位首席信息官来说，宁愿将IT预算花在新技术和新事物上，也不愿将其浪费在清理前任留下的烂摊子上。
然而人们也有理由对云原生抱有希望。虽然云原生不是一把神奇的“扫帚”，但其核心实践确实可以帮助企业减少技术债务，并提供新的软件功能，而不会产生更多的债务，至少不会像以往那样产生更多的债务。
让企业清除技术债务以便永远不会产生新债务，当然是难题的一部分，但更直接的问题是如何偿还现有的遗留技术债务。
多年来，便利的快捷方式、笨拙的编码，以及基础设施中各种各样的接口，已经形成了一团乱麻。而对于这个难以解决的问题，可能需要采用“快刀斩乱麻”的措施。
云原生计算就是这样的一把快刀：基于领域驱动设计的架构重构。领域驱动设计要求将复杂的企业软件挑战分解为单独的业务领域，每个领域都有一个“限界上下文”。
限界上下文可以根据业务需求限制上下文来解决诸如“客户”或“发票”之类的业务。例如，大型企业的不同部门可能对客户有不同(可能有所重叠)的概念。每一个都代表一个单独的限界上下文。
早期对微服务架构的探索导致了互联微服务的激增，其复杂性限制了其可扩展性，并且很快显现出来。而通过限界上下文组织它们是管理这种复杂性以及大规模交付基于微服务的解决方案的关键。
因此，领域驱动设计已经成为云原生计算的一部分，此外，它告诉人们必须如何按照这种新范式来实现遗留资产的现代化。
解决具有高技术债务的遗留软件挑战的第一步是应用架构重构，从而将遗留架构转换为具有限界上下文的模块化元素。换句话说，企业必须遵循业务驱动的限界上下文引入模块化，以便引导减少技术债务的路径。
而魔鬼在细节中。根据企业面临的业务需求和遗留挑战，可以通过以下几种方式来利用这种架构重构：
可能会发现限界上下文中的现有代码根本不符合当今的要求。在这种情况下，可以将该代码重写为微服务。
遗留业务逻辑仍然具有价值，然后将其迁移到微服务。
可以将遗留模块作为API公开，因为它们已经具有有用的API，或者因为更新了遗留代码以通过API公开它。
可以使用机器人流程自动化(RPA)程序编写与旧模块交互的脚本。
需要注意的是，由于之前已将遗留软件重新组织和模块化为限界上下文，因此上述四种方法中的每一种都比其他方法更加简单。
此外，如果有必要的话，未来的重构也会更加直接，因为采用了“分而治之”的方法来划分技术债务。例如，随着时间的推移，企业还清四笔较小的技术债务比一笔大的技术债务更加轻松。
这种方法也是减少机器人流程自动化(RPA)脆弱性的最佳方法之一。如果没有限界上下文驱动的架构重构，那么应用程序环境中的任何地方发生任何变化，此类机器人程序就会崩溃。通过适当的划分，此类故障将更易于管理且更易于修复。
防止新的技术债务
防止新的技术债务就像要求保持房间整洁一样，虽然也许会保持一段时间，但到后来将会变得一团糟。
需要的是更多的结构，对吗?至少在云原生的情况下，这种结构确实有帮助。
云原生计算提供了一系列广泛的最佳实践，描述了如何最好地构建软件、配置基础设施、创建和部署应用程序以及管理生产中的一切。
当然，如果遵循所有这些建议，就不太可能背负新的技术债务，或者至少不会那么快地出现技术债务。
“基础设施即代码”(IaC)原则就是一个关键示例。IaC原则指出，工作人员不应在生产中弄乱服务器。 IaC原则当然可以限制生产中的额外技术债务，因为它提供了一种解决生产问题的主动方法。那么只有一个问题：IaC做得还不够。
IaC的问题在于必须编写各种程序。然后，必须像任何其他程序一样对这些程序进行测试、管理和版本控制——这意味着技术债务可能会像任何其他软件一样蔓延。
幸运的是，云原生计算已经超越了IaC，其中每一步都比之前的一步有所改进。
第一步：通过声明性配置来表示基础设施，它指定应该如何配置基础设施，而不指定如何实现此类配置。
与IaC相比，声明式方法减少了技术债务，因为没有太多的空间来使用快捷方式，但这些表示(通常出现在YAML文件或其他基于JSON的格式中)仍然非常像代码，尤其是对于复杂的动态基础设施配置。
第二步：GitOps。GitOps为软件发布和管理带来了以Git为中心的实践和流程。
GitOps在许多方面补充了基础设施配置的声明式方法，因为它采用声明式方法进行软件部署。GitOps通过为其流程提供更多结构而更进一步，而结构越多，技术债务蔓延的机会就越少。
第三步是当前最先进的技术：基于意图的计算。
基于意图的计算包含三个部分
以技术策略的形式对相关软件(基础设施、应用程序代码等)的声明性表示。
这种技术策略的抽象，如表示底层配置的业务意图的业务策略。
确保底层软件符合这一业务意图的一种机制，从而在策略应用中消除策略漂移。
换句话说，基于意图的计算采用声明式配置方法和GitOps，并添加额外的结构，从本质上确保整个云原生环境随着时间的推移符合业务意图。这样的合规性才是一把斩断技术债务这团乱麻的最好的快刀。
云原生的 WebAssembly 能取代 Docker 吗？
❝WebAssembly 是一个可移植、体积小、加载快并且兼容 Web 的全新格式。也正是因为它具有很高的安全性，可移植性，效率和轻量级功能，成为应用程序安全沙箱方案的理想选择。现如今 WebAssembly 已受到容器，功能计算以及物联网和边缘计算社区的广泛关注。究竟 WebAssembly 是怎样的一种技术，能否取代 Docker，就请阅读本文。
本文是整理自 KubeSphere 2020 年度 Meetup 中 Second State CEO Michael Yuan 的分享。
❞
大家下午好，我是 Second State 的 CEO Michael Yuan，我们公司的主要研发在台北和美国，然后在北京望京有个办公室。今天非常开心来到 KubeSphere 2020 年度 Meetup，我给大家分享的主题是云原生的 WebAssembly 能取代 Docker 吗？
背景
这是一个著名的 Twitter，是 Docker 创始人 Solomon Hykes 在 2019 年 3 月份发布的。他说如果 2008 年的时候，WASM (WebAssembly) 和 WASI (WebAssembly System Interface, WASM 系统接口) 这两个东西已经存在了的话，他就没有必要创立 Docker 了。他认为 WebAssembly 是计算的未来。这条推特在社区里造成很大影响，引发了很多人的的疑问。因为很多人认为，WebAssembly 可以在浏览器里取代 JavaScript，是用来玩游戏的。为什么突然成为在服务端能够取代 Docker 的东西呢？也就在这一年多后，包括我们公司在内，很多人在这里面做了很多 research。
WebAssembly 在服务端的位置
在服务端，我们一般可以把容器、虚拟机或者说运行环境分成三个不同的抽象的层次。
1.在最底层是硬件的 Hypervisor VM，或者说像 AWS Firecracker，这种叫做 microVMs，能够直接跟硬件打交道。
2.上面一层叫做 Application containers，在这种 vm 上面你可以做像 Docker 这样的 application container。application container 仍然是在操作系统这个层级，是需要把整个操作系统调进来的。
3.再上面一层叫做 High level language VMs ，这是从 Jvm 开始的。然后把 Webassembly 在操作系统这个层级上面给抽象出来了。这是 WebAssembly 在服务端的位置。
如果 WebAssembly 能够做成一个像 JVM 的 language VM，我们在今天也许能够实现 Java 二十几年前提出的梦想：在不同的操作系统上，在不同的硬件和软件的平台上，能够给开发者提供一个安全并高抽象性的运行环境。
WebAssembly 和 Docker 的对比
WebAssembly 跟 Docker 之间到底是什么关系，为什么说 WebAssembly 有可能会取代 Docker 呢？这里列举了 WebAssembly 相对于 Docker 的一些优势。
-
在冷启动上，WebAssembly 比 Docker 快 100 倍
大家如果做 serverless 或者做容器服务，有一个诟病很多的问题就是冷启动慢。AWS 有预留实例（reserve instance），如果要 keep hot，就违背了无服务器的初衷。用 serverless，我想要的是按毫秒付费，结果我现在先要把东西给 reserve 起来，变成了按天付费。WebAssembly 有一个很大的优势，就是不用启动整个操作系统，所以它在冷启动的时候性能超过 Docker 100倍。
-
在执行时间上，WebAssembly 比 Docker 快 10%-50%
WebAssembly 是一个非常简单的虚拟机，没有操作系统那套东西，所以它在运行时性能也比 Docker 快 10%-50%。
-
WebAssembly 占用的空间更小
WebAssembly 的应用一般在 1MB 以下，而 Docker 镜像经常就能够达到一两百 MB。
-
WebAssembly 有一个现代的安全模型
WebAssembly 安全策略是“Capability-based Security”，一种基于给定资源的安全性控制策略。可以有针对性地为每一个独立的模块实例提供不同的操作系统接口/资源权限。这些操作系统接口或资源权限可以在每个模块进行实例化时被调用者主动指定。
-
WebAssembly 使软件更具有可组合性
目前有一个 serverless 应用架构叫做 JAMStack，一个 JavaScript 应用后面可能会有 100 个甚至 1000 个 serverless 函数。我们需要把这些 serverless 函数组合在一起。如果我们用容器来做的话，其实是一件非常重的事。因为这要从网络或者操作系统层次来做。但是使用 WebAssembly 可以通过“nanoprocess”，在有安全控制的情况下，将这些函数组合在一起。
-
WebAssembly 无缝支持服务器应用程序框架
如 Node.js，Python 等。
以上就是 WebAssembly 相对于 Docker 的优势所在。
WebAssembly 和 Rust
讲到 WebAssembly，不能不讲的就是 Rust。Rust 已经连续 5 年在 Stack Overflow 上成为开发者最受欢迎的语言，大有取代 C 语言的趋势。
因为 WebAssembly 与 LLVM 相接，所以前端可以支持 20 种语言，但是对有 runtime 的语言比如 Python 和 Java 不能很好地支持，对 C++、Rust 等语言支持较好。所以我们觉得 WebAssembly 和 Rust 是天生一对，就像 Java 和 JVM 一样。
Rust 提高了开发者的效率和内存的安全。WebAssembly 提高了运行时的安全与跨平台的执行。而且他们同时都是高性能的和轻量级的。
WebAssembly System Interface（WASI）
WASI 类似于 Java 的 JNI。WebAssembly 之前一直是一个浏览器里的技术，今年要把它放到服务器端，如果要访问文件系统、线程、命令、服务器上的标准库等等，那么就必须通过 WASI。
另外比如说 serverless 的一个主要应用场景是 AI 推理，那么就需要在 WebAssembly 的 runtime 里能够用 GPU、ASIC、TensorFlow 等，这些都是通过 WASI 加入进来的。
WebAssembly 和 Kubernetes 结合
WebAssembly 在浏览器里普及率高，但在服务器端普及率低，这是因为在服务器端它的调度能力不强，缺乏 DevOps 的解决方案。目前是需要自身去管理进程，管理资源分配。所以能够把 WebAssembly 和 Kubernetes 结合起来，是一个非常前沿的领域。
其中一种方法是把 WebAssembly 做成 OCI（open container interface） compliant，另一种方法是在 containerd 里面写 shim API。
现在有不同的人涉足这个领域，包括我们自己，但是目前还是一个比较早期的项目阶段。也希望大家能够关注这个项目，跟我们讨论更好的做法。
上图中的这个链接，是阿里云做的，采用的第二种方法。
上文讲到 Docker 的创始人发布的推特在社区造成了很大影响，引发了很多 Docker 粉丝的不满。为了平息大家的怨言，他又发布了一条推特。事实上一年半之后，我们发现情况完全不是这样的，他应该把 Docker 这个字改成 Kubernetes。
WebAssembly 会取代 Docker 吗？
即便 WebAssembly 能够取代 Docker，也不会很快。Docker 有自己的生态，而且与 WebAssembly 不在同一个抽象的层级，所以不是一个新的 runtime 能够很快就取代的。
但是 WebAssembly 在有些方面会有很大的应用，包括需要有高性能的和轻量级的，比如微服务、JAMStack、边缘计算等。
这是我们的网站，，欢迎大家一起交流！
关于 KubeSphere
KubeSphere （https://kubesphere.io）是在 Kubernetes 之上构建的开源容器混合云，提供全栈的 IT 自动化运维的能力，简化企业的 DevOps 工作流。
KubeSphere 已被 Aqara 智能家居、本来生活、新浪、华夏银行、四川航空、国药集团、微众银行、紫金保险、中通、中国人保寿险、中国太平保险、中移金科、Radore、ZaloPay 等海内外数千家企业采用。KubeSphere 提供了开发者友好的向导式操作界面和丰富的企业级功能，包括多云与多集群管理、Kubernetes 资源管理、DevOps (CI/CD)、应用生命周期管理、微服务治理 (Service Mesh)、多租户管理、监控日志、告警通知、审计事件、存储与网络管理、GPU support 等功能，帮助企业快速构建一个强大和功能丰富的容器云平台。
以上是关于云原生计算能消除技术债务吗？的主要内容，如果未能解决你的问题，请参考以下文章