2015 年 10 月
第 30 卷，第 10 期
Microsoft Azure - Microsoft Azure - 大图
作者 Tony Meleg | 2015 年 10 月
每个月，本杂志都会向读者详细介绍 Microsoft Azure 的某些新的或有趣的服务。对于开发者来说，开发之路是永无止境的，但是通往成功的道路往往不止一条，这有时候会给人们造成困扰。将零零散散的信息汇聚起来形成一张“大图”并不是一件简单的事情。 我们的行业正不断创新，对于 IT 组织和 IT 从业者来说，无法查看大图将会引发实际问题。本文全部旨在帮助你了解 Azure，避免关注细枝末节 - 这与我们的日常工作正好相反。
让我们面对它吧，即使开发者并不是时时刻刻擅长化难为简。通常，面对某个简单的问题，我们会实施非常复杂的解决方案。我们需要了解相关工作原理，尤其是那些并非由我们本人生成的工作。在某种程度上这属于信任问题，但也使我们可以了解如何调整和微调软件的某个组件或整个软件，以满足我们的特定需求。这也关乎于控制。
Microsoft 的大手笔
如果你对我关于开发者的主张耳熟能详，那么你可能对我接下来的介绍不感兴趣。Azure 是一个由应用程序构建基块或“服务”组成的集合，其中每一项都提供你有时可能在要生成的应用程序中需要的不同功能。Microsoft 相信这些块可自我复原、可高度扩展并且可自行管理。你可以在世界各地提供任何服务、仅支付你所消费的部分，最重要的是，你可以随时随地更改你的消费。你可能不喜欢的是： 这些服务才刚刚开始。它们简化了你的工作；你对它们的控制可能会大大减少；你看不到它们的内部。换句话说，除了信任它们，你别无他法。这听起来并不像你会感兴趣的事情，对吗？因为你想要获得控制权，你不“信任”，而且你喜欢复杂的事情？
你可以大致将 Azure 分为三层：数据中心基础结构、基础结构服务以及平台服务，如图 1 所示。
.png "Microsoft Azure 概念视图")
图 1 Microsoft Azure 概念视图
你可以理解为这三层彼此堆叠，每一层的下面都有一个抽象层。所以，基础结构即服务 (IaaS) 主要是基础物理服务器、存储和联网的抽象。平台即服务 (PaaS) 是应用程序软件基础结构的抽象，它通常安装在服务器上并在创建 Web 服务器、数据库、消息传递系统和标识基础结构等的应用程序时使用。该服务的职责不在于提供软件本身，而是提供给你一项可持续运行、可复原、始终在线的服务（以及幕后操作来以透明方式监控和修复任何问题，而不会降低应用程序的性能）。
这些服务不仅可用在 Azure 公有云中，也可用在其他任何地方。它可以充当你的数据中心、主机或者外包程序。Microsoft 最近推出了 Azure Stack 来实现此理念 - 它将作为 Azure 的秘密武器和服务提供，并将部署到你自己的硬件上。毕竟，它也只是在 Windows Server 和 Hyper-V 的核心基础顶端生成的软件而已。在这个新世界里，你并不真的关心如何正确构建解决方案以及如何计划服务，因为你的注意力集中在你所需要的服务上。
平台构建基块
所以，让我们大致看一下 Azure 整体。图 2 列出了一系列功能组中的所有服务，可跨基础结构服务和平台服务拆分。应该将基础结构服务视为允许你为现有应用程序创建低级别基础结构的功能。你需要装有磁盘的计算机；需要将其联网在一起；需要共享磁盘；并且需要将它们连接到其他位置上的其他系统和网络等等。
.png "Microsoft Azure 服务")
图 2 Microsoft Azure 服务
在基础结构服务层上，抽象更为人熟知，因为它们代表基础物理数据中心，例如以虚拟机 (VM) 形式存在的计算机以及附加到计算机的虚拟磁盘。它允许你运行已有系统，并且如常执行操作，因为唯一的抽象是计算机，而不是你可能使用的应用程序软件。你仍然有责任安装、管理、修补、修复以及复原在联网的 VM 中或之间运行的任何软件，其操作方式与你在自己的数据中心中的操作方式一致。
与此相反，平台服务包含使你远离服务正在使用的较低级别的计算机/存储/网络的功能；也就是说使所有抽象对象远离你。一般来说，如果无法实际接触或者连接到特定服务中的基础 VM，则服务就是 PaaS。同样，你无需选择提供服务的软件，也无需调试或者控制该软件。该服务的职责是适合工作、自我修复和修补，并且监控所有 Azure 数据中心内所需的服务的所有部分。你只需要关注如何使用它 - 无论如何，这才是你的实际工作。
旁白 - Azure 数据中心基础结构
你可能感兴趣，因为我们所有人都对促进 Azure 的所有基础复杂计算和数据中心基础结构很痴迷。你可能想了解服务器的物理硬件规格、所使用的交换机以及机架的构建方式。你可能想了解可在所有服务上提供超级快的恒定速度的复杂网络拓扑，以及可将 Azure 数据中心区域连接在一起的全局网络。可能你很好奇目前全世界装有 Azure 的全部 24 个数据中心区域（或者即将在加拿大和印度推出的 5 个新区域），如图 3 所示。
.png "Microsoft Azure 全球数据中心足迹")
图 3 Microsoft Azure 全球数据中心足迹
这是你作为开发者在新领域内进行的首次尝试： 至少在 Azure中，你不需要再考虑它。如果你想在自己的数据中心中使用 Azure Stack 生成自己的“Azure”，你（或你组织内的其他人）仍然需要将所有这些物理条件考虑在内。你在过去需要考虑这些（甚至需要考虑特定应用程序所需的基础结构）的其中一个原因是：万一出错，付出的代价将非常高昂。你无法真的了解所需服务器的数量和大小；你假设最差的情况，并在此基础上增加一些，以防万一。在 Azure 中，这些问题都不会出现，因为需要多少，提供多少即可。如果你需要更大的计算机，则获取一个大计算机；如果获取的计算机过大，只需进行更换即可。在 Azure 中，你只需要确定应用程序用户的所在地，以及哪些数据中心最适合用来交付解决方案。通常是最接近的那一个。
基础结构服务 - 更可控、更有效
当你在图 2 中查看 60 项左右的服务时，列表可能会使人感到困惑。但是，大多数时候，你生成的大部分应用程序中仅包含很少的功能。通常，具有核心 Web 服务器和关系数据库，以及很多用来标识、报告以及执行一些批处理操作的其他对象。现在，我们将专门讨论 Web 基础结构和数据库。
你可以立即做出选择： 你是否从事基础结构或平台层抽象方面的工作？ 你是否启动某些 VM、安装 Web 服务器及数据库并开始运行？ 请记住，这一抽象主要关于物理服务器、存储/磁盘以及网络，而非需要在这些服务器上运行的软件。听起来很容易、很熟悉，猜一猜这是什么。这就是你整个职业生涯中要做和已做的事情。请看一下图 4。VM 具有虚拟磁盘，这些磁盘可以跨 VM 共享，或者附加到特定计算机。VM 可以放在虚拟网络内，以便它们可以通信，而且网络可以连接到你自己的数据中心，以及跨越 Azure 区域。这些都是通过该软件抽象实现的，这意味着你最后使用了一台具有一个或多个磁盘的计算机，并且位于与其他计算机连接的网络中。
.png "服务器、磁盘和联网的虚拟机抽象")
图 4 服务器、磁盘和联网的虚拟机抽象
你需要对 VM 集内部所需的一切进行控制、优化、调整、调试和干扰。事实上，因为使用了抽象，它甚至比你的本地环境更有优势。你无需再考虑物理计算机、主机操作系统和虚拟机管理程序。无需担心虚拟磁盘的底层存储基础结构的复原。提供了一组几乎令人难以置信的 VM 大小以供选择（CPU 和 RAM 的不同组合，以及不同的磁盘大小、速度以及网络带宽）。
更好的是，它是全自助式服务，每一项都可以自动化，因此可以非常轻松地定义所需的基础结构，并通过一个简单的脚本启动数百个实例。
假设你的应用需要适当程度的伸缩和复原。可轻松创建 VM 和 Web 服务器的 Web 场，以及数据库群集。你（或者与你关系最好的 IT 专业人员）知道如何实现所有这些操作 - 这并不简单，但是可行。你可以随时执行此操作，无论白天还是夜晚；可以在世界任何地方预配它；可以仅支付你所消费的部分并随时更改主意、全部撤销并且不购买任何物品。这多么不可思议？ 听起来令人难以置信，有什么注意事项吗？
在基础结构层上，你仍然需要执行大量工作来部署和运行一切。所有对象均运行后，你需要做更多的工作来使其持续运行。但是，这非常有用，尤其是当你想“让它运行”时。在本地环境中，部署一组复杂的、互相关联的 VM 时会出现更多问题，包括 Azure 中的功能（例如 Azure 资源管理器）、通过 Windows PowerShell 的自动化，以及许多来自第三方的其他解决方案。所有对象均工作后，你仍然需要修补你在 VM 内部使用的所有软件，其中包括正在运行的任何操作系统。你需要管理所有应用程序软件的运行状况，这对于 Web 服务器和数据库来说并不麻烦，但是当你向外扩展或者加入 5 个其他功能时，就会非常麻烦。
你需要对工作或工作量进行控制。如果你想控制，则需要付出更多努力来生成所需内容，并使其全部正常工作。
平台服务 - 控制越少、工作越少
你可能记得一句话“所有计算机科学问题都可以通过向其添加另一个间接层来解决。” 然而，有人在这句话后又加了一句“...但是，这通常会引发另一个问题。”
事实确实如此，平台服务就是最明显的例子。图 2 中的 Azure 服务图展示了用于本示例中所需的两个构建基块的两个平台服务抽象：Web 服务器和数据库。在 Azure 中，这些抽象是 Web 应用（在 Web 和 Mobile 部分中）和 SQL 数据库（在 Data 部分中）。在 Azure 中预配这些服务的方法与预配任何服务的方法一致，即转至 Azure 管理门户、选择所需的服务并填入所需的详细信息：服务名称、数据中心位置、初始性能/定价等级等等。
从这里可以体现出控制越少/工作越少这一点。让我们以数据库为例。我在北欧的数据中心中预配了一个数据库。在不到 1 分钟的时间里，我的数据库可以充分运行，我接下来要做的是向该数据库部署架构和数据，然后连接到我的 Web 应用。不需要安装软件；我得到了所需的 SQL 数据库。事实上，我不止得到了一个数据库，我得到的是三个，它们在一个高度可用的群集里一起工作，使我获得了难以想象的复原等级。我只需选择不同的性能等级，即可上下调整三个数据库的性能（可以更改我支付的价格）。你只能选择这个三向群集数据库；你必须接受它，因为服务始终希望确保能向你提供一个有效的数据库，而这是最行之有效的方式。
正如图 5 所示，当你使用 Azure Web 应用为自己的应用预配 Web 基础结构时，将有一个类似的模型起作用。你可以使用简单的滑块选择所需的实例数。你只需上下调整实例计数，该服务会完成剩余工作。甚至可以让系统基于负载或计划来为你完成此操作。更重要的是，服务的职责是始终提供你指定的实例计数，并且监控和修复断开的实例。你只需要写入 Web 应用代码并将位传递给服务，以便它可以确保所有位在你的实例上均位于所需的适当位置。
.png "更改 Web 应用实例计数")
图 5 更改 Web 应用实例计数
所以，平台服务抽象提供的服务通常负责为你预配、复原和管理该服务。抽象引发的“其他问题”是你将失去一些控制权。你无法选择软件、无法访问“内部”、无法调整和微调从操作系统到堆栈一直使用的软件 - 你完全失去控制权。你失去的另一项控制权是你现在无法使用该服务的任何功能，也无法使用该服务的 API；也就是说，你无法干预应用程序代码与该服务的交互方式。例如，你可能需要数据库中提供而服务器不提供的一些具体内容。可能是特定数据类型，甚至是全文搜索之类的整体功能。你可能正在将现有应用程序移动到云，在你的应用中使用的功能与 Azure 中服务的功能不匹配。您将怎么办？
图 2 中的 Azure 服务构建基块图列出了 IaaS 或 PaaS 中的所有服务，你可以“一起”使用它们，并且无界限限制。例如，没有任何理由致使 PaaS Web 应用服务不能与安装了 Oracle（在 Linux 上运行）或 SQL Server（在 Windows 上运行）的 VM 一起使用。现在，你可以平衡控制和工作量。事实上，你可以做的更多。由于所有这些构建基块都在等候使用，所以理所当然地你可以从任何地方使用它们。它所需要的只是一个简单 API 或者你已经用来与这些服务交流的一些现有协议。可以将这些块中的任何一个与你自己的数据中心中的现有系统一起使用。也可以将这些块与来自第三方（甚至是来自其他云提供商）的其他块一起使用。当然，它假设应用程序可以容忍用户造成的延迟问题，但这是可能的。
其他服务
那么，你为什么需要 Azure 中的所有这些功能？ 如果你环顾自己的 IT 商店，你会发现在当今生产环境中运行的所有应用程序中，有相当一大部分的应用程序软件使用这些应用：消息传递系统、数据分析功能、标识基础结构、安全层、备份系统、数据仓库、监控和管理系统等等。总的来说，在你的整个 IT 组合中，你需要所有这些“内容”。 我喜欢将 Azure 视为一组“IT 乐高积木”。 当你在生成下一个出色对象时，你并不是随时都需要所有类型的块，但是你的工具包中需要包含所有这些类型。
你如何决定在生成新的解决方案时使用哪些块？ 这与之前没什么不同 - 你需要了解构建基块的功能，并使其符合你的应用程序的特定需求，然后进行调用。需要注意的是，在云中生成应用程序的方式不同，而且更为复杂。它两种都不属于，但是你需要执行一些其他操作，因为你的工作环境是“共享”基础结构这一基本概念。这意味着许多服务都有约束，而且这些约束随着所使用的各种功能级别和定价等级的不同而不同；你需要了解它们的具体内容。我记得你不喜欢一成不变；你想根据应用程序加载和需要自行调整。你需要保守地对这些约束以及服务可用性和响应作调整。你可以使用相同工具、相同语言和框架来生成解决方案，而且所有处于最低级别的服务都使用基于 REST 的 API 以及特定于框架的包装程序。这意味着你实际上可以从具有简单 Web 堆栈的任何对象（例如传感器）访问构建基快，原因是云推动了物联网解决方案的发展。
云的好处是你可以快速迭代（因为它很容易启动服务）；你可以尝试一些其他方法；由于投入非常少，所以失败也不要紧，而且造成的损失不大。回过头来看图 2。是否缺少某些内容？ 在图中你可能会看到你不需要的对象，但是我敢保证你很难判断哪些功能是你需要的或者已经具有的。我们为你提供了大量的指南，对每项服务都提供了广泛的指导和详细实施说明。
大多数开发者可以通过 DNA 获得更多新信息。你有机会接触更多技术，尝试更多新鲜事物。即使你的公司几乎从来也不生成任何对象，将它放到公有云中，开发者仍然可以从这一世界上最佳的位置获得知识并快速成长。
应变
在结束前我最后再讲一个主题，就是如何应对变化。我必须要承认 Azure 的创新脚步异乎寻常的快，要想紧跟其步伐是一件非常困难的事情，然而这是我的工作。过去，你可以花费 3 到 5 年来研发产品特性和功能，但是这个时代一去不复返了。现在缩短为 6 个月。你会发现，在你生成内容期间，会出现新新功能甚至是整个新服务，它需要将这些内容评估和重构到你的解决方案中。设定 1 年的通知期后，功能和服务也可以被移除，而在过去的服务器软件行业里，支持周期往往在 10 年以上。
服务版本控制现在出现了，这意味着向服务添加新功能可能会无法实现该服务以及在服务上生成的应用。所以需要决定是否进行版本控制，即是否创建新的端到端实现。这正是最近在 Azure 上通过 Azure SQL 数据库完成的工作。有关 Azure SQL 数据库版本 12 的新增功能，请查看 bit.ly/1Dcjpo4 上的文章。
关键是使用云需要缴税，你要有这个认知，并了解哪些因素会产生税费。你需要了解云支持/变更通知过程，以便提早做计划，而不会猝不及防。当然，税费也会发生变化，与本地相比，它的税费会更高，缴税频率会更大。但是不要因为税费望而却步，它的好处也是显而易见的。它会显著提高你的工作效率、大幅度提高质量并尽可能降低风险。
了解更多详细内容？ 通过 AzureCon 虚拟活动，你可以获得 Azure 专家意见、查看问题和答案并找到所有关于 Azure 最新创新的信息。你可以在 bit.ly/1KRD76d 上注册以访问所有举办的展会信息。
Tony Meleg是 Microsoft Azure 团队的技术产品经理。他会抽出时间为各种受众编写技术信息、分享 Azure 的信息并用通俗易懂的方法让大家了解复杂的内容。