国外很多的软件都有这样一个问题——系统设置不一定在 Setting 里。这不，找了很久的 smartgit 的代理设置，愣是没找到：

上网搜也没搜出个所以然来。在菜单栏一个一个点，发现了 Preference。啧啧啧，这才是某些软件的系统设置。

填写完代理地址即可。

博主是蘑菇街的员工，写了不少kubernetes的文章。这篇的原文链接：http://wsfdl.com/kubernetes/2018/07/09/why_not_flanneld.html

基于 UDP 的 flannel 网络模型具有简单易用，不依赖底层网络的特点，所以很多入门者偏向选择 flannel 作为 K8S 的网络方案。我们曾考虑尽量采用原生的网络模型，但是在实际生产环境下，受限于 overlay 网络和其它网络的互通性，以及 overlay 网络的性能等问题，我们摒弃了 flannel。

flannel 基本介绍

关于 flannel 的介绍和基本原理，官网和各类博客的做了非常详细的介绍，此处不再累述。Flannel 网络平面下的 pod 之间具有良好的互通性，但是 pod 和 K8S 外部的 IP 互通性欠佳，所以本节重点介绍 flannel 中的 pod 和 K8S 外部 IP 互通原理。

Pod 访问 K8S 外部 IP

当 pod 访问 K8S 外部 IP 时，pod 的报文在计算节点以 SNAT 的形式访问外部 IP，所以外部 IP 感知到的是计算节点的 IP，而非 pod 的 IP。如下例子，当报文经 SNAT 后，src IP 由 192.168.0.2 修改为 10.0.0.2；src port 由 43345 修改为 47886。

+--------------------------+
|  Node 10.0.0.2           |
| +-----------------+      |                 +--------------+
| | Pod 192.168.0.2 | SNAT |  ------------>  | Dst 10.0.0.3 |
| +-----------------+      |                 +--------------+
+--------------------------+
报文中的 IP／Port 信息
src: 192.168.0.2:43345                       src: 10.0.0.2:47886
dst: 10.0.0.3:80                             dst: 10.0.0.3:80

K8S 外部 IP 访问 pod

外部 IP 无法直接访问 K8S 中的 pod，为了解决这个问题，K8S 引入了 service 和 ingress，其中 service 为 4 层的概念，支持 UDP 和 TCP；ingress 为 7 层概念，支持 http。

虽然 service 支持 cluster IP, node port, loadbalancer 等模式，但是 cluster IP 仅限于 pod 之间的访问；node port 基于 DNAT 为外部服务访问容器提供了入口； loadbalancer 依赖云厂商；而 ingress 仅支持 7 层协议，不满足 rpc 调用等场景，所以相比而言 node port 模式更为简便可行。

K8S 分配计算节点上的某个端口，并映射到容器的某个端口，当外部服务访问容器时，只需要访问相对应的计算节点端口，该端口收到报文后，将目的 ip 和 端口替换为容器的 ip 和端口，最终将报文转发到容器。

                                 +--------------------------+
                                 |  Node 10.0.0.2           |
+--------------+                 |      +-----------------+ |                 
| Src 10.0.0.3 |  ------------>  | DNAT | Pod 192.168.0.2 | |
+--------------+                 |      +-----------------+ |
                                 +--------------------------+
报文 IP／Port 信息
src: 10.0.0.3:43345               src: 10.0.0.3:43345
dst: 10.0.0.2:47886               dst: 192.168.0.2:80

采用 flannel 的缺点

业务方接入 K8S 是一个循序渐进灰度的过程，而非一刀切。在现有的电商技术栈下，业务方之间存在大量的上下游依赖，而且依赖关系相对复杂。我们梳理在 flannel 网络模型下，业务方接入过程中极有可能遇上的问题。

服务发现问题

服务发现是重要的中间件之一，常见的开源项目有 dubbo 和 zookeeper 等。公司自研了类似 dubbo 的组件，并且接入了大量的业务。

