k8s上运行我们的springboot服务之——简单的架构思考

发布于: 2020 年 05 月 21 日

综述

目前java后台开发人员不管面试还是真实的项目实战都离不开一个主题soa,微服务的技术实现主要有springcloud和dubbo(当然还有其他的一些rpc框架)。个人觉得rpc架构只是一种服务调用的实现,我们开发人员更应该去了解各个技术实现各个复杂的业务功能(例如:如果用分布式锁、lua去实现秒杀),具体表现在开发人员的工作内容了解业务去用合理的sql语句解决问题,其他的接口和底层的服务,在架构上应该是现成的拿来即可用。

随着k8s技术的出现和迅速的市场占有(可以去看看阿里云等无不和k8s有紧密的联系)个人觉得所有的rpc框架以后都不得不去拥抱k8s,目前springcloud已有k8s的starter了。

google果然是大厂,推出k8s后又推出了istio了。个人觉得我们使用k8s+istio和springcloud的某些功能也能完美的搭建我们后台的微服务。这样能更好去构建开发,发布,测试,监控等等devops流程

一张粗略的架构图

1、通过istio(边车,监控,负载均衡等等) + cloud的gateway(白名单,权限,访问统一入口,服务是否允许被调用)来完成微服务。

2、基础服务划分,相互之间尽量不要有调用,注意其原子性和幂等性

3、对于整个框架构建,如果有一个需求需要查询多个服务的需求,例如:我用户,订单,支付在不同的基础服务,有个需求是 我需要分页查询用户的的订单和支付(通过用户id把数据串联起来),那么这一部分查询需要单独搞一个聚合服务,专门来处理这种 跨服务的查询,不要在某个服务或者在业务系统来调不同的业务来组装

4、不能环形依赖

5、简单的说明

1)所有服务访问和调用入口在gateway,gateway做了很多处理,减少服务直接的访问

2)服务打包成docker镜像上传到私服,k8s构造svc的时候去统一的私服拉取镜像

3)需要访问服务的时候需要从k8s的master节点进入,以www.服务名.com的方式,也就是配置/etc/hosts:www.服务名.com对应masterip

4)所有的配置放到nacos中

5)服务间调用通过feign来完成

6)服务日志统一通过logback flunet收集,放到db(efk)中,方便查看

7)文件存储用mongo的gridfs实现

8)mysql的读写分离,分布式事务

9)分布式锁用redisson完成,lua脚本的重要性

10)监控通知使用alertmanager,skywalking等

11)爬虫考虑

12)当然如果涉及到大数据,那么spark,hadoop,flume,hbase按需加入到各个服务中,这是后话了 等等

未来的技术方向

个人觉得未来的技术:物联网+人工智能+5G+cloud+大数据+区块链

具体的架构代码https://gitee.com/lvmoney/zhy-frame-parent

发布于: 2020 年 05 月 21 日 阅读数: 27
用户头像

柠檬

关注

人生尚未成功,朋友仍需努力 2020.05.21 加入

长期从事微服务,中台等后台开发和架构设计。一些见解和实现可查看https://gitee.com/lvmoney/zhy-frame-parent

评论 (1 条评论)

发布
用户头像
一直没搞清楚JVM-Docker-K8s-Istio之间的关系
2020 年 05 月 23 日 15:45
回复
我来排个序:k8s,istio,docker,jvm,springboot
2020 年 05 月 23 日 16:15
回复
没有更多了
k8s上运行我们的springboot服务之——简单的架构思考