接口异步

当业务打到一定规模后，接口串行是性能的一大杀手，因为它：

• 影响用户体验：一个接口往往会至少调用3~5个甚至更多的服务，对于用户的访问会有极大的延迟。
• 降低系统吞吐：比如一个大的事务或者请求往往会长时间占用链接当业务高峰来了后会占用很多链接无法释放，导致请求排队。

接口的异步化往往是解决这种问题的利器，我们可以使用一些带有顺序消费能力的消息队列来解决这种问题。我们实际开发中往往是将一个大事务通过MQ等手段异步拆成多个小事务来增大并发。

分布式事务的数据一致性

分布式服务必然会带来数据一致性的问题，和事务的CAID相比，基本遵循俩个原则

CAP理论

C:一致性
A:高可用性
P:发生故障好，保证分区可用

分布式事务往往无法完全严格实现CAP，一般是保证P的基础上实现C、A。

BASE理论

是CAP的一种延展

BA：基本可用，对应的是降级
S：柔性状态，即允许当前数据存在中间状态，比如mysql同步时候各从库的数据可能不一致
E：最终一致性，即一段时间之后数据会达成最终一致

俩阶段提交

原始的分布式事务采用XA俩阶段提交。分为俩个接口：

• XT：客户端–>事务管理器，负责开始事务、提交事务、回滚事务

• XA：一般是资源管理器和事务之间交互，比如回滚，提交等。

  在这个协议下整个事务的流程是这样的：

  1. 客户端开启事务;
  2. 客户端操作事务中多个资源管理器（mysql）这时候数据已经持久化
  3. 客户端提交事务
     1. 第一阶段：prepare，事务管理器去轮询各资源管理器检查状态，返回 READY,NOT_READY,READY_ONLY，
     2. 第二阶段：commit or rollback，根据第一节阶段的结果进行rollbacck（NOT_READY）或者commit（READY）。

分布式系统–柔性事务

上面的方案在传统项目中是可以的，但是在互联网应用中，这种项目因为锁的存在会极大的降低性能。

通过日志来进行业务补偿

事务日志：记录事务的开始，事务参于者，状态。保存在事物管理器
undo/redolog：用于发生异常后为了实现最终一致性，进行重试( 正想补充 redolog ) 或者回滚 （ 反向补偿 undolog ）

可靠消息传递

防止在网路错误时候出现消息丢失情况，我们要实现，at least once：即消息可能投递多次

主要幂等性：同一条数据执行多次后，结果不能发生改变。实现方案是采用排重表。【如：可能有多条插入数据库的消息，我们应该只能写入一条记录这种是幂等行，解决方案可能会采用一个排重列表，过滤掉重复的消息】

无锁设计

减少锁开销

1. 表面事务回滚，没有回滚则没有锁
2. 通过辅助表取代热点数据的修改。如，秒杀系统的库存的预减
3. 乐观锁

阿里的实践

消息队列

具体叫rocketmq的实践，先发一个half-message给mq此时对消费者即远端事务透明，生产者完成本地事务提交给mq，mq在将事务发给消费者。

兜底策略：如果mq长期没有half-message的ack,mq会主动问询生产者状态，来确认事务是进一步进行还是丢弃。

缺点：仅适用于俩个参与者，仅能提供正向补偿。

TCC

为了解决多参与者以及实现反向补偿（rollback），在支付宝场景下实现了TCC(try confirm cancel)

• try:对资源的检验、锁定，实现软隔离
• confirm:事务的真正提交过程，只用try阶段锁定的资源。
• cancel:取消回滚

tcc只提供了框架，真正的资源回滚还需要业务方自己通过代码进行回滚。

TXC

新一大分布式事务处理框架，他是通过在db层上实现了比较薄的代理来实现分布式事物。

• TXC用来开启(register)一个事务，分配一个txid
• 之后所有的对db的请求会先通过txc-rm这个代理，他负责解析sql语句如果遇到Insert/delete/update会生成undolog和redolog
• 自动回滚：当有回滚需求时候
  • 校验当前数据库的值和redolog是否一致，如果一致通过undolog回滚
  • 如果不一致，说明别的进程和事务已经修改了数据库，这时候回滚可能会导致数据不一致，只能同构redolog进行重试补偿。

