面试攻略

被访问0


又到了一年一度的跳槽旺季,面试官要问的问题你真的准备好了吗?

恒宇少年最近在公众号陆续整理面试题、面试攻略,从面试官的心理来分析回答问题。

公众号的二维码在右侧,有需要实时获取微信公众号推送的同学可以扫码关注下。

Java基础

消息队列

持续更新,敬请期待…

官宣,GitHub正式发布了移动端v1.0版本

GitHub在2019年开发者大会上已经表明正在研发手机客户端,而就在昨天(2020-3-18)提供了正式版本的下载链接,苹果端也已经上架到了AppStore

安装

GitHub移动端 官网上仅提供了两种安装方式,如下图所示:

如果你手机上可以访问Google那么你就可以通过Google Play直接安装,当然手机上访问Google还是需要一点灰色手段的,不过不用怕, 我已经将Apk下载了,放到了阿里云的对象存储内,可以直接访问下载。

IOS安装

https://apps.apple.com/cn/app/github/id1477376905

复制上面的地址到Safari浏览器中打开。

Android 安装

https://hengboy-image.oss-cn-beijing.aliyuncs.com/GitHub.v1.0.0.apk

复制上面的地址在浏览器直接访问即可。

当我们安装完成就可以看到在你的手机上多了一个 “黑猫” 应用。

开箱

打开GitHub App 然后登录我们的账号。

首页

首页中间的内容分为了三个部分,分别是:My Work(我的工作台)Favorites(收藏夹)Recent(最近动态)

  1. Issues

    点进去可以查看由我创建的、分配给我的、提到我的Issues列表,支持搜索功能。

  2. Pull Requests

    点进去可以查看由我创建、分配给我、提到我的、已合并的Pull Requests列表,支持搜索功能。

  3. Repositories

    点进去可以查看账号下的全部仓库(加入组织创建的、由我创建的、Fork的)

  4. Organizations

    点进去可以看到我所加入的组织,可以查看组织的详情、组织内的仓库列表。

消息通知

搜索

输入关键字可以搜索GitHub内匹配关键字的仓库列表。

个人首页

点击左上角的头像可以进去我的主页,主页的顶部是个人的详细信息,中间为自定义固定的展示仓库(最多6个),底部则是创建的仓库、点赞的仓库、加入的组织。

设置

自定义皮肤

皮肤默认根据手机系统的设定而来,我手机设置为深色系,而GitHub App也是黑色,可以自行修改为亮色。

自定义Icon图标

![](/images/post/github-app-release/IMG_1675 2.PNG)

手机App的图标也支持自定义,内部提供了多种样式供你选择。

浏览代码

浏览代码比较麻烦,需要一层一层进入Package,不过返回的时候比较简单,点击文件名称后面的箭头,可以选择返回任意一层,当然也可以直接返回Root目录,查看代码的质感还是很不错的。

项目主页

查看项目主页详情的功能基本跟网页版的差不多,点击Browse code就可以查看该项目的全部代码,点击右上角的“+”号可以直接创建Issues

优缺点

  1. 使用起来不太稳定,需要开代理
  2. 由于App安装文件较小,使用起来流畅度很不错
  3. 基本的功能很完整,该有的都有了
  4. 只能分享一个链接地址

使用nginx的负载均衡机制实现用户无感更新服务

前言

用户请求的转发是接口服务在部署时必须要做的一步。

请求转发的步骤大约分为如下几步:

  1. 域名解析到转发服务器
  2. 转发服务器会根据权重(weight)、备用(backup)配置转发到统一网关
  3. 如果统一网关存在灰度的配置,需要根据身份或者头信息过滤请求
  4. 转发到具体的业务服务

目前市面上优秀的请求转发有很多种,比如:NginxF5KongTengine等,其中Tengine是阿里巴巴基于Nginx进行封装,我们本章的内容基于Nginx进行讲解,我们先来准备下nginx的测试环境。

准备环境

如果你的测试环境没有安装Nginx,下面我通过两种方式来说下具体的安装过程。

使用Brew安装Nginx

如果你是OSX系统,可以直接使用brew管理工具进行安装,这种方式比较简单,自动从远程服务器下载最新稳定的版本进行解压、配置环境等。

1
2
# 安装nginx
➜ ~ brew install nginx

静静等待~

安装完成后,我们先来修改下端口号(brew安装包把默认的监听端口号改为了8080,一般在使用解压的方式安装时监听端口都是80)。

我们需要先找到nginx.conf这个文件的位置:

1
2
➜  ~ sudo find / -name nginx.conf           
/usr/local/etc/nginx/nginx.conf

找到文件后,我们通过sudo vi /usr/local/etc/nginx/nginx.conf命令来修改默认的端口号,位置如下:

1
2
3
4
5
server {
listen 80;
server_name localhost;
#...
}

修改后保存退出。

最后不要忘记重启Nginx服务。

