seata在分布式系统中的角色

为什么要选择seata进行讲解？

微服务已经不是什么新鲜话题了，越来越多的公司在进行微服务改造以及相关的探索实践工作。分布式服务在飞速发展，给我们带来减少业务耦合、独立部署等诸多优点的同时，也带来了维护成本高、系统复杂度上升等问题，其中尤为突出的就是分布式事务。当前市面上已经有一些分布式事务的解决方案，其实主要分为刚性事务和柔性事务。刚性事务：比如常见的分布式解决方案，XA两阶段提交，TCC 模式 try commit cancel。柔性事务，比如基于rocketMQ最终一致性方案来保证业务数据的一致性。如果你自己去基于这些原理去实现技术方案的话，消耗大量的开发精力和维度成本。或多或少都存在这样或者那样的问题。所以市面上出现了分布式解决方案框架 比如 国产开源的LCN，阿里的seata。这里说一点，LCN和seata都是解决分布式事务下面的场景，LCN和Seata的实现思路基本上大致是一样的，但是seata的性能要比LCN好，而且不会出现死锁情况。然后市面上分布式事务解决框架主要就是这两个,但是我们选择学习技术的框架主要从以下几个方面去考虑：

1：框架的成熟度，社区的活跃性：其实玩框架就要玩大厂开源的框架，大厂开源框架之前，他们都会在自己的公司里面进行大量项目的实践，大量的bug修复。所以一旦开源了他们的框架一定是很成熟的，各种各样的问题其实在他们在公司里面都遇到过，不可能出现那种低级的问题。其次假设你在玩框架出现什么疑难杂症的时候，去社区里面问他们都是可以帮你提供思路去解决的。而且你可以从官网上看到seata的活跃度很高的，社区一直在维护这个框架，可见阿里对这个框架是很重视的。而LCN其实已经停止更新维护了，如果你在开发中有什么问题，很难有人给你去解决问题。

2：框架的特性：seata支持的模式很丰富的，无侵入式的AT模式，自定义逻辑的TCC两阶段方式，SAGA长事务解决方案，XA相关解决方案。一套成熟的解决方案架构，这几种模式其实已经满足了市面上所有的业务解决方案了。

3：另外如果你业务场景在是最终一致性，柔性事务场景的话，在rocketMQ和rabbitMQ之间选型框架来实现分布式事务的话，尽量采用RocketMQ，RabbitM他底层不是用java语言编写，扩展能力比较差，定位问题也比较困难。而且从性能角度比较的话，rabbitMQ抗并发能力与RocktMQ相差很远。

基于以上特点，从框架成熟度，社区的活跃性，框架的支持的场景特性，性能各个方面进行考量，所以我们对阿里大厂玩的seata框架进行讲解。

第二章主要讲解的内容点

Seata官网 -> 学习相关模式的特性，AT模式，TCC模式，Saga模式，XA模式，特性 以及 应用场景，包括他的架构特点 –> down官网的案例下来进行跑跑相关的案例代码，这样一个环节下来，其实同学们对这个框架是怎么玩的，涉及到那些特性，脑子里就有一个初步的印象和了解。为我们后面剖析源码的时候打好基础。有些同学跑一些框架案例经常会出现各种各样的报错，难以解决，而且，不知道怎么去看案例相关的代码。所以在讲解每个模式之前，我都会首先把相关模式的代理例子先带着大家去玩玩，把他跑起来。其实同学们以后在玩任何一门框架的时候都是基本上是这个思路，从官网先学习他框架相关的架构设计理念，一些专业名词解释，一些支持的特性，每个特性的应用场景。然后针对不同特性他官网提供的源码下载下来跑一跑结合实际的框架去理解，去消化下，去总结。这样其实就是入门了，学习这些将这些有助于我们后面学习源码的时候有个整体的思路，后面源码层面其实有些地方还是比较复杂的，容易绕晕，思路跑偏，我们在第二章对这些框架模式架构设计有了最基本的了解之后，有助于我们后面学习框架的时候不容易迷失方向。

