软件架构设计系列总结—5—SOA面向服务架构简述

  在上篇中我们简单谈了下架构设计中服务层的简单理解，在这里我们将继续服务层的架构，在本节我们将重点在于分布式服务。在分布式系统中表现层和业务逻辑层 并不处于同一物理部署，所以我们必须存在分布式服务，以契约方式发布于 络中，我们的关注点在于服务，面向服务编程，这种通过组合业务逻辑暴露可用服务的架构叫做面向服务架构（SOA）。

    SOA强调一个松耦合，基于宏服务的架构，通过契约暴露给服务消费者可用的服务交互。SOA是以服务为组成构建，原则有：

1. 边界清晰：

       服务层是消费者交互到系统业务的唯一入口,所有我们的服务必须能够被消费者所理解,以及最好处理Request/Response基于消息交换RPC调用,职责明确单一.还有我们更希望我们的服务为作用明确的,CQS(命令-查询分离原则).

2. 服务的自治性

       服务自治主要表现在每个服务都是独立的，其系统部署，管理监控都是独立的。自治体现了服务的松耦合，但并不是服务就是一个孤岛，其可以通过消息交换消费其他服务。

3. 使用契约（接口和数据载体），而非实现

        这也是面向对象设计第一原则。在我们的服务设计中SOA一个重要目标就是互操作，基于SOAP等标准协议实现跨平台互操作，可能存在异构系统。所以我们该选择接口而不是语言具体的类以及基于消息交互。服务对于开发就是一些列行为的组合，数据契约就是数据迁移对象，数据载体。契约使得我们并不关心服务的内部实现，而只关心提供了那些服务，服务的签名如何，怎么调用之类的。

4. 兼容性基于策越

   对于消费者来说服务是否能满足他的需求，这需要服务语义兼容，语义兼容也应该通过可访问方式暴露。是的服务可发现。

    ＳＯＡ是一种设计原则规范，其目标在于为复杂系统提供互操作性和以服务为基础组件构造系统逻辑。把具体的业务逻辑和流程屏蔽，暴露出用户可用的行为集合。ＳＯＡ是一中原则而非集体技术。wcf，webservice是具体ＳＯＡ技术。同时ＳＯＡ也不是我们的目标，客户是不与关心我们采用ｓｏａ与否，这只是我们对系统的一种解决方案。

SOA优势在于给我们提供更好的代码重用，版本控制，安全控制，扩展延伸性。同时降低和服务的耦合，交互必须依赖于服务契约和数据契约，并不关心服务的内部实现。在我们的版本升级，修改过程中可以完全可以重新实现替换原有服务，并不会影响消费程序的使用。

最后说一点：我觉得不管是服务或者resetfull服务我们都必须定义契约，依赖于契约，虽然微软的而技术允许我们直接寄宿服务类，但是对于服务的扩展和延伸而言，说这句话的原因在于我最近看见一些直接寄宿服务类的resetfull架构。