1
➜  ~ brew services restart nginx

解压包方式

首先去nginx官方提供 http://nginx.org/download 的下载地址去挑选自己中意的版本,下面以1.17.7版本示例:

点击下载完成后解压安装即可(注意编译环境,可能会缺少一些依赖库,本机安装对应的依赖就可以了)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 解压nginx
tar -xvf nginx-1.17.7.tar.gz
# 进入目录
cd nginx-1.17.7
# 配置
./configure --prefix=/usr/local/nginx
# 编译
sudo make
# 安装
sudo make install
# 进入nginx执行目录
cd /usr/local/nginx/sbin
# 启动nginx
./nginx

安装完成如果访问 http://127.0.0.1 可以看到Welcome to nginx!字样,说明我们已经安装成功了。

示例项目

为了演示更新服务用户无痛感知,我们先来创建一个简单的SpringBoot示例项目,在项目内添加一个测试接口,项目pom.xml依赖如下所示:

1
2
3
4
5
6
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
</dependencies>

示例接口

创建一个名为TestController的测试控制器,如下所示:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
/**
* 测试控制器
*
* @author 恒宇少年
*/
@RestController
@RequestMapping(value = "/test")
public class TestController {
@Autowired
private ServerProperties serverProperties;

@GetMapping
public String hello() {
return "请求分发到了,端口号:" + serverProperties.getPort() + "的服务,接口访问成功.";
}
}

配置转发

我们测试所需要的请求接口已经准备好了,接下来需要在访问nginx时将请求转发到我们测试的接口,配置转发时需要用到nginx的两个关键字,分别是upstreamlocation

  • upstream:服务器组,配置请求分发到组内多台服务器。
  • location:转发的路径前缀,如:”/user/“,当我们访问http://127.0.0.1/user/1时,就会执行该location的转发业务。

upstream转发流程如下图所示:

配置UpStream

nginx.conf文件http内添加转发的服务器组(upstream),如下所示:

1
2
3
4
5
6
# 负载配置
upstream test {
server 127.0.0.1:8080 weight=1;
server 127.0.0.1:9090 weight=2;
server 127.0.0.1:9000 backup;
}

配置Location

在上面已经配置好了服务器组,我们需要把名为test的服务器组作为代理的方式配置在location,在locationserver下新增一个location,如下所示:

1
2
3
4
5
6
7
8
9
10
# 配置"/lb/"路径的请求全部转发到本地8080端口
location /lb/ {
proxy_pass http://test/;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_connect_timeout 50;
proxy_read_timeout 50;
proxy_send_timeout 50;
}

重启Nginx

我这里是使用brew的方式安装的nginx,所以重启的命令如下所示:

1
brew services restart nginx

如果你是安装包的方式安装:

1
2
3
4
# 进入安装包目录
cd /usr/local/nginx/sbin
# 重载
./nginx -s reload

权重配置

nginx中有一个权重的概念,根据权重值的大小来控制请求流量,当权重的配值越大时,流量分发就会越多,我们在test服务器组内配置权重解释:

  • server 127.0.0.1:8080 weight 1; 权重占比为1/3,每3次请求会转发1次到这台服务器上。
  • server 127.0.0.1:9090 weight 2; 权重占比为2/3,每3次请求会转发2次到这台服务器上。

备用配置

当我们在upstream内的server尾部添加backup时,表示这台服务器是备用服务器,只有其他服务器都停机时才会启用,我们更新时其实就利用的这一点。

运行测试

为了演示方便我们直接将本章测试项目package打包后,通过--server.port来指定运行的端口号来模拟多台服务器的场景。

1
2
3
4
5
6
# 启动127.0.0.1:8080服务器
java -jar target/use-nginx-loadbalance-upgrade-service-0.0.1-SNAPSHOT.jar --server.port=8080
# 启动127.0.0.1:9090服务器
java -jar target/use-nginx-loadbalance-upgrade-service-0.0.1-SNAPSHOT.jar --server.port=9090
# 启动127.0.0.1:9000备用服务器
java -jar target/use-nginx-loadbalance-upgrade-service-0.0.1-SNAPSHOT.jar --server.port=9000

注意:使用多个终端窗口运行服务。

nginx.conf>server中配置location的转发条件为/lb/路径前缀,所以我们访问 http://127.0.0.1/lb/test (由于nginx监听的端口号是80,所以通过nginx访问转发时不需要携带端口号)就会被转发到test服务器组内的服务器上。

测试点:权重转发

1
2
3
4
5
6
7
8
9
10
11
curl http://localhost/lb/test
端口号:8080,接口访问成功.

curl http://localhost/lb/test
端口号:9090,接口访问成功.

curl http://localhost/lb/test
端口号:9090,接口访问成功.

curl http://localhost/lb/test
端口号:8080,接口访问成功.