缓存的使用

以大促为例，阿里采用自己开发的Tair作为缓存，我们可以使用redis的方案。

以秒杀场景为例，看下缓存的作用：

首先要做服务集群的隔离

小库存的秒杀场景

1. 商品详情页的缓存降低数据查询压力
2. 库存校验的的条件判断：在下单前判断库存是否还足够
3. 下单时候用乐观锁来修改库存

大库存热点商品的秒杀

这种情况不适合用乐观锁的原因是锁所冲突很大，并且会出现后下单的反而抢到了商品情况。

我们这时候在下单时候，可以按照如下逻辑，注意括号中的备注

预订单对用户不可见(用于缓存崩溃等情况恢复用的快照)–>发送消息给mq（保证下订单的顺序）–> 缓存中扣减库存（事务交给缓存）–>修改订单状态，完单。

在业务达到一定规模后，由于数据库是中心架构的，一个设计糟糕的数据库将会给业务带来非常严重的灾难，这方面阿里提出了很多宝贵的经验和方法论。

阿里数据库的分布式方案

1. 垂直拆分：根据不同的业务以高内聚、低耦合的原则，将数据拆分到不同的数据库中
2. 读写分离：垂直拆分后有些服务的请求量依然很大，我们首先想到的是读/写分离，因为往往业务场景决定这读远远大于写，这时候进行读写分离可以有效降低写的压力，且从库可以追加多个
3. 分库分表：读写分离无法解决单表写的性能问题，以及单表数据量大的问题，针对这个问题我们可以采用水平分库/表的方案，根绝业务特点对表、库进行水平拆分，分表可以减小单表数据量，分库可以减少单库连接数的上线，从而满足业务的需求。

阿里开发了TDDL，作为数据库的拆分方案，特点是：全面支持jdbc，对业务无侵入。

1. matrix：根据业务配置分表规则针对sql语句进行解析，选择需要执行的groupDS
2. groupDS：负责读写分离，以及根据权重选择atomDS；
3. atomDs:持有数据库的原子链接；

数据库分表的原则

1. 数据尽量均匀：防止数据倾斜；
2. 减少事务边界：尽量减少违反分表分库规则的事务，否则需要进行全表扫描，因为需要在内存中进行聚合，就会降低系统性能，且系统的性能指标就降为单库的指标。
3. 异构索引表来满足跨表查询的场景；

4. 提供其他搜索方案来解决复杂的查询、搜索场景；

   其中异构索引表，大部分小企业可以采用业务来解决，阿里提供了精卫系统在系统层面来解决数据同步需求：

5. 原理是消费binlog，通过配置进行过滤，同步；

6. 支持多线程同时同步，为了保证数据在并发情况的一致性，同一条语句根据规则打到同一个线程执行；
7. 强大的UI工具支持；

8. 数据的安全性：

   1. 采用zookeeper做调度、管控；
   2. 手动主从切换、宕机回复；

   PS：

   数据库分表分数据遇到了”数据均匀”，”减少事务边界”这两种情况冲突的情况，应该优先解决数据均匀的问题，因为减少事务边界可以采用异构索引表的方式解决。

   实际开发中我们采用82原则，针对80%的情况下有20%的场景出现没有分表字段的情况，采用异构索引的方式处理，其他小概率的查询我们可以全表扫描等方案。

中台不是一成不变的要能跟这业务一起成长，提供多样的接口，作为业务的沉淀

共享服务考量指标

• 设计：遵循面向对象的原则
  运营：中台要切实能够解决业务问题，业务能够运营
• • 工程：在做拆分时候要考虑投入的成本

建设中台的几个原则

1. 高内聚，低耦合
2. 数据完整性
3. 业务可运营性
4. 循序渐进

与大部分企业的服务化的演进之路如初一辙

单体应用阶段

单体应用，所有的服务跑在一个war包中，这个war包200多MB。之后遇到了如下的问题

