Mind of Bigyellow

 https://mp.weixin.qq.com/s/yZIk5xuDYPUgr38i-0_ESA?utm_source=pocket_mylist

 https://www.toutiao.com/a7043600901508088334/?log_from=94eb1c45d0dc5_1640052448731&wid=1640288269363

https://mp.weixin.qq.com/s/9Lmr9DM-0YrdcaZZKGGu1A   缓存使用小技巧： （1）服务与服务之间 不要通过缓存传递数据； （2）如果缓存挂掉，可能导致 雪崩 ，此时要做 高可用缓存 ，或者 水平切分； （3）调用方不宜再单独使用缓存 存储服务底层的数据，容易出现数据不一致，以及反向依赖； （4）不同服务， 缓存实例要做垂直拆分；

https://mp.weixin.qq.com/s/6M6ZQrkzmg2h0ez7mFpKWQ ITIL 为 ITSM 提供了专业术语和流程指导，告诉我们应该怎么去做 IT 服务，而 ITSM 是落地的 IT 服务，不停的在流程中被使用。 IT 服务管理的难点就在于管理的无序和被动，无法透明化或可视化，技术人员的服务意识差，效率低且 IT 人员的成本高；IT 服务的风险也是很大的， ITIL 中 IT 的服务管理包含      服务台管理、      事件管理、      问题管理、 问题管理的目的是防止问题和因问题而造成事故（Incident）的发生，以最大程度减小 反复出现事故 （recurring incident）的发生，以此最大程度减小无法避免事故的负面影响。 信息技术基础架构库 （ITIL）有如下定义：问题是 事故 的原因。      变更管理、      配置管理、      发布管理、      服务级别管理等。 https://mp.weixin.qq.com/s/iwyHJCuno2zrC9qetflcVA

https://mp.weixin.qq.com/s/ZZXYhG_UUecESBDmp8jqPg                                     四层负载均衡                                                      七层负载均衡 URL解析                            ❌                                                                       ✅ 擅长                      DNS域名轮流解析                               应用层负载调度                               客户管调度 原理                     通过报文里面目标地址来调度               通过报文中真正有意义的内容                              a) 通过修改IP方式 SNAT -> DNAT                              NAT: Network Address Translation                              b) 通过修改目标MAC (Direct Routing) LVS          四层LB      Nginx     七层LB HAProxy， 四层和七层

 https://mp.weixin.qq.com/s/OojCtlC1HZkc5X9XYDecNg 不管你  Dockerfile  用其中哪个(ENTRYPOINT, CMD)  指令，两个指令都推荐使用 exec 格式，而不是 shell 格式。原因就是因为使用 shell 格式之后，程序会以  /bin/sh -c  的子命令启动，并且 shell 格式下不会传递任何信号给程序。这也就导致，在  docker stop  容器的时候，以这种格式运行的程序捕捉不到发送的信号，也就谈不上优雅的关闭了。 docker stop  停掉容器的时候，默认会发送一个  SIGTERM  的信号，默认 10s 后容器没有停止的话，就  SIGKILL  强制停止容器。

 https://mp.weixin.qq.com/s/9KX04mmLNQbKZt-iQYk7qg 【流量不均】负载均衡配置错误，导致大量请求打到少量机器，造成“热点”影响服务可用性，怎么办？ 通过链路分析按 IP 分组统计链路数据，快速了解调用请求分布在哪些机器上，特别是问题发生前后的流量分布变化，如果大量请求突然集中在一台或少量机器，很可能是流量不均导致的热点问题。再结合问题发生点的变更事件，快速定位造成故障的错误变更，及时回滚。 【单机故障】网卡损坏/CPU 超卖/磁盘打满等单机故障，导致部分请求失败或超时，如何排查？ 通过链路分析先筛选出异常或超时请求，根据宿主机 IP 或容器 IP 进行聚合分析，快速判断是否存在单机故障。如果异常请求集中在单台机器，可以尝试替换机器进行快速恢复，或者排查该机器的各项系统参数： 【慢接口治理】如何快速梳理慢接口列表，解决性能瓶颈？ 找到慢接口后，可以结合相关的调用链、方法栈和线程池等数据定位慢调用根因，常见原因包括以下几类： 数据库/微服务连接池过小， 大量请求处于获取连接状态，可以调大连接池最大线程数解决。 N+1 问题， 比如一次外部请求内部调用了上百次的数据库调用，可以将碎片化的请求进行合并，降低网络传输耗时。 单次请求数据过大， 导致网络传输和反序列化时间过长且容易导致 FGC。可以将全量查询改为分页查询，避免一次请求过多数据。 日志框架“热锁”， 可以将日志同步输出改为异步输出。 【业务流量统计】如何分析重保客户/渠道的流量变化和服务质量 可以使用链路分析的自定义 Attributes 过滤和统计实现低成本的业务链路分析。 【灰度发布监控】500台机器分10批发布，如何在第一批灰度发布后，就能快速判断是否有异常？ 变更三板斧“可灰度、可监控、可回滚”，是保障线上稳定性的重要准则。其中，分批次灰度变更是降低线上风险，控制爆炸半径的关键手段。一旦发现灰度批次的服务状态异常，应及时进行回滚，而不是继续发布。 不同机器流量进行版本打标 {"attributes.version": "v1.0.x"} ，通过链路分析对attributes.version 进行分组统计，可以清晰的区分发布前后或不同版本的流量变化和服务质量。不会出现灰度批次异常被全局监控掩盖的情况。 基于链路明细数据进