服务端模块化架构设计RPC模块化设计与分布式事务

　　模块间的调用问题
　　由于我们的模块是可以任意组合的，所以就会有一个问题：当两个模块是打包在一起的时候，相当于是内部调用当两个模块是在两个不同的服务的时候，就变成的远程调用
　　也就是说，我们需要为每一种组合都适配一遍
　　这不要了命了么？
　　不要急，我有办法，一套代码适配两种情况用户接口示例
　　我们在之前实现的juejinpin（沸点）模块中，就有用户模型，比如发布沸点的用户，评论的用户等等
　　而用户的相关业务我们有单独的juejinuser（用户）模块，所以juejinpin（沸点）模块中的用户信息就需要从juejinuser（用户）模块中获取
　　这里就会出现我们之前说的问题
　　如果juejinpin（沸点）和juejinuser（用户）是合并在一起的，就像juejinappliactionsingle，那么可以直接进行内部调用
　　如果juejinpin（沸点）和juejinuser（用户）是分开的，就像juejinappliactionsystem和juejinappliactionpin，那么需要通过远程服务调用抽象模块接口
　　对于获得用户信息这个功能，我们先定义一个接口UserApipublicinterfaceUserApi｛通过id获得用户信息UserROget（Stringid）；｝复制代码
　　其中UserRO是userremoteobject，表示远程的，非本模块的用户对象
　　我们可以把这个接口放在juejinbasic中，这样其他的模块也能进行复用RemoteUserRepository
　　我们为juejinpin（沸点）模块中的UserRepository实现一个RemoteUserRepositoryRepositorypublicclassRemoteUserRepositoryimplementsUserRepository｛AutowiredprivateUserApiuserApi；根据id获得一个领域模型OverridepublicUserget（Stringid）｛returnro2do（userApi。get（id））；｝publicUserro2do（UserROro）｛模型转换｝省略其他代码｝复制代码
　　当我们的juejinpin（沸点）模块调用UserRepositoryget（id）时，实际是通过UserApiget（id）来获得用户信息，再通过ro2do将UserRO转为我们juejinpin（沸点）模块中指定的User模型实现UserApi
　　接下来我们分别实现内部调用和远程服务调用这两种用户获取方式InnerUserApi
　　在juejinuser（用户）模块中实现InnerUserApiComponentpublicclassInnerUserApiimplementsUserApi｛这个是juejinuser中的UserRepositoryAutowiredprivateUserRepositoryuserRepository；这个是juejinuser中的UserFacadeAdapterAutowiredprivateUserFacadeAdapteruserFacadeAdapter；OverridepublicUserROget（Stringid）｛UseruseruserRepository。get（id）；returnuserFacadeAdapter。do2ro（user）；｝｝复制代码
　　我们只需要直接调用UserRepository就行了
　　这条链路是这样的：
　　如果模块是合并的，那么直接通过内部的juejinuser（用户）模块提供的InnerUserApi就能获得用户信息了FeignUserApi
　　在juejinbasic（基础）模块中实现FeignUserApipublicclassFeignUserApiimplementsUserApi｛AutowiredprivateUserFeignClientuserFeignClient；OverridepublicUserROget（Stringid）｛ResponseUserROresponseuserFeignClient。get（id）；if（response。isSuccess（））｛returnresponse。getObject（）；｝thrownewRuntimeException（response。getMessage（））；｝｝FeignClient（namejuejinuser）publicinterfaceUserFeignClient｛GetMapping（user｛id｝）ResponseUserROget（PathVariableStringid）；｝复制代码
　　这里需要集成UserFeignClient，通过Feign的方式来获得用户的信息
　　这条链路是这样的：
　　如果模块间是分开的，分别位于不同的服务中，就需要通过Feign等RPC方式了Feign路由映射
　　我们的juejinuser（用户）模块对应的服务实际上是juejinappliactionsystem，或者是其他的名称（不同的模块组合可能会有不同的命名）
　　但是如果每种组合方式都要手动修改对应的名称，那肯定不行，太麻烦了
　　我们可以看到在上面的示例中指定为对应的模块名称juejinuser，也就是UserFeignClient上的注解FeignClient的参数是juejinuser
　　但是只是这样还不行，毕竟我们没有一个叫juejinuser的服务
　　所以我们要想办法让juejinuser能够根据不同模块组合动态的映射为对应的服务名称
　　这个功能其实我们已经在网关路由模块化支持与条件配置实现过了，大概的流程是在build。gradle中添加额外的脚本生成router。properties，其中记录当前服务包含的模块processResources｛资源文件处理之前doFirst｛SetStringmSetnewHashSet（）遍历所有的依赖project。configurations。forEach（configuration｛configuration。allDependencies。forEach（dependency｛如果是我们项目中的业务模块则添加该模块名称if（dependency。groupcom。bytedance。juejin）｛mSet。add（dependency。name）｝｝）｝）移除，基础模块不需要路由mSet。remove（juejinbasic）如果包含了业务模块if（！mSet。isEmpty（））｛获得资源目录FileresourcesDirnewFile（project。projectDir，srcmainresources）创建路由文件FilefilenewFile（resourcesDir，router。properties）if（！file。exists（））｛file。createNewFile（）｝将模块信息写入文件PropertiespropertiesnewProperties（）properties。setProperty（routers，String。join（，，mSet））OutputStreamosnewFileOutputStream（file）properties。store（os，Routersgeneratedfile）os。close（）｝｝｝复制代码读取router。properties将数据同步到注册中心ComponentpublicclassRouterRegister｛监听服务注册前置事件EventListenerpublicvoidregister（InstancePreRegisteredEventevent）throwsException｛读取router。properties资源文件ClassPathResourceresourcenewClassPathResource（router。properties）；加载到Properties中PropertiespropertiesnewProperties（）；try（InputStreamisresource。getInputStream（））｛properties。load（is）；｝获得routers值Stringroutersproperties。getProperty（routers）；写入metadata中MapString，Stringmetadataevent。getRegistration（）。getMetadata（）；metadata。put（routers，routers）；｝｝复制代码
　　（上面两块更详细的内容可以看网关路由模块化支持与条件配置中的实现）监听心跳事件刷新模块和服务的映射关系
　　这里我们只要把网关的路由刷新逻辑移过来就行了Slf4jpublicclassRouterLoadBalancerClientFactoryextendsLoadBalancerClientFactory｛privatefinalDiscoveryClientdiscoveryClient；privatevolatileMapString，StringrouterMapCollections。emptyMap（）；publicRouterLoadBalancerClientFactory（LoadBalancerClientsPropertiesproperties，DiscoveryClientdiscoveryClient）｛super（properties）；this。discoveryClientdiscoveryClient；｝OverridepublicTTgetInstance（Stringname，ClassTtype）｛StringroutergetRouter（name）；log。info（Routermapping：｛｝｛｝，name，router）；returnsuper。getInstance（router，type）；｝protectedStringgetRouter（Stringname）｛returnrouterMap。getOrDefault（name，name）；｝监听心跳事件EventListenerpublicvoidrefreshRouters（HeartbeatEventevent）｛新的路由映射MapString，StringnewRouterMapnewHashMap（）；获得服务名ListStringservicesdiscoveryClient。getServices（）；for（Stringservice：services）｛获得服务实例ListServiceInstanceinstancesdiscoveryClient。getInstances（service）；if（instances。isEmpty（））｛continue；｝这里直接拿第一个ServiceInstanceinstanceinstances。get（0）；获得metadata中的routersStringroutersMetadatainstance。getMetadata（）。getOrDefault（routers，）；String〔〕routersroutersMetadata。split（，）；for（Stringrouter：routers）｛newRouterMap。put（router，service）；｝｝if（！this。routerMap。equals（newRouterMap））｛log。info（Updateroutermap｛｝，newRouterMap）；｝更新缓存this。routerMapnewRouterMap；｝｝复制代码
　　通过监听服务注册的心跳，同步模块和服务的映射关系
　　扩展LoadBalancerClientFactory，在中间添加一步将模块名称映射为服务名称的逻辑
　　这里高版本的SpringCloud用的是springcloudloadbalancer做的负载均衡，所以我们扩展LoadBalancerClientFactory就行了
　　如果是低版本，用的是ribbon，扩展的类是不一样的，有需要的话可以看【SpringCloud】协同开发利器之动态路由RibbonLoadBalancer解析篇，也可以参考这个库的源码来扩展ribbon条件配置
　　最后还需要添加一个配置类ConfigurationAutoConfigureBefore（LoadBalancerAutoConfiguration。class）EnableFeignClients（basePackagescom。bytedance。juejin。basic。rpc。feign）publicclassFeignAutoConfiguration｛BeanConditionalOnMissingBeanpublicUserApiuserApi（）｛returnnewFeignUserApi（）；｝BeanpublicLoadBalancerClientFactoryrouterLoadBalancerClientFactory（LoadBalancerClientsPropertiesproperties，DiscoveryClientdiscoveryClient）｛returnnewRouterLoadBalancerClientFactory（properties，discoveryClient）；｝｝复制代码
　　用ConditionalOnMissingBean标记FeignUserApi
　　当juejinpin（沸点）和juejinuser（用户）是合并在一起的时候，Spring会识别到InnerUserApi，于是不会注入FeignUserApi，所有的用户接口都会走本地用户模块的UserRepository
　　当juejinpin（沸点）和juejinuser（用户）是分开的时候，FeignUserApi会被注入，所有的用户接口都会走Feign
　　这样我们只需要根据需求定义对应的xxApi，然后分别实现InnerApi和FeignApi或是DubboApi的方式，之后无论我们对模块进行怎么样的自由组合都能够自动适配，不需要额外的手动处理分布式事务问题
　　如果我们的模块间调用需要用到分布式事务是否存在一些方式能够做到兼容呢，当两个模块合并在一起的时候就用本地事务，当两个模块分开的时候就用分布式事务，根据模块间的组合方式自动识别切换
　　目前我的答案是不太好做（当然如果有大佬想到比较好的方式也可以分享一下）
　　现在有如下的代码PostMapping（test）SmartTransactional我们自己实现事务切面publicvoidtest（）｛a。a（）；本地调用b。b（）；本地调用或服务间调用｝复制代码
　　如果我们自己实现事务切面
　　我们什么时候能知道是不是服务间调用？b。b（）调用的时候，我们可以根据不同的实现确定是本地调用还是服务间调用
　　当我们调用b。b（）确定了服务间调用需要选择分布式事务的时候，a。a（）已经执行了
　　所以我们其实没办法在方法开始之前确定方法中是否会有服务间调用，更何况还会有嵌套事务等复杂场景
　　如果一定要用分布式事务的话，还是单独处理比较好，可以额外加一个方法PostMapping（testlocal）TransactionalpublicvoidtestLocal（）｛a。a（）；本地调用b。b（）；本地调用｝PostMapping（testseata）GlobalTransactionalpublicvoidtestSeata（）｛a。a（）；本地调用b。b（）；服务间调用｝复制代码
　　这样的写的话也不需要频繁修改，只需要让前端调不同的接口就行了
　　而且一般来说需要用到分布式事务的也就几个核心场景，不会特别多
　　所以这种方式虽说加入了一些人工判断但应该也不会特别麻烦总结
　　要一套代码适配不同的场景其实就是定义一个接口然后进行多种实现，其优势在于借助接口的特性在不同场景下适配不同的实现，不仅不需要频繁修改代码，还可以实现InnerUserApi，FeignUserApi，DubboUserApi等多种方式，甚至其他系统的用户信息，如DouYinUserApi
　　同时借助已有的组件为我们服务，如Spring的条件配置，注册中心的组件能力等