微服务项目实战01、什么是微服务

01、微服务和传统服务讲解

--一个对于学java比较经常碰到的，也是必须要了解的内容。即微服务 docker springboot springcloud的关系

--一个基本的应用业务场景图，帮助理解微服务

--部署前准备：
    --服务docker化
        --主要是调整服务配置便于做成镜像
    --用docker-compose将所有的运行内容集中，并保证容器间的通信
    --搭建私有仓库用于存放镜像，所用的是harbor

--服务编排：
    --主要是k8s

02、软件架构是如何发展到微服务这一步的

--最开始的jsp -->  mvc --> dubbo -->

--单体架构：
    将功能和业务集中在一个发布包中，部署运行在同一个进程就是单体架构
        --易于开发
        --易于测试
        --易于部署
        --易于水平伸缩：只要把打好的包复制到另一个配置好的环境中即可

    --单体架构的挑战：
        --代码膨胀，难以维护
        --新人上手困难
        --创新困难：前后端框架切换代价太大
        --构建部署成本太大
        --扩展性差：扩展性不是指水平伸缩而是指对单台机器的要求非常高，这就很难办到

--由于单体架构很难做提高，因此就需要使用微服务

--微服务：
    --一套小服务开发单个应用，每个服务运行在独立的进程中
    --采用轻量级的通讯机制互联
    --自动化部署

--微服务的衡量标准：
    --微的标准：
        --代码量不能作为衡量标准：和编程语言 人都有关系
        --开发时间：不能
        --微应该是不可度量的

    --微的特征：
        --单一职责，只把紧密相关的业务逻辑放在一起，把不够紧密地业务逻辑独立出去
        --轻量级通信
        --隔离性：每个微服务独立运行互相不干扰
        --有自己的数据：降低数据的复杂度
        --技术多样性：不在乎语言是什么，只要提供出来API即可

    --微的背景：
        --互联网快速发展
        --敏捷开发，精益方法深入人心，也就是用最少的开发做最快速的迭代
        --容器技术的成熟

--微服务优势：
    --独立性：比如对于登录服务可能qbs为2，用户服务qbs为10。因此登陆的微服务开启2个，用户的开启10个，同一类的微服务相互之间独立不受干扰提高容错性，不同类的微服务之间定制化开发节约成本
    --敏捷性：如果想要对功能做修改非常容易
    --技术栈灵活：不论后台怎么实现只要保持统一接口API即可
    --高效团队

--微服务劣势：
    --额外的工作：主要是服务的拆分，是非常深的学问，拆分过大过小都不合适。例如 DDD -- Domain-Driven Design / 领域驱动设计
    --数据一致性：尽量让涉及多表联查的数据库和服务在同一个微服务中
    --沟通成本上升

--微服务的结构如下： 
    --场景设定：
        --用户登陆注册
        --发短信 发邮件
        --查看课程列表和对课程进行curd

--首先看一下单体架构什么样，如下图所示：  
    --一整个应用提供多个API接口供web和手机调用

--微服务搭建上述场景的结构图：

03、微服务通信

--什么时候需要通信：
   
--如何高效便捷安全的通信：

--微服务如何发现彼此：

--微服务如何部署 更新 扩容
    --一般一个系统可能涉及到的微服务能够达到

--微服务之间通信：
    --通信模式：
        --一对一 还是 一对多
        --同步 还是 异步

--发布订阅：
    --给订阅者，关注者发送消息

--发送异步响应：
    --平台在接单以后，将其分发给不同供应商让其抢单，先到先得
    --可能现在是根据算法配单，但也基本是一个模式

    --通信协议考虑：
        --REST API：基于HTTP协议的通信接口，用于前后端的数据交互
            --REST：Representational State Transfer表现层状态转移，也就是前后端按照http协议请求和响应数据
            --API：接口
            --这个不强制和业务场景有关

        --RPC：dubbo grpc motan dubbox thrift等

        --MQ：消息队列，对于消息订阅非常合适

    --微服务之间通信框架选择：
        --RPC使用的最多，那就涉及到如何选择一个RPC框架：
            --IO：同步IO 异步非阻塞IO || 长连接 短连接
            --线程调度模型：单线程还是多线程
            --序列化方式：json xml 二进制的不可见序列化[不常用]
            --多语言支持：
            --服务治理：服务发现 服务监控 支持集群部署 服务的高可用

        --流行的rpc框架：
            --dubbo grpc motan dubbox thrift

--dubbo[阿里]示意图如下：

--motan[新浪微博]示意图如下：
    --subscribe：订阅
    --notify：通知
    --好像只支持java

