这是介绍适用于 Spring 开发人员的 Microsoft Azure 的 6 部分系列文章的第 6 部分，新文章会在每周一和周四发布。如果没有 Microsoft 的 Asir Vedamuthu Selvasingh, Yitao Dong, Bruno Borges, Brian Benz 和 Theresa Nguyen 的贡献，我无法完成本文。你可以在 Github 上找到本系列的代码。在阅读文章时，如有任何反馈或问题，请在 Twitter (@starbuxman) 上联系我。你还可以在我的 Spring Tips (@SpringTipsLive) 系列文章，Bootiful Azure 中了解更多关于 Microsoft Azure 的信息。

以下是所有文章

• 酷炫 Azure：迈出使用 Microsoft Azure 的第一步
• 酷炫 Azure：使用 Microsoft SQL Server 进行基于 SQL 的数据访问
• 酷炫 Azure：使用 CosmosDB 进行全球规模数据访问
• 酷炫 Azure：与 Azure Service Bus 集成
• 酷炫 Azure：对象存储服务
• 酷炫 Azure：投入生产！

本系列关于 Microsoft Azure 的最后一篇文章是一个快速总结，回顾了在使用 Spring Boot 和 Microsoft Azure 构建的应用部署到生产环境时需要记住的事项。

安全配置

我们在舒适的本地机器上轻松自如地开发了应用程序，按需插入相关的配置值。问题是，这些值通常非常敏感，不应未经加密地留在文件系统上。有许多不错的解决方案。你当然可以部署 Spring Cloud Config Service 本身。如果你在 Microsoft Azure（或其他平台）上运行 Pivotal Cloud Foundry，这是推荐的方式，因为只需一行命令即可部署并使其工作。你当然也可以部署 Hashicorp Vault 并使用 Spring Cloud Vault。或者，你可以将密钥和值存储在 Microsoft 自己的 Key Vault 服务中。为了有效地使用 Key Vault，你需要配置 Microsoft Active Directory，虽然亲爱的读者，这不是我希望你或你的亲人遇到的事情，但这确实是我非常感兴趣的事情。

Microsoft Active Directory

在我 20 多年帮助组织构建软件的经历中，我几乎没有见过不使用 Microsoft Active Directory 的组织，即使它们仅通过 LDAP 接口使用。当然，我希望 Google Apps 在企业中获得更多关注，但我们必须非常清楚：Active Directory 是企业 IT 中最流行的标准。这是一种生活方式，即使在你和我理想的应用开发世界中，我们可能不需要经常担心它。而且这是有充分理由的！它为商务专业人士整合了整个 Windows 桌面体验。它是 Office365 故事的跳动心脏，也是组织自我组织和自我构建的方式。想知道你是否升职了？查 Active Directory！想知道某人坐在哪里？查 Active Directory！想强制重置密码？维护企业范围的审计日志？解雇某人？查 Active Directory！你可能认为你的组织运行 Active Directory，但请清楚：它运行着你的组织。

Active Directory 是一个目录服务器。它提供用户、组织等的树形结构。它充当 Microsoft CRM、Microsoft SQL Server、Microsoft Office 甚至 Microsoft Windows 本身等技术的身份管理器。你可以在 Active Directory 中描述用户、他们的权限和角色以及更多内容。这又回到了我们的主题。Microsoft Azure 为你运行 Active Directory！你可以直接从平台导入和配置 Microsoft Active Directory 安装的所有相关信息。甚至还有一个 Spring Boot starter 可以将 Microsoft Azure 连接到你的 OAuth 委托的基于 Spring Boot 和 Spring Security 的应用程序。你可以自己部署和管理 Microsoft SQL Server 或 Microsoft Active Directory 吗？当然。但是，你应该这样做吗？

Application Insights

随着你扩展和启动更多的微服务，你将会引入越来越多的移动部件，在系统中观察数据从一个节点到另一个节点的移动变得越来越重要。在这里，Microsoft Application Insights 对 Spring 应用程序的集成——目前至少与 Microsoft Azure 的主要 Spring 集成分开交付——使其使用起来轻而易举！将 com.microsoft.azure: applicationinsights-spring-boot-starter : 1.1.0-BETA 添加到你的构建文件中。

你可以像这样编写脚本创建 Application Insights 订阅

#!/usr/bin/env bash

rg=$1
appname=${rg}-appinsights

