十年风雨！看蚂蚁金服SOFA 分布式架构演进.docx

? ? ? ? ? ? ? ? 十年风雨！看蚂蚁金服SOFA 分布式架构演进 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 01 介绍 _____ 大家好，我是蚂蚁金服的鲁直，是蚂蚁金服微服务团队的 ?TL，同时也负责 SOFA 对外开源的相关事宜。 非常感谢中生代社区王友强，蚂蚁右军的组织，让我今天能够有机会给大家做一个分享。我今天给大家带来的分享是「SOFA 分布式架构的演进」。 在开始之前，可能很多人不太清楚 SOFA 是什么东西，这里先做下简单地介绍。SOFA 是蚂蚁金服自研的一套金融级分布式中间件，从写下第一行代码到今天已经有将近 10 年的时间，包含了应用容器，RPC，消息，数据中间件，分布式事务，限流，熔断，分布式链路追中等等框架，算是一个分布式中间件全家桶。随着蚂蚁金服这 10 年业务的飞速发展，SOFA 也在这个过程中得到了大量地锤炼，快速地成长，支撑了每年双十一，双十二，新春红包等大型活动。大家可以从下面这种图中看到 SOFA 涵盖的范围。在今年 4 月份，SOFA 开始了开源之路，目前已经有部分组件开源在了 Github 上面，欢迎大家围观 star：/alipay 。 02 早期模块化 _____ 要讲 SOFA 的发展过程，要从支付宝的早期开始，在支付宝的早期，支付宝的全站的架构非常简单，就是一个简单的分层架构，类似于下面这张图： 最前面是一个负载均衡器，负载均衡器的流量直接打到当时支付宝唯一的系统钱包系统里面来，然后钱包系统后面连着一个数据库。这种系统的分层设计在刚开始系统流量不高，团队不大的时候，没有太大的问题，但是当团队规模扩大，团队内部以及团队之间的协作成本就会越来越高，所以在 SOFA 最开始的版本中，我们引入了模块化的方案，来为系统解决系统内部的协作的问题，也为服务化做准备。 SOFA 的模块化不同于一般的模块化的方案，在一个一般的模块化的方案里面，只是在代码的组织结构上进行了模块化的拆分，负责同一个功能的代码内聚到到一个 Maven 模块下面，最终打包成一个 JAR 包。这种模块化的方案有一个缺陷，就是没有考虑运行时的问题，在这种模块化的方案里面，一般上都只有一个 Spring 的上下文，意味着一个模块里面的 Bean 可以任意地访问另一个模块里面的 Bean 而没有任何控制，长期来看，这种情况会导致模块和模块之间在运行时的高度耦合。 为了解决这个问题，SOFA 的模块化方案给每一个模块都加上了一个独立的 Spring 上下文，默认的情况下，一个模块不能直接引用另一个模块的 Bean。当需要引用另一个模块的 Bean 的时候，需要在代码中通过类似于 RPC 的服务发布和引用来解决，比如当模块 A 需要调用模块 B 的 SampleService 这个 Bean 的时候，模块 B 可以通过以下的代码来提供服务： sofa:service?ref=sampleService?interface=com.alipay.sofa.sample.SampleService/ 另一个模块 B 就可以通过以下的代码来引用服务： sofa:reference?id=sampleService?interface=com.alipay.sofa.sample.SampleService/ 通过 SOFA 的模块化方案改造之后，一个系统的模块可以如下图所示，图中的红线就是 JVM 的服务发布和引用： 03 从单应用到服务化 _____ 通过 SOFA 引入模块化的方案之后，在一定程度上帮助业务解决了研发效率的问题。但是随着业务的不断地发展，团队规模的不断扩大，单纯靠一个系统内的模块化已经难以满足业务的诉求，所以，在这个时期，我们开始了服务化的改造，这个时候，SOFA 之前的模块化的方案的另一个优势就能够体现出来了，当我们将一个系统的多个模块通过服务化拆成多个系统的时候，只需要在原来的 sofa:service/ ?以及 sofa:reference/ 里面加上一个协议，就可以将本地的模块间的调用变成 RPC 的调用： sofa:service?ref=sampleService?interface=com.alipay.sofa.sample.SampleService ? ? ? ? ? ? ? ? ? ?sofa:binding.bolt/ ? ?sofa:service/ sofa:reference?id=sampleService?interface=com.alipay.sofa.sample.SampleService ? ? ? ? ? ? ? ? ? ?sofa:binding.bolt/sofa:reference/ 在服务化