根据访问的结果来看,8080端口号的服务是每3次中请求了1次,而9090则是每3次中请求了2次,这一点正是符合我们配置的权重(weight),测试通过。

测试点:备用生效

我们把80809090这两个服务都停掉,再次访问 http://127.0.0.1/lb/test

1
2
3
4
5
6
7
8
curl http://localhost/lb/test
端口号:9000,接口访问成功.

curl http://localhost/lb/test
端口号:9000,接口访问成功.

curl http://localhost/lb/test
端口号:9000,接口访问成功.

可以看到我们的备用服务器启用了,已经把全部的请求流量转发到9000这台服务上,测试通过。

敲黑板,划重点

当我们把80809090都停掉时,备用服务器会启用,这时我们就可以来更新80809090这两个服务的运行代码,更新完成后重启,只要80809090这两台服务器有一台处于运行状态,nginx就不会把流量分发到备用的9000,以此类推把全部的服务都更新完成。

代码示例

如果您喜欢本篇文章请为源码仓库点个Star,谢谢!!!
本篇文章示例源码可以通过以下途径获取,目录为use-nginx-loadbalance-upgrade-service

GitHub标星超1万的Chrome插件,助你轻松查看文件Git历史

前言

之前给大家介绍过一款好用的GitHub代码层级阅读浏览器插件Octotree,该插件直接可以读取GitHub源码仓库的全部文件并生成树形层级关系,省去了连续不断地点击进入目录的操作。

GitHistory Chrome Plugin

有些时候我们需要查看源码仓库中某一个文件的修改历史记录,方便我们做一些变动的追溯,在GitHub上还真有一款大神级别的浏览器插件,该插件可以界面图形化查看某一个文件的全部修改历史记录,很是方便,今天推荐给大家。

该插件在Chrome商店内可以找到,名为:Git History Browser Extension,由Luis Reinoso提供。

它是一款开源的浏览器插件,仓库地址:https://github.com/pomber/git-history,目前Star已经超过11k。

怎么使用?

通过Chrome商店安装完成后,这时我们打开GitHub的任意仓库(这里以ApiBoot仓库为例),找到某一个文件点击后,效果如下:

可以看到在工具栏多出了一个名为Open in Git History的按钮,我们点击该按钮会跳转到 https://github.githistory.xyz/ ,效果如下图所示:

在地址栏中除了域名以外,后面的地址与访问GitHub时是一样的。

该页面分了两部分:

  1. 顶部横向滚动条

    初次访问该页面时默认是最新的提交的历史文件内容,在顶部会列出该文件的全部的提交记录,当我们点击任意一个记录时,在下面都会显示属于这个文件这次提交的内容。

  2. 底部文件历史内容

    对应顶部的提交信息当前文件的变动内容。

不能访问Chome商店?

由于网络访问受限,我们无法直接访问Chrome商店,我在之前文章中推荐了一款科学上网的神器,GHelper也是一款浏览器插件(该插件可直接通过源码方式安装)。

关注 “程序员恒宇少年”微信公众号,回复”Google”获取GHelper源码方式安装包。

使用Gitbook创建文档并导出PDF

导出PDF的方式有很多种,之前使用过马克飞象的导出功能,不过只是简单的导出并不能添加目录,因为源文件是markdown编写的,经过筛选后采用了gitbook的方式进行编写文档并且使用gitbook pdf .的方式导出为PDF文件。

在阿里Java大牛们都是这样对Java项目代码分层的

代码分层,对于任何一个Java开发来说应该都不陌生。一个好的层次划分不仅可以能使代码结构更加清楚,还可以使项目分工更加明确,可读性大大提升,更加有利于后期的维护和升级。

作为高级Java,你应该了解的Linux知识

作为一个javaer,我以前写过很多关于Linux的文章。但经过多年的观察,发现其实对于大部分人,有些东西压根就用不着。用的最多的,就是到线上排查个问题而已,这让人很是苦恼。那么,我们就将范围再缩小一下。

Linux上,最常用的一批命令解析(10年精选)

Linux这么多命令,通常会让初学者望而生畏。下面是我结合日常工作,以及在公司的内部培训中,针对对Linux不是很熟悉的同学,精选的一批必须要搞懂的命令集合。

记一次操蛋的方案降级(云上冷热分离的坎坷之路)

系统的数据,就是公司的生命。哪怕是狗屎,我们也要将它冷冻起来冰封以备后用。垃圾的产品设计就比较让人费解,会时不时从冰柜中将屎取出,想要品尝其中残留的味道。
不过这其中,还是有些有价值的需求。这种情况,就需要将数据进行冷热分离,对数据进行隔离。不至于让一颗老鼠屎,坏了一锅粥。

秒懂 QPS、TPS、PV、UV、GMV、IP、RPS!

QPS、TPS、PV、UV、GMV、IP、RPS等各种名词,外行看起来很牛X,实际上对程序员来说都是必懂知识点。下面我来一一解释一下。

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×