首先简要介绍服务发现的基本过程，provider 作为服务提供方，它启动后向注册中心注册信息，如 IP 和 port 等等；consumer 作为消费者，它首先访问注册中心获取 provider 的基本信息，然后基于该信息访问 provider。

                         +-----------+ 
                      _  |  注册中心  |  _
     2. get provider  /| +-----------+ |\ 1. register
        basic info   /                   \
    +----------+    /                     \    +----------+                              
    | consumer | --+  3. access provider   +-- | provider |
    +----------+      ------------------>      +----------+

让我们设想一种场景，当 provider 先接入 K8S 后，每当 provider 向 register 注册时，它获取本地的 IP 并把该 IP 注册到中心。consumer 访问注册中心，拿到 provider 的 IP 后，却发现这个 IP 并不可达，如此严重影响了业务方接入 K8S。

有人会想到，是否可以先接入 consumer，然后再接入注册中心和 provider 呢？事实上，电商体系的链路比较长，依赖复杂，某个应用既有可能是上游业务的 consumer，同时也是下游业务的 provider，导致业务方无法平滑接入。虽然 K8S 也实现了服务发现功能，但是和我们自研的服务发现功能差距较大，涉及到大量的改造，成本和风险过高。

额外的端口管理问题

某些不需要服务发现的业务方接入到 K8S 后，需要通过 node port 暴露服务入口。那么问题来了，为了避免端口冲突，暴露的端口往往是随机的，这就要求业务方需要额外的增加端口管理，动态维护 pod 对应宿主机端口信息。此外，这也给业务方的下游增加了复杂性，因为下游可能要经常变更访问的端口号。

用户体验问题

业务方常常需要 SSH 登陆到容器中定位问题。当容器运行在 flannel 网络模型下时，业务方访问容器的方式主要有三种：1. 通过 node port 访问，这种情况下需要业务方维护随机端口，增加了管理和使用的复杂性；2. 通过跳板机访问，这种方式需要引入了跳板机器；3. 通过 kube exec，这种情况下需要完善权限控制的机制，且 K8S 地升级会中断 SSH 连接。无论采用哪种方式，都带来额外的维护成本。

我们常常用 ping 包来检查目的主机是否可达，有些甚至用 ping 来作为主机是否宕机的标志。处于 flannel 下的 pod 无法被 ping 通，这也容易业务方的误解，增加沟通成本。

flannel 性能问题

最后，flannel 还潜在网络性能问题，主要因为：

• 运行在用户态，增加了数据拷贝流程。每次处理报文时，需要将报文从内核态拷贝到用户态处理，处理完后再拷贝到内核态。
• 基于 UDP 封装的 overlay 报文，带来额外的封包和解包操作。
• 引入 service，增长网络链路。service 默认是通过 iptables 实现的，当条目过多时，iptables 存在性能问题。

从官网的测试结果来看，采用 flannel 容器的网络带宽降低了 50%。从博文 networking-solutions-for-kubernetes 测试结果来看，flannel 有一定概率出现较大的 latency，这将给公司某些对时延敏感的业务，如交易支付链路带来致命的影响。

感想

在私有云场景下，业务接入 PaaS 是一个循序渐进的过程，更是一个不断演讲的过程。为了让业务尽可能平滑的接入，PaaS 应适当考虑业务原场景和使用习惯，尽可能的避免业务方大幅度修改逻辑，如此业务方接入更为顺畅，沟通成本也更低。一些更高级的需求，如服务发现，故障恢复等等，可以待业务方接入之后再逐步用起来。

网络模型的选择是重中之重，让 Pod 和虚拟机物理机处于一个扁平互通的网络非常有必要，首先它避免了缺乏互通性带来的各种问题，降低业务的接入成本。其次，可以避免引入 service 模块，降低维护成本和潜在的性能风险。

和虚拟机一样，蘑菇街基于 neutron 的 VLAN 模型为容器提供网络，这使得容器的网络和虚拟机物理机在逻辑上处于同一个平面，互相可达，且 neutron 作为一个成熟的组件，稳定性高；社区基于 BGP 协议的 calico 等网络模型 ，也是一个潜在的选择，但是节点路由的数目与容器数目相同，不适合大规模场景。

参考资料

• 记一次 K8S 自研网络插件的泛洪问题
• 实现一个简单的SOCK V5代理服务器—协议
• 同局域网下的 Iptables DNAT
• kubernetes的网络数据包流程
• Kubernetes网络原理

