日常工作笔记以及从网上收集来的运维干货。
2021年10月27日 网络流量限速是一个经久不衰的话题，Linux 内核中已经实现了若干种流量限速的方式。
2021年10月25日 系统上运行着诸多进程，通过 jps 命令能够快速有效识别 Java 进程。
2021年10月25日 了解如何使用 ps、kill 和 killall 命令来终止进程并回收系统资源。
2021年09月08日 TCP/IP的七层模型
2021年09月07日 1. 为什么连接的时候是三次握手，关闭的时候却是四次握手？
2. 为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？
3. 为什么建立连接是三次握手，关闭连接确是四次挥手呢？
4. 为什么不能用两次握手进行连接？
5. 如果已经建立了连接，但是客户端突然出现故障了怎么办？
6. 为什么要三次握手？
7. 为什么要四次挥手？
8. 为什么TCP客户端最后还要发送一次确认呢？
9. 简述TCP三次握手的过程？
2. 为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？
3. 为什么建立连接是三次握手，关闭连接确是四次挥手呢？
4. 为什么不能用两次握手进行连接？
5. 如果已经建立了连接，但是客户端突然出现故障了怎么办？
6. 为什么要三次握手？
7. 为什么要四次挥手？
8. 为什么TCP客户端最后还要发送一次确认呢？
9. 简述TCP三次握手的过程？
2021年09月03日 因为网络传输的限制，很多时候，我们需要在 Linux 系统下对大文件进行切割。将一个大文件切割成为多个小文件，当传输完毕之后再进行合并。这样做的好处是效率更高。
2021年09月03日 本文介绍几款 Linux 运维的实用的工具。
MongoDB 是一个基于分布式文件存储的数据库。由 C++ 语言编写。旨在为 WEB 应用提供可扩展的高性能数据存储解决方案。
MongoDB 将数据存储为一个文档，数据结构由键值(key=>value)对组成。MongoDB 文档类似于 JSON 对象。字段值可以包含其他文档，数组及文档数组。
MongoDB 将数据存储为一个文档，数据结构由键值(key=>value)对组成。MongoDB 文档类似于 JSON 对象。字段值可以包含其他文档，数组及文档数组。
2021年09月14日
2021年09月14日 mongoimport 和 mongoexport 并不能可靠地保存所有的富文本 BSON 数据类型，因为 JSON 仅能代表一种 BSON 支持的子集类型。因此，数据用这些工具导出导入或许会丢失一些精确程度。
2021年09月14日
2021年09月14日
本书不会重复造轮子，写出差异化，以实用性为初心，实例化引导为手段，避免阳春白雪式的理论宣导，或是皮相之谈的代码解读。总结而言本书的特点如下：
实例导向，理论为辅：笔者多年服务于互联网金融公司，本书以信贷系统这一真实项目为线索，循序渐进地介绍服务架构的来龙去脉，微服务架构的基础性理念介绍是必须的，但不会生搬硬套地解释某些知识点的设计原理，而会更加关注在架构演进过程中为什么要用到这些技术及这些技术的适用场景及局限。
言简意赅，拒绝话痨：对比国内外技术书箱，很大的差异在于国内很多作者喜欢“堆代码”，喜欢“旁征博引”，本书不求“厚”，但求“精”，对于一些显而易见或是网络中已有详尽介绍的知识点本书尽量以扩展阅读的形式呈现给读者，不占用过多篇幅介绍。
内容殷实，力求全面：在保证行文紧凑的同时，本书尽量覆盖服务架构的核心点、项目实例的全流程关键点，并且会引入一些相关的扩展话题以供探讨，IT技术的发展可能是各个行业中最快的，服务架构做为最重要的IT基础性技术之一自然也在快速地进化，所以本书也会用适当的篇幅用实例介绍目前比较业界被看好的Service Mesh及Serverless技术。
扩展丰富，追根溯源：本书以脚注或扩展阅读的形式引用了大量基础或发散性的解释说明做为知识体系的补充，引文力求正本清源，多为论文链接或权威网站（多见于Wikipedia、InfoQ、IBM）的一手资料。
实例导向，理论为辅：笔者多年服务于互联网金融公司，本书以信贷系统这一真实项目为线索，循序渐进地介绍服务架构的来龙去脉，微服务架构的基础性理念介绍是必须的，但不会生搬硬套地解释某些知识点的设计原理，而会更加关注在架构演进过程中为什么要用到这些技术及这些技术的适用场景及局限。
言简意赅，拒绝话痨：对比国内外技术书箱，很大的差异在于国内很多作者喜欢“堆代码”，喜欢“旁征博引”，本书不求“厚”，但求“精”，对于一些显而易见或是网络中已有详尽介绍的知识点本书尽量以扩展阅读的形式呈现给读者，不占用过多篇幅介绍。
内容殷实，力求全面：在保证行文紧凑的同时，本书尽量覆盖服务架构的核心点、项目实例的全流程关键点，并且会引入一些相关的扩展话题以供探讨，IT技术的发展可能是各个行业中最快的，服务架构做为最重要的IT基础性技术之一自然也在快速地进化，所以本书也会用适当的篇幅用实例介绍目前比较业界被看好的Service Mesh及Serverless技术。
扩展丰富，追根溯源：本书以脚注或扩展阅读的形式引用了大量基础或发散性的解释说明做为知识体系的补充，引文力求正本清源，多为论文链接或权威网站（多见于Wikipedia、InfoQ、IBM）的一手资料。
2021年10月30日 我们谈了很多微服务改造的点，但已有项目转微服务势必会遇到一个棘手的问题：新系统怎么替换老系统？下面我就讨论下几种主流方案。
2021年10月30日 微服务的特点决定了它会存在较长的调用链路，一个请求一般会跨3个以上的服务（网关->应用聚合层->服务化层）而跟踪它的调用情况是异常定位及性能优化的关键之一。要能跟踪我们势必需要在日志中记录每个请求唯一的跟踪Id，我们可以在HTTP请求或MQ接收时判断消息Header是否存在Trace_Id，如果不存在则认为是新的请求，进而生成一个UUID作为Trace_Id，如果存在则沿用这个Trace_Id，然后在打日志时加上这个Trace_Id。最后通过日志收集工具将这个本地日志收集到一个聚合平台上进行查询。这能解决问题，实际上这也是Google Dapper(《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》)的核心思路，Google Dapper是Google的日志追踪服务。
2021年10月30日 容器化部署是微服务非常理想的选择，它可以实现上文提到的快速发布及本节要谈的自动化节点伸缩与故障转移。
2021年10月30日 服务监控是保证生产环境稳定最基础也是最重要的措施，微服务下尤是。如果没有成熟的一套监控方案那微服务化注定会失败！
2021年10月30日 传统的服务运维对自动化的要求不需要太高，但使用微服务后服务的数量会急剧上升，一个成熟的微服务可能有几十到几百个组件，每个组件做HA，最终可能有成百上千个实例，同时还要考虑开发、测试、UAT/预发、生产、灰度等环境，人工部署将是灾难性的。