架构设计/开发常用工具框架

• 工具框架

• 1.rpc框架：brpc，spp
• 2.缓存数据库(nosql、kv)：redis，couchbase，memcache，cassandra（facebook开源分布式）
• 3.服务发现：consul，zookeeper
• 4.消息队列：kafka
• 5.监控：grafana，influx db(时序数据库)
• 6.数据库：mysql
• 7.版本管理：gitlap（开源），svn，github
• 8.数据分发：rsync，dragonfly（基于p2p）
• 9.进程管理：supervisor
• 10.c++配置，log框架：gflags，glog
• 11.性能检测、调试：perf，gperformance，strace，gdb
• 12.持续集成工具：jenkins
• 13.c++编译工具：blade
• 14.用线上流量压测：tcpcopy
• 15.抓取线上流量：tcpdump，wireshark
• 16.windows共享linux文件：samba
• 17.容器化：rpm打包，dockerfile。用k8s管理容器。
• 18.配置中心：Apollo(携程开源)，Nacos（阿里开源）
• 19.分布式全文搜索引擎：ElasticSearch
• 20.跨平台的画图工具（可替代visio）：Draw.io，xmind(思维导图)

• 架构上的设计技巧及经验

• 1. redis可用作本地缓存，采用master-slave架构，访问速度很快。
• 2. P99不稳定，抖动严重，可能是因为流量少，波动大。
• 3. io超时时间设置：一般设置为P999，保证服务可用率达到99.9%，更严格的，可以设置到9999。
• 4. 线程数一般设置为cpu核数，最大程度利用cpu资源。
• 5. 微服务高可用的常用手段：健康检查、熔断、限流、降级、监控预警、跨DC容灾、质量控制：

健康检查：定时对ip列表节点探测检查，一般是用tcp检测某个端口是否可用，如果不可用，就将它从列表中删除。consul提供了脚本方式检测。

上游调用下游服务，因为各种原因，造成下游服务某些节点不可用，造成io超时，那就需要重试。

熔断：如果上游服务调用下游某个节点，检查出来频繁超时，即超时重试多次后都失败了，那么就直接短路掉，不再访问该下游节点。注意，这里熔断并不会从consul机器列表中删除，删除是由consul的健康检查来做。设计思路如下：

1. Closed：初始状态，熔断器关闭，下游节点正常提供服务。
2. Open: 失败次数，失败百分比达到一定的阈值之后，熔断器打开，停止访问该节点。
3. Half-Open：熔断一定时间之后，小流量尝试调用该节点，如果成功则恢复，熔断器变为Closed状态。

限流：一般分为qps限流，并发限流。

qps限流：限制每秒处理请求数不超过阈值。并发限流：限制同时处理的请求数目（监控concurrency）。

常用算法：

1、滑动窗口计数算法

整个红色的矩形框表示一个时间窗口，在我们的例子中，一个时间窗口就是一分钟。然后我们将时间窗口进行划分，我们就将滑动窗口划成了6格，所以每格代表的是10秒钟。每过10秒钟，我们的时间窗口就会往右滑动一格。每一个格子都有自己独立的计数器counter，比如当一个请求在35秒的时候到达，那么30~39对应的格子的counter就会加1。检测当前时间窗口的请求总数，即将最后6个格子的counter累加，如果超过阈值，则触发限流。

那么滑动窗口怎么解决刚才的临界问题的呢？59s到达的100个请求会落在灰色的格子中，而60s到达的请求会落在橘黄色的格子中。当时间到达60s时，我们的窗口会往右移动一格，那么此时时间窗口内的总请求数量一共是200个，超过了限定的100个，所以此时能够检测出来触 发了限流。

我再来回顾一下刚才的计数器算法，我们可以发现，计数器算法其实就是滑动窗口算法。只是它没有对时间窗口做进一步地划分，所以只有1格。由此可见，当滑动窗口的格子划分的越多，那么滑动窗口的滚动就越平滑，限流的统计就会越精确。

2. 漏桶算法：请求进入到漏桶里，漏桶以一定的速度漏出请求，当请求流入速度过大时，会桶直接溢出。当水超过桶流量则丢弃，因为桶容量是不变的，保证了整体的速率。

3. 令牌桶算法：令牌桶算法是比较常见的限流算法之一，大概描述如下：

1）桶设置最大的放置令牌限制。

2）根据限流大小，设置按照一定的速率往桶里添加令牌。当桶满时、新添加的令牌就被丢弃或者拒绝；

3）请求达到后首先要获取令牌桶中的令牌，拿着令牌才可以进行其他的业务逻辑，处理完业务逻辑之后，将令牌直接删除；

4）令牌桶有最低限额，当桶中的令牌达到最低限额的时候，请求处理完之后将不会删除令牌，以此保证足够的限流；

漏桶算法VS令牌桶算法

漏桶算法的出水速度是恒定的，那么意味着如果瞬时大流量的话，将有大部分请求被丢弃掉（也就是所谓的溢出）。因此，漏桶算法对于存在突发特性的流量来说缺乏效率。

令牌桶算法生成令牌的速度是恒定的，而请求去拿令牌是没有速度限制的。这意味，面对瞬时大流量，该算法可以在短时间内请求拿到大量令牌，可以处理瞬时流量，而且拿令牌的过程并不是消耗很大的事情。

降级：在流量高峰期，如果下游某服务压力过大，为了确保核心功能的稳定运行，把一些非必要服务降级，不再访问。

比如：降级超时严重的io，降级比较复杂的业务逻辑（比如rank）使用兜底逻辑。

跨DC容灾：多DC部署服务，手动切换流量到另一个DC，DC之间有专线连接，使用专线容灾保底。

质量控制：staging小流量预发布，余弦曲线监控，A/B测试。

画图工具

xmind，drawio（跨平台）