--thrift[facebook]示意图如下：
    --序列化支持多种
    --支持多种语言：python c c++ java 
    --多种IO
    --多种线程模型支持
    --缺少服务治理

--grpc[google]示意图如下：

--多种rpc框架对比：

04、服务发现、部署更新和扩容

--服务发现：
    --传统的架构：不含服务发现

    --客户端发现：

    --服务端发现：

05、服务的部署更新扩容

--由于微服务数量众多，更新部署频率高。部署更新极其复杂

--服务编排：
    --包含服务发现 服务部署 更新 扩缩容，除此之外可能还包括别的功能

--服务编排的工具：
    --docker swarm[docker]  ||  mesos[apache]  ||  kubernetes[google]

06、springboot与微服务

--springboot核心使命：   
    --化繁为简

--springboot核心功能:
    --独立运行  java -jar xxx.jar
    --内嵌web服务器  能够直接通过命令行启动的原因
    --简化配置
    --提供了准生产的应用监控

--springboot与微服务的关系：
    --springboot特点：轻量级 无需复杂的配置 直接就能启动
    
    --微服务特点：数量多 轻量级

07、springcloud与微服务的关系

--springcloud的使命：
    --简化java的分布式系统

    --提供的分布式能力如下：
        --统一的配置管理
        --服务的注册 发现
        --服务的调用
        --负载均衡
        --全局锁
        --登陆器
      
    --特点：
        --是一系列框架的集合
        --简化的java分布式系统
        --对springboot的封装
    
    --核心组件：
        --Netflix Eureka 服务发现组件
        --Netflix Ribbon 客户端负载均衡组件
        --Netflix Hystrix 断路器
        --Netflix Zuul 服务网关
        --Spring Cloud Config 分布式配置

--springboot:
    --意在简化，是一种开发配置风格，使用起来不想ssm那样需要配置大量文件

--springcloud:
    --意在提供一个简化的分布式系统，将已有框架进行整合，使其风格 功能得到统一

--springcloud与微服务：
    --微服务就是一个独立的分布式服务，springcloud就是微服务的Java解决方案
    --所提供的功能还不包括服务的监控、服务的启动、报错处理等功能，这些需要服务编排框架来完成

08、springcloud的五大核心组件基本讲解--便于理解微服务与springcloud关系

--Netflix Eureka 服务发现组件
    --客户端发现模式
    --每个机房独立，保证了集群的高可用
    --Eurake Server：服务注册中心，类似于zookeeper
    --Application Service：在Eurake中注册服务，并实时更新和Eurake保持服务的一致性。同时Eurake会检测Application Service，如果一段时间内没有相应就判断其失效将其移除
    --Application Client：通过在Eurake中查询注册服务、接口ip，再对服务进行调用
    --这里Eurake只是告诉客户端服务的ip 端口，并不会涉及到客户端和服务端的数据交互
    --不论是client 还是 service，都会运行一个Eurake client用以和Eurake保持交互和通信

--Netflix Ribbon 客户端负载均衡组件
    --首先这张图是一个云上的应用场景，亚马逊ELB接受请求并发给Edge Service
    --Edge Service接收到请求后，Ribbon会通过Eurake的服务发现调用接口。每一类Ribbon管理一系列的同类分布式微服务，通过负载均衡算法找到一个后台并发送给该后台进行处理


--Edge Service:
    --微服务存在各种各种返回的原始数据，需要通过Edge Service进行整合
    
    --特点：
        --整合后端多个服务的数据
        --离用户最近

--Netflix Hystrix 断路器：
    --一个web用户请求一个数据库资源，当一个请求没有响应时，web用户可能拼命点击导致即使数据库及时回复以后，堆积的请求再次压垮服务
    --解决的两个问题：
        --当发现请求不被响应时，后续的请求就不会发送给服务方
        --当服务不可用时，可以找一个更优的结果返回给前端，比如去除最近的缓存数据发送回去

    --Hystrix的状态切换：
        --首先处于closed状态，断路器闭合，请求和响应都没有问题
        --当请求没有得到响应时，断路器快速断开，处于open状态
        --过一段时间再次发送请求，如果通了则切换为 half open状态，如果继续请求没有问题就切换回close状态，如果仍然出现错误则退回open状态

Netflix Zuul 服务网关
    --提供网关APIGateWay，用于负载均衡，权限控制等
    --主要是服务路由寻找和分配

--Spring Cloud Config 分布式配置
    --zookeeper可以提供动态配置更新加载，spring cloud config是默认使用静态加载当然也可以配置成动态