Dubbo 服务化架构

开源、高性能、透明化,当前最成熟的 SOA 服务治理方案




我们的电商架构,将应用程序进行业务拆分,如订单、用户、优惠促销、售后、商品管理等业务,这些业务独立运行,并提供服务给其他业务。


系统利用分布式服务框架(阿里的 Dubbo )搭建分布式服务。Dubbo 是开源的、高性能和透明化的 RPC 远程调用服务框架,是当前最成熟的 SOA 服务治理方案。


对于复杂的分布式事务,我们的电商架构通过微交易架构 TCC 来解决复杂事务的一致性问题。




SOA

面向应用SOA把原单体应用里的业务逻辑层剥离出来,作为单独的服务对外提供。


例如,会员使用的演出详情页,展示演出的信息、演出库存,演出价格;会员系统修改订单,同时也需要获取演出的基本信息、价格信息等。





微服务

每个服务独占式地封装对应主数据表的访问,这些服务构成系统的基础服务,一起组成系统的微内核,供所有上层应用共享。



微内核服务是原子服务,接口粒度比较细,可以在其上构造聚合服务,为上层应用提供粗粒度服务。可以是信息聚合,比如图演出聚合服务整合演出的基本信息/库存/价格;也可以是流程聚合,比如下单接口,调用来自多个服务的接口,共同完成复杂的下单操作。

这里服务是分层次的,聚合服务是上层,基础服务是底层,依赖规则如下:


        ●  上层服务可以调用同层服务和基础服务
        ●  基础服务是原子服务,不可相互调用
        ●  前端应用可调用聚合服务和跨层调用基础服务





TCC

跨应用之间,通过业务层面逻辑顺序,进行预先锁定,后续应用事物失败,之前应用数据回滚来实现。

TCC分别对应Try、Confirm和Cancel三种操作,这三种操作的业务含义如下:

    Try:预留业务资源
    Confirm:确认执行业务操作
    Cancel:取消执行业务操作


稍稍对照下关系型数据库事务的三种操作:DML、Commit和Rollback,会发现和TCC有异曲同工之妙。


在一个跨应用的业务操作中,Try操作是先把多个应用中的业务资源预留和锁定住,为后续的确认打下基础,类似的,DML操作要锁定数据库记录行,持有数据库资源;Confirm操作是在Try操作中涉及的所有应用均成功之后进行确认,使用预留的业务资源,和Commit类似;而Cancel则是当Try操作中涉及的所有应用没有全部成功,需要将已成功的应用进行取消(即Rollback回滚)。其中Confirm和Cancel操作是一对反向业务操作。



关于我们 · 技术社区 · 招贤纳士 · 联系我们 · 公司网站
© 2017 版权所有 北京瑞友科技股份有限公司 京ICP备10023829号-1