NET 应用架构指导 V2 学习笔记（十六） 服务层设计指导
2010-06-04 00:13 Virus-BeautyCode 阅读(2510) 评论(4) 编辑 收藏 举报如果你的应用是通过服务来提供功能，将服务分离出来一层是相当重要的。这篇将介绍服务的设计，和设计服务的过程中可能遇到的问题，以及服务的设计步骤。
在服务层，你定义服务接口的实现，以及数据契约。一个重要的概念就是服务不应该暴露实现的细节，已经在应用内部使用的业务实体。确保你的业务实体不至于过度影响数据契约。服务层应该提供翻译数据契约和业务实体的组件。
服务接口。服务已接口的形式暴露。你可以将服务接口看做是应用暴露给潜在消费者的，关于业务逻辑实现的外观（主要是业务逻辑层的逻辑）。
消息类型。当通过服务层来交换数据，数据结构被包装为操作支持的消息结构。服务层也包括数据类型和定义在消息中使用的数据类型的契约。
设计考虑
在设计服务层的时候，有很多因素要考虑。但是在设计的时候，一定要考虑消息相关的因素。主要是服务使用消息为基础的交互，通过网络，肯定要比在进程中交互慢，服务和它的消费者的交互通常使用异步方式。另外，在服务端和消费者之间传递的消息可能被路由，修改，接收到的和发送的时候不是一个顺序，甚至在没有使用有保证的投递的情况下可能会丢失。可以参考下面的设计原则：
- 将服务设计为应用范围，而不是组件范围。服务操作应该是粗粒度的，集中于应用操作。服务操作定义的粒度细，可能会导致性能和伸缩性问题。但是，应该确保服务不会返回大量的数据。例如：一个服务操作可能返回大量的统计数据，你应该返回适当量的数据，而不是一次返回大量的数据。确保这个量对于服务和消费者来说都比较合适。
- 在设计服务和数据契约的时候考虑扩展性，不要假定你已经知道客户端是谁。换句话说，数据契约应该设计为，扩展它们的时候，对于服务的消费者没有影响。
- 只为服务契约进行设计。服务层应该只提供功能，而不应该暴露实现功能的细节。同样，如果你需要改变服务契约来提供新的功能，新的操作和类型和现有的契约不具有向后兼容性的话，考虑修订你的契约。
- 从基础架构关注中分离服务层关注。
- 用标准的元素组成实体。
- 在设计的时候，考虑非法的请求。不是所有的服务请求都是合法的，对输入的数据进行合法性验证，验证长度、类型，决绝和清除所有的非法输入。
- 确保服务可以被发现，对于重复的消息可以管理。确保重复的消息不会被处理，或者是重复的处理对于结果没有影响。
- 确保服务可以管理不是按照顺序接受的消息。如果有可能，即使消息不是按照发送的时候的顺序到达的，一样可以按照正确的顺序处理他们。
特定的设计问题
- 用户验证
- 授权
- 通信
- 异常管理
- 消息通道
- 消息结构
- 消息端点
- 消息保护
- 消息路由
- 消息翻译
- 服务接口
- 数据验证
用户验证
用户验证用来角色服务消费者的身份。为服务层设计一个有效的身份验证策略对于安全和可靠性是非常重要的。验证失败会导致系统受到各种攻击，可以参考下面的设计原则：
- 为用户验证选合适的技术，在可能的时候使用平台的特征。
- 考虑为服务代码实现不同的信任设置。
- 确保在使用基本验证，或者是明文的身份信息的时候使用SSL协议。
技术考虑
下面的指导会帮助你选择适当的技术：
- 在需求简单的时候，考虑使用webservice。
- 如果你需要高级的功能，例如可靠的会话，事务，消息日志，性能，支持多协议的情况下，考虑使用WCF。
- 如果你决定使用ASMX，考虑使用WSE。但是，通常情况下，如果你需要WSE的安全，考虑迁移到WCF。
- 如果你决定使用WCF。如果你需要和非WCF和非Windows的系统进行交互，考虑使用在SOAP的基础上使用HTTP协议。如果是内网应用，考虑使用TCP来提高性能和传输安全。如果支持的WCF客户端在同一台机器上，考虑使用命名管道协议。
部署考虑
服务层可以和其它层部署在同一个物理层，也可以单独部署在一个物理层。将服务层和业务逻辑层部署在同一个物理层，来提高性能。可以参考下面的原则：
- 将服务层和业务逻辑层部署在同一个物理层，来提高性能，除非有安全考虑，需要分开部署。
- 如果服务和服务的消费者在同一个物理层，考虑使用命名管道和共享内存协议。
- 如果服务被本地的另外一个应用访问，考虑使用TCP协议来通信。
- 如果服务是通过互联网来访问的，考虑使用HTTP协议进行通信。
设计步骤
一个设计服务层的方法是从服务接口开始，要在服务中暴露的方法和协议。又被叫做协议设计优先。一旦定义好服务接口，下一步就是设计服务实现。可以参考下面的设计原则：
- 定义数据和消息契约的结构。
- 定义服务支持的服务契约。
- 设计业务实体到数据契约之间的翻译。
- 设计和业务逻辑交互的抽象方法。
未完待续。。。。。。。。。。。。。。。。。。。。。。。
