当涉及到 CPU 的时候，有许多术语：AArch64、x86\_64、amd64、arm 等等。了解它们是什么以及它们之间的区别。

当你查看数据表或软件下载页面时是否被 ARM、AArch64、x86_64、i386 等术语混淆？这些被称为 CPU 架构，我会帮你深入了解这个计算话题。

以下的表将为你总结每个字符串所代表的意义：

从左到右是使用该术语来描述 CPU 架构超过其右侧其他可选用术语的偏好。

从左到右是使用该术语描述 CPU 架构的优先级，使用左侧的而不是其右侧的其他可供选择的术语。

如果你像我一样是个极客，并想要更深入地解释，请继续阅读！

概述：CPU 架构

通常来说，我之前列出的术语是描述 CPU 架构的。但严格讲，它们被计算机工程师视为 CPU 的 指令集架构 Instruction Set Architecture （ISA）。

CPU 的指令集架构定义了 CPU 如何解析二进制代码中的 1 和 0。

这些 CPU 的 ISA 有几个主要的类别：

• x86（AMD/英特尔）
• ARM
• RISC-V
• PowerPC（IBM 仍在使用）

当然，还有更多种类的 CPU ISA，比如 MIPS、SPARC、DEC Alpha 等等。但我列出的这些至今仍然被广泛使用（以某种形式）。

上述列出的 ISA 主要根据 内存总线的宽度 分为至少两个子集。内存总线的宽度指的是 CPU 和 RAM 一次能传输的位数。内存总线有很多种宽度，但最常见的是 32 位和 64 位。

? 32 位的 CPU ISA 要么是已经过时的历史产物，被留下来要么只是为了支持旧的系统，要么只运用在微控制器中。可以说，所有新的硬件都已经是 64 位的了，特别是那些面向消费者的硬件。

x86（AMD/英特尔）

x86 CPU 的指令集架构主要源于英特尔，因为英特尔是最初搭配 8085 微处理器创建了它。8085 微处理器的内存总线宽度为 16 位。而后来，AMD 加入了这个领域，并且一直紧随英特尔的步伐，直到 AMD 创建出了自己的超集 64 位架构，超过了英特尔。

x86 架构的子集如下：

• i386：如果你拥有的是 2007 年之前的 CPU，那么这可能就是你的 CPU 架构。它是现在使用的 AMD/英特尔的 x86 架构的 32 位“版本”。
• x86_64/x86/amd64：这三个术语在不同的项目中可能会被交替使用。 但它们都是指 x86 AMD/英特尔架构的 64 位“版本”。无论如何，x86_64 这个字符串比 x86 和 amd64 使用得更广泛（也更受欢迎）。例如，FreeBSD 项目称 64 位的 x86 架构为 amd64，而 Linux 和 macOS 则称之为 x86_64。

? 由于 AMD 在创造 64 位 ISA 上超越了英特尔，所以一些项目（比如 FreeBSD）把 x86 的 64 位版本称为 amd64。但更被广泛接受的术语还是 x86\_64。

对于 CPU ISA，“x86” 这个字符串是一种特殊的情况。你要知道，在从 32 位的 x86（i386）到 64 位的 x86（x86_64）的过渡过程中，CPU 制造商确保了 CPU 能够运行 32 位 和 64 位指令。所以，有时你可能会看到 x86 也被用来意指“这款产品只能运行在 64 位的计算机上，但如果该计算机能运行 32 位指令，那么你也可以在它上面运行 32 位的用户软件”。

这种 x86 的模糊性——也就是诸如能同时运行 32 位代码的 64 位处理器——其主要用于和存在于运行在 64 位处理器上的，但是允许用户运行 32 位软件的操作系统，Windows 就通过这种被称作“兼容模式”的特性运用了这种方式。

汇总一下，由 AMD 和 英特尔 设计的 CPU 有两种架构：32 位的（i386）和 64 位的（x86_84）。

其它的英特尔

x86_64 ISA 实际上有几个子集。这些子集都是 64 位，但它们新添加了诸如 SIMD（ 单指令多数据 Single Instruction Multiple Data ）指令等功能。

• x86_64-v1：这是大多数人都熟知的基础 x86_64 ISA。当人们谈论 x86_64 时，他们通常指的就是 x86_64-v1 ISA。
• x86_64-v2：此版本新增了更多如 SSE3（ 流式 SIMD 扩展版本 3 Streaming SIMD Extensions 3 ）之类的指令扩展。
• x86_64-v3：除了基础指令外，还新增了像 AVX（ 高级矢量扩展 Advance Vector eXtensions ）和 AVX2 等指令。这些指令可以使用高达 256 位宽的 CPU 寄存器！如果你能够有效利用它们，就能大规模并行处理计算任务。
• x86_64-v4：这个版本在 x86_64-v3 ISA 的基础上，迭代了更多的 SIMD 指令扩展，比如 AVX256 和 AVX512。其中，AVX512 可以使用高达 512 位宽的 CPU 寄存器！

ARM

ARM 不仅是一家为 CPU ISA 制定规范的公司，它也设计并授权给其他厂商使用其 CPU 内核，甚至允许其他公司使用 ARM CPU ISA 设计自己的 CPU 内核。（最后那句话听起来就像是个 SQL 查询似的！）

你可能因为如树莓派这类的 单板计算机 Single Board Computer ）（SBC）听说过 ARM。但其实 ARM 的 CPU 还广泛应用于手机中。最近，苹果从使用 x86_64 处理器转向了在其笔记本和台式机产品中使用自家设计的 ARM 处理器。

就像任一种 CPU 架构一样，ARM 基于内存总线宽度也有两个子集。

官方认定的 32 位和 64 位 ARM 架构的名称分别是 AArch32 和 AArch64。这里的 AArch 字符串代表 “ Arm 架构 Arm Architecture ”。这些是 CPU 执行指令时可切换的模式。

实际符合 ARM 的 CPU ISA 的指令规范被命名为 ARMvX，其中 X 是规范版本的代表数字。目前为止，已经有九个主要的规范版本。规范 ARMv1 到 ARMv7 定义了适用于 32 位 CPU 的架构，而 ARMv8 和 ARMv9 是适用于 64 位 ARM CPU 的规范。（更多信息在此）

? 每个 ARM CPU 规范又有进一步的子规范。例如 ARMv8，我们有 ARMv8-R、ARMv8-A、ARMv8.1-A、ARMv8.2-A、ARMv8.3-A、ARMv8.4-A、ARMv8.5-A、ARMv8.6-A、ARMv8.7-A、ARMv8.8-A 和 ARMv8.9-A。 其中 -A 表示“应用核心”，-R 表示“实时核心”。

你可能会觉得困惑，为什么在 AArch64 正式被 ARM 认定为 64 位 ARM 架构后，有些人仍然称其为 arm64。原因主要有两点：

