微服务项目实战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是默认使用静态加载当然也可以配置成动态

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值