2023-11-28更新：

https://blog.syntevo.com/smartgit/2023/04/05/smartgit-hobby-license.html

重新申请爱好者许可证，以前的不能用了。

我在这里对23.1版本做了个备份：

• win
• mac
• linux

2022-02-08更新：

目前可以直接使用自己的邮箱向官方申请非商用密钥，所以不需要这么麻烦了。

上个月开始，smartgit 就调整了它的免费版策略，每隔一段时间就出现无法跳过的30秒钟“非商业许可证”。这种情况不需要“破解”。

但如果你不小心按了商业版，实际上还是会给你弹出等待，超过时间还会强制购买，否则无法使用。本文介绍在这种情况下，如何解决这个问题。

本文记录通过重置软件，继续试用的方式，跳过这个强制许可证，每隔1个月需要重新操作一次。略显麻烦，不过操作起来简单，值得一试。

1. Win+R

2. 输入以下命令

   %APPDATA%\syntevo\SmartGit\
   

   

3. 删除 settings.xml 文件。

   

最后注意不要主动升级版本。

原文：https://www.jianshu.com/p/3170399b50e6

统计IP访问量（独立ip访问数量）

awk '{print $1}' access.log | sort -n | uniq | wc -l

查看某一时间段的IP访问量(4-5点)

grep "07/Apr/2017:0[4-5]" access.log | awk '{print $1}' | sort | uniq -c| sort -nr | wc -l  

查看访问最频繁的前100个IP

awk '{print $1}' access.log | sort -n |uniq -c | sort -rn | head -n 100

查看访问100次以上的IP

awk '{print $1}' access.log | sort -n |uniq -c |awk '{if($1 >100) print $0}'|sort -rn

查询某个IP的详细访问情况,按访问频率排序

grep '127.0.01' access.log |awk '{print $7}'|sort |uniq -c |sort -rn |head -n 100

页面访问统计 查看访问最频的页面(TOP100)

awk '{print $7}' access.log | sort |uniq -c | sort -rn | head -n 100

