编者按：本博客出自Softlibrary的首席技术官Miguel Parejo之手，描述了该公司是如何使用Windows Azure 和 Windows Azure Marketplace运行和出售其多租户信息管理服务。
Softlibrary 于1988年建于巴塞罗那（西班牙）。自那时以来，它一直参与信息管理并为我们的客户提供尖端的自定义解决方案。为达到此目的，该公司从一开始就接受微软平台和体系结构。
Kern4Cloud 是一个多租户服务，专注于信息管理而不管它是否属于企业性质。它可以处理所有信息生命周期，提供发布、分类和分级、词汇-语义和词典系统、版本控制、多语种、在线翻译和工作流进程的一系列工具。
我们选择Windows Azure 因为它驻留在认证的数据中心，信息和服务以一种可靠和安全的方式保存。Windows Azure资源都能伸缩以提供高性能的解决方案。
系统内现有信息的每个部分都以XML格式保存，所以我们也可以看到Kern4cloud是作为将异构数据源转换成标准和国际化格式的一个黑盒。
让我们看看怎样使用Kern4Cloud完成一个典型的流。你的公司很可能有一个私隐政策声明并有可能随着时间变化。一旦导入第一个版本，你可以创建新的版本、复制现有的版本，甚至使用主要的翻译引擎在线翻译并作为解决方案的一部分。该系统可以将文件转换成纯XML格式，这样你稍后就可以使用自己的编辑器编辑它们，这个WYSIWYM 编辑器被称作X.Edit。所有这些都可以使用被称作K4C.Workplace 的web组件完成。你的公司可能是以一些部门在发布之前必须提供许可。在这种情况下，可以首先创建一个工作流，迫使那些且只有那些参与发布流程读写和修改声明、检查他们遵守的规章、正确的翻译并最终给获得他们的同意，这样该文档可以被发布并投入使用。
面临的挑战
当首次接触Windows Azure时，我们意识到体系结构和设计阶段应包括一些成本效益的策略。在从Windows Azure上的解决方案中迁移或从头开始创建解决方案时，必须考虑一些计费的驱动程序。幸运的是，微软提供了一些额外的特性和功能，使得这一过程要容易得多。举几个例子：
还有其他工具，但你也可以看看除此之外的一些成本效益策略。所以这就是主要的挑战：设计、迁移、适应和以一种开发人员从来没有过的方式编写代码。项目中的每一个股东都必须考虑一个新参数：成本。我们不是说Windows Azure成本贵，只是以其他的方式。
当重新设计核心组件后，我们面临着另一个挑战。如何验证多租户服务中的用户呢？Windows Azure带有访问控制服务（ACS）。ACS让我们以透明的方式处理身份，集中于授权过��。
体系结构
现在我们知道了Kern4cloud是干什么的了，下面将介绍谁将使用它，稍后我们会使用Windows Azure组件说明这些。
下面列出了主要组件：
- K4C.Workplace: 它是UI的核心。用户可以version、编辑、发布、删除、批量操作、排序、搜索、使用单一窗口轻松地删选数据。一切都组织在Grid中以增加可见性，因此也增加了可用性。请参考第一张图片。
- K4C.Admin: 在这里管理员可以管理所有的属性，X.Edit样式和映射、用户组、用户权限、工作流等等。
- Repositories: 有三个存储库。一个用于二进制文件（Office、图像和视频等等）；一个用于XML文件（包含提取的信息和元数据）；最后K4C.Admin处理所有信息，索引的数据用于快速搜索，这些被存在两个数据库里。
- Workflows: 该组件处理用户定义的所有workflow进程。
这是体系结构的缩略图。让我们看看它是怎样与Windows Azure组件映射的。
在进入细节之前，有一件事必须加以解释。为两个主要受众提供Kern4Cloud建模服务。
- 个人用户: 他们拥有的磁盘空间有限，某些功能被禁用并且共享存储资源。
- 企业用户： 当一个公司订阅此模型时，自动提供给他们一套私人资源。公司内部的所有用户将通过K4C.Workplace访问共同的资料库。然而，K4C.Admin可以帮助管理员来隔离组织内的信息。
下面的四幅图显示了我们的体系结构中最重要的Windows Azure组件。它们之间有一些交互，为了提高可读性这里忽略了这一点。
- 图 1: 展示了Web Roles K4C.Workplace 和 K4C.Admin。两者都被部署在同一托管服务中。它们是系统的入口点且只有它们有一些UI。它们从SQL Azure检索最新的信息因为我们的索引引擎和K4C.Workplace组件在当用户交互和修改数据时确保它将在那里。因为全文索引支持目前在SQL
Azure上不可用，我们的搜索引擎需要做一些额外的工作。最近，我们开始关注Hadoop因为相信这可能是一个不错的选择。
- K4C.FileProperties: 这是一个将二进制文件转换成XML的web服务。下面的隐私策略示例中，想象他们由环境中带有一些标题、页脚等样式的Word文件组成的，可以使用K4C.Admin将它们映射到XML标记。一旦你保存了一个新版本，如果正确地设置了映射，索引角色将发送文件到服务，结果将是一个可以进一步编辑的XML文件。这就是你在很多平台和设备上显示信息的方式。
- K4C.Backoffice: 它是一个网站和K4C系统的中间层。如果你想要在网站上显示你的私隐政策声明，你必须要向服务提出请求，也可以被其他用户所共享，但它依赖于访问控制服务以确保数据隔离，这就是为什么在发出任何请求之前你首先需要对ACS进行验证。
- 图 2: 到那时候，所有这些角色都被部署到相同的托管服务上（但不同于图1中的那个）。
- 工作流和索引：这些都是Worker角色。第一个从Workflows Queues弹出消息并处理它们。索引worker角色是一个以一致的状态索引和保存所有信息的服务。它还会检测文档的更改来向Workflows Queues推送消息。为了最小化瓶颈，两者都是多线程的。然而，单个实例的资源是有限的，因此需要缩放。此刻，该组件手动缩放但我们正在准备新的版本，包括Windows Azure Autoscaling Application Block (WASABi)，它是Enterprise Library 5.0 Integration Pack for Windows Azure的一个组件。我们计划自动缩放，其他的K4C组件基于CPU和内存使用量及网络负载。
系统里的每个角色都有自己的缩放参数。一些只根据CPU使用率进行缩放，或者根据网络使用情况，等等。如果它的缩放参数类似于先前部署的那些（尽管这不是我们所遵循的唯一规则）我们将角色部署到特定的托管服务中。假设将来K4C.Backoffice被第三方用户所使用，因此我们正计划将此组件的新版本部署到它自己的托管服务中。
- 图 3: SQL Azure服务为每一位客户保存数据。当企业也有自己的数据库时，单个用户享用两个数据库（？Individual users share two databases while businesses have their own pair）。所有的敏感信息都被正确地加密到数据层中。
- 图 4: 我们有两个存储账户。一个为客户服务，另一个用于部署、诊断程序和备份。XML数据被存储在Tables中，每个客户标示使用一个分区键，因此将从不同的服务器中提供数据服务，参考这里。我们已经重写了TableServiceContext类并截获WritingEntity 和 ReadingEntitity 事件，所以我们在写入表之前加密和压缩xml数据，从tables获取数据后以其他的方式。
Windows Azure Marketplace集成
最后我们决定通过在Windows Azure Marketplace上提交应用程序授权Kern4Cloud。对于一个基于云计算的解决方案来说这是一个很好的地方，因为它是一个平台，在那里客户可以安全订阅我们的服务，也不用担心存在不合理收费问题。如果客户想订阅我们的服务，他们只需要访问Windows Azure Marketplace 然后搜索 Kern4Cloud。当选择最合适的产品后，Windows Azure Marketplace将提示使用一个Windows Live ID账号登录并提供一些付费信息（如信用卡号码）。在Windows Azure Marketplace中，订阅按月计费，所以第一个月将立即收费。客户会信任计费过程，因为是由微软提供的，ISVs只用遵循一些规则并向Windows Azure Marketplace提供他们的报出价格。整个过程迅速、安全，对客户和供应商来说也是可靠的。
此外，将任何解决方案整合到Marketplace上都相当容易。基本上，你应遵循Windows Azure Training Kit (WATK)上例子中所提到的步骤。微软已经收集好不错的例子和构建基于Windows Azure解决方案的最佳做法。你可以找到单独的Windows Azure Marketplace整合项目，但我建议下载整个培训包。
通过例子来看看这是怎么工作的：
- 假设一个客户在Windows Azure Marketplace上找到你的解决方案，并且想要订阅。一旦提供了计费和订阅信息，Marketplace就会为客户转到你网站上的AzureMarketplaceOAuthHandler.ashx处理器，通知一个新客户订阅了该解决方案。
- 你的网站必须确认该请求确实来自Windows Azure Marketplace。名为AzureMarketplace.OauthUtility的项目处理该任务，你可以在WATK中找到。你既可以附加该项目也可以引用DLL。它包含上面提到的处理器，因此还应在web.config文件里添加以下代码：
<handlers> <add name="AzureMarketplaceOAuthHandler" verb="*" path="AzureMarketplaceOAuthHandler.ashx" type="Microsoft.AzureMarkeplace.OAuthUtility.AuthorizationResponseHandler, Microsoft AzureMarketplace.OAuthUtility"/> </handlers>
该项目也依赖于Microsoft.IdentityModel 和 Microsoft.IdentityModel.Protocols.Oauth库。
当确认请求来自Windows Azure Marketplace时，你的解决方案告诉客户正在订阅，所以如果需要的话你可以请求额外的信息。为此，你必须在网站上添加5个类。其中一个用于读取纯粹将网站定义作为Windows Azure Marketplace客户端的信息。此信息应当被保存在web.config 里，如下所示：
<azureMarketplaceConfiguration appSpecificAzureMarketplaceOAuthClientId="YOUR_CLIENT_ID" appSpecificAzureMarketplaceOAuthClientSecret = "CLIENT_ECRET_KEY" appSpecificPostConsentRedirectUrl = "http://127.0.0.1:81/AzureMarketplaceOAuthHandler.ashx" appSpecificWellKnownPostConsentUseUri = "http://127.0.0.1:81/Subscription/New"/>
这个信息必须与Marketplace中所定义的一致（不管它是否是playground）。
当然，还必须要添加一个section元素：
<section name="azureMarketplaceConfiguration"
type="YOURNAMESPACE.AzureMarketplaceConfiguration, YOURASSEMBLY"
requirePermission="false"/>注意，在生产环境中别忘了替换测试URL。
另一个重要的类是SubcriptionUtils.cs。这会是Marketplace请求的最终目的地。在这里你将创建CreateSubscription 和 Unsubscribe 方法以处理所有的请求。你只需要在Global.asax (Application_Start 方法里)中添加这行代码：
AzureMarketplaceProvider.ConfigureOAuth(new SubscriptionUtils());
添加之后，你的网站现在可以从Marketplace上获取订阅请求并根据需要处理它们了。
简言之
从非云端系统迁移不是很容易，但是是一件令人兴奋的事情。Windows Azure提供了我们需要的所有的服务来完成任务。我们只需在前面采取一些注意事项。有一个人在网站上参与讨论时说到云计算是否意味着IT的终结。我们的经验得出结论，IT部门不会消失，他们只需要适应于这些平台。此外，我们相信随着混合云成为主流这一问题的辩论将很快结束。
在这里感谢微软公司让我们成为这一博客系列中的第一家西班牙公司。如果你希望了解任一方面的详细信息，请随时联系我们。