1. arm64 这个名称在 ARM 决定采用 AArch64 之前就已经广为人知了。（ARM 的一些官方文档也将 64 位的 ARM 架构称为 arm64…… ?）
2. Linus Torvalds 对 AArch64 这个名称表示不满。 因此，Linux 的代码库主要将 AArch64 称为 arm64。然而，当你在系统中运行 uname -m 时，输出仍然是 aarch64。

因此，对于 32 位 ARM CPU，你应该寻找 AArch32 这个字符串，但有时也可能是 arm 或 armv7。相似的，对于 64 位 ARM CPU，你应该找 AArch64 这个字符串，但有时也可能会是 arm64、ARMv8 或 ARMv9。

RISC-V

RISC-V 是 CPU 指令集架构（ISA）的一个开源规范。**但这并不意味着 CPU 自身是开源的！**这有点像以太网的情况。以太网规范是开源的，但你需付费购买网线、路由器和交换器。同样，RISC-V CPU 也要花钱购买。 ?

尽管如此，这并没有阻止人们创建并在开源许可下提供免费获取（设计上的获取，并非物理核心/SoC）的 RISC-V 核心。这是其中的一项尝试。

? 总结一下：如果你在寻找运行于 RISC-V 消费级 CPU 上的软件，你应该寻找 “rv64gc” 这一字符串。这是许多 Linux 发行版所公认的。

像所有 CPU 架构一样，RISC-V 拥有 32 位和 64 位 CPU 架构。但由于 RISC-V 是非常新的描述 CPU ISA 的方式，大部分主流消费端或客户端的 CPU 核心一般都是 64 位的。大部分 32 位的设计都是微控制器，用于非常具体的用例。

它们的区别在于 CPU 的扩展。被称为 RISC-V CPU 的最低要求即实现“ 基本整数指令集 Base Integer Instruction Set ”（rv64i）。

下表列出了一些扩展及其描述：

在 rv64i 这一字符串中，rv 表示 RISC-V，64 指的是 64 位 CPU 架构，而 i 指的是强制性的基本整数指令集扩展。 rv64i 之所以是一体的，因为即使 i 被认为是一种“扩展”，但它是必须的。

约定俗成的，扩展名称按上述特定顺序排列。因此，rv64g 展开为 rv64imafd，而不是 rv64adfim。

? 还有其他一些像 Zicsr 和 Zifencei 这样的扩展，它们位于 d 和 g 扩展之间，但我故意不列出，以避免令你感到害怕。

因此，严格说来，（在写这篇文章的时候）rv64g 实际上是 rv64imafdZicsrZifencei。恶魔般的笑声

PowerPC

PowerPC 曾是苹果、IBM 以及，摩托罗拉早期合作时代的一种流行 CPU 架构。在苹果转向英特尔的 x86 架构之前，它一直被应用于苹果的全部消费品产品线。

最初，PowerPC 采取的是大端字节序的内存排序。后来随着 64 位架构的引入，增加了使用小端字节排序的选项。这么做的目的是为了与英特尔的内存排序保持兼容（以防止软件错误），因为英特尔自始至终都一直采用的是小端字节序。有关字节序的更多内容，我可以唠叨很久，不过你可以通过阅读 这篇 Mozilla 的文档 来了解更多。

由于字节序在此也起到了一定的作用，PowerPC 共有三种架构：

• powerpc：表示 32 位的 PowerPC 架构。
• ppc64：表示拥有大端字节序内存排序的 64 位 PowerPC 架构。
• ppc64le：表示拥有小端字节序内存排序的 64 位 PowerPC 架构。

目前，ppc64le 是被广泛使用的架构。

结论

市面上有各种各样的 CPU 架构。对于每一种架构，都有 32 位和 64 位的子集。在现有的 CPU 中，我们可以找到 x86、ARM、RISC-V 和 PowerPC 等架构。

其中，x86 是最广泛和易于获取的 CPU 架构，因为英特尔和 AMD 都采取了这种架构。此外，ARM 提供的产品几乎在手机和易于获取的单板计算机中被独占使用。

RISC-V 正在努力使硬件更广泛地被使用。我就有一款带有 RISC-V CPU 的单板计算机。 ?

而 PowerPC 主要用于服务器，至少当前如此。

（题图：MJ/634ac7ea-b344-443a-b041-3bb3b31a956f）

via: https://itsfoss.com/arm-aarch64-x86_64/

作者：Pratham Patel 选题：lujun9972 译者：ChatGPT 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

我正在制作一份有关计算机以二进制表示事物的小册子，有人问我一个问题 - 为什么 x86 架构使用 8 位字节？为什么不能是其他大小呢？

对于类似这样的问题，我认为有两种可能性：

• 这是历史原因造成的，其他尺寸（如 4、6 或 16 位）同样有效。
• 8 位是客观上的最佳选择，即使历史发展不同，我们仍然会使用 8 位字节。
• 一些混合 1 和 2 的因素。

我对计算机历史并不是非常着迷（与阅读计算机文献相比，我更喜欢使用计算机），但我总是很好奇计算机事物今天的方式是否存在本质原因，或者它们大多是历史偶然的结果。因此，我们将谈论一些计算机历史。

作为历史偶然性的一个例子：DNS 有一个 class 字段，它有 5 种可能的值（internet、chaos、hesiod、none 和 any）。 对我来说，这是一个明显的历史意外的例子 - 如果我们今天重新设计 DNS 而不必担心向后兼容性，我无法想象我们会以相同的方式定义类字段。我不确定我们是否会使用 class 字段！

这篇文章没有明确的答案，但我在 Mastodon 上提问，并找到了一些潜在的 8 位字节原因。我认为答案是这些原因的某种组合。

字节和字有什么区别？

首先，本文中经常提到 “ 字节 byte ” 和 “ 字 word ”。它们有什么区别？我的理解是：

• 字节的大小 是你可以寻址的最小单元。例如，在我的计算机上，程序中的 0x20aa87c68 可能是一个字节的地址，然后 0x20aa87c69 是下一个字节的地址。
• 字的大小 是字节大小的某个倍数。我对此困惑了多年，维基百科的定义非常模糊（“字是特定处理器设计使用的自然数据单元”）。我最初认为字大小与寄存器大小相同（在 x86-64 上为 64 位）。但是根据 英特尔架构手册 的第 4.1 节（“基本数据类型”），在 x86 上，虽然寄存器是 64 位的，但一个字是 16 位的。因此我困惑了 —— 在 x86 上，一个字是 16 位还是 64 位？它可以根据上下文而有不同的含义吗？这是怎么回事？

现在让我们来讨论一些使用 8 位字节的可能原因！

原因 1：将英文字母适配到 1 字节中

维基百科文章 表示 IBM System/360 于 1964 年引入了 8 位字节。

在管理该项目的 Fred Brooks 的一段 视频采访 中，他讲述了原因。以下是我转录的一些内容：

…… 6 位字节在科学计算中确实更好，而 8 位字节则更适合商业计算，每个字节都可以针对另一个字节进行调整，以使两种字节互相使用。

因此，这变成了一个高管决策，我决定根据 Jerry 的建议采用 8 位字节。

……