1. 数据库的链接到了瓶颈：因为所有的程序在一个war包中，这个工程的数据库连接池非常大，已经逼近了单机数据库的连接池的上限；
2. 所有功能耦合在一起：牵一发而懂全身，很可能一个小改动就引起宕机;
3. 性能问题：没法做业务的隔离，一个接口慢，会拖垮整个项目
4. 业务膨胀导致没有一个人能了解所有的代码，祖传代码盛行。

服务化

飞行中换发动机，采用去中心化的分布式架构逐步用服务替换掉单体应用。

淘宝的微服务化

淘宝采用去中心化的微服务架构。与之相对的是中心化架构，著名的“ESB”架构，这个架构有个致命的问题，ESB作为真个架构的路由，所有的服务都会落在ESB上，那么他就会成为整个系统的瓶颈，维护成本很高，并且会制约业务发展。这些是互联网业务无法容忍的，所以淘宝就采用了HSF这种去中心化的分布式架构，服务直接点对点的直接调用。（它的特点naming服务只做服务发现、订阅和配置更新的推送，在服务之间大量的请求并没有走naming）。

这种架构也就是现在的微服务架构，因为它：

1. 以服务方式提供应用
2. 以服务的方式而非项目的方式组织架构
3. 通过服务的只能编排提供业务支撑

4. 智能运维，以及健壮的平台稳定性（降级、限流、熔断）

   当然微服务话我们也要接受如下挑战：

5. 服务的管控：服务的配置中心，服务的全链路跟踪等需要支持否则排错，自我运维闭环是无法实现的；

6. 分布式事务的支持：与单体不同，对于数据一致性要求高的场景我们要想办法支持分布式事务的场景;
7. 只能运维的支持以及平台稳定性挑战;
8. 组织架构的变化：要根据服务特点组织组织架构的变化;

演进史

建立共享服务中心，前期根据业务拆分了4个中心用户中心，商品中心，交易中心，店铺中心。

用户中心

改造成本低相较于其他模块功能简单，受益巨大上游调用次数多，所以是很好的🕙。

为什么要有中台

由于企业的业务不断发展，出现很多功能重复的系统，导致整个技术部门烟囱临立的情况。

烟囱的危害具体有

• 功能重复导致资源浪费，道理不说了。
• 打通不同系统的成本很高，不同的系统，数据、业务都是独立的，想打通需要耗费很大的精力，并且之后的修改很有可能牵一发而动全身。
• 由于数据、业务分散在不同的系统中，这种无法收敛的状态也不利于公司的技术、业务沉淀，比如：随着业务的发展，A业务原有的系统无法满足，如果没有中台那么A就很有可能在开发一套新的系统，抛弃原有的系统。如果有中台就可以通过中台不断迭代，甚至有可能复用给其他的业务。

搭建一个合格的中台的条件

• 首先，来自于企业和团队的决心，耐心。我们都知道阿里巴巴的中台策略很出名，原因在于整个集团对于共享服务的态度，要求业务部门必须接入共享服务中心，哪怕初期功能在简陋、在粗糙，否则搭建的中台就是另一个又昂贵，又脱离业务的新烟囱。
• 其次，中台的开发者要深入到业务当中，对现有的不同部门、团队的业务进行抽象提取共性，以服务重用的目标来建立、思考中台，而不是简单的将服务打通，堆积在一起。
• 再次，中台的开发者要有长期迭代的心态，不是上线这个项目或者这个服务就完了。上线这个项目才仅仅是迈出这个中台服务的第一步。后续的迭代成长才是关键。

搭建中台的具体好处

• 便于业务的创新：每个业务都只是从自己业务的角度看待问题，但是如果从中台的角度看待问题，横跨多个业务，在整合的过程中可能碰撞出新的想法。
• 快速迭代、业务试错：supercell和阿里巴巴的大中台小前台策略，可以保证在最小的资源投入前提下进行快速的试错。
• 数据打通：真正体现大数据的威力，并且懂业务的人才：因为如果还是传统项目制度，研发只会关注现有功能开发和维护，而不会从业务方面思考问题，通过构建中台，研发更加贴近业务会去思考技术如何更好的为业务服务。
• 改变组织形式提高效能：从自上而下的流失组织架构，改为以共享服务为中心的小团队协作。

