“软件+服务”(S+S)思路:架构先行

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

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

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

企业架构

·专有、涉及关键业务的系统——这些系统本质上是专有、涉及关键业务的，或者是提供竞争优势的，它们往往被看得很重要，外包给外部服务供应商的话会有风险。因此这些系统往往由组织的现有IT部门设计、开发、操作、管理。

·非专有、涉及关键任务的系统——那些非专有，但仍然涉及关键任务的系统可以由另一家公司开发，不过仍然要由组织的现有IT部门设计、操作和管理。

·非专有的系统——只要能和服务供应商建立合适的服务水平协议（SLA），非专有、提供标准化功能和接口的系统通常就很适合外包给云服务供应商。这种系统的例子有电子邮件、日历、内容管理工具。

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

软件架构，集成设计

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

软件架构，应用设计

·远程服务失败时要实施一定的策略

·用补偿事务代替原子事务

·使用异步消息传递

·服务发生变化时更新应用的消费服务

·测试有特定需求的S+S应用

·软件架构，信息设计

S+S会迫使组织采用一种新的方法进行信息设计：

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

要将数据支持为服务范式

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

基础设施架构

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

安全

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

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

管理

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

操作

考虑外包IT操作角色和责任对业务的影响。业务连续性、责任、员工和客户满意度都是关键因素，这些因素必须通过确定明确的SLA和可靠的云服务供应商来解决。

企业应该在融合软件和服务环境的IT操作中发挥积极作用。不过企业应该建立监控系统，以便发现外包服务中技术问题，而不是关注于执行细节。企业还应该建立操作过程，以确保服务供应商尽快解决了问题。

结论

·消费云——将应用和IT服务外包给第三方的云供应商，比如微软的BusinessProductivity在线套件、CRM在线和LiveMeeting服务。

·使用云——使用云中可用的平台和基础设施服务，像WindowsAzure和SQLAzure。

·拥抱云——成为云服务供应商。BizTalkServer企业服务总线（ESB）工具集对此有所帮助，因为该工具集“能集成数据更新、编排通过云服务处理信息交换的工作流”。