我在我的 IBM 职业生涯中做出的最重要的技术决策是为 360 选择 8 位字节。

我相信字符处理将变得重要，而不是十进制数字。

使用 8 位字节处理文本很有道理：2 ⁶ 为 64，因此 6 位不足以表示小写字母、大写字母和符号。

为了使用 8 位字节，System/360 还引入了 EBCDIC 编码，这是一种 8 位字符编码。

接下来在 8 位字节历史上重要的机器似乎是 英特尔 8008，它设计用于计算机终端（Datapoint 2200）。终端需要能够表示字母以及终端控制代码，因此使用 8 位字节对其来说很有意义。计算机历史博物馆上的 Datapoint 2200 手册 在第 7 页上说 Datapoint 2200 支持 ASCII（7 位）和 EBCDIC（8 位）。

为什么 6 位字节在科学计算中更好？

我对这条 “6 位字节在科学计算中更好” 的评论很好奇。以下是 Gene Amdahl 的一段采访摘录：

我原本希望采用 24 和 48 而非 32 和 64，因为这将为我提供一个更合理的浮点系统。因为在浮点运算中，使用 32 位字大小时，你必须将指数保持在 8 位中用于指数符号，并且要使其在数字范围上合理，你必须每次调整 4 个位而不是单个位。因此，这将导致你比使用二进制移位更快地失去一些信息。

我完全不理解这条评论 - 如果你使用 32 位字大小，为什么指数必须是 8 位？如果你想要，为什么不能使用 9 位或 10 位？但这是我在快速搜索中找到的全部内容。

为什么大型机使用 36 位？

与 6 位字节相关的问题是：许多大型机使用 36 位字大小。为什么？在维基百科的 36 位计算 文章中有一个很好的解释：

在计算机问世之前，即需要高精度科学和工程运算的领域，使用的是十位数码电动机械计算器……这些计算器每位数码均有一个专用按键，操作人员在输入数字时需要用到所有手指，因此，虽然有些专业计算器有更多位数码，但这种情况是个实际的限制。

因此，早期针对相同市场的二进制计算机通常使用 36 位字长度。这足以表示正负整数最高精度到十位数字（最小应为 35 位）。

因此，这种 36 位大小似乎是基于

的，它等于 34.2。嗯。

我猜这个原因是在 50 年代，计算机非常昂贵。因此，如果您想要你的计算机支持十位十进制数字，你将设计它恰好具有足够的位来执行此操作，而不会更多。

现在计算机更快更便宜，因此，如果您想要出于某种原因表示十位十进制数字，你只需使用 64 位即可 - 浪费一点空间通常并不会有太大问题。

还有人提到，一些具有 36 位字大小的计算机可以让你选择字节大小 - 根据上下文，你可以使用 5 或 6 或 7 或 8 位字节。

原因 2：与二进制编码的十进制一起工作

20 世纪 60 年代，有一种流行的整数编码叫做 二进制编码的十进制 binary-coded decimal （缩写为 BCD），它将每个十进制数字编码为 4 位。

例如，如果你想要编码数字 1234，在 BCD 中，它会是这样的：

0001 0010 0011 0100

因此，如果你想要能够轻松地与二进制编码的十进制一起工作，你的字节大小应该是 4 位的倍数，比如 8 位！

为什么 BCD 很流行？

这个整数表示方法对我来说真的很奇怪 —— 为什么不用更有效率的二进制来存储整数呢？在早期的计算机中，效率非常重要！

我最好的猜测是，早期的计算机没有像我们现在这样的显示器，所以一个字节的内容被直接映射到开关灯上。

这是来自维基百科一个带有一些亮灯的 IBM 650 显示器的图片（CC BY-SA 3.0 许可）：

因此，如果你想让人们能够相对容易地从二进制表示中读取十进制数，这样做就更有意义了。我认为，今天 BCD 已经过时了，因为我们拥有显示器，并且我们的计算机可以将用二进制表示的数字转换为十进制，并显示它们。

此外，我想知道，“ 四位 nibble ”（意为 “4 位”）这个词是不是来自 BCD 的。在 BCD 的上下文中，你经常会引用半个字节（因为每个十进制数字是 4 位）。所以有一个 “4 位” 的词语是有意义的，人们称 4 个位为 “ 四位 nibble ”。今天，“四位” 对我来说感觉像是一个古老的词汇，除了作为一个趣闻我肯定从未使用过它（它是一个很有趣的词！）。维基百科关于 “四位” 的文章支持了这个理论：

“四位” 用来描述存储在 IBM 大型计算机中打包的十进制格式（BCD）中数字的位数。

还有一个人提到 BCD 的另一个原因是 金融计算。今天，如果你想存储美元金额，你通常只需使用整数的分数，然后在需要美元部分时除以 100。这没什么大不了的，除法很快。但显然，在 70 年代，将一个用二进制表示的整数除以一个 100 是非常慢的，所以重新设计如何表示整数，以避免除以 100 是值得的。

好了，关于 BCD 就说这么多。

原因 3：8 是 2 的幂？

许多人说，CPU 的字节大小是 2 的幂次方很重要。我无法确定这是真的还是假的，而且我对 “计算机使用二进制，所以 2 的幂次方很好” 这种解释感到不满意。这似乎非常合理，但我想深入探讨一下。而且从历史上看，肯定有很多使用字节大小不是 2 的幂次方的机器，例如（来自这个来自 Stack Exchange 上复古计算版块的 帖子）：

• Cyber 180 大型机使用 6 位字节
• Univac 1100/2200 系列使用 36 位字长
• PDP-8 是一台 12 位计算机

一些我听到的关于 2 的幂次方很好的原因我还没有理解：

• 一个单词中的每个位都需要一个总线，而你希望总线数量是 2 的幂次方（为什么？）
• 很多电路逻辑容易针对分而治之的技术（我需要一个例子来理解这个）

对我更有意义的原因是：

• 它使设计“时钟分频器”更容易，这些分频器可以测量“在这条线路上发送了 8 位”，分别基于减半进行操作 - 你可以将 3 个减半时钟分频器串联起来。Graham Sutherland 告诉我这个，他制作了这个非常酷的 分频器模拟器，展示了这些分频器的工作原理。该网站（Falstad）还有很多其他示例电路，似乎是制作电路模拟器的一个非常酷的方式。
• 如果你有一个指令可以将字节中的特定位清零，则如果你的字节大小为 8（2 的 3 次方），你可以只使用 3 位指令来指示哪一位。x86 似乎没有这样做，但 Z80 的位测试指令 是这样做的。
• 有人提到一些处理器使用 进位前瞻加法器，它们按 4 位分组。经过一些快速的谷歌搜索，似乎有各种各样的加法器电路。
• 位图：你计算机的内存被组织成页（通常大小为 2 的 n 次方）。它需要跟踪每一页是否空闲。操作系统使用位图来完成这项工作，其中每个位对应一页，并且根据页面是空闲还是占用，值为 0 或 1。如果你有一个 9 位的字节，你需要除以 9 来在位图中找到你要查找的页面。除以 9 的速度比除以 8 慢，因为除以 2 的幂次方总是最快的。

