电商项目——初识电商——第一章——上篇
电商项目——分布式基础概念和电商项目微服务架构图，划分图的详解——第二章——上篇
电商项目——电商项目的虚拟机环境搭建_VirtualBox，Vagrant——第三章——上篇
电商项目——Linux虚拟机中安装docker,mysql,redis_VirtualBox——第四章——上篇
文章目录
要想看懂电商项目的架构图（如上）我们必须先掌握了解分布式的基础知识（如下）
1：分布式基础概念
1.1 微服务
微服务架构风格，就像是把一个单独的应用程序开发为一套小服务，每个小服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP API。这些服务围绕业务能力来构建，并通过完全自动化部署机制来独立部署。这些服务使用不同的编程语言书写，以及不同数据.存储技术，并保持最低限度的集中式管理。
简而言之:拒绝大型单体应用，基于业务边界进行服务微化拆分,各个服务独立部署运行。
1.2 集群.分布式.节点
- 集群是个物理形态，分布式是个工作方式。
- 只要是一堆机器，就可以叫集群。他们是不是一起协作着干活。这个谁也不知道:
《分布式系统原理与范型》定义,
“分布式系统是若干独立计算机的集合，这些计算机对于用户来说就像单个相关系统”
- 分布式系统(distributed system)是建立在网络之上的软件系统。
- 分布式是指将不同的业务分布在不同的地方。
- 集群指的是将几台服务器集中在一起，实现同一业务。
例如，阿里巴巴是一个分布式系统。众多业务运行在不同的机器，所有业务构成一个大型的业
务集群。每一个小的业务，比如用户系统，访间压力大的时候一台服务器是不够的。我们就
应该将用户系统部署到多个服务器，也就是每一个业务系统也可以做集群化
- 分布式中的每一个节点，都可以做集群。而集群并不一定就是分布式的。
- 节点：集群中的一个服务
小王开了一家周麻婆，原来只要一个厨师（服务器）就可以满足客户（任务）需求，随着现在客人越来越多（分布式事务出现），厨师的需求也变多了（出现了集群），每一个厨师可以叫做节点
1.3 远程调用
-
在分布式系统中，各个服务可能处于不同主机。但是服务之间不可避免的需要互相调用。我们称为运程调用。
-
SpringCloud中使用HTTP+JSON的方式完成运程调用
客户（事务）之间也要讨论这家饭店，什么好吃，什么不好吃
1.4 负载均衡
- 分布式系统中，A服务需要调用B服务，B服务在多台机器中都存在，A调用任意一个服务器均可究成功能。
- 为了使每一个服务器都不要太忙或者太闲，我们可以负载均衡的调用每一一个服务器。提升网站的健壮性。
- 常见的负载均衡算法
- 轮询,为第一个请求选择健康池中的第一一个后端服务器，然后按顺序往后依次选择,直到最后一个，然后循环。
- 最小连接。优先选择连接数最少。也就是压力最小的后端服务器.在会话较长的情况下可以考虑采取这种方式。
- 散列，根据请求源的IP的散列(ash)来选择要转发的服务器。这种方式可以一定程度上保证特定用户能连接到相同的服务器.如果你的应用需要处理状态而要求用户能连接到和之前相同的服务器。可以考虑采取这种方式。
有时候一个客人只想要他指定的厨师做菜给他吃，就意味着他要在很多厨师中找到一个他喜欢的，这就是负载均衡，他想要怎么选厨师的方法就是负载均衡算法
1.5 服务注册/发现.注册中心
- A服务调用B服务，A服务并不知道B服务当前在哪几台服务器有，哪些正常的，哪些服务已经下线。解决这个问题可以引入注册中心
- 如果某些服务下线.我们其他人可以实时的感知到其他服务的状态,从而避免调用不可用的服务
1.6 配置中心
- 每一个服务最终都有大量的配置，并且每个服务都可能部署在多台机器上。我们经常需要变更配置，我们可以让每个服务在配置中心获取白己的配置.
- 配置中心用来集中管理微服务的配置信息
1.7 服务熔断.服务降级
-
在微服务架构中，微服务之间通过网络进行通信，存在相互依赖.当其中一个服务不可用时，有可能会造成雪崩效应。要防止这样的情况，必须要有容错机制来保护服务。
-
服务熔断
设置服务的超时，当被调用的服务经常失败到达某个阀值，我们可以开启断路保护机制，后来的请求不再去调用这个服务。本地直接返回默认的数据 -
服务降级
在运维期间， 当系统处于高峰期，系统资源紧张。我们可以让非核心业务降级运行。
降级:某些服务不处理.或者简单处理[抛异常、返回NULL.调用Mock数据、调用Fallback处理
1.8 API网关
- 在微服务架构中，API Gateway作为整体架构的重要组件，它抽象了改服务中都需要的公共功能，同时提供了客户端负载均衡，服务自动熔断，灰度发布，统一认证，限流流控，日志统计等丰富的功能，帮助我们解决很多API管理难题。
2：电商项目微服务架构图详解
如下架构图解释了我们电商项目的技术架构和技术组合方案，只有大家完整做出这一整项目才可以理解，我们接下来先做简单介绍
- 首先我们的项目是前后端分离开发，我们分为内网部署和外网部署，外网就是面向公众访问的来部署前端项目可以由手机，电脑网站访问；内网部署的是我们整个后台集群；
- 公众使用客户端来完成我们相应的功能，比如登录，注册等都要向后台的服务来发送请求，但是请求都不是直接过来的；
- 我们发送请求的完整的流程应该是这样的，首先通过任意客户端来发送请求，请求先通过nginx集群，nginx把请求，先转交给API网关（Spring Cloud Gateway）网关可以根据当前请求，动态的路由到指定服务，看当前请求是想调用商品服务，还是购物车服务，还是检索服务，如果我们路由过来查询商品，但是商品服务很多，那么我们网关还可以负载均衡的来调用商品服务，例如当某个服务出现问题，我们还可以在网关这个级别来执行熔断和降级（SpingCloud Sentinel），我们网关还有认证授权，和令牌限流（限制我们的流量，比如有一百万个请求过来了，我们就可以只先放一万个过去）等功能；
- 当我们的请求通过网关到达服务的时候，我们的服务就进行处理（服务都是用Spring Boot写的）；服务与服务之间会互相调用，比如下订单的时候订单服务会调用商品服务，我们使用的是SpringCloud Feign组件；而且有些请求，我们需要登录以后才可以处理，所以我们还有一个基于OAuth2.0的认证中心，我们除了一般登录，还有社交登录（如微博），整个应用的安全和权限我们都使用里面的SpringSecurity进行控制；
- 我们这些服务需要保存一些数据，或者需要使用缓存等等，我们缓存使用的是Redis（分片集群和哨兵集群）；持久化存储数据，我们使用的是MySQL集群（可以做读写分离，或者分库分表）；我们还会使用消息队列，来完成异步解耦和分布式事务的最终一致性（使用RabitMQ消息队列）；我们有些服务需要检索商品信息就用到了ES；我们还要保存一些商品信息，我们就要用到aliyun的OSS；
- 包括在项目上线以后，我们为了快速定位我们出现的一些问题，我们就会使用ELK来对日志进行相关处理，也就是使用LogStash来收集各种日志，然后放入到ES中，在用Kibana可视化界面来从ES检索出相关的日志信息，来进行快速定位问题的所在。
- 服务都可以部署在很多台机器，而且服务与服务之间都会进行调用，那么我们就得知道服务彼此都在那里，我们推荐将所有的服务都要注册到注册中心，别的服务可以从注册中心中发现其他服务所在位置（使用SpringCloud Alibaba来作为注册中心和配置中心）；
- 调用服务可呢会出现一个问题，比如下订单服务调用商品服务，商品服务在调用库存服务，可呢某一个链路出现了问题，我们就要追踪整个服务调用链，看下哪里出现了问题，我们可以使用服务追踪（SpringCloud Sleuth+Zipkin)把我们的服务的每一个信息来交给开源的Prometheus来进行聚合分析，再由Grafana进行可视化展示，通过Prometheus提供的Aitermansger得到我们服务的一些告警信息，这些告警信息可以以邮件，手机等方式告诉我们的开发运维人员；
- 我们还提供了持续集成和持续部署，由于我们的电商项目微服务众多，每一个都打包太麻烦了，有了持续集成，我们开发人员可以将修改后的代码提交给GitHub，运维人员可以通过Jenkins，从GitHub中获取到代码，将它打包成Docker镜像，最终我们使用Kuberneters，来集成整个Docker服务（以Docker容器的方式来运行）；以上就是我们整个微服务架构图的解释
3：电商项目微服务划分图详解
项目微服务划分图就反应了我们项目中一些相关的微服务和技术组合，
- 这个项目是基于前后端分离的开发，前端项目分为admin-vue（面向工作人员使用的后台管理系统）shop.vue（面向公众访问的web网站系统），当然我们也可以有app和小程序；
- 我们请求通过网关，到达业务微服务群，商品服务（包含对商品的增删改查，以及商品的上下架，和商品详情）；还有支付服务（集成了支付功能）；优惠服务（商品集成的优惠的相关信息）；用户服务（用户的一些个人中心，收货地址，列表维护等等）；仓储服务（每一个商品的库存都有多少，存储在那个仓库）；检索服务（主要完成商品的检索）；中央认证服务（登录，注册，单点登录功能，和社交登录功能）；购物车服务（商品购物车的增删改查，和结账）；后台管理也是给相应的服务发送相关请求；我么这些服务运行期间还要依赖第三方的服务（这些都不是我们编写的，是一些组织公司帮我们写好，我们直接可以用的）；
- 在如上微服务期间，我们要怎治理好，让他有条不紊的健壮的运行，我们需要使用图上最右边的技术
