分为外网(面向用户)和内网,首先通过客户端(手机,电脑等)发送请求,请求先来到NGINX,NGINX将请求转交给后台服务(先转交给API网管spring cloud gateway)。网管可以动态路由看发送过来的请求想要调用的是哪个服务,如果服务有集群部署,那么网管还可以进行负载均衡的调用服务,如果某个服务有问题,也可以在网关级别对服务进行熔断降级(sentinel) 还可以进行认证授权操作,还可以进行限流操作,如果同时又100W个请求到达,那么我们可以只放行过去1W个请求,防止把后台压垮。
当通过网关到达业务集群后(每个都是单独的spring boot 项目),服务与服务之间可能需要互相调用,有些请求需要登录才能进行,此时使用auth2.0,整个应用中的安全控制都使用spring security 。
特别是服务要保存一些数据,要是用缓存,此时使用的是Redis集群,可以使分片集群加上哨兵集群,持久化使用MySQL集群,可以做读写分离,也可以做分库分表,服务与服务之间,我们会使用消息队列(RabbitM)来进行异步解耦和分布式事务的最终一致性。
有些服务有全文检索,检索一些商品信息,我们使用elasticSearch ,
有些服务在运行期间,可能要存取一些图片视频等,我们使用的是阿里云的对象存储服务OSS (上面这些就是数据存储相关的内容)
在上线后为了快速定位问题,我们使用ELK做相关的处理。使用logstash 来收集业务里面的各种日志,把它存储到ES中,然后再使用KLbana可视化界面 从ES中检索出相关信息,帮我们快速定位线上问题的所在。
然后开始上面部分:将服务注册到注册中心,别的服务就能从注册中心中发现其他服务所在的位置(nacos),同样地,每一个服务的配置众多,我们需要实现改一处配置在众多地方生效,我们需要配置中心(nacos).如果在服务调用过程中出现问题,比如商品调用订单调用库存,那么我们需要链路追踪来定位哪里出现了问题。Sleuth+zipkin将服务的信息交给开源的prometheus 进行聚合分析,再由grafana进行可视化展示,通过prometheus提供的altermanager 实时得到服务的告警信息,把告警信息以邮件或者短信的方式通知开发或运维(这是上面一部分。)
然后还提供了持续集成和持续部署(CI/CD),由于微服务众多,每个都需要我们自己打包部署,那么耗时太多, 通过持续集成我们开发人员可以将修改后的代码提交到GitHub,然后运维人员从GitHub中获取到代码将它打包成docker镜像,最终我们使用K8S 来集成我们整个docker服务。将服务以docker容器的方式来运行。