我可能很糟糕地扭曲了其中一些解释：在这里，我非常超出了自己的知识领域。我们继续前进吧。

原因 4：小字节大小很好

你可能会想：好吧，如果 8 位字节比 4 位字节更好，为什么不继续增加字节大小呢？我们可以有 16 位字节啊！

有几个保持字节大小较小的理由：

• 它是一种空间浪费 —— 字节是你可以寻址的最小单位，如果你的计算机存储了大量的 ASCII 文本（只需要 7 位），那么每个字符分配 12 或 16 个位相当浪费，而你可以使用 8 个位代替。
• 随着字节变得越来越大，你的 CPU 需要变得更复杂。例如，你需要每个位线路一条总线线路。因此，我想简单总是更好。

我对 CPU 架构的理解非常薄弱，所以就说到这里吧。对我来说，“这是一种空间浪费” 的理由似乎相当有说服力。

原因 5：兼容性

英特尔 8008（1972 年）是 8080（1974 年）的前身，8080 是第一款 x86 处理器 8086（1976 年）的前身。似乎 8080 和 8086 很受欢迎，这就是我们现代 x86 计算机的来源。

我认为这里有一个 “如果它好好的就不要动它” 的问题 - 我假设 8 位字节功能良好，因此英特尔看不到需要更改设计的必要性。如果你保持相同的 8 位字节，那么你可以重复使用更多指令集。

此外，80 年代左右我们开始出现像 TCP 这样的网络协议，它们使用 8 位字节（通常称为“ 八位组 octet ”），如果你要实现网络协议，你可能希望使用 8 位字节。

就这些！

在我看来，8 位字节的主要原因是：

• 很多早期的电脑公司都是美国的，美国使用最广泛的语言是英语
• 这些人希望计算机擅长文本处理
• 较小的字节大小通常更好
• 7 位是你可以用来容纳所有英文字母和标点符号的最小尺寸
• 8 比 7 更好（因为它是 2 的幂次方）
• 一旦有得到成功应用的受欢迎的 8 位计算机，你希望保持相同的设计以实现兼容性。

有人指出 这本 1962 年的书 第 65 页谈到了 IBM 选择 8 位字节的原因，基本上说了相同的内容：

1. 其完整的 256 个字符的容量被认为足以满足绝大多数应用程序的需要。
2. 在该容量范围内，单个字符由单个字节表示，因此任何特定记录的长度并不因该记录中字符而异。
3. 8 位字节在存储空间上是相当经济的。
4. 对于纯数字工作，一个十进制数字只需要 4 个比特表示，两个这样的 4 位字节可以打包成一个 8 位字节。尽管这种数字数据包装不是必需的，但为了提高速度和存储效率，它是一种常见做法。严格来说，4 位字节属于不同的代码，但与 4 位及 8 位方案相比，它们的简单性导致了更简单的机器设计和更清晰的寻址逻辑。
5. 4 位和 8 位的字节大小，作为 2 的幂次方，允许计算机设计师利用二进制寻址和位级索引的强大功能（见第 4 章和第 5 章）。

总的来说，如果你在英语国家设计二进制计算机，选择 8 位字节似乎是一个非常自然的选择。

（题图：MJ/3526a0d5-bee5-4678-8637-e96e9843b53c）

via: https://jvns.ca/blog/2023/03/06/possible-reasons-8-bit-bytes/

作者：Julia Evans 选题：lkxed 译者：ChatGPT 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

在将嵌入式系统操作系统移植到不同的芯片架构时，RT-Thread 的维护者们从中学到了什么。

曾经有人问我，为什么计算机被称为“计算机”，它们做的事情可远不止计算数字。一台现代的个人电脑可以浏览互联网、播放音频和视频、为视频游戏和电影生成漂亮的图形、模拟和预测复杂的天气模式和流行病风险、将建筑和工程蓝图变为现实等等。

计算机之所以能做到这些，是因为所有这些问题都可以归结为数字方程，而计算机的 CPU —— 其中央处理单元 —— 实际上不过是一个简单的计算器。

为了让 CPU 向硬盘驱动器发送信号以写入数据，或向显示器发送信号以显示图像，它必须接收指令。这些指令是以 “代码” 的形式出现的，这是一种简明的说法，即必须有人写一个 程序 ，与CPU “说” 同样的语言。CPU 理解的是 机器语言，这是一个大多数人都无法理解的比特阵列，大多数人都不可能手动写出来。相反，我们使用像 C、C++、Java、Python 等编程语言。这些语言被解析并编译成机器语言，然后交付给 CPU。

如果你试图用一种它不理解的语言来指示 CPU，它不知道该怎么做。你可以通过尝试用 x86\_64 RHEL 镜像启动 树莓派 来体验这种误传尝试的尴尬结果。如果它能工作就好了，但是不能。

将一个操作系统移植到一个新的架构上

RT-Thread 项目 为嵌入式系统程序员提供了一个开源的操作系统（OS）。嵌入式领域是非常多样化的，有很多物联网（IoT）、定制工业和业余设备。RT-Thread 的目标是使嵌入式编程对每个人来说都很容易，无论你使用什么设备。有时，这意味着要将一个操作系统移植到一个新的架构上，不管是用于相同架构但指令集略有不同的的芯片，还是用于全新的架构。

一开始处理这个问题可能会有点吓人 —— 你可能不知道从哪里开始或如何开始。这篇文章收集了 RT-Thread 维护者在将 RTOS 移植到新的芯片架构时学到的经验。

你在开始之前需要知道什么

这里是一个看似难以逾越的过程的高屋建瓴的观点。这对你的项目来说可能有所不同，但从概念上来说，这是相对普遍的，即使一些具体的细节是不同的：

1. 准备好一个 C 语言的执行环境
2. 确认可以通过串行端口发送和接收字符
3. 确认上下文切换代码可以工作
4. 获取支持的硬件定时器
5. 确认中断程序可以通过串口接收和解析数据

执行模式

对于大多数先进的体系结构，操作系统和用户应用程序运行在不同的权限级别上。这可以防止有功能故障的代码影响操作系统的集成和安全。例如，在 ARMv7-A 架构中，操作系统通常在系统模式下运行，而在 ARMv8-A 中，操作系统可以在 EL2 或 EL3 权限级别上运行。

通常情况下，芯片在通电时以最高权限级别执行启动代码。但在此之后，操作系统会将特权级别切换到其目标模式。

1、执行 C 代码

这一步的关键动作是将 块起始符号 block starting symbol （.bss）部分设置为零，并设置堆栈指针。

在 C 语言的实现中，未初始化的全局变量和静态变量通常存储在 .bss 部分，它不占用存储设备的任何空间。当程序被加载时，相应的空间被分配到内存中，并被初始化为零。当操作系统启动时，它必须自己做这项工作。

