再谈服务设计

标签: 随笔文章 | 发表时间:2013-09-04 09:19 | 作者:人月神话
分享到:
出处:http://blog.sina.com.cn/cmmi
服务设计本身分两个方面的内容,一个是本身的服务契约和接口的设计,如soap webservice下的wsdl和xsd文件的设计。一个更加重要的是关于服务的性能,安全,事务,同步/异步,大数据量,日志监控,SLA等方面的设计,前者是实现基本的服务功能,后者才是满足一个高可用的服务架构。

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

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

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

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

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

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

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

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

相关 [服务 设计] 推荐:

再谈服务设计

- - 人月神话的BLOG
服务设计本身分两个方面的内容,一个是本身的服务契约和接口的设计,如soap webservice下的wsdl和xsd文件的设计. 一个更加重要的是关于服务的性能,安全,事务,同步/异步,大数据量,日志监控,SLA等方面的设计,前者是实现基本的服务功能,后者才是满足一个高可用的服务架构. 尽量多根据业务场景设计适合特定业务场景的粗粒度的业务服务,而减少数据服务的使用.

服务设计初探

- - 携程设计委员会
以往,交互设计师的日常主要是配合产品功能需求,快速地绘制线框图,做原型demo,设计网站、手机上人机界面的交互——可若仅限于此,不免有沦为“绘图师”之虞. 在屏幕上与用户的信息交互,只是用户行为的一环. 在设计的过程中我们大可以从固定的配合需求中跳出来,加入“服务设计”的理念,更广泛地思考用户与多服务触点的关系,以求给用户更好的体验.

云服务器安全设计

- - WooYun知识库
目前越来越多的初创企业把自己的业务系统架设在公有云上,包含:阿里云、Ucloud、青云、华为云和AWS. 在云上的安全怎么保证,是目前摆在我们面前的最大问题,因为,互联网公司业务系统在不断迭代,迭代周期最少的有3天,而且架构也不断在改变. 在这种频繁改变的过程中,云安全应该怎么保证. ,云主机安全服务平台(Cloud security as a service),为多租户提供云主机安全服务的产品,减少用户业务系统攻击面,防止恶意的定向攻击(APT).

同步类服务:还能怎么做产品设计创新?

- comain - 同步控
本文灵感源自上周在微博上发布的这么一条感想:. “花一个小时扫描了下本周 @爱范儿 上的有趣创新项目,基本归纳为:① 老土的领域垂直化(eProf/OrderWithMe);② 枯燥的事情趣味化(Pitochart/Perltrees);③ 蛋疼的玩法数字化(ibragu/LEGO Life);④ 无聊的数据社交化(NextGoals);⑤ 窥私的欲望公开化(teleportd).

以互联网产品为核心的服务设计

- - 百度商业用户体验部
当前互联网产品的发展日新月异,从业者在不断地深挖产品的方方面面,这些工作足以使产品的质量非常优秀,但为什么有时却得不到广大用户的认可呢. 从服务设计的角度来分析,我们也许可以得到答案. 进行产品设计时,一般要考虑四个因素:用户、情景、过程、对象(即产品本身). 在服务设计的思路里,产品可以是有形的,也可以是无形的——与用户发生交互的每个环节都是产品的一部分.

高性能服务器设计——模块间通信

- - CSDN博客架构设计推荐文章
       在同一台机器上,不同进程之间的,数据通信方式主要有:socket、unix socket、消息队列、管道、共享内存等多种手段,各个通信方式均存在比较合适的使用场景.      常见进程间的通信方式.        1)socket,主要用于机器之间的网络数据传输,当然也可以用在同一台机器不同进程之间,优点在于可以不做任何的修改,就可以做到跨机器之间的数据传输;.

Memcached的服务设计与启动过程——C10K系列

- - 行业应用 - ITeye博客
C10k要解决的问题,是10K个连接. LINUX下,使用EPOLL可实现异步非阻塞(注:阻塞的一定是同步的,阻塞是调用方自己阻塞自己(等待事件)). 非阻塞:是指调用方不会阻塞自己,如被调用方有数据就返回,无数据就返回EAGAIN,调用方根据EAGAIN决定自己的策略. 因此非阻塞,和异步没有任何关联.

Netty系列之Netty百万级推送服务设计要点

- - 开源软件 - ITeye博客
原文地址:http://www.infoq.com/cn/articles/netty-million-level-push-service-design-points?utm_source=infoq&utm_medium=related_content_link&utm_campaign=relatedContent_articles_clk.

分布式高可用id服务器设计实现

- - C++博客-首页原创精华区
服务端/后台开发中如何生成id是每个开发者都会遇到的问题,在电商、游戏领域尤其突出. 如何保证生成id的唯一性、可靠性、高可用性,如何组织id的格式,在不同的应用场景和限制下实现方式也不尽相同. 我们的应用场景类似电商,在一个订单的生命周期内,有多个逻辑需要生成各自的id,还要考虑到可读性和灵活性,我们决定实现一个独立的id服务.

高并发服务端分布式系统设计概要

- - 博客 - 伯乐在线
写这篇文章的目的,主要是把今年以来学习的一些东西积淀下来,同时作为之前文章《 高性能分布式计算与存储系统设计概要》的补充与提升,然而本人水平非常有限,回头看之前写的文章也有许多不足,甚至是错误,希望同学们看到了错误多多见谅,更欢迎与我讨论并指正. 我大概是从2010年底起开始进入高并发、高性能服务器和分布式这一块领域的研究,到现在也差不多有三年,但其实很多东西仍然是一知半解,我所提到的许许多多概念,也许任何一个我都不能讲的很清楚,还需要继续钻研.