再谈服务设计

标签: 随笔文章 | 发表时间:2013-09-04 17: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,设计网站、手机上人机界面的交互——可若仅限于此,不免有沦为“绘图师”之虞. 在屏幕上与用户的信息交互,只是用户行为的一环. 在设计的过程中我们大可以从固定的配合需求中跳出来,加入“服务设计”的理念,更广泛地思考用户与多服务触点的关系,以求给用户更好的体验.

[译] 微服务设计指南

- - IT瘾-dev
本文为翻译发表,转载需要注明来自公众号EAWorld. 作者:Thilina Ashen Gamage. 原题:Microservices Design Guide. 原文:http://t.cn/EAvCCMb. 全文5949字,阅读约需要10分钟. 2018年,每个人都听说过微服务. 微服务是当今软件工程师的一个热门话题.

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

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

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.

为什么在做微服务设计的时候需要DDD?

- - DockOne.io
记得之前在规划和设计微服务架构的时候,张队长给了我一个至今依然记忆深刻的提示:『你的设计蓝图里为什么没有看到DDD的影子呢. 随着对充血模型的领域认知的加深,我越加感觉到DDD的重要性. 但是DDD内容繁多,是不是要深入去了解呢,我觉得不必入坑太深,个人浅见,它最核心的一点就是针对贫血模型的不足而设计,把原先传统的贫血模型里的业务逻辑层拎出来,融入到Domain层,这样面对复杂业务的规模化变更,我们只需要专注于Domain即可.

深度解析DDD中台和微服务设计

- - DockOne.io
随着业务发展,领域模型和微服务会不断变化和演进,如何用最小代价来适应因为业务变化,而带来的领域模型和微服务演进. 建立 DDD、中台和微服务的统一语言. 我们先简单回顾一下中台的发展历程,2017 年《企业 IT 架构转型之道:阿里巴巴中台战略思想和架构实战》出版后,中台就受到业界热捧. 中台的出现是为了解决以往烟囱式和单体架构的重复开发、数据分散和试错成本高的问题,也是为了提高企业市场响应能力,解决巨型企业由于产品种类繁多、部门林立和沟通困难,而导致的商业模式创新难的问题.

微观SOA:服务设计原则及其实践方式(下篇)

- - 博客园_知识库
   上篇: 微观SOA:服务设计原则及其实践方式(上篇).   在 上一篇文章中,我说到SOA是一个特别大的话题,不但没有绝对统一的原则,而且很多原则本身的内容也具备相当模糊性和宽泛性. 虽然我们可以说SOA ≈ 模块化开发 + 分布式计算,但由于其原则的模糊性,我们仍然很难说什么应用是绝对符合SOA的,只能识别出哪些是不符合SOA的.

微观SOA:服务设计原则及其实践方式(上篇)

- - 博客园_知识库
   下篇: 微观SOA:服务设计原则及其实践方式(下篇).   大量互联网公司都在拥抱SOA和服务化,但业界对SOA的很多讨论都比较偏向高大上. 本文试图从稍微不同的角度,以相对接地气的方式来讨论SOA,集中讨论SOA在微观实践层面中的缘起、本质和具体操作方式,另外也用相当篇幅介绍了当今互联网行业中各种流行的远程调用技术等等,比较适合从事实际工作的架构师和程序员来阅读.