另一方面，操作系统必须初始化堆栈空间并设置堆栈指针。由于 C 语言程序在进入和退出函数时在堆栈上保存和恢复局部变量，所以在调用任何 C 函数之前必须设置堆栈指针。RT-Thread 必须为每个新创建的线程做这个步骤。

2、至少使用一个串行驱动器

RT-Thread 通过串口输出信息和日志，这也有助于在移植过程中对代码进行调试。在这个阶段，通过串口 接收 数据是不必要的。当我们第一次在串口上看到我们友好的、熟悉的 RT-Thread 的标志时，我们就知道我们走对了路！

3、确认上下文切换逻辑

一个任务的上下文是它的整个执行环境，它包含通用寄存器、程序计数器、堆栈帧的位置等等。当一个新的线程被创建时，RT-Thread 必须手动分配和设置它的上下文，这样调度器就可以切换到新的线程，就像它对其他线程一样。

有三件事需要注意：

• 首先，当 RT-Thread 启动时，默认情况下中断是禁用的。当任务调度器第一次被启用时，它们就会被启用；这个过程是在上下文切换期间用汇编语言实现的。
• 第二，当一个线程退出时，下一个调度将开始，这时拥有的资源会被空闲的线程回收。
• 第三，数据被推入堆栈的顺序必须与从堆栈中弹出数据的顺序一致。

一般来说，你希望正常进入主函数和 msh 控制台。然而，在这个阶段无法实现输入控制，因为串行输入中断还没有实现。当串行中断实现后，就可以进行 msh 输入了。

4、设置定时器

RT-Thread 需要一个定时器来定期产生中断；它被用来计算自系统启动以来所经过的“滴答”。计数器的编号用于提供软件中断功能，并指示内核何时开始调度一个任务。

设置时间片的值可能是一件棘手的事情。它通常是 10ms 到 1ms。如果你在一个慢速的 CPU 上选择一个小的时间片，大部分时间就会花在任务切换上 —— 不利于完成其他事情。

5、确认串口工作正常

在这一步，我们通过串口与 RT-Thread msh 进行交互。我们发送命令，按回车键，然后看着 msh 执行命令并显示结果。

这个过程通常不难实现。不过，有一点要提醒大家。在某些平台上，在处理完串口中断后，别忘了清除中断标志。

一旦串口工作正常，移植过程基本上就完成了。

实践

为了将你的项目移植到不同的芯片架构上，你需要非常清楚地了解你所针对的芯片的架构。熟悉你的项目中最关键的部分的底层代码。通过对照芯片的手册结合大量的实际工作经验，你会了解芯片的特权模式、寄存器和编译方法。

如果你没有需要移植到新芯片的项目，请加入我们；RT-Thread 项目总是需要帮助将 RTOS 移植到新的芯片上！作为一个开源项目，RT-Thread 正在改变开源嵌入式编程的面貌。请在 RT-Thread 俱乐部介绍你自己并寻求帮助!

本文基于 DEV 社区上的 如何将操作系统移植到不同的芯片架构上？，并经许可转载。

via: https://opensource.com/article/21/5/port-chip-architectures

作者：Alan Smithee 选题：lujun9972 译者：wxy 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

任何一种架构都是有利有弊的，而能满足你组织的独特需要的决策才是正确的选择。

对于许多初创公司来说，传统的知识认为，从单一整体架构开始，而不是使用微服务。但是，我们还有别的选择吗？

这本新书 —— 《初创公司的微服务》，从许多 CIO 们理解的微服务的角度，解释了微服务的优点与缺点。

对于初创公司，虽然不同的 CTO 对此给出的建议是不同的，但是他们都一致认为环境和性能很重要。如果你正考虑你的业务到底是采用微服务还是单一整体架构更好，下面讨论的这些因素正好可以为你提供一些参考。

理解范围

首先，我们先来准确定义我们所谓的 “整体服务” 和 “微服务” 是什么。

微服务是一种方法，它开发一个单一的应用程序来作为构成整体服务的小服务，每个小服务都运行在它自己的进程中，并且使用一个轻量级的机制进行通讯，通常是一个 HTTP 资源的 API。这些服务都围绕业务能力来构建，并且可依赖全自动部署机制来独立部署。

一个整体应用程序是按单个的、统一的单元来构建，并且，通常情况下它是基于一个大量的代码来实现的。一般来说，一个整体服务是由三部分组成的：数据库、客户端用户界面（由 HTML 页面和/或运行在浏览器中的 JavaScript 组成）、以及服务器端应用程序。

“系统架构处于一个范围之中”，Zachary Crockett，Particle 的 CTO，在一次访谈中，他说，“在讨论微服务时，人们倾向于关注这个范围的一端：许多极小的应用程序给其它应用程序传递了过多的信息。在另一端，有一个巨大的整体服务做了太多的事情。在任何现实中的系统上，在这两个极端之间有很多合适的面向服务的架构”。

根据你的情况不同，不论是使用整体服务还是微服务都有很多很好的理由。

“我们希望为每个服务使用最好的工具”，Julien Lemoine 说，他是 Algolia 的 CTO。

与很多人的想法正好相反，整体服务并不是过去遗留下来的过时的架构。在某些情况下，整体服务是非常理想的。我采访了 Steven Czerwinski 之后，更好地理解了这一点，他是 Scaylr 的工程主管，前谷歌员工。

“尽管我们在谷歌时有使用微服务的一些好的经验，我们现在 [在 Scalyr] 却使用的是整体服务的架构，因为一个整体服务架构意味着我们的工作量更少，我们只有两位工程师。“ 他解释说。（采访他时，Scaylr 正处于早期阶段）

但是，如果你的团队使用微服务的经验很丰富，并且你对你们的发展方向有明确的想法，微服务可能是一个很好的替代者。

Julien Lemoine，Algolia 的 CTO，在这个问题上，他认为：“我们通常从使用微服务开始，主要目的是我们可以使用不同的技术来构建我们的服务，因为如下的两个主要原因：

• 我们想为每个服务使用最好的工具。我们的搜索 API 是在底层做过高度优化的，而 C++ 是非常适合这项工作的。他说，在任何其它地方都使用 C++ 是一种生产力的浪费，尤其是在构建仪表板方面。
• 我们希望使用最好的人才，而只使用一种技术将极大地限制我们的选择。这就是为什么在公司中有不同语言的原因。

”

如果你的团队已经准备好从一开始就使用微服务，这样你的组织从一开始就可以适应微服务环境的开发节奏。

权衡利弊

在你决定那种方法更适合你的组织之前，考虑清楚每种方法的优缺点是非常重要的。

整体服务

优点：

• 很少担心横向联系： 大多数应用程序开发者都担心横向联系，比如，日志、速度限制、以及像审计跟踪和 DoS 防护这样的安全特性。当所有的东西都运行在同一个应用程序中时，通过组件钩子来处理这些关注点就非常容易了。
• 运营开销很少： 只需要为一个应用程序设置日志、监视、以及测试。一般情况下，部署也相对要简单。
• 性能： 一个整体的架构可能会有更好的性能，因为共享内存的访问速度要比进程间通讯（IPC）更快。

