基础服务和复合服务的区别?

kazaff
  • 987

最近在搞SOA,技术层面的东西还容易理解,但是思想层面的就相对有些难以消化了~

基础服务和复合服务,字面上来看非常简单,无非就是基础服务表示原子不可分,复合服务可以由多个基础服务或复合服务组合而成。

但是在实际项目中,往往很难容易的把业务场景归类为它们之中的某一个~

所以想问大家,有没有什么辅助分类的心得或原则?

希望以实际场景为例,我试着假设一种场景:

班级,学生

基础服务就是:

  • 班级的基本信息的增删改查
  • 学生的基本信息的增删改查

能否以此实例来延伸举一些基础服务和复合服务的实际例子?

回复
阅读 3.5k
3 个回答
✓ 已被采纳

SOA设计最好以实际例子来,以班级学生的增删改查做为SOA的例子,容易让人偏离SOA的目标。为了分布式而分布式。
SOA服务的抽象应该是最难的,不熟悉业务的肯定抽象不出来,所谓“增删改查”原子接口粒度太细了
以电商场景为例
增加一个订单,在之前要检查库存、检查用户帐户余额,生成订单、生成货品子单、生成支付单,不同的情况还有不同的分支,这里涉及到十几张表的逻辑,你要是提供一堆表的增删改查接口,客户端没法用,理解业务成本太高。
而且,稍微增加一个业务需求,比如下单的时候计算促销扣减,这个如果不封装到SOA接口中,就会散落到各个客户端去,这样SOA就没有任何意义了。
所以,SOA必然是带有业务含义、逻辑的接口,万万不能因为所谓的“原子性、重用性”,把以前一个进程内的数据增删改查接口发布成为SOA接口。增删改查的原子接口直接在进程内部搞定,不要发布成分布式的,否则效率太低了。

复合型SOA接口怎么抽象才能好,和你对业务了解的深度有关,这个看经验了,没有通用范式可遵循
如果是不理解的新业务,我们设计接口刚开始是遵循业务的需求,怎么方便怎么来。
一旦业务需求发生变化,或者多个业务需要使用接口,就会通过版本号迭代,接口重构,慢慢的把重用性做出来。
打个比方,刚开始我们用户中心有三类客户,分别在三张不同表,提供了三类不同的SOA接口,后来内部设计将其统一为主表+扩展表的形式,变为同一个表的用户不同的分类,这时候,就开始重构接口,设计2.0,将其统一。接口升级的时候,保持对前一个版本的兼容,也是很重要的。

是否可以以事务的维度去区分呢?

比方说,需要跨事务来完成的一些操作就属于复合服务?

那复合服务就是:

  • 班级调整,增班并班之类的

没做过SOA,根据你的场景推的……

撰写回答
你尚未登录,登录后可以
  • 和开发者交流问题的细节
  • 关注并接收问题和回答的更新提醒
  • 参与内容的编辑和改进,让解决方法与时俱进
宣传栏