系统资源瓶颈

CPU 性能分析

CPU优化思路

从这几个方面出发，我相信你已经想到了很多的优化方法。这里，我主要强调一下，最典型的三种优化方法。

1. 把进程绑定到一个或者多个 CPU 上，充分利用 CPU 缓存的本地性，并减少进程间的相互影响。
2. 为中断处理程序开启多 CPU 负载均衡，以便在发生大量中断时，可以充分利用多 CPU 的优势分摊负载。
3. 使用 Cgroups 等方法，为进程设置资源限制，避免个别进程消耗过多的 CPU。同时，为核心应用程序设置更高的优先级，减少低优先级任务的影响。

内存 性能分析

内存优化思路

1. 除非有必要，Swap 应该禁止掉。这样就可以避免 Swap 的额外 I/O ，带来内存访问变慢的问题。
2. 使用 Cgroups 等方法，为进程设置内存限制。这样就可以避免个别进程消耗过多内存，而影响了其他进程。对于核心应用，还应该降低 oom_score，避免被 OOM 杀死。
3. 使用大页、内存池等方法，减少内存的动态分配，从而减少缺页异常。

磁盘IO 性能分析

磁盘IO 优化思路

1. 也是最简单的方法，通过 SSD 替代 HDD、或者使用 RAID 等方法，提升 I/O 性能。
2. 针对磁盘和应用程序 I/O 模式的特征，选择最适合的 I/O 调度算法。比如，SSD 和虚拟机中的磁盘，通常用的是 noop 调度算法；而数据库应用，更推荐使用 deadline 算法。
3. 优化文件系统和磁盘的缓存、缓冲区，比如优化脏页的刷新频率、脏页限额，以及内核回收目录项缓存和索引节点缓存的倾向等等

网络 性能分析

而要分析网络的性能，自然也是要从这几个协议层入手，通过使用率、饱和度以及错误数这几类性能指标，观察是否存在性能问题。比如 ：

• 在链路层，可以从网络接口的吞吐量、丢包、错误以及软中断和网络功能卸载等角度分析；
• 在网络层，可以从路由、分片、叠加网络等角度进行分析；
• 在传输层，可以从 TCP、UDP 的协议原理出发，从连接数、吞吐量、延迟、重传等角度进行分析；
• 在应用层，可以从应用层协议（如 HTTP 和 DNS）、请求数（QPS）、套接字缓存等角度进行分析。

网络 优化思路

1. 你可以增大套接字缓冲区、连接跟踪表、最大半连接数、最大文件描述符数、本地端口范围等内核资源配额；
2. 也可以减少 TIMEOUT 超时时间、SYN+ACK 重传数、Keepalive 探测时间等异常处理参数；
3. 还可以开启端口复用、反向地址校验，并调整 MTU 大小等降低内核的负担。

我们如何建立有效的监控体系？我们可以从俩个维度来看，系统指标，应用指标。

系统指标

在开始监控系统之前，你肯定最想知道，怎么才能用简洁的方法，来描述系统资源的使用情况。不过不要忘记，每种资源的性能指标可都有很多，使用过多指标本身耗时耗力不说，也不容易为你建立起系统整体的运行状况。在这里，我为你介绍一种专门用于性能监控的 USE（Utilization Saturation and Errors）法。USE 法把系统资源的性能指标，简化成了三个类别，即使用率、饱和度以及错误数。

• 使用率，表示资源用于服务的时间或容量百分比。100% 的使用率，表示容量已经用尽或者全部时间都用于服务。
• 饱和度，表示资源的繁忙程度，通常与等待队列的长度相关。100% 的饱和度，表示资源无法接受更多的请求。
• 错误数表示发生错误的事件个数。错误数越多，表明系统的问题越严重。

工具有:zabix，Prometheus等

应用指标

应用指标可以直观的反应出服务的运行状况，我们更关注，请求数，延迟，错误率等，分布式系统、微服务还需要把握整个请求链路。