缺点：

• 紧耦合： 整体服务的应用程序倾向于紧耦合，并且应用程序是整体进化的，分离特定用途的服务是非常困难的，比如，独立扩展或者代码维护。
• 理解起来很困难： 当你想查看一个特定的服务或者控制器时，因为依赖、副作用、和其它的不可预见因素，整体架构理解起来更困难。

微服务

优点：

• 非常好组织： 微服务架构一般很好组织它们，因为每个微服务都有一个特定的工作，并且还不用考虑其它组件的工作。
• 解耦合： 解耦合的服务是能够非常容易地进行重组织和重配置，以服务于不同的应用程序（比如，同时向 Web 客户端和公共 API 提供服务）。它们在一个大的集成系统中，也允许快速、独立分发单个部分。
• 性能： 根据组织的情况，微服务可以提供更好的性能，因为你可以分离热点服务，并根据其余应用程序的情况来扩展它们。
• 更少的错误： 微服务允许系统中的不同部分，在维护良好边界的前提下进行并行开发。这样将使连接不该被连接的部分变得更困难，比如，需要连接的那些紧耦合部分。

缺点：

• 跨每个服务的横向联系点： 由于你构建了一个新的微服务架构，你可能会发现在设计时没有预料到的很多横向联系的问题。这也将导致需要每个横向联系点的独立模块（比如，测试）的开销增加，或者在其它服务层面因封装横向联系点，所导致的所有流量都需要路由。最终，即便是整体服务架构也倾向于通过横向联系点的外部服务层来路由流量，但是，如果使用整体架构，在项目更加成熟之前，也不过只是推迟了工作成本。
• 更高的运营开销： 微服务在它所属的虚拟机或容器上部署非常频繁，导致虚拟机争用激增。这些任务都是使用容器管理工具进行频繁的自动化部署的。

决策时刻

当你了解了每种方法的利弊之后，如何在你的初创公司使用这些信息？通过与这些 CTO 们的访谈，这里有三个问题可以指导你的决策过程：

你是在熟悉的领域吗？

如果你的团队有以前的一些领域的经验（比如，电子商务）和了解你的客户需求，那么分割成微服务是低风险的。如果你从未做过这些，从另一个角度说，整体服务或许是一个更安全的选择。

你的团队做好准备了吗？

你的团队有使用微服务的经验吗？如果明年，你的团队扩充到现在的四倍，将为微服务提供更好的环境？评估团队大小对项目的成功是非常重要的。

你的基础设施怎么样？

实施微服务，你需要基于云的基础设施。

David Strauss，Pantheon 的 CTO，他解释说："[以前]，你使用整体服务是因为，你希望部署在一个数据库上。每个单个的微服务都需要配置数据库服务器，然后，扩展它将是一个很重大的任务。只有大的、技术力量雄厚的组织才能做到。现在，使用像谷歌云和亚马逊 AWS 这样的云服务，为部署一个小的东西而不需要为它们中的每个都提供持久存储，对于这种需求你有很多的选择。“

评估业务风险

技术力量雄厚的初创公司为追求较高的目标，可以考虑使用微服务。但是微服务可能会带来业务风险。Strauss 解释说，“许多团队一开始就过度构建他们的项目。每个人都认为，他们的公司会成为下一个 ‘独角兽’，因此，他们使用微服务构建任何一个东西，或者一些其它的高扩展性的基础设施。但是这通常是一种错误的做法”。Strauss 说，在那种情况下，他们认为需要扩大规模的领域往往并不是一开始真正需要扩展的领域，最后的结果是浪费了时间和努力。

态势感知

最终，环境是关键。以下是一些来自 CTO 们的提示：

什么时候使用整体服务

• 你的团队还在创建阶段： 你的团队很小 —— 也就是说，有 2 到 5 位成员 —— 还无法应对大范围、高成本的微服务架构。
• 你正在构建的是一个未经证实的产品或者概念验证： 如果你将一个全新的产品推向市场，随着时间的推移，它有可能会成功，而对于一个快速迭代的产品，整体架构是最合适的。这个提示也同样适用于概念验证，你的目标是尽可能快地学习，即便最终你可能会放弃它。
• 你没有使用微服务的经验： 除非你有合理的理由证明早期学习阶段的风险可控，否则，一个整体的架构更适用于一个没有经验的团队。

什么时候开始使用微服务

• 你需要快速、独立的分发服务： 微服务允许在一个大的集成系统中快速、独立分发单个部分。请注意，根据你的团队规模，获取与整体服务的比较优势，可能需要一些时间。
• 你的平台中的某些部分需要更高效： 如果你的业务要求集中处理 PB 级别的日志卷，你可能需要使用一个像 C++ 这样的更高效的语言来构建这个服务，尽管你的用户仪表板或许还是用 Ruby on Rails 构建的。
• 计划扩展你的团队： 使用微服务，将让你的团队从一开始就开发独立的小服务，而服务边界独立的团队更易于按需扩展。

要决定整体服务还是微服务更适合你的组织，要坦诚并正确认识自己的环境和能力。这将有助于你找到业务成长的最佳路径。

关于作者

jakelumetta - Jake 是 ButterCMS 的 CEO，它是一个 API-first CMS。他喜欢搅动出黄油双峰，以及构建让开发者工作更舒适的工具，喜欢他的更多内容，请在 Twitter 上关注 @ButterCMS，订阅 他的博客。关于他的更多信息……

via: https://opensource.com/article/18/1/how-choose-between-monolith-microservices

作者：jakelumetta 译者：qhwdw 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

过去我们曾经发布过一些关于 Finagle 、Manhattan 这些项目的文章，还写过一些针对大型事件活动的架构优化的文章，例如天空之城、超级碗、2014 世界杯、全球新年夜庆祝活动等。在这篇基础设施系列文章中，我主要聚焦于 Twitter 的一些关键设施和组件。我也会写一些我们在系统的扩展性、可靠性、效率方面的做过的改进，例如我们基础设施的历史，遇到过的挑战，学到的教训，做过的升级，以及我们现在前进的方向等等。

天空之城：2013 年 8 月 2 日，宫崎骏的《 天空之城 （ Castle in the Sky ） 》在 NTV 迎来其第 14 次电视重播，剧情发展到高潮之时，Twitter 的 TPS（Tweets Per Second）也被推上了新的高度——143,199 TPS，是平均值的 25 倍，这个记录保持至今。-- LCTT 译注

数据中心的效率优化

历史

当前 Twitter 硬件和数据中心的规模已经超过大多数公司。但达到这样的规模不是一蹴而就的，系统是随着软硬件的升级优化一步步成熟起来的，过程中我们也曾经犯过很多错误。

有个一时期我们的系统故障不断。软件问题、硬件问题，甚至底层设备问题不断爆发，常常导致系统运营中断。出现故障的地方存在于各个方面，必须综合考虑才能确定其风险和受到影响的服务。随着 Twitter 在客户、服务、媒体上的影响力不断扩大，构建一个高效、可靠的系统来提供服务成为我们的战略诉求。

