前言

承接上文 ​​互联网架构演进之路​​

1、ServiceMesh架构设计
2、高可用设计手段
3、高并发设计手段

先推荐大家一个很好用的画软件设计图的工具

gitmind

此图仅仅为了展示使用gitmind画出来效果 请忽略内容

简洁、清晰、有效

​​正文开始​​

ServiceMesh架构设计

​​公共业务逻辑下沉​​

业务程序不关注通讯组件
通过jar包的方式引入
基础设施组件升级困难

服务组件版本升级
要让业务组在jar包中替换
影响基础设施团队的交付能力和交付速度

多编程语言之间 通信 问题
每种语言都要写一套基础设施 成本大
因为通讯组件和应用程序耦合在一起

业务研发团队和基础设施团队务必物理解耦

一套基础实施支持多语言开发
应用程序可以多种语言
基础设施能力从应用程序中下沉成为一个单独的进程

​​服务网格​​

1、独立进程
2、服务之间通讯
3、不管有状态服务还是无状态服务未来一定跑在云原生(docker k8s)上
4、轻量级网络代理
5、与应用程序部署在一起 对应用程序透明

​​服务网格架构​​

sidecar 是一个 rpc服务

应用程序A->sidecarA->sidecarB->应用程序B
反向同理

通讯协议两两都是tcp
数据协议 pb 

不管应用程序是什么语言 只有一套sidecar就行了

服务升级不依赖业务团队
业务团队迭代速度快

​​为什么必须部署在一起​​

同一个物理机或k8s pod
基于 tcp 轻量级 
不需要考虑负载均衡\重试\服务注册\配置中心\路由

​​最早期ServiceMesh​​

​​案例1-百度空间​​

用的是pull模式

百度空间 数据量大 数据一致性没那么高 是异步架构

​​案例2-社交IM​​

pc桌面版 tcp长连接

web用不了tcp长连接
http协议模拟 长轮询

类似直播 难点 抗同时并发量

同步架构 消息实时性

路由层是IM特有的 不需要关注

​​水平方向拆分​​

最开始的时候
业务简单 人少 业务都放在一个进程 好维护
粒度粗

​​垂直方向拆分​​

公共逻辑层 

1、组件化 jar包
2、服务化 下沉为独立服务 提供兼容接口

​​继续水平拆分​​

互联网核心技术实践

1、高可用设计手段
2、高并发设计手段（从架构、代码、算法）
3、服务无状态化（高可用其中一个手段之一）
4、负载均衡 （常用的负载均衡算法 更多广义角度阐述）
5、服务幂等性（依赖于分布式锁）
a 请求重复执行多次 服务保证最终结果完全一致
b 业务 库存只剩一个 多个用户同时抢购 保证商品不超卖
c 用户下单 用户没有结束之前 不允许重复下单
d 消息发到mq 发了多次 下游消费保证消息去重
6、分布式事务
7、服务降级 限流 熔断 
8、灰度发布
9、服务全链路压测

高可用设计

​​硬件总是会有生命周期​​

1、
x86 32cpu 128内存 万兆 1T硬盘 一台5万左右
基本上使用3年 

宕机和服务器台数相关 台数越多宕机可能性越大

2、
分布式 CAP

单机CA不存在 没有网络划分 

AP和CP更多 机房多个硬盘 网络发生划分 机器还可不可用

​​软件总会有Bug​​

​​评价维度​​

• 不科学(因流量有低峰和高峰)

一年/一季度/一月 停机时间占比
99表示365*24*60*1%=88小时

1个9是90%
365*24*60*90%=1/10 880个小时

• 科学

停机时间影响的总的请求量/总的请求量

​​冗余 部署多份​​

服务部署在不同的机柜和不同机架

无状态化（完全对等）可以快速扩容 弹性缩容

比如两台机器 每一台都是全量的session数据 不是无状态的

如果一台服务挂了 重启 session没了 就不对等了

​​负载均衡​​

网关->业务逻辑层1和业务逻辑层2

过程：

若业务逻辑层1挂了
负载均衡组件会知道1挂了
踢掉1
转移到2上
恢复1

异步是高并发手段也是高可用手段

不太关心返回结果
不是请求的关键路由

核心流量同步 非核心异步

不仅仅服务层面高可用
数据层面也要高可用

​​服务实时监控​​

实时监控 实现逻辑:

基于日志来做
5秒记录一个日志
耗时打在日志记录上
写在本地磁盘
通过flume 数据采集 
发送到kafaka消息队列 
然后spark实时统计实时耗时 

​​服务分级-降低和避免服务出现故障​​

​​如何无缝停止线上服务​​

目标:停机对用户没有伤害
即如果接受了你的请求 我100%处理完

在网关层面拒绝掉

​​网关热切换功能​​

热开关切换

比如8点停机
8点过来的请求都处理完
8点之后的请求 开关从0变1 所有请求都拒绝

​​8点前的请求保证什么时候处理完？​​

1、不优雅：每层打不打日志 如果打印日志这一层还在处理
2、优雅：前端请求 有超时时间 
若超时时间5秒
则8点05秒的时候 超时

关机从上层往下层停止服务

​​不具备热开关​​

机器防火墙配置在某一个时间点只出不进

​​请求流程​​

高并发设计

缩短延迟
提高吞吐量
让系统处于合理状态

​​空间换时间​​

缓存数据库数据
因数据库比内存昂贵

​​时间换空间​​

网络传输 http通讯 gz压缩 解压会消耗cpu时间

