Lab1花了三天时间，一些小细节不注意，在一些细节处出了许多问题，一点点的debug还是给解了，虽然完成的很慢，但做出来的那一刻还是很开心的，终于pass all了。

注意：这篇文章不是为了记录解题思路，还是得遵从老师的意思。当然如果你正在解题，没有人交流的话，你可以选择两个，第一，在B站的该课程视频评论下，找到slack链接，加入进去；第二，联系我，我也会尽量帮助你理解这道实验题。

这是个小工具，比如想输出一个表格，每个表格都是对应着公司的JIRA正在跑的项目，那就可以使用Go将其导出。

如果单独去研究JIRA的库是没有特别的必要的，首先要找的是不是已经存在脚手架了，此处使用：go-jira。

抱着学习的心态学习一下别家农场的代码，不同厂商的代码习惯肯定是不同的，标准更为的不同，这些都是我们可以学习的目标，毕竟很多东西是可以用来借鉴的，当然，轮子这玩意，能用现在还在维护的，就使用还在维护的，我其实有点不理解为啥要重复造轮子这事。

前言

根据现在在了解的东西，选了一个log-agent模块来看看，初看只看发现有点眼熟，后来看了下确实是filebeat，这里面很多东西是搬的filebeat那一套，当然，我说的就包括有设计框架，那到底B站是怎么魔改的呢，借此我要来学习了。

这个好像没什么好讲，主要是gin框架下，httptest包要怎么写，这个是重点。直接上代码吧。

闲暇的时候写了个根据SQL文件自动转化成Markdown文件的工具，因为go程序编程成程序，使用非常方便。

而且相对来说，这玩意写起来，关键其实是在正则表达式，这玩意也是让我猝不及防的。

学习搭建并行处理管道，感受GO语言魅力。

学习的代码。

在一些需要大量访问的服务中，访问量过大，处理方式无非是，① 提升后台性能（包括提升硬件性能，优化代码或者分布式架构这些的）；② 限速，（在一顿时间内，限制访问者的成功率，例如某接口访问限制为1000次/s）。

在实现限速功能的时候，其中一种常用的方法是使用 token bucket 算法来实现。

我之前写过一篇比较简单的，服务器限流问题。

本文是学习熔断器后的一些总结，之前就对微服务相关的东西进行一些了解，其中熔断器肯定是需要了解的。

为什么需要熔断器呢？

分布式系统中经常会出现某个基础服务不可用造成整个系统不可用的情况, 这种现象被称为服务雪崩效应。为了应对服务雪崩，一种常见的做法是手动服务降级(将一些不重要 或 不紧急的服务或任务进行服务的 延迟使用 或 暂停使用)。而Hystrix（熔断器）的出现，给我们提供了另一种选择。

单元测试在一定意义上能够保证代码的质量，用以衡量软件工程的质量，帮助我们规避重构的风险。

每一个单元测试代表着一个业务逻辑，修改代码后，运行单元测试，就能帮助我们确定新代码会不会影响已有的业务逻辑，可以降低线上的风险和测试的问题。