Twitter系统故障的界面被称为 失败鲸 （ Fail Whale ） ，如下图 -- LCTT 译注

挑战

一开始，我们的软件是直接安装在服务器，这意味着软件可靠性依赖硬件，电源、网络以及其他的环境因素都是威胁。这种情况下，如果要增加容错能力，就需要统筹考虑这些互不关联的物理设备因素及在上面运行的服务。

最早采购数据中心方案的时候，我们都还是菜鸟，对于站点选择、运营和设计都非常不专业。我们先直接托管主机，业务增长后我们改用租赁机房。早期遇到的问题主要是因为设备故障、数据中心设计问题、维护问题以及人为操作失误。我们也在持续迭代我们的硬件设计，从而增强硬件和数据中心的容错性。

服务中断的原因有很多，其中硬件故障常发生在服务器、机架交换机、核心交换机这地方。举一个我们曾经犯过的错误，硬件团队最初在设计服务器的时候，认为双路电源对减少供电问题的意义不大 -- 他们真的就移除了一块电源。然而数据中心一般给机架提供两路供电来提高冗余性，防止电网故障传导到服务器，而这需要两块电源。最终我们不得不在机架上增加了一个 ATS 单元（ 交流切换开关 （ AC transfer switch ） ）来接入第二路供电。

提高系统的可靠性靠的就是这样的改进，给网络、供电甚至机房增加冗余，从而将影响控制到最小范围。

我们学到的教训以及技术的升级、迁移和选型

我们学到的第一个教训就是要先建模，将可能出故障的地方（例如建筑的供电和冷却系统、硬件、光纤网络等）和运行在上面的服务之间的依赖关系弄清楚，这样才能更好地分析，从而优化设计提升容错能力。

我们增加了更多的数据中心提升地理容灾能力，减少自然灾害的影响。而且这种站点隔离也降低了软件的风险，减少了例如软件部署升级和系统故障的风险。这种多活的数据中心架构提供了 代码灰度发布 （ staged code deployment ） 的能力，减少代码首次上线时候的影响。

我们设计新硬件使之能够在更高温度下正常运行，数据中心的能源效率因此有所提升。

下一步工作

随着公司的战略发展和运营增长，我们在不影响我们的最终用户的前提下，持续不断改进我们的数据中心。下一步工作主要是在当前能耗和硬件的基础上，通过维护和优化来提升效率。

硬件的效率优化

历史和挑战

我们的硬件工程师团队刚成立的时候只能测试市面上现有硬件，而现在我们能自己定制硬件以节省成本并提升效率。

Twitter 是一个很大的公司，它对硬件的要求对任何团队来说都是一个不小的挑战。为了满足整个公司的需求，我们的首要工作是能检测并保证购买的硬件的品质。团队重点关注的是性能和可靠性这两部分。对于硬件我们会做系统性的测试来保证其性能可预测，保证尽量不引入新的问题。

随着我们一些关键组件的负荷越来越大（如 Mesos、Hadoop、Manhattan、MySQL 等），市面上的产品已经无法满足我们的需求。同时供应商提供的一些高级服务器功能，例如 Raid 管理或者电源热切换等，可靠性提升很小，反而会拖累系统性能而且价格高昂，例如一些 Raid 控制器价格高达系统总报价的三分之一，还拖累了 SSD 的性能。

那时，我们也是 MySQL 数据库的一个大型用户。SAS（ 串行连接 SCSI （ Serial Attached SCSI ） ）设备的供应和性能都有很大的问题。我们大量使用 1U 规格的服务器，它的磁盘和回写缓存一起也只能支撑每秒 2000 次的顺序 IO。为了获得更好的效果，我们只得不断增加 CPU 核心数并加强磁盘能力。我们那时候找不到更节省成本的方案。

后来随着我们对硬件需求越来越大，我们成立了一个硬件团队，从而自己来设计更便宜更高效的硬件。

关键技术变更与选择

我们不断的优化硬件相关的技术，下面是我们采用的新技术和自研平台的时间轴。

• 2012 - 采用 SSD 作为我们 MySQL 和 Key-Value 数据库的主要存储。
• 2013 - 我们开发了第一个定制版 Hadoop 工作站，它现在是我们主要的大容量存储方案。
• 2013 - 我们定制的解决方案应用在 Mesos、TFE（ Twitter Front-End ）以及缓存设备上。
• 2014 - 我们定制的 SSD Key-Value 服务器完成开发。
• 2015 - 我们定制的数据库解决方案完成开发。
• 2016 - 我们开发了一个 GPU 系统来做模糊推理和训练机器学习。

学到的教训

硬件团队的工作本质是通过做取舍来优化 TCO（总体拥有成本），最终达到达到降低 CAPEX（资本支出）和 OPEX（运营支出）的目的。概括来说，服务器降成本就是：

1. 删除无用的功能和组件
2. 提升利用率

Twitter 的设备总体来说有这四大类：存储设备、计算设备、数据库和 GPU 。 Twitter 对每一类都定义了详细的需求，让硬件工程师更针对性地设计产品，从而优化掉那些用不到或者极少用的冗余部分。例如，我们的存储设备就专门为 Hadoop 优化过，设备的购买和运营成本相比于 OEM 产品降低了 20% 。同时，这样做减法还提高了设备的性能和可靠性。同样的，对于计算设备，硬件工程师们也通过移除无用的特性获得了效率提升。

一个服务器可以移除的组件总是有限的，我们很快就把能移除的都扔掉了。于是我们想出了其他办法，例如在存储设备里，我们认为降低成本最好的办法是用一个节点替换多个节点，并通过 Aurora/Mesos 来管理任务负载。这就是我们现在正在做的东西。

对于这个我们自己新设计的服务器，首先要通过一系列的标准测试，然后会再做一系列负载测试，我们的目标是一台新设备至少能替换两台旧设备。最大的性能提升来自增加 CPU 的线程数，我们的测试结果表示新 CPU 的 单线程能力提高了 20~50% 。同时由于整个服务器的线程数增加，我们看到单线程能效提升了 25%。

这个新设备首次部署的时候，监控发现新设备只能替换 1.5 台旧设备，这比我们的目标低了很多。对性能数据检查后发现，我们之前对负载特性的一些假定是有问题的，而这正是我们在做性能测试需要发现的问题。

对此我们硬件团队开发了一个模型，用来预测在不同的硬件配置下当前 Aurora 任务的填充效率。这个模型正确的预测了新旧硬件的性能比例。模型还指出了我们一开始没有考虑到的存储需求，并因此建议我们增加 CPU 核心数。另外，它还预测，如果我们修改内存的配置，那系统的性能还会有较大提高。

硬件配置的改变都需要花时间去操作，所以我们的硬件工程师们就首先找出几个关键痛点。例如我们和 SRE（ 网站可靠性工程师 （ Site Reliability Engineer ） ）团队一起调整任务顺序来降低存储需求，这种修改很简单也很有效，新设备可以代替 1.85 个旧设备了。

