1、微服务实践痛点与解决方案目录CONTENTS微服务的拆分分布式事务微服务的监控微服务拆分微服务粒度服务划分方法-DDDMarketingcontextSalescontextSupportcontextdomainsSales opportunitiesSalesconstractcustomerslicensecustomersdetectsBound context微服务拆分线索单个系统作为一个微服务粒度会太大吗？数据库的table大概有多少，有50以上？（数据库大概50张表左右）管理成本，容易理解？这个微服务团队需要多少人，5-7个人subsystemservice packagedep

2、endencylibTable-prefix多个service之间有类似的功能服务需要注意的一些点pattern描述Bussiness-driver拆分的时候首先考虑业务需求Service first data last先拆分业务，再拆分数据Share1.频繁变动的服务，作commonservice2.比较固定的服务，log，dateutil,stringutil，可以封装成jar包Anti-rest服务之前的交互可以有rest，再有些情况也可以通过eventAnti-retrytimeout必须结合Circuitbreaker模式，避免一直重试浪费资源DAG不要涉及环路的设计Distribu

3、tion Transaction设计的时候一定要考虑事务，能避免尽量避免dependency运行时候依赖，部署避免依赖微服务分布式事务微服务分布式-springJTA1.Atomikos2.Bitronix3.LCN Tm事务管理器S1（txclient）S2(txclient)1.starttransaction注册事务2注册事务3.提交和回滚DB连接池DB连接池4.Commit&rollbacktstartAtstartBtstartctendAtendB.C锁时间微服务分布式-事务MQ全局事务由一个个小的本地事务组成ServiceAMQDBServiceB2执行本地事务1发送消息3执行本

4、地事务1发送half消息2发送成功4Confirm/rollback4Confirm/rollback5超时回查6超时回查消息可消费B 在消费的时候cashMq保证消息至少消费一次1执行本地事务发送消息2网络或者Acrash分布式事务Mq考虑回滚的复杂度ABASTBFTCBSTCFT缺点：正向补偿：服务一多，反向补偿复杂度会很高，一般mq采用用正向补偿的方式，利用重试机制和人工处理避免回滚时间窗口拉长：异步消费时间无法控制；正向补偿失败后，需要人工处理优点：实现相对简单，rocketmq已经支持事务.ST.FT.事务MQ的适用场景实时性要求不高的业务-后一个服务之要能够完成，时间长一点没关系被

5、动型业务-后一个服务对前一个服务没有决策权退款付款记账微服务分布式-基于saga算法ServiceAServiceBAlphaDBTransaction Astart/EndTransaction Bstart/EndTransactionId异常/超时补偿OMEGAOMEGA优点（相比TCC）：只需要写一个幂等的补偿接口实时性相对比较好缺点：数据隔离性不好SAGA执行流程ServiceAServiceBsagastartTxid1 A start(补偿接口描述符)Txid=1ServiceCsagastartTxid1 A start(补偿接口描述符)Txid1 B start(补偿接口描述

6、符)Txid1 B endTxid1 C start(补偿接口描述符)Txid=1触发补偿alpha服务挂掉，end没有发送Aplfa crash，消息发送不出来Txid1 B start(补偿接口描述符)Txid1 B endTxid1 C start(补偿接口描述符)Txid1 C end(补偿接口描述符)Txid1 A endsagaendTxid1 C abortTxid1 B 补偿Txid1 A endsagaenddoA()doB()doC()SAGA模式的适用场景可补偿的事务，实时性要求比MQ高的事务