Dubbo 服务化架构
开源、高性能、透明化，当前最成熟的 SOA 服务治理方案
开源、高性能、透明化，当前最成熟的 SOA 服务治理方案
我们的电商架构，将应用程序进行业务拆分，如订单、用户、优惠促销、售后、商品管理【lǐ】等业务，这些业务独立运行，并提供服务给其他业务。
系统利用分布式服务框架（阿里的 Dubbo ）搭建分布式服务。Dubbo 是开源的、高性能和透明化的 RPC 远程调用服务框架【jià】，是当前最成熟的 SOA 服务治理方案。
对于复杂的分布式事务，我们的电商架构通过微交易架构 TCC 来解决复杂事务的一致性问题。
面向应用SOA把原单体应用里的业务逻辑层剥离出来，作为单独的服务对外提供。
例如，会员使用的演出详情页，展示【shì】演出的信息、演出库存，演出价格；会员系统修改订单，同时也需要获取演出的基本信息、价格信息等。
每个服务独占式地封装对应主数据表的访问，这些服务构成系统的基础服务，一【yī】起组成系统的微【wēi】内核，供所有上层应用共享。
微内核服务是原子服务，接口粒度比较细，可以在其上构造聚合服务，为上层应用提供粗粒度服务。可以是信息聚合，比如图演出聚合服务整合演出的基本信息/库存/价格；也可以是流【liú】程聚合，比如下单【dān】接口，调用来自多个服务的接口，共同完成复杂【zá】的下单操作。
这里服务是分层次的，聚合服务是上层，基础服务是底层，依赖规则如下：
● 上层服务可以调用同层服务和基础服务
● 基础服务是原子服务，不可相互调用
● 前端应用可调用聚合服务和跨层调用基础服务
跨应用之间，通过业务层面逻辑顺序，进行预先锁定，后续应用事物失败，之前应用数据回滚来实现。
TCC分别对应Try、Confirm和Cancel三种操作，这三种操作的业务含义如下：
Try：预留业务资源
Confirm：确认执行业务操作
Cancel：取消执行业务操作
稍稍对照下关系型数据库事务的三种操作：DML、Commit和Rollback，会发现和TCC有异曲同工之妙。
在一【yī】个跨应用的业务操作中，Try操作是先把多个应用中的业务资源预留和锁定住【zhù】，为后续的确认打下基础，类似的，DML操作要锁定数据库记录行，持有数据库资源；Confirm操作是在Try操作中涉及的所有应用均成功之后进行确认，使用预留的业务资源，和Commit类似；而Cancel则是当Try操作中涉及的所有应用没有全部成功，需要将已成功【gōng】的应用进行取消（即Rollback回滚）。其中Confirm和Cancel操作是一【yī】对反向业务操作。
© 2017 版权所有 北京瑞友科技股份有限公司 京ICP备10023829号-1