04、简介-项目微服务架构图

上节课我们了解了分布式里边的一些基础概念，那么接下来呢，我们就基于这些概念来看一下我们整个项目的微服架构图，这里呢，我们有一张高清版本的架构图来给大家点开好，这个架构图呢就解释了我们整个项目的技术架构以及技术组合方案，但只有大家完整的做完我们整个项目才会有一个深刻的理解。但是呢，我们可以先来简单的看一下我们整个架构图，如果接下来听不懂也很正常，这些都是我们后来将学习的技术。首先我们说我们这个项目呢，是前后分离开发，我们分为内网部署和外网部署。外网也就是面向公众访问的来部署我们的前端项目，可以由手机APP，当然也可以有电脑的外包网站，而内网部署的是我们整个后台的服务集群，公众呢是通过使用我们的客户端来完成相应的功能，比如登录、注册等，都要通过客户端给我们后台的这些服务来发送请求，当然呢，请求不是直接过来的，所以我们完整的请求流程应该是这样子的，首先通过任意客户端给我们这儿发请求，请求呢先来到我们的NG集群，当这一块呢，暂时先不用改，NG呢将我们把请求转交给我们的后台服务，当然也不是直接转给我们指定的后台服务，N呢会将所有的请求先转交给我们的API网关，那么API网关呢，我们使用spring cloud get外，那网关可以完成什么功能呢？比如网关可以根据当前请求。

动态的路由到指定的服务，看当前请求是想要调用商品服务呢，还是购物车服务，还是检索等等等等等，路由过来的时候呢，如果我们某一个服务众多，比如我们当然请求是来查询商品的，商品呢在三个服务里边都有咱们这个商品服务，那我们网关呢，还可以负载均衡去来调用商品服务，当然当某些服务出现问题，我们也可以在网关这个级别来对服务做统一的熔断和降级，那么这个熔断降级呢，我们使用spring cloud，阿里巴巴提供的sentel这个组件，当然我们网关还有其他的功能，比如认证授权请求过来以后呢，看是否合法，合法了再放行过去。包括呢，我们网关还可以进行限流，也就是限制我们的瞬时流量，比如当前100万个请求同时进来了，我们害怕把所有的请求放过去，把整个后台服务压垮，那我们可以在网关处进行限流、流量控制。我们只。

给他放行1万个过去，那让我们的后台业务集群能很容易的处理完这些请求，但这些东西呢，我们后来都会说，我们呢都是使用spring cloud阿里巴巴提供的sentel组件来完成我们的限流、熔断以及降级工作，当我们的请求通过网关最终到达我们这个服务以后呢，我们服务就进行处理，当然我们这些服务呢，都是使用spring boot来写的一个个的微服务，那服务与服务之间有可能会互相调用，比如下订单的时候，我们又要调商品服务来查询商品的一些信息，那我们使用的是cloud份组件，而且呢，有些请求可能需要登录以后才能处理，所以呢，我们专门还有一个基于奥to的认证中心，我们除了有一般的登录，我们还整合了基于奥to的这些社交登录，那么整个应用里边的安全以及权限控制，我们都是用spring security来进行。

控制。特别是呢，我们这些服务要保存一些数据，或者呢我们要使用缓存等等，那我们缓存呢，使用的是我们red的集群，可以是分片集群加上哨兵集群，当然我们持久化存储数据，使用我们的MYSQL集群，我们可以做成读写分离，也可以最终做分库分表，包括呢，我们服务跟服务之间，我们后来还会使用消息队列来进行异步解耦，包括完成分布式事务的最终一致性，那我们使用的是remit MQ整个集群来做我们的消息队列，包括呢，我们有些服务，比如我们有检索，全文检索，我们要检索一些商品信息，我们使用elas search。

而且呢，我们有些服务在运行期间可能要存取一些图片、视频等，我们使用的是阿里云的对象存储服务，那这一块呢，就是我们整个服务关于数据存储相关的解决方案，包括呢，在项目上线以后，我们为了快速定位项目中可能出现的一些问题，我们使用ELK来对日志进行相关的处理，也就是使用logtench来收集我们业务里边的各种日志，把它呢存储到ES中，然后再使用K班的可视化界面，从ES中检索出相关的日志信息，帮我们快速定位线上问题的所在。

接下来呢，我们再来看上面这些内容，首先我们说在分布式系统中，由于我们每一个服务都可能部署在很多台机器，而且服务跟服务之间要互相调用，那么就得知道彼此都在哪里，那么我们就推荐呢，将所有的服务都需要注册到注册中心，然后呢，别的服务可以从注册中心中去来发现其他服务所在的位置，所以呢，我们使用spring cloud，阿里巴巴NAS来作为我们服务的注册中心，同样的每一个服务的配置众多，我们后来要集中管理这些配置，实现呢改移处配置，这些服务呢，都来自动修改掉，那我们需要一个配置中心，我们也使用spring cloud，阿里巴巴提供的NAS作为我们的配置中心，我们的所有的服务呢，都可以从配置中心中动态获取它的配置，包括服务。在调用期间可能会出现一个问题，比如我们下订单。

服务调用商品服务，商品服务再调用库存服务，可能呢，某一个链路出现了问题，我们呢就得追踪我们整个服务调用链，看哪里出现了问题，那哪一块问题该怎么解决等等，那我们呢可以使用服务追踪，那服务追踪呢，我们使用spring cloud提供的los加zipy，把我们每一个服务的这些信息，然后呢交给我们的开源的promises进行聚合分析，再由gra进行可视化展示，通过promises提供的alert manager，我们实时的得到我们一些服务的告警信息，把这些告警信息呢，可以以邮件或者手机短信的方式通知我们的开发或者运维人员。

而且我们还提供了持续集成和持续部署，要说我们项目发布起来呢，由于我们微服务众多，每一个都打包部署到服务器太麻烦，那有了持续集成，我们开发人员呢，可以将我们修改后的代码提交给gihab，然后呢，我们的运维人员可以通过自动化工具金ins，然后呢从getar have中获取到代码，将它打包成刀客镜像，最终呢，我们使用K8S来集成我们整个docker服务，我们将服务呢以docker容器的方式来运行。以上呢就是我们整个项目的微服务架构图，可能大家现在呢满脸期待又一脸无助，没关系，除了spring boot my circle以及red我什么都不讲，直接使用外，剩下的所有牵扯到的技术以及环境，我们都会在项目中一一讲解和搭建。