04、简介-项目微服务架构图_7)项目结构图:每日一图,今天的图中除了业务微服务之外,特应该体现出 resttemplate

分为外网（面向用户）和内网，首先通过客户端（手机，电脑等）发送请求，请求先来到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容器的方式来运行。
1
2
3