• 全链路分析：掌握整个请求链路的响应时间、成功率，有zipkin,还有各大公司的trace方案
• 指标分析：还需要对重点的业务，逻辑字日志中大点进行监控，解决方案可以采用：elk或者efk。

接文章[/系统优化-案例分析-网络丢包分析]

当服务的请求数变大时候，我们往往发现系统吞吐下降。排查思路如下：

优化连接数

用ss命令发现estab的很少，timewait很多。

1
2
3

ss -s
查看
TCP:   53 (estab 9, closed 38, orphaned 0, synrecv 0, timewait 38/0), ports 0

通过dmsg命令，查看系统的error信息排查是否是conntrack的问题。通过修改参数来解决。

1
2
3
4
5
6
7
8
9

dmsg |tail

#查看最大值
sysctl net.netfilter.nf_conntrack_max
#查看当前值
sysctl net.netfilter.nf_conntrack_count

#设置最大值
sysctl -w net.netfilter.nf_conntrack_max

排查应用问题

比如nginx和tomcat等我们可以查看应用错误的原因，因为大部分采用master+worker的方案，我们可以增加worker的进程

排查tcp方面的原因

用netstat -s|grep tcp 查看丢包原因，如果发现丢包原因是socket overflowed，则用ss -ltnp命令看下Linsterner端口的队列情况,增大backlog相关的参数。

1

ss -ltnp

优化端口范围

如果出现类似这样的错误，我们可以看下是否是端口范围过小导致没法创建新连接

1
2
3

(99: Cannot assign requested address)

sysctl net.ipv4.ip_local_port_range

内核线程

linux系统有几个进程号比较小的进程

• 0号进程：idel进程用来初始化1号进程和2号进程
• 1号进程：systemd进程也叫init进程，用来初始化所有的用户进程
• 2号进程：kthreadd，在内核态运行，用来管理内核线程

常见的几个内核线程

1
2
3
4
5
6
7
8
9
10

$ ps -f --ppid 2 -p 2
UID         PID   PPID  C STIME TTY          TIME CMD
root          2      0  0 12:02 ?        00:00:01 [kthreadd]
root          9      2  0 12:02 ?        00:00:21 [ksoftirqd/0]
root         10      2  0 12:02 ?        00:11:47 [rcu_sched]
root         11      2  0 12:02 ?        00:00:18 [migration/0]
...
root      11094      2  0 14:20 ?        00:00:00 [kworker/1:0-eve]
root      11647      2  0 14:27 ?        00:00:00 [kworker/0:2-cgr]

• ksoftirqd:软中断线程
• kworker:用于执行内核工作队列，分为绑定 CPU （名称格式为 kworker/CPU86330）和未绑定 CPU（名称格式为 kworker/uPOOL86330）两类
• migration:在负载均衡过程中，把进程迁移到 CPU 上。每个 CPU 都有一个 migration 内核线程。

调试

场景准备：俩台服务器，服务器一运行docker，服务器二压力机，

服务器一：

1
2
3

# 运行Nginx服务并对外开放80端口
$ docker run -itd --name=nginx -p 80:80 nginx

服务器二发压命令

1
2

# sync_flood攻击
$ hping3 -S -p 80 -i u10 192.168.1.2

这时候服务器变慢，top观察如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

$ top
top - 08:31:43 up 17 min,  1 user,  load average: 0.00, 0.00, 0.02
Tasks: 128 total,   1 running,  69 sleeping,   0 stopped,   0 zombie
%Cpu0  :  0.3 us,  0.3 sy,  0.0 ni, 66.8 id,  0.3 wa,  0.0 hi, 32.4 si,  0.0 st
%Cpu1  :  0.0 us,  0.3 sy,  0.0 ni, 65.2 id,  0.0 wa,  0.0 hi, 34.5 si,  0.0 st
KiB Mem :  8167040 total,  7234236 free,   358976 used,   573828 buff/cache
KiB Swap:        0 total,        0 free,        0 used.  7560460 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
    9 root      20   0       0      0      0 S   7.0  0.0   0:00.48 ksoftirqd/0
   18 root      20   0       0      0      0 S   6.9  0.0   0:00.56 ksoftirqd/1
 2489 root      20   0  876896  38408  21520 S   0.3  0.5   0:01.50 docker-containe
 3008 root      20   0   44536   3936   3304 R   0.3  0.0   0:00.09 top
    1 root      20   0   78116   9000   6432 S   0.0  0.1   0:11.77 systemd
 ...