其次，主要宣导授人以渔的思想，教大家怎么去看官网的设计架构，以及架构层面一些知识要点，以后同学们在新上手任何一门新框架的时候，怎么去官网看相关的知识点。其实我发现有些同学在项目中需要用到一个新技术或者说项目需要用到什么技术，一般来说就是  方式一：打开百度或谷歌 -> 搜索关键字【xx教程】-> 找几篇看一看 -> 参考技术文章或博客开始搞 -> 收工。方式二：买相关的书籍或网上找一堆视频照着搞一搞。整个过程面上看一点毛病都没有，你也很好的完成了任务，用到了项目中，很开心，我早期也是这样。不可否认，这样效率很高。但是这样有个缺点，其实你学的东西比较碎，知识点零散，应付下开发工作也许还暂时OK，但是你要正儿八经掌握这门框架就难了。

比如

1、这个框架使用时候有什么限制或注意的地方吗？

2、框架支持扩展吗，我想在那里加个自定义的实现

3、有个某某需求，这个框架能做实现或吗

4、3.5版本的新特性了解了吗

其实当你面对这些问题的时候，从你学习资料的视频或者书籍里面没讲到的时候，心里就没底了，你就回答不上来上面的问题了。

为什么会出现这种情况？

       为什么？每个视频或者书籍的作者在写这些内容的时候站的角度可能都不一样，面向的用户接受群体也可能不一样，作者A注重实用给初学者看，作者B强调理论和原理给高级人员看，再加上作为搜索资料的我们，可能并不能辨别一片文章的深浅，适用程度，一篇看不懂就多搜几篇，一本书没看明白就多买几本，这样，对初学者来说容易迷失，整个来说你学的就不成体系，东一下西一下，你的知识是碎片化的，很难对框架有系统的认识，再一个你的理解就圈在了作者理解的范围内，还可能出现搜了半天最后调不通，发现你用的跟作者的版本不一致，甚至可能会出现作者对于某一问题的认知理解有偏差，而你也就认为是这个样子的，作者说的就是对的，多年以后才发现哦原来不是那样的，当然也有高质量的系列博客或成套教程讲的也非常细非常好，但是这样的资料毕竟少，现在付费知识的优质内容也很多，但是这些学习途径都有一个本质没有变，就是你接收的都是别人消化过的内容，别人告诉你的经验。基于以上的一个情况就反应出了，我们在学习一门框架的时候很容易出现碎片化的知识点，不够系统

那我们怎么学习一门框架？

一个成熟的技术出来可以没有博客没有书籍，一定会有一个官方文档，毋庸置疑，它一定是最准确、最实时的资料，所以我想讲的是技术人应该学会从官方资料去学习一个技术的能力，应该具备这种自我学习总结的能力，个人认为非常重要。总结一下我觉得看官方文档学能带来这么些好处：

1、学会看文档学习的能力，你就具备的学会其他一切技术框架的基础

2、官方文档一般都会从它的架构设计到每个点的细节乃至配置属性都会有，完整、及时又准确，可以保证你学的内容一定是最正确的

3、可以更近距离的接触框架本身，我是这么一种感觉

4、官方的东西原汁原味，能够锻炼自我学习总结能力

但是但是，一般来说开源技术框架都来自国外，（近几年国内的开源技术框架发展也十分迅猛），官网文档都是英文，有一些会配有中文，但是如果没有中文英文不好怎么办，不要怕），一个字【硬啃】，配合有道词典或其他翻译工具一点一点来，慢慢你就会发现，技术框架领域高频单词就那么些，读官方文档基本不用考虑时态，不用懂语法，只要词汇量够，看懂不是什么难事，当然单词量就需要多看多积累，慢慢就好了，这里多提一句，有时间有机会学英语，一定好好学。当然看文档也有一定的技巧，开始上手肯定比较难，从小框架开始，前期可以结合一些其他资料对应着看，慢慢适应，万事开头难。