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

综述

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

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

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

一张粗略的架构图

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-55BMAbtW-1589352095433)(外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-5kmAI2Ve-1589352176197)()]
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+大数据+区块链

以上说的均可以参考link
link