微服务架构

1 前后分离开发，分外网部署和内网部署；外网部署如面向公众访问的前端项目; 内网部署是后端的整个服务集群
2 公众通过客户端(手机、pc、pad)发请求，请求先来到nginx高可用集群，
    nginx将请求转交给API网关集群gateway，网关负载均衡(ribbon)动态路由到指向的服务集群；
    服务调用通过sentinel对可能出现问题的服务进行熔断和降级；
    一个个的微服务都是使用springboot写的；
3 服务与服务之间的调用采用feign/openfeign
4 登录采用整合Oauth2(认证中心)，有些请求可能需要登录后处理，
一般登录和整个oauth2的社交登录；应用里面的安全权限控制用springsecurity来控制
5 服务要保存数据，可以使用redis缓存集群，持久化使用mysql集群(读写分离、分库分表)
6 服务跟服务之间使用rabbitmq来实现异步解耦，事务一致性(数据)，使用mq来做整个服务消息队列
7 某些服务的检索使用elasticsearch,某些服务可能要存取图片视频等用阿里的OSS(对象存储服务)
    elasticsearch来做全文检索服务；
8 项目上线后，为了快速定位项目中可能出现的问题，使用ELK来对日志做相关的处理；
    就是用LogStash来收集业务服务集群里的日志存到ES中，使用可视化界面Kibana从ES中检索出相关的日志信息帮我们快速的定位问题的所在；
9 分布式系统中每个服务可能部署在多台机器，服务跟服务之间要相互调用，就得知道彼此都在那里，所以将服务注册进nacos集群注册中心，别的服务从注册中心发现其它服务所在的位置；每个服务的配置众多，要集中管理这些服务的配置实现改一处配置服务的配置都自动修改掉，使用nacos配置中心
10 服务的调用链路中可能出现问题就得追踪服务调用链看那里出现了问题，使用服务追踪使用sleuth+zipkin把每个服务的这些信息交给开源的Prometheus（pro mei se s）进行聚合分析，再由Grafana进行可视化展示，通过Prometheus提供的altermanager实时的得到告警信息，把这些告警信息可以以邮件或短信方式通知开发或运维人员
11 ci/cd：即还提供了持续集成、持续部署；由于微服务众多(发布)，每一个都打包部署到服务器太麻烦；开发人员将修改后的代码提交到github,运维人员可以通过自动化工具jenkins从gitbub中获取代码，将它打包成docker镜像，最终使用k8s来集成整个docker服务，将服务以docker容器的方式来运行