​​变更次数少的数据​​

1、app页面上购物分类 一级 手机 二级电脑
变更少 不能每次登陆就拉取一次
通过版本号判断 哪些更新了 只有更新了才会下载

2、好友数 每次登陆的时候拉一次 变化不频繁 
列表数据有一个版本号 server端和客户端都放一个
判断版本号有没有更新 若有则拉一次

​​哪些请求的耗时很大​​

1、一个服务集群若有4万QPS
对于占90%流量的前5接口进行优化

剩下的qps也不能忽略 若是慢查询 也不行

2、查看一个服务调用了多少rpc请求 
若数据、算法等核心的同步化

非核心流程异步执行
拆分到单独模块去执行 比如消息队列 

3、一个逻辑调用多个RPC接口
接口之间没有数据依赖 可以考虑并行调用

​​优化层次​​

​​代码层面​​

1、不要循环遍历rpc请求
   而应该调用批量接口组装数据

2、避免生成过多无用对象 比如使用isDebugEnabled() 应直接log.debug()

3、ArrayList HashMap初始化容量设置是否合理
扩容代价很大
比如根据业务量实际情况直接初始化大小100万 虽然耗费点内存 但性能可以保证

4、rpc接口查询出来的数据复用

5、复制一份数据 直接修改
读多写少的情况 用CopyOnWriteArrayList

6、StringBuilder的容量在预分配的情况下 性能比String提升15倍左右

7、是否正确初始化数据 全局共享数据 饿汉式模式 
   即在用户访问前先初始化好

​​数据库​​

1、状态值 若长度在255以内 用unsigned tinyint ; ip使用int而非varchar

2、使用enum的场景 使用tinyint替换 因enum扩展需要改表

3、禁止select * 会耗费 io、内存、cpu、网络

4、分析查询场景建立合适的索引
分析字段的可选择性、索引长度、对长的varchar使用前缀索引

5、字段 Not Null

允许Null字段需要额外的存储空间去处理Null
并且很难优化

目的是降低服务器CPU使用率、IO流量、内存占用、网络消耗、降低响应时间

​​局部性原理​​

这是个二维数组 在内存中是一维数组

第一段 耗时 140ms
第二段 耗时 2700ms

越靠近CUP越快

1、速度越来越高 内存->L3->L2->L1多级缓存

2、在内存是一个大的一维数组 
二维数组在内存中按行排列
先存放a[0]行 再放a[1]行

3、按行遍历：局部性原理 Cache Hit(缓存命中率高)

4、按列遍历：下一列和上一列的数组元素在内存中并不是连续的 
   很可能导致Cache Miss(缓存未命中)

5、CPU需要去内存载入数据 速度较CPU L1 Cache的速度降低了很多
(主存 100ns L1 Cache 0.5ns)

6、能用缓存就用缓存 无论是本地缓存还是分布式缓存

7、高频访问 时效性不高 适合缓存 比如 广告位
   时效性很高 需要考虑缓存一致性问题 不适合用缓存 比较交易数据

​​代码逻辑要适应数据变化的场景​​

1、explain:SQL的执行计划
2、prossible_keys idx_addtime 
key null 表示没有索引

查询数据量一旦超过30% 不会走索引 全表扫描

​​报表查询​​

只计算增量数据和之前计算结果合并

​​并发和锁优化​​

基于CAS LockFee(读不需要加锁 写加锁)比mentex(读写都要加锁)性能要好

​​案例1-电商秒杀系统​​

数据分层次校验
上层尽量过滤无效请求
可以是不精确过滤
层层限流 最后一层做数据一致性校验 扣减库存

漏斗模式

1、静态数据 Html js css静态文件 放CDN 缓存到用户端(APP/浏览器)

2、非实时动态数据 缓存在靠近用户访问链路的位置（商品标题、商品描述、用户是否有秒杀资格、秒杀是否已结束） 

3、实时数据：营销数据（红包、折扣）商品库存数 过滤掉用户

​​如何保证不超卖​​

DB事务保证一致性

​​案例2-Feed系统​​

热点数据缓存到调用链路更靠近用户的地方

1、内存存储最活跃的数据

2、L1缓存容量小负责抗最热点的数据
L2缓存考虑目标是容量 缓存更大范围数据
一般一般用户的timeline
高热点数据单独缓存 比如设置白名单 大V的用户数据单独缓存

3、feed 前3页 97% 前面几页数据作为热点数据缓存到L1 cache

4、业务逻辑层往往也会开一些缓存来存热点数据 比如大V的id

​​push模式​​

若push 那只推活跃用户
比如1万个用户 在业务逻辑层 每批100个用户需要推送 
100个线程并行推

从策略上优化

先推活跃用户

​​如何区分活跃用户?​​

活跃用户列表 长度100万
用户已上线就在列表中写一下 下线删除

​​微博数据存储解决方案​​

1、Pika Key-Value 固化存储(持久化存储)
2、对象存储 Ceph\FastDFS

​​微信朋友圈是推拉结合​​

1、发现 有消息提醒 是推
2、点开朋友圈是拉

​​微博最新数据展示逻辑​​

比如你有500个好友 拿每个人的100个数据 共5万条数据 在业务逻辑层按照timeline倒序排列

​​websocket和长轮询本质上没区别​​

websocket底层也是长轮询
web上用不了tcp协议
websocket在http基础上封装了长轮询

后记

接下来会继续分享 服务网格ServiceMesh相关的实践 

觉着有用的话 点个再看哈😄