实现“软件+服务”(S+S)的注意事项

来自微软的八名架构师撰写了设计 S+S 和云计算的注意事项，这篇文章集合了在为企业规划软件加服务（S+S）的解决方案时，应该考虑的设计因素。

文章的作者有 Fred Chong、Alejandro Miguel、Jason Hogg、Ulrich Homann、Brant Zwiefel、Danny Garber、Joshy Joseph、Scott Zimmerman 和 Stephen Kaufman，他们将 S+S 定义为软件即服务（SaaS）的扩展：

S+S 为组织外包开发、管理、部署提供了更多的选择，也提供了更多运行业务的技术操作因素。S+S 与面向服务的体系架构（SOA）原则协同工作。S+S 提供了采购、融资、部署应用软件和服务的多种模式，从而帮助实现 SOA 的企业增加其技术选择。

S+S 与 SOA 相辅相成，因为“S+S 凭借部署在公司内部的云计算和解决方案为组织提供了优化 IT 投资的计算模型”。S+S 并不会否定使用 SOA 的地方，而是“提供采购、融资、部署应用软件和服务的多种模式，以此帮助 SOA 优化其技术选择”。

在作者的设想中，S+S、SOA、云计算之间的关系如下：

文章对企业架构做了如下分析，从而解决了很多问题：

企业架构

要实现 S+S，企业架构需要评估现有的 IT 资源，包括系统、应用、人力和经验，决定哪些是内部可实现的，哪些需要外包。就此而言，作者推荐了一个很多大型组织已经在用的模式：

• 专有、涉及关键业务的系统——这些系统本质上是专有、涉及关键业务的，或者是提供竞争优势的，它们往往被看得很重要，外包给外部服务供应商的话会有风险。因此这些系统往往由组织的现有 IT 部门设计、开发、操作、管理。
• 非专有、涉及关键任务的系统——那些非专有，但仍然涉及关键任务的系统可以由另一家公司开发，不过仍然要由组织的现有 IT 部门设计、操作和管理。
• 非专有的系统——只要能和服务供应商建立合适的服务水平协议（SLA），非专有、提供标准化功能和接口的系统通常就很适合外包给云服务供应商。这种系统的例子有电子邮件、日历、内容管理工具。

他们还建议仔细斟酌组织的 IT 成熟度、ROI 或成本节约、以及采用 S+S 解决方案的难易程度。

软件架构，集成设计

关于软件集成，作者先提出了一个假设——“通过数据集成、功能集成、展示集成等各种技术”，大多数企业应用都跟其它应用有联系。

他们说在紧耦合系统中，

组织要么在子系统中围绕功能子集建立粗粒度的 Facade，要么采用集成技术，在传统应用和托管到本地 / 外部的服务之间搭建桥梁。

针对那些使用 SOA 服务的系统，作者建议考虑将这些服务迁移到云中，包括使用 Internet 服务总线技术，因为非正式的消息总线技术不能满足该方法。

软件架构，应用设计

作者认为，“应用根据面向服务的原则进行设计，会为 S+S 应用的采用或集成奠定一个坚实的基础”，但这还不充分。向企业 IT 系列服务添加远程服务还需要考虑很多重要的问题：

• 远程服务失败时要实施一定的策略
• 用补偿事务代替原子事务
• 使用异步消息传递
• 服务发生变化时更新应用的消费服务
• 测试有特定需求的 S+S 应用

软件架构，信息设计

作者们注意到，S+S 会迫使组织采用一种新的方法进行信息设计：

传统上，企业应用的重点是数据一致性、事务可靠性，还有不断增加的吞吐量。它们通常依赖于关系型数据模型和关系型数据管理系统，这些模型和系统遵循原子性、完整性、一致性和持久性（ACID）原则设计可靠的数据库。S+S 不同于此，它会促使组织去思考自己的信息设计过程。

要将数据支持为服务范式

设计出来的服务和底层数据结构必须要能支持更多的事务量，或者必须能处理比往常更大的数据量。这必然会给架构设计和数据分区策略带来变化。分区策略必须借助功能分割或水平分区来支持底层数据库的水平扩展。不过这些策略可能会影响性能的优化。这就解释了为什么一些高性能的系统正在远离 ACID 可靠性，而是越来越偏向于基本可用（Basically Available）、柔性状态（Soft State）和最终一致性（BASE），并开始解除逻辑分区和物理分区架构之间的耦合了。

基础设施架构

作者在这部分立马表示，企业过去必须购买所有需要的计算基础设施，包括服务器、存储设备、网络设备和桌面。有时甚至要新建大楼和数据中心，来安置所有的设备和相关人员。云计算（尤其是基础设施即服务（IaaS）和虚拟化）为公司提供了新的机会，能将基础设施的一些需求转移到其它组织。

尽管 IaaS 带来了好处，但企业架构师仍然要考虑可用性、伸缩性、安全性、可靠性和可管理性，权衡大量的设计因素。

安全

安全在过去的二十年中一直是企业的重要方面。自从互联网出现以来，总结出的安全教训现在都仍然适用。关键的 S+S 安全要素有：

S+S 安全涉及广泛的主题，要提供身份及其授权，要允许内部系统和云服务之间的单点登录，要在传输和静止状态保护数据，还要增强部署在云平台上的应用代码，以防应用遭受恶意软件的攻击和渗透。

管理

在处理企业防火墙内的应用和服务的同时，IT 管理者还需要考虑防火墙外的应用和服务，“不仅要从已部署的技术角度考虑，还要从 IT 角色和责任、操作程序及政策的角度出发，这些视角对已部署软件和服务的使用和操作会产生影响”：

举例来说，应用外包给 SaaS 供应商，现在维护这些应用的管理员和操作者并不是企业员工。在 S+S 的世界里，传统的 IT 角色和责任可能需要合并为单独的服务提供者角色，该角色实际上承担 SLA 中指定的责任。还应该明确确定依法强制执行责任的条款，以减少因服务供应商不能圆满履行责任而产生的负面结果。同样，解决用户问题和技术问题的 IT 管理流程现在也该由服务供应商处理。对最小化服务中断来说，建立明确的升级程序、将有效的沟通渠道并入企业的最终用户支持过程都是至关重要的。

操作

提到操作，作者们建议：

考虑外包 IT 操作角色和责任对业务的影响。业务连续性、责任、员工和客户满意度都是关键因素，这些因素必须通过确定明确的 SLA 和可靠的云服务供应商来解决。 企业应该在融合软件和服务环境的 IT 操作中发挥积极作用。不过企业应该建立监控系统，以便发现外包服务中技术问题，而不是关注于执行细节。企业还应该建立操作过程，以确保服务供应商尽快解决了问题。

结论

在结论中，作者提出了组织涉及云计算的三种方式：

• 消费云——将应用和 IT 服务外包给第三方的云供应商，比如微软的 Business Productivity 在线套件、CRM 在线和 Live Meeting 服务。
• 使用云——使用云中可用的平台和基础设施服务，像 Windows Azure 和 SQL Azure。
• 拥抱云——成为云服务供应商。BizTalk Server 企业服务总线（ESB）工具集对此有所帮助，因为该工具集“能集成数据更新、编排通过云服务处理信息交换的工作流”。

查看英文原文： Considerations for an S+S Implementation