再谈服务设计

服务设计本身分两个方面的内容，一个是本身的服务契约和接口的设计，如soap webservice下的wsdl和xsd文件的设计。一个更加重要的是关于服务的性能，安全，事务，同步/异步，大数据量，日志监控，SLA等方面的设计，前者是实现基本的服务功能，后者才是满足一个高可用的服务架构。

尽量多根据业务场景设计适合特定业务场景的粗粒度的业务服务，而减少数据服务的使用。数据服务往往暴露大量不应该暴露的数据信息，有违反数据的封闭原则。同时数据服务本身传递的数据量很大，对于服务的消费调用以及ESB总线本身也会造成性能压力。

当设计数据服务的时候要注意，尽量暴露的是领域业务对象，而不是实际数据库的数据库表对象。领域对象是业务也容易理解的概念，而业务上并不会关心具体数据库层面的物理逻辑和数据存储。

减少纯粹意义上的通道型服务的设计，这种服务首先没有严格的服务契约定义，同时传递大量的和当前业务处理无关的数据信息。虽然通道型的服务可以应对灵活多变的业务场景和业务逻辑，但是本身是以牺牲服务的粗粒度和高内聚特性来达到的。一个业务服务如果不能很好的通过服务接口和契约进行自解释，那么这个服务本身算不上严格意义上的服务。

能够设计为异步服务的地方，尽量采用异步服务的方式进行设计。异步服务下虽然增加了服务设计的难度，服务消费和提供的复杂性，但是本身可以彻底达到两个业务组件间的彻底松耦合。同时在异步服务模式下很容易启用消息中间件本身的重试机制，发布订阅机制等。

在组合服务设计的时候，虽然可以调用多个原子服务进行组合，但是由于原子服务本身的无状态特性很难控制分布式事务，你也可以启用ws-transaction标准等来控制分布式事务。但是个人建议最好的方式还是对于组合服务直接调用底层的API方法进行组合，直接启用spring层或数据库的事务机制来控制完整的事务。当然如果原子服务本身的提供方本身来源于不同的物理数据库，则必须处理分布式事务问题。

对于企业级的SOA参考架构下，服务主要解决两个方面的问题，一个是通过服务实现能力的复用和共享，一个是通过服务实现跨业务系统或业务组件的集成。因此这两个方面要区别对待，并不是所有的服务都一定是高复用的，对于特定组件间交互识别和设计的服务往往并不能复用，但是解决了组件间的松耦合问题。

再次强调下服务设计中的服务粒度是指服务提供方本身对服务实现细节的暴露程度，服务内部实现细节暴露的越少则服务的粒度越粗，反之服务的粒度则细化。从这个意义上来看，粗粒度的服务往往针对特定的业务场景设计，并不一定复用度高，但是很好的满足了实现细节的封闭性原则。而细粒度的服务则就是暴露内部细节，虽然可以达到很好的服务复用度，但是不满足组件的高内聚特征，也不利用后续组件内业务规则的管理。

  青春就应该这样绽放   游戏测试：三国时期谁是你最好的兄弟！！   你不得不信的星座秘密