为了更好的优化效率，我们对新硬件的配置做了修改，只是扩大了内存和磁盘容量就将 CPU 利用率提高了20% ，而这只增加了非常小的成本。同时我们的硬件工程师也和合作生产厂商一起为那些服务器的最初出货调整了物料清单。后续的观察发现我们的自己的新设备实际上可以代替 2.4 台旧设备，这个超出了预定的目标。

从裸设备迁移到 mesos 集群

直到 2012 年为止，软件团队在 Twitter 开通一个新服务还需要自己操心硬件：配置硬件的规格需求，研究机架尺寸，开发部署脚本以及处理硬件故障。同时，系统中没有所谓的“服务发现”机制，当一个服务需要调用一个另一个服务时候，需要读取一个 YAML 配置文件，这个配置文件中有目标服务对应的主机 IP 和端口信息（预留的端口信息是由一个公共 wiki 页面维护的）。随着硬件的替换和更新，YAML 配置文件里的内容也会不断的编辑更新。在缓存层做修改意味着我们可以按小时或按天做很多次部署，每次添加少量主机并按阶段部署。我们经常遇到在部署过程中 cache 不一致导致的问题，因为有的主机在使用旧的配置有的主机在用新的。有时候一台主机的异常（例如在部署过程中它临时宕机了）会导致整个站点都无法正常工作。

在 2012/2013 年的时候，Twitter 开始尝试两个新事物：服务发现（来自 ZooKeeper 集群和 Finagle 核心模块中的一个库）和 Mesos（包括基于 Mesos 的一个自研的计划任务框架 Aurora ，它现在也是 Apache 基金会的一个项目）。

服务发现功能意味着不需要再维护一个静态 YAML 主机列表了。服务或者在启动后主动注册，或者自动被 mesos 接入到一个“服务集”（就是一个 ZooKeeper 中的 znode 列表，包含角色、环境和服务名信息）中。任何想要访问这个服务的组件都只需要监控这个路径就可以实时获取到一个正在工作的服务列表。

现在我们通过 Mesos/Aurora ，而不是使用脚本（我们曾经是 Capistrano 的重度用户）来获取一个主机列表、分发代码并规划重启任务。现在软件团队如果想部署一个新服务，只需要将软件包上传到一个叫 Packer 的工具上（它是一个基于 HDFS 的服务），再在 Aurora 配置上描述文件（需要多少 CPU ，多少内存，多少个实例，启动的命令行代码），然后 Aurora 就会自动完成整个部署过程。 Aurora 先找到可用的主机，从 Packer 下载代码，注册到“服务发现”，最后启动这个服务。如果整个过程中遇到失败（硬件故障、网络中断等等）， Mesos/Aurora 会自动重选一个新主机并将服务部署上去。

Twitter 的私有 PaaS 云平台

Mesos/Aurora 和服务发现这两个功能给我们带了革命性的变化。虽然在接下来几年里，我们碰到了无数 bug ，伤透了无数脑筋，学到了分布式系统里的无数教训，但是这套架还是非常赞的。以前大家一直忙于处理硬件搭配和管理，而现在，大家只需要考虑如何优化业务以及需要多少系统能力就可以了。同时，我们也从根本上解决了 Twitter 之前经历过的 CPU 利用率低的问题，以前服务直接安装在服务器上，这种方式无法充分利用服务器资源，任务协调能力也很差。现在 Mesos 允许我们把多个服务打包成一个服务包，增加一个新服务只需要修改配额，再改一行配置就可以了。

在两年时间里，多数“无状态”服务迁移到了 Mesos 平台。一些大型且重要的服务（包括我们的用户服务和广告服务系统）是最先迁移上去的。因为它们的体量巨大，所以它们从这些服务里获得的好处也最多，这也降低了它们的服务压力。

我们一直在不断追求效率提升和架构优化的最佳实践。我们会定期去测试公有云的产品，和我们自己产品的 TCO 以及性能做对比。我们也拥抱公有云的服务，事实上我们现在正在使用公有云产品。最后，这个系列的下一篇将会主要聚焦于我们基础设施的体量方面。

特别感谢 Jennifer Fraser、David Barr、Geoff Papilion、 Matt Singer、Lam Dong 对这篇文章的贡献。

via: https://blog.twitter.com/2016/the-infrastructure-behind-twitter-efficiency-and-optimization

作者：mazdakh 译者：eriwoon 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

有的时候 Linux 新手们在下载软件的时候十分困惑，因为下载页面常常同时提供32位和64位版本的软件。所以弄清楚你的操作系统是32位的还是64位的十分重要，因为你在做很多事情的时候都需要这个信息。在这篇文章里，我们会讨论五种检测你的Linux系统是32位还是64位的方法。

检测你的 Linux 是32位还是64位的

请注意文中的这些方法是在 Ubuntu 13.10 平台测试.

1. 执行‘uname -a’ 命令

最常见的一个测试方法是运行 uname command 命令。

例如，在我的系统里，它显示了以下信息：

$ uname -a
 Linux ubuntu 3.11.0-12-generic #19-Ubuntu SMP Wed Oct 9 16:12:00 UTC 2013 i686 athlon i686 GNU/Linux

那个高亮的 i686 (or 有时候会是i386) 说明操作系统是32位的，但是如果显示的是 x86\_64，那就说明这个操作系统是64位的。

2.运行 ‘uname -m’ 命令

上面的命令内涵太多了，可以用这个参数直指人心：‘uname -m’ 。

例如，在我的系统里，它显示了以下信息：

$ uname -m
 i686

这说明我的 Ubuntu Linux 系统是32位的，如果输出显示的是x86\_64，就说明系统是64位的。

3.使用 file 命令

尽管这样做纯粹是炫耀技巧，但是仍然不失为一种达到目的的方法。使用这个方法，需要你运行 file 命令并带上 /sbin/init 作为参数。

举个例子:

$ file /sbin/init
 /sbin/init: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0xc0d86a25a7abb14cad4a65a1f7d03605bcbd41f6, stripped

高亮的 32-bit 说明这是一个32位的操作系统,如果显示为 64-bit 则说明操作系统是64位的

4. 使用 arch 命令

另外一个可以选择的方法是使用 arch 命令，这个命令用于输出机器的硬件名称。

这里有一个示例:

$ arch
 i686

在这里你可以看到输出的是 i686, 这说明这是一个32位操作系统，对于64位的操作系统，输出的应该是x86\_64。

5. 通过系统设置的方法

如果你使用的是 Ubuntu 12.04 或更高, 你可以很简单地在** All Settings -> Details**里查看你的系统结构。

这样你就可以看到系统类型(32-bit)在这里清晰地显示出来。

你还知道别的方法来检测操作系统是32位还是64位的吗？在下面回复与我们分享吧。

via: http://mylinuxbook.com/5-ways-to-check-if-linux-is-32-bit-or-64-bit/

译者：crowner 校对：Caroline

本文由 LCTT 原创翻译，Linux中国 荣誉推出