查看访问最频的页面([排除php页面】(TOP100)

grep -v ".php"  access.log | awk '{print $7}' | sort |uniq -c | sort -rn | head -n 100 

查看页面访问次数超过100次的页面

cat access.log | cut -d ' ' -f 7 | sort |uniq -c | awk '{if ($1 > 100) print $0}' | less

查看最近1000条记录，访问量最高的页面

tail -1000 access.log |awk '{print $7}'|sort|uniq -c|sort -nr|less

每秒请求量统计 统计每秒的请求数,top100的时间点(精确到秒)

awk '{print $4}' access.log |cut -c 14-21|sort|uniq -c|sort -nr|head -n 100

每分钟请求量统计 统计每分钟的请求数,top100的时间点(精确到分钟)

awk '{print $4}' access.log |cut -c 14-18|sort|uniq -c|sort -nr|head -n 100

每小时请求量统计 统计每小时的请求数,top100的时间点(精确到小时)

awk '{print $4}' access.log |cut -c 14-15|sort|uniq -c|sort -nr|head -n 100

性能分析 在nginx log中最后一个字段加入$request_time

列出传输时间超过 3 秒的页面，显示前20条

cat access.log|awk '($NF > 3){print $7}'|sort -n|uniq -c|sort -nr|head -20

列出php页面请求时间超过3秒的页面，并统计其出现的次数，显示前100条

cat access.log|awk '($NF > 1 &&  $7~/\.php/){print $7}'|sort -n|uniq -c|sort -nr|head -100

蜘蛛抓取统计 统计蜘蛛抓取次数

grep 'Baiduspider' access.log |wc -l

统计蜘蛛抓取404的次数

grep 'Baiduspider' access.log |grep '404' | wc -l

TCP连接统计 查看当前TCP连接数

netstat -tan | grep "ESTABLISHED" | grep ":80" | wc -l

用tcpdump嗅探80端口的访问看看谁最高

tcpdump -i eth0 -tnn dst port 80 -c 1000 | awk -F"." '{print $1"."$2"."$3"."$4}' | sort | uniq -c | sort -nr

背景

以前博客有两篇涉及到nodejs，当时只是轻度使用，不甚熟悉。估计今后使 nodejs 的地方会越来越多，本文整理了node 的一些笔记。

介绍

简单来说，nodejs 就是运行在服务端的JavaScript。

为什么要使用 nodejs ？它跟 java PHP 有什么区别呢？

node.js 有非阻塞，事件驱动I/O等特性，非常适合高并发的应用。

以上说明对于一些人来说可能显得晦涩不少，又要去查什么叫非阻塞、事件驱动等。下面是更简单的解释。

在 Java™ 和 PHP 这类语言中，每个连接都会生成一个新线程，每个新线程可能需要 2 MB 的配套内存。在一个拥有 8 GB RAM 的系统上，理论上最大的并发连接数量是 4,000 个用户。随着您的客户群的增长，如果希望您的 Web 应用程序支持更多用户，那么，您必须添加更多服务器。当然，这会增加服务器成本、流量成本和人工成本等成本。

除这些成本上升外，还有一个潜在技术问题，即用户可能针对每个请求使用不同的服务器，因此，任何共享资源都必须在所有服务器之间共享。

鉴于上述所有原因，整个 Web 应用程序架构（包括流量、处理器速度和内存速度）中的瓶颈是：服务器能够处理的并发连接的最大数量。

Node 解决这个问题的方法是：更改连接的方式。每个连接发生一个在 Node 引擎进程中的事件，而不是为每个连接生成一个新的线程（并为其分配一些配套内存）。Node 不会死锁，因为它根本不允许使用锁，它不会直接阻塞 I/O 调用。

转自：https://www.ibm.com/developerworks/cn/opensource/os-nodejs/index.html

安装

我是用的系统为 Debian 8.8，root用户。

安装可用三种方式：

1. 源安装
2. PPA安装
3. mvm安装

1. 源安装

apt-get update
apt-get install nodejs npm

查看版本：

nodejs -v
npm -v

如果你是用普通用户安装，要确保该用户拥有 sudo 权限。

如果使用root用户安装，另外增加如下命令：

npm config set user 0
npm config set unsafe-perm true

2. PPA安装

curl -sL https://deb.nodesource.com/setup_10.x -o nodesource_setup.sh
bash nodesource_setup.sh

apt-get install nodejs npm

查看版本：

nodejs -v
npm -v

如果你是用普通用户安装，要确保该用户拥有 sudo 权限。

如果使用root用户安装，另外增加如下命令：

npm config set user 0
npm config set unsafe-perm true

为了使某些npm包能够工作（例如，需要从源代码编译代码），需要安装build-essential包：

apt-get install build-essential

3. NVM安装

curl -sL https://raw.githubusercontent.com/creationix/nvm/v0.33.11/install.sh -o install_nvm.sh

运行脚本bash：

bash install_nvm.sh

软件会安装到~/.nvm。它还在~/.profile文件添加三行以使用nvm，你可以参考。如果使用zsh的话依样画葫芦把它拷贝到 ~/.zshrc中。

查看可用的Node.js版本的信息：

nvm ls-remote

我选择了最新的长期支持版本：

nvm install 8.11.1
nvm use 8.11.1

查看版本：

node -v
npm -v

安装模块时需要注意如下事项，以express模块为例:

npm install express

如果您想要全局安装模块，使用相同版本的Node.js将其提供给其他项目，您可以添加-g标志：

npm install -g express

这将安装包：

~/.nvm/versions/node/node_version/lib/node_modules/express

全局安装模块将允许您从命令行运行命令，但是您必须将程序包链接到本地范围以从程序中请求它：

npm link express

卸载

以前两种方式安装的，运行如下命令卸载：

sudo apt remove nodejs

使用nvm方式的，运行如下命令卸载：

1. 确定要删除的版本是否为当前活动版本：

  nvm current

1. 如果您要定位的版本不是当前的活动版本，则可以运行：

  nvm uninstall node_version

此命令将卸载所选的Node.js版本。

1. 如果要删除的版本是当前活动版本，则必须先停用nvm以启用更改：

  nvm deactivate

参考资料

• Node.js 究竟是什么？ - IBM

• 如何在Debian 9上安装Node.js

• sh: 1: node: Permission denied

  ​