springrain微服务架构

原创
09/15 11:42
阅读数 1

目标

以前单位主要是外包项目为主,在设计微服务架构时需要满足以下条件

  • 技术组件模块化,按需依赖加载

  • 对开发人员要求低,2年经验满足业务开发.

  • 学习成本低,正常情况2周就要能够上手开发业务.

  • 方便开发运维调试,最好是单机调试

  • DevOps工具链完善,摆脱人力运维

  • 场景灵活,不修改业务代码,可以实现单体,微服务部署模式切换.

  • 支持自动化的分布式事务,不写补偿代码.

方案选型

  • 鉴于SpringCloud的组件复杂度,不采用.

  • 最新的Serverless基本是推翻了现有的运维开发方式和体系,目前整体还处于大厂的验证阶段,不采用.

  • Service Mesh 能够利用现在的开发运维体系,把SpringCloud的组件下沉到平台层,业务层基本可以做到无侵入无感知,Istio+K8S黄金搭档,让基础组件和业务分离,采用此方案.

组件选型

软件环节越多,整体技术栈的复杂度就越高,坚持最少组件思想.比如ES即做全文检索又做NoSQL,RocketMQ即处理日志又参与业务.

  • Istio和K8S作为基础平台,使用istio集成的组件:EFK,Prometheus,Grafanan,Kiali

  • CephFS实现分布式文件系统,和K8S对接,解决应用pod漂移之后的数据同步问题.

  • MySQL MGR作为数据库集群方案,保障数据库集群安全和读写性能.

  • Redis作为分布式缓存和分布式锁.

  • RocketMQ作为消息队列,处理流量削峰和日志等异步处理.

  • ES做为全文检索和NoSQL引擎.

  • Flink作为大数据引擎,使用K8S代替yarn进行资源调度,cephfs代替hdfs,数据落盘到ES,整体脱离Hadoop技术栈,降低开发运维成本.

  • GRPC作为服务通讯协议

  • Seata作为分布式事务方案

  • Sharding-jdbc作为分库分表方案

  • springrain作为业务开发平台.

  • Jenkins作为代码部署平台

设计实现

说明

springrain实现功能模块拆分,根据业务需要,选择不同的依赖,例如springrain-frame-cache-memory 和 springrain-frame-cache-redis 缓存组件.

根据场景修改Maven打包POM依赖,隔离业务代码的影响
每个业务模块(例如springrain-system)里有service接口,service实现,web三个子模块项目,隔离相互的关联性.service接口service实现对类的命名和路径由严格的规范要求. 通过Maven的POM配置,按需引用依赖的模块.
例如在微服务方式下,服务B依赖服务A,服务B的POM只需要依赖服务Aservice接口项目,不依赖服务Aservice实现.如果是单体项目,依赖服务Aservice实现即可.

实现思路:

  • 启动加载springbean时,先检查本地是否有实现,如果没有就启动GRPC远程调用,如果开启了GRPC,就会调用Seata的配置,同时开启分布式事务.(开发人员无感知)

  • 基于seata分布式事务实现.支持有注解和无注解(底层记录日志)混合使用.(开发人员无感知)

  • 基于Istio实现微服务的发现,监控,熔断,限流.(开发人员无感知)

限制:

  • 接口和实现的命名强制规范.

  • 一个RPC接口只能有一个实现.

  • 分布式事务,一定要避免A服务update表t,RPC调用B服务,B服务也update表t.这样A等待B结果,B等待A释放锁,造成死锁.

  • Service层不可以使用Servlet API,例如 HttpRequest

实现代码

微信无法很好支持代码显示和资料连接,影响阅读体验,麻烦访问以下地址或者点击 [阅读原文]


https://www.jiagou.com/post/58-grpc-seata-mesh/#%E5%AE%9E%E7%8E%B0%E4%BB%A3%E7%A0%81

本文分享自微信公众号 - 架构经验(gh_1e5343e31369)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部