az resource create \
    --resource-group $rg \
    --resource-type "Microsoft.Insights/components" \
    --name $appname \
    --location "South Central US" \
    --properties '{"ApplicationId":"bootiful","Application_Type":"web"}'

这将创建一个订阅并将其绑定到 bootiful 资源组。使用以下命令访问生成的密钥（假设 $rg 和 $appname 变量在同一作用域内）

az resource show -g $rg -n $appname --resource-type "Microsoft.Insights/components" --query properties.InstrumentationKey

然后你需要指定 azure.application-insights.instrumentation-key 并为你的应用程序指定一个 spring.application.name 名称。公平地说，无论如何你都应该这样做。就是这样！重新启动你的应用程序，通过应用程序中的 HTTP 端点驱动一些流量（即使只是在 localhost 上运行），然后登录到 Microsoft Application Insights 控制面板并查看实际的检测数据！

Cloud Foundry

你不应该运行无法收取费用的软件。Pivotal 的传奇人物 James Watters 经常谈论“价值线以下”的工作，以及技术人员和高管应该专注于对特定组织而言处于价值线以上的工作。一般的组织已经有足够多的问题了。运行 MySQL 或 Kafka 等商品软件不应该成为他们的问题之一。运行那些无法让你业务与众不同的东西也不应该成为他们的问题之一。在足够长的时间里，如果你能找到一个能胜任这项工作的人来为你运行，无论是什么，它的成本都会无限地低。理想情况下，最终运行该软件的人应该对运行这些东西有既得利益。大多数组织的使命绝不是配置 SSL 或调试 MySQL 复制问题。请别人为你做这些几乎总是更便宜的。

如果你尝试做一些标准的事情，那么你应该完全依赖标准化工具。为什么当你可以使用 Cloud Foundry 或 Kubernetes 等工具来运行基于 Java 或 Node 的应用程序时，却要使用云厂商的锁定工具呢？Cloud Foundry 或 Kubernetes 的人才库更大，成本几乎为零，而且易用性与云厂商提供的任何东西持平或更好。

这是 Microsoft 和 Pivotal 建立如此良好关系的重要原因之一。企业客户明白，对于某些工作负载而言，公有云是必然的选择，但他们不想被锁定。可选择性是宝贵的。能够迁移到不同的平台是宝贵的。敏捷性——应对变化的能力——是宝贵的。我们一直都看到这一点；Google Cloud Platform 在推出时对某些工作负载类型的价格比 Amazon Web Services 更便宜。一些公有云厂商在某些你可能希望所在的区域提供了其他厂商没有的可用区。组织越来越多地采取混合云或多云策略，因为他们知道自己的工作负载会变化，可用性需求也会变化。这些组织希望尽可能降低在各种云基础设施上进行运营、安全、培训和部署的成本。

Pivotal Cloud Foundry 在这里是一个自然的选择；它允许组织可靠地部署到任何云平台，并且在必要时，也能轻松地降级到平台特定的服务。正是由于这个事实，Microsoft 在 2017 年和 2018 年将 Pivotal 评为年度合作伙伴。Pivotal Cloud Foundry 是我们基于 Apache 2 许可证的开源 Cloud Foundry 项目的发行版，它有助于推动 Microsoft Azure 上的资源使用，并以尽可能可移植的方式进行，同时仍然突显其有价值和独特之处。

我完全赞成使用 Microsoft Azure 这样的服务来简化基础架构搭建的工作，特别是当 Microsoft 能够提供差异化的体验时。但是运行 Java 进程或 Node.js 进程呢？坚持使用像 Cloud Foundry 或 Kubernetes 这样的事实标准基础设施。在 Microsoft Azure 上部署 Cloud Foundry 相当简单，一旦部署完成，在那里部署 Spring Boot 应用程序也非常简单。通常就像运行 cf push -p my.jar 一样简单。你当然需要 Cloud Foundry CLI，在这里获取。

在 Cloud Foundry 的世界里，服务代理是一个 HTTP API，Cloud Foundry 平台通过它来管理对...某种东西的供应和生命周期。它可以是像 MySQL 这样的数据库，也可以是像 Apache Kafka 这样的消息队列。它可以是一个 Active Directory 安装，也可以是一个 CosmosDB 连接。它可以是很多东西。Microsoft 和 Pivotal 团队携手合作，确保在 Microsoft Azure 上运行 Pivotal Cloud Foundry 的用户的服务代理选项以尽可能方便的方式支持核心服务。此列表包括 Microsoft Azure 服务，如 Azure 存储、Azure Redis 缓存、Azure Service Bus、Azure 事件中心、Azure SQL 数据库（SQL Server、PostgreSQL 和 MySQL）和故障转移组，以及 Azure CosmosDB。

