微服务架构思想

 

微服务介绍

1.微服务架构是一种架构思想，架构就是为了解耦，实际的开发方式是分布式系统开发
Spring Boot+Spring Cloud
Spring Cloud是一个编程模型，微服务开发的一种标准，一系列的接口
Spring Cloud Netflix 网飞
Spring Cloud Alibaba阿里巴巴



2.满足三大指标：高可用，高性能，高并发
高可用---服务一直可以用，N个9,6个9，使用率达到99.99999%,允许宕机的时间是31.536秒
高性能---响应速度保证在3秒钟以内
高并发---系统的承载能力，
（new User()放到堆，List<> Map<> JVM->内存   不足就会导致OOM->宕机->重启->需要时间120秒）


3.解决四大问题：
这么多服务，客户端如何访问
这么多服务，服务与服务之间如何通信
这么多服务，服务如何治理
这么多服务，服务挂了怎么办


一个淘宝首页有2000 个微服务组成，千人千面
一个苏宁易购首页有600个微服务组成

    • 如何应对高并发？

垂直扩展
   升级配置 1CPU 2核心 2G
   4路32核 4CPU 128G 性能瓶颈

水平扩展
  多买服务器-->负载均衡 Nginx 策略问题（轮询，Hash 一直，权重）
  1CUP 4核心 32G   192.168.0.1
  1CUP 4核心 32G   192.168.0.2
  1CUP 4核心 32G   192.168.0.3
  1CUP 4核心 32G   192.168.0.4
  1CUP 4核心 32G   192.168.0.5
 
系统
  计算密集型 cpu
     2cpu 8核 16GB
  内存密集型 内存 Redis
    1cpu 2核  128GB
   
用户分地区 

跨地区访问会延迟 100ms

所以用户->根据IP（分辨）->CDN内容分发网络

广州 1cpu 4核心 32GB 172.0.0.1
北京 1cpu 4核心 32GB 172.1.0.1
上海 1cpu 4核心 32GB 172.2.0.1
南京 1cpu 4核心 32GB 172.3.0.1

    • 单点故障、分布式数据库中间服务

分布式数据库中间件

数据库的水平拆分
单库-->单点故障-->中心化

数据库
User_0  192.168.0.1
   数据表
     User_0
        ID 20200428056000
       bId 业务Id
     User_1
         ID 20200428056001
     User_2
         ID 20200428056002
     User_3
         ID 20200428056003
     ...
     User_9
         ID 20200428056009
数据库     
User_1  192.168.0.2
   数据表
     User_0
        ID 20200428056000
       bId 业务Id
     User_1
         ID 20200428056001
     User_2
         ID 20200428056002
     User_3
         ID 20200428056003
     ...
     User_9
         ID 20200428056009
数据库     
User_2  192.168.0.3
   数据表
     User_0
        ID 20200428056000
       bId 业务Id
     User_1
         ID 20200428056001
     User_2
         ID 20200428056002
     User_3
         ID 20200428056003
     ...
     User_9
         ID 20200428056009
     
 查询->配置多数据源
 物理查询
select * from 'user_0'.'user_0';
select * from 'user_0'.'user_1';
select * from 'user_0'.'user_9';
select * from 'user_1'.'user_9';

 逻辑查询
 select * from user
 -->发送给专门处理物理查询服务呢？分布式数据库中间件（MyQat-->重启了Alibabat淘汰的分库分表,Apache Sharding-Sphere）
 Apache Sharding-Sphere
 Shariding -JDBC->源码里依赖，有一定的侵入性
 Shariding-Proxy->分部署数据库中间件，单独部署
 Shariding-Sidecar->Kubernetes里，高可用

分布式数据库中间服务->高内聚低耦合
用来解析SQL，配置多数据源，分库分表规则（分片）
Spring Boot->yaml配置多数据源

    • CAP 

C  
  一致性->强一致性，原子性
    强一致性
    弱一致性
        顺序一致性
        最终一致性
A
  可用性->高可用+高性能，即服务一直可用，而且是正常响应时间
  
P
  分区容错性
  

要么CP ->强一致性系统->金融系统
要么AP ->强可用性系统->互联网系统

 

    • BASE 理论

电商
   双十一 天猫购物街B（香奈儿）2B（天猫）2C（用户）
      保证基本可以用->重要业务，浏览大促商品，促进成交（订单，支付）
   双十二 淘宝狂欢节 C（卖家）2C（买家）
   
   
 数据最终要落盘，持久化
     弱一致性
         顺序一致性
         a b c d
         1 2 3 4
         最终一致性（5分钟写进来）
         a b c d

    • 微服务的四大问题

Spring Cloud Alibaba + Dubbo

Zookeeper 分布式协调技术 分布式锁 ztree -> znode -> 有序节点

Redisson 分布式锁 RedLock 脑裂问题

Dobbo ->Nacos

Dobbo 只是一个通信框架

1.这么多服务，客户端如何访问？

API网关 反向代理
   Zuul(网飞，同步并阻塞的)、
   Spring CLoud Gateway（异步）、
   Consul、
   OpenRestry（物联网）
   Kong


域名的请求方式

例如：四个服务，一共12个服务IP
登录服务 10.0.0.1、10.0.0.2、10.0.0.3
商品服务 10.0.1.1、10.0.1.2、10.0.1.3
注册服务 10.0.2.1、10.0.2.2、10.0.2.3
订单服务 10.0.3.1、10.0.3.2、10.0.3.3

2.这么多服务，服务与服务之间是如何通信的？

同步通信 ：HTTP、RPC (对外RESI，对内【同一个局域网】RPC Dubbo Thrift)
异步通信：消息队列MQ (RocketMQ、RabbitMQ)

3.这么多服务，服务如何治理？

注册中心 Eureka  Nacos
链路追踪 ZipKin SkyWalking
日志收集 ELK

4.这么多服务，挂了怎么办？

熔断机制 Sentinel
负载均衡 微服务自带负载均衡

    • 微服务架构的构建原则

伸缩能力
可用性
健壮性
弹性
独立的匿名服务
去中心化的治理
故障隔离
自动供给
通过 DevOps 实现持续交付

 

posted on 2021-07-27 12:39  妖妖灵嘛  阅读(251)  评论(0)  编辑  收藏  举报

导航