cpu的idel下降，si很高，且进程ksoftirqd占用比较高，初步判断软中断出现了问题，我们之前通过sar和vmstat抓包去看，现在我们可以通过perf家火焰图工具查看，使用方法如下：

1
2
3
4
5
6
7
8
9

#安装 FlameGraph
git clone https://github.com/brendangregg/FlameGraph
cd FlameGraph

#录制
perf record -a -g -p 9 -- sleep 30

#生成火焰图
perf script -i perf.data|./stackcollapse-perf.pl --all|./flamegraph.pl >flame.svg

生成的火焰图如下：

动态分析

工具如图

优化思路

见图：

应用层：应用程序错误
Socket：读写缓冲区溢出。排查方案，查看socket参数，抓包
TCP：资源或者链接跟踪超限。排查方案，netstat -s
IP：MTU获取路由错误。排查方案，netstat -i
网络链路层：QoSor校验错误。排查方案，tc
网卡：网络拥塞，DMA的ringBuffer溢出。排查方案，netstat -i，抓包

案例排查链路

看网络包收发状态

1
2
3
4
5

root@nginx:/# netstat -i
Kernel Interface table
Iface      MTU    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0       100      106      0     32 0            43      0      0      0 BMRU
lo       65536        0      0      0 0             0      0      0      0 LRU

查看QoS策略

如下有一个丢包30%的策略删除之

1
2
3
4
5
6
7

root@nginx:/# tc -s qdisc show dev eth0
qdisc netem 8001: root refcnt 2 limit 1000 loss 30%
 Sent 2450 bytes 43 pkt (dropped 18, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0

##删除策略
root@nginx:/# tc qdisc del dev eth0 root netem loss 30%

看tcp收发情况

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

root@nginx:/# netstat -s
Ip:
    Forwarding: 1          //开启转发
    31 total packets received    //总收包数
    0 forwarded            //转发包数
    0 incoming packets discarded  //接收丢包数
    25 incoming packets delivered  //接收的数据包数
    15 requests sent out      //发出的数据包数
Icmp:
    0 ICMP messages received    //收到的ICMP包数
    0 input ICMP message failed    //收到ICMP失败数
    ICMP input histogram:
    0 ICMP messages sent      //ICMP发送数
    0 ICMP messages failed      //ICMP失败数
    ICMP output histogram:
Tcp:
    0 active connection openings  //主动连接数
    0 passive connection openings  //被动连接数
    11 failed connection attempts  //失败连接尝试数
    0 connection resets received  //接收的连接重置数
    0 connections established    //建立连接数
    25 segments received      //已接收报文数
    21 segments sent out      //已发送报文数
    4 segments retransmitted    //重传报文数
    0 bad segments received      //错误报文数
    0 resets sent          //发出的连接重置数
Udp:
    0 packets received
    ...
TcpExt:
    11 resets received for embryonic SYN_RECV sockets  //半连接重置数
    0 packet headers predicted
    TCPTimeouts: 7    //超时数
    TCPSynRetrans: 4  //SYN重传数
  ...

查看iptables

查看各种链的策略

1
2
3
4

iptables -t filter -nvL  ip是数字 verbose list [--line-number-]

## 删除策略
iptables -t filter -D [INPUT or OUTPUT 等链名] [line-number]

注意MTU的大小

hping3 -S通过，但是http访问依然，原因可能和MTU有关，排查后调整

curl: (28) Operation timed out after 3005 milliseconds with 0 bytes received

1
2
3
4
5
6
7
8

root@nginx:/# netstat -i
Kernel Interface table
Iface      MTU    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0       100      106      0     32 0            43      0      0      0 BMRU
lo       65536        0      0      0 0             0      0      0      0 LRU

##调整
root@nginx:/# ifconfig eth0 mtu 1500