你可以通过在 CLI 上发出 cf marketplace 命令来检查 Cloud Foundry 服务目录。它会显示所有相关服务，然后你可以选择预配该服务的实例及其关联的计划。计划描述了你可以从服务代理资源中获得的特定服务级别，并且自然地特定于每个提供的服务代理。

假设你有一个部署到 Cloud Foundry 的 Spring Boot 应用程序，其逻辑名称为 myapp

> cf push -p my.jar --no-start myapp

假设你想为你的应用程序预配一个 Microsoft SQL Server 实例，并且你想将其逻辑上引用为 mydb。你的会话可能如下所示。以下命令将预配一个 SQL Server 实例，通过内联 JSON 或 .json 文件路径指定参数，并为其指定逻辑名称 mydb。

> cf create-service azure-sqldb basic mydb -c '{"sqlServerName": "Bootiful"}'

该服务很快就会被预配并在应用程序内部可用。你只需要将服务绑定到你的应用程序，这样相关的连接信息就可以作为环境变量注入到应用程序的环境中。

cf bind-service myapp mydb
cf restart myapp

现在，你正在运行的 Spring Boot 应用程序将有一个环境变量 VCAP_SERVICES，其内容将包含刚刚预配的服务的连接信息。它看起来像这样

"VCAP_SERVICES": {
  "azure-sqldb": [
    {
      "credentials": {
        "sqldbName": "fake-database",
        "sqlServerName": "fake-server",
        "sqlServerFullyQualifiedDomainName": "fake-server.database.windows.net",
        "databaseLogin": "ulrich",
        "databaseLoginPassword": "u1r8chP@ss",
        "jdbcUrl": "jdbc:sqlserver://fake-server.database.windows.net:1433;database=fake-database;user=fake-admin;password=fake-password;Encrypt=true;TrustServerCertificate=false;HostNameInCertificate=*.database.windows.net;loginTimeout=30",
        "jdbcUrlForAuditingEnabled": "jdbc:sqlserver://fake-server.database.secure.windows.net:1433;database=fake-database;user=fake-admin;password=fake-password;Encrypt=true;TrustServerCertificate=false;HostNameInCertificate=*.database.secure.windows.net;loginTimeout=30",
        "hostname": "fake-server.database.windows.net",
        "port": 1433,
        "name": "fake-database",
        "username": "ulrich",
        "password": "u1r8chP@ss",
        "uri": "mssql://ulrich:u1r8chP@[email protected]:1433/fake-database?encrypt=true&TrustServerCertificate=false&HostNameInCertificate=*.database.windows.net"
      }
    }
  ]
}

在 Spring Boot 中，你可以使用扁平化的属性访问语法引用这些属性，例如：vcap.services.mydb.credentials.jdbcUrl。这里的常见模式是在云中运行应用程序时激活一个 Spring Profile。例如，cloud？这样你就可以在代码中将配置文件放在 application-cloud.properties 下，当应用程序在 Cloud Foundry 中启动时，该属性文件就会被加载。你可以将默认的本地配置放在 application-default.properties 中。因此，当 Spring Boot 启动时没有指定 Profile 时，它会加载 application-default.properties 中的配置。当在 Azure 上的 Cloud Foundry 中运行时，它会加载 application-cloud.properties 中的配置。因此，你可以将以下内容添加到你的 application-default.properties 文件中。

spring.datasource.url=${vcap.services.mydb.credentials.jdbcUrl}

酷炫！

后续步骤

在本文以及之前的文章中，我们只是触及了 Spring、Microsoft Azure 和 Cloud Foundry 可能实现的功能的冰山一角。显而易见的是，这里存在着良好的共生关系，每项技术都使其下层变得更加强大。难怪 Azure 的大量工作负载都是基于 Linux、Spring Boot 和 Cloud Foundry 的：这些东西协同工作得很好。对于那些想进一步了解 Spring 在 Microsoft Azure 上的应用的人，请查看 Azure 的资源门户