发表于

打开 Visual Studio Code 的设置，按如下配置即可：

1
2
3
4
5
{
  // 找到您的 git 目录
  "terminal.integrated.shell.windows": "C:\\Program Files (x86)\\Git\\bin\\bash.exe",
  "terminal.integrated.shellArgs.windows": ["--login", "-i"]
}

发表于

deploy.sh

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
#!/bin/sh

# 本脚本用于开发环境，直接打包需要发布的文件，然后通过 SSH 复制到服务器并直接通过 pm2 启动执行。
# 主要功能：
#   - 打包本地文件
#   - 剪切备份 $BUILDDIR 目录（实际程序执行的目录）
#   - 复制到远程服务器 $BUILDDIR 目录
#   - 解压
#   - 使用备份的配置文件覆盖
#   - 启动程序

WORKROOT=/path/to/your/dir/on/remote/server
BUILDDIR=$WORKROOT/build

SKEY=" -i ~/.ssh/your-ssh-key-file"
SCHANNEL="your-ssh-user@your-ssh-host"
SROOT=$SCHANNEL:$WORKROOT
SBUILD=$SCHANNEL:$BUILDDIR
DATE=`date '+%Y-%m-%d%H%M%S'`

. ./bash/pack.sh $DATE

echo "copying files..."
scp $SKEY -r ./build/build-$DATE.zip $SROOT
ssh $SKEY $SCHANNEL mv $BUILDDIR $BUILDDIR-$DATE

echo "unzipping files..."
ssh $SKEY $SCHANNEL unzip -q $WORKROOT/build-$DATE.zip -d $BUILDDIR
#ssh $SKEY $SCHANNEL cp $WORKROOT/bak/etc/config.json $BUILDDIR/etc/config.json

echo "starting..."
CMD="cd $BUILDDIR ; pm2 restart ./etc/pm2.config.json"
ssh $SKEY $SCHANNEL $CMD

pack.sh

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
#!/bin/sh

# 需要在项目根目录执行，如：./bash/pack.sh

DATE=$1

if [ -z "$DATE" ] ; then
  DATE=`date '+%Y-%m-%d%H%M%S'`
fi

# 备份本地配置，使用生产环境配置
mv ./etc/config.json ./etc/config.dev.json.bak
mv ./etc/config.prod.json ./etc/config.json

echo "packing files..."
zip -r -q ./build/build-$DATE.zip ./bin
zip -r -q ./build/build-$DATE.zip ./dal
zip -r -q ./build/build-$DATE.zip ./etc -i ./etc/*.json
zip -r -q ./build/build-$DATE.zip ./controller
zip -r -q ./build/build-$DATE.zip ./middlewares
zip -r -q ./build/build-$DATE.zip ./models
zip -r -q ./build/build-$DATE.zip ./node_modules
zip -r -q ./build/build-$DATE.zip ./public
zip -r -q ./build/build-$DATE.zip ./routes
zip -r -q ./build/build-$DATE.zip ./utils
zip -r -q ./build/build-$DATE.zip ./views
zip -r -q ./build/build-$DATE.zip ./app.js

# 还原配置
mv ./etc/config.json ./etc/config.prod.json
mv ./etc/config.dev.json.bak ./etc/config.json

发表于

场景：

  • SSH 跳板机：10.0.0.1
  • MySQL 数据库：10.0.0.2:3306

MySQL 部署的机器不允许 SSH 连接，并且数据库端口只允许 localhost 或 10.0.0.1 这台跳板机访问，此时本机可以通过 ssh 连上跳板机，通过 ssh 建立的隧道端口转发连接上 MySQL 数据库。

1
2
3
4
5
6
7
8
9
10
11
# 本机连接跳板机
# 打开本机 13306 端口，代理到 ssh 跳板机，并且通过跳板机访问 10.0.0.2:3306
ssh -fCPN -L localhost:13306:10.0.0.2:3306 root@10.0.0.1
# 参数解释
# -C    使用压缩功能,是可选的,加快速度.
# -P    用一个非特权端口进行出去的连接.
# -f    一旦SSH完成认证并建立port forwarding,则转入后台运行.
# -N    不执行远程命令.该参数在只打开转发端口时很有用（V2版本SSH支持）

# 连接 MySQL
mysql -uusername -ppassword -hlocalhost -P13306

参考：

http://mingxinglai.com/cn/2015/09/connect-mysql-via-ssh-tunnel/

发表于

架构是这样定义的

  • 每个系统都有一个架构
  • 架构由架构元素以及相互之间的关系构成
  • 系统是为了满足 利益相关者（stakeholder） 的需求而构建的
  • 利益相关者都有自己的关注点（concerns）
  • 架构由架构文档描述
  • 架构文档描述了一系列的架构视角
  • 每个视角都解决并且对应到利益相关者的关注点。

架构师的首要任务是尽最大可能找出所有利益相关者，业务方，产品经理，客户/用户，开发经理，工程师，项目经理，测试人员，运维人员，产品运营人员等等都有可能是利益相关者，架构师要充分和利益相关者沟通，深入理解他们的关注点和痛点，并出架构解决这些关注点。架构师常犯错误是漏掉重要的利益相关者，沟通不充分，都会造成架构有欠缺，不能满足利益相关者的需求。利益相关者的关注点是有可能冲突的，比如管理层（可管理性）vs技术方（性能），业务方（多快好省）vs 技术方（可靠稳定），这需要架构师去灵活平衡，如何平衡体现了架构师的水平和价值。

Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.

—- Grady Booch, UML的创始人之一

架构表示对一个系统的成型起关键作用的设计决策，这里的关键性是由“改变它”的成本来决定的。

微服务中每个服务可以独立演变，它的cost of change比较小，整体架构比较灵活，是一种支持创新的演化式架构。

Architecture Requirements

Requirement Feature Description
Easy to separate Autonomy 易分离，自治性
Easy to understand Understandablility 可理解性
Easy to extend Extensibility 可延展性
Easy to change Changeability 可变性
Easy to replace Replaceability 可替换性
Easy to deploy Deployability 可部署性
Easy to scale Scalability 伸缩性，可扩展性
Easy to recover Resilience 可恢复性
Easy to connect Uniform interface 易连接，易集成，统一接口
Easy to afford Cost-efficiency 成本效率，性价比

架构的目标是用于管理复杂性、易变性和不确定性，以确保在长期的系统演化过程中，一部分架构的变化不会对架构的其它部分产生不必要的负面影响。这样做可以确保业务和研发效率的敏捷，让应用的易变部分能够频繁地变化，对应用的其它部分的影响尽可能的小。

微服务更多是关于组织和团队，而不是技术

organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.

康威定律：设计系统的组织，其产生的设计和架构等价于组织间的沟通结构.

image

发表于 | 更新于

kubernetes

指引：https://kubernetes.io/docs/tasks/tools/install-kubectl/

安装 VM 驱动

腾讯云 CVM 未能启用驱动启动 minikube，安装驱动的过程可忽略。

- VirtualBox

CentOS：虚拟机不支持内部 VM，未在物理机上尝试

1
2
3
4
5
6
7
8
9
cd /etc/yum.repos.d/
wget http://download.virtualbox.org/virtualbox/rpm/rhel/virtualbox.repo
yum update

rpm -Uvh https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
yum install -y binutils gcc make patch libgomp glibc-headers glibc-devel kernel-headers kernel-devel dkms
yum install -y VirtualBox-5.2

service vboxdrv start

MAC 上可以直接下载安装：https://www.virtualbox.org/wiki/Downloads

- KVM2

安装成功，但 minikube start 时未能尝试成功

https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#kvm2-driver

1
2
3
4
5
6
yum -y install libvirt-daemon-kvm qemu-kvm

curl -Lo docker-machine-driver-kvm2 https://storage.googleapis.com/minikube/releases/latest/docker-machine-driver-kvm2 \
&& chmod +x docker-machine-driver-kvm2 \
&& sudo cp docker-machine-driver-kvm2 /usr/local/bin/ \
&& rm docker-machine-driver-kvm2

附：查看虚拟机网络以及使用不同的网络启动 minikube

1
2
3
4
5
yum -y install libvirt virt-install bridge-utils
# 查看虚拟机网络
virsh net-list --all
# 使用不同的虚拟机网络(minikube-net)
minikube start --vm-driver kvm2 --kvm-network minikube-net

- 其他驱动

指引：https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#kvm-driver

安装 kubectl

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# CentOS
cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
yum install -y kubectl

# MAC: 方式一
brew install kubernetes-cli
# MAC：方式二
curl -Lo kubectl http://storage.googleapis.com/kubernetes-release/release/v1.5.1/bin/darwin/amd64/kubectl && chmod +x kubectl && sudo mv kubectl /usr/local/bin/

# 安装校验
kubectl version

# 确保服务已启动
systemctl enable kubelet.service
systemctl start kubelet.service

安装 minikube

指引：https://github.com/kubernetes/minikube/releases

1
2
3
4
5
6
7
8
# CentOS
curl -Lo minikube https://storage.googleapis.com/minikube/releases/v0.29.0/minikube-linux-amd64 \
    && chmod +x minikube \
    && sudo cp minikube /usr/local/bin/ \
    && rm minikube

# MAC
brew cask install minikube

运行

（使用 KVM2 驱动）运行之前

1
2
3
4
5
6
7
8
9
10
11
# 启动服务
systemctl enable libvirtd && systemctl start libvirtd

# 查看进程文件
ls -l /var/run/libvirt/libvirt-sock

# 若进程文件不存在，则修改配置：
vi /etc/libvirt/libvirtd.conf

# 取消行前注释，重新启动服务
#unix_sock_dir = "/var/run/libvirt"

拉取 k8s 相关镜像

原本在 minikube start 命令中会自动拉取镜像，但是因为众所周知的原因，我们无法成功拉取到镜像。这里可以使用阿里 docker 容器镜像服务：https://dev.aliyun.com/search.html

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# 进入虚拟机拉取，而非本机
minikube ssh

# 拉取镜像
docker pull registry.cn-hangzhou.aliyuncs.com/k8sth/kube-apiserver-amd64:v1.10.0
docker pull registry.cn-hangzhou.aliyuncs.com/k8sth/kube-controller-manager-amd64:v1.10.0
docker pull registry.cn-hangzhou.aliyuncs.com/k8sth/kube-scheduler-amd64:v1.10.0
docker pull registry.cn-hangzhou.aliyuncs.com/k8sth/etcd-amd64:3.1.12
docker pull registry.cn-shenzhen.aliyuncs.com/kubernetes_google/kubernetes-dashboard-amd64:v1.10.0

# 修改 tag
docker tag registry.cn-hangzhou.aliyuncs.com/k8sth/kube-apiserver-amd64:v1.10.0 k8s.gcr.io/kube-apiserver-amd64:v1.10.0
docker tag registry.cn-hangzhou.aliyuncs.com/k8sth/kube-controller-manager-amd64:v1.10.0 k8s.gcr.io/kube-controller-manager-amd64:v1.10.0
docker tag registry.cn-hangzhou.aliyuncs.com/k8sth/kube-scheduler-amd64:v1.10.0 k8s.gcr.io/kube-scheduler-amd64:v1.10.0
docker tag registry.cn-hangzhou.aliyuncs.com/k8sth/etcd-amd64:3.1.12 k8s.gcr.io/etcd-amd64:3.1.12
docker tag registry.cn-shenzhen.aliyuncs.com/kubernetes_google/kubernetes-dashboard-amd64:v1.10.0 k8s.gcr.io/kubernetes-dashboard-amd64:v1.10.0

Kubenetes

指引：https://kubernetes.io/docs/setup/minikube/#quickstart

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
# 在代理下运行时，需要指定正确的代理，否则 minikube 在内部访问网络会有问题
# 注意，代理地址应当是在虚拟机中能够访问的地址，不能使用 127.0.0.1、localhost 这种
https_proxy=http://web-proxy.oa.com:8080
minikube start \
    --docker-env http_proxy=http://web-proxy.oa.com:8080 \
    --docker-env https_proxy=http://web-proxy.oa.com:8080 \
    --docker-env no_proxy=192.168.99.0/24
    --vm-driver=none

# 安装和启动过程中可能产生错误，通过该命令查看日志
minikube logs -f

# 启动 k8s（ CentOS 上不使用任何 vm 驱动，MAC 上默认可使用 VirtualBox）
minikube start \
    --network-plugin=cni \
    --container-runtime=containerd \
    --bootstrapper=kubeadm
    --vm-driver=none

# Dashboard
# https://github.com/kubernetes/dashboard
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/master/src/deploy/recommended/kubernetes-dashboard.yaml
kubectl proxy

# 部署及运行镜像
kubectl run hello-minikube --image=registry.cn-hangzhou.aliyuncs.com/acs/echoserver:1.4 --port=8080

# 导出服务
kubectl expose deployment hello-minikube --type=NodePort

# 查询 Pod
kubectl get pod
kubectl get pods --all-namespaces

# 查看状态
kubectl describe --namespace=kube-system po kubernetes-dashboard-6f4cfc5d87-d647l
kubectl logs kubernetes-dashboard-6f4cfc5d87-x976v --namespace=kube-system
kubectl cluster-info

# 调用服务
curl $(minikube service hello-minikube --url)

# 删除服务
kubectl delete services hello-minikube

# 删除部署
kubectl delete deployment hello-minikube

# 停止 k8s
minikube stop

向 kubernetes 添加账号

https://github.com/kubernetes/dashboard/wiki/Creating-sample-user

FAQ

failed to create kubelet: misconfiguration: kubelet cgroup driver: “cgroupfs” is different from docker cgr…driver: “systemd”

该问题因为 docker 的配置和 kubelet 的配置不一致导致。

使用 docker info 打印 docker 信息：

1
2
3
4
5
6
[root@VM_0_16_centos kubelet.service.d]# docker info | grep Driver
 WARNING: Usage of loopback devices is strongly discouraged for production use. Use `--storage-opt dm.thinpooldev` to specify a custom block storage device.
  WARNING: You're not using the default seccomp profile
Storage Driver: devicemapper
Logging Driver: journald
Cgroup Driver: systemd

而查看 kubelet 服务的启动参数（--cgroup-driver），其设置为 cgroupfs：

1
2
3
4
5
6
7
8
9
10
11
[root@VM_0_16_centos kubelet.service.d]# more /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

[Unit]
Wants=docker.socket

[Service]
ExecStart=
ExecStart=/usr/bin/kubelet --hostname-override=minikube --cluster-domain=cluster.local --cgroup-driver=cgroupfs --authorization-mode=Webhook --client-ca-file=/var/lib/minikube/certs/ca.crt --fail-swap-on=false --kubeconfig=/etc/kubernetes/ku
belet.conf --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --pod-manifest-path=/etc/kubernetes/manifests --allow-privileged=true --cluster-dns=10.96.0.10 --cadvisor-port=0

[Install]

此时，修改 docker 的服务参数（vi /usr/lib/systemd/system/docker.service），将其中的 --exec-opt native.cgroupdriver 参数值改为 cgroupfs 。

然后，重启 docker，重启 kubelet

1
systemctl daemon-reload && systemctl restart docker && systemctl restart kubelet

[ERROR FileContent–proc-sys-net-bridge-bridge-nf-call-iptables]: /proc/sys/net/bridge/bridge-nf-call-iptables contents are not set to 1

解决方案：

1
2
echo 1 > /proc/sys/net/bridge/bridge-nf-call-iptables
echo 1 > /proc/sys/net/bridge/bridge-nf-call-ip6tables

Unable to update cni config: No networks found in /etc/cni/net.d

yum install -y kubernetes-cni

参考

https://www.jianshu.com/p/a42eeb66a19c

发表于

引言

作为一个软件系统，需要写日志，这是不言而喻的，这是大家都会不假思索地说“那当然”的事。不论是什么语言，写日志的专用框架也不一而足，写到文本的，写到数据库的，写到队列的，写到Redis的等等等等。对于日志的几个级别，Trace、Debug、Warning、Error、Fault，大家也能够如数家珍。但是，有多少人能够回答下面这几个问题呢？

为什么需要写日志？
什么时候写日志？
日志是写给谁看的？
日志里都要写什么？
日志的组织形式应该怎样？

接下来，我尝试一一地解答这些问题，说说我的理解。

为什么需要写日志

首先我们要树立一个观点，那就是“不是为了记录日志而记录日志，日志也不是随意记的”。要实现能够只通过日志文件还原整个程序执行的过程，达到能透明地看到程序里执行情况，每个线程每个过程到底执行到哪的目的。日志就像飞机的黑匣子一样，应当能够复原异常的整个现场乃至细节。

作为程序员，我相信吐槽写注释、写文档的段子已经见得很多了。然而在我看来，写日志的重要性完全不亚于前两者，甚至在很多时候，比前两者更为重要。

我们说“软件工程”，很多人只着眼了“软件”两个字，而忽视了“工程”。软件本身是为解决问题服务的，作为一项工程，我们不单要考虑软件本身的开发环节（注释、文档），还应当考虑软件的运营环节（日志）。世界上没有100%完美的事，不存在没有 bug 的软件系统，一旦软件上线，作为开发人员的我们，就不再能够接触到了，如果系统发生了异常，我们却又对系统运行的状态一无所知，那我们就完全没有办法解决问题。有时候重启一下应用，重启一下系统什么的，也能临时解决，但这只是掩耳盗铃，该来的还会再来，出现过的异常，还会在某一天再次出现。

这个时候对“日志”的需求便应运而生。通过日志，记录程序在运行过程中的细节，记录发生异常时的现场，我们便能像庖丁解牛一样，对运行中的应用了如指掌了。

什么时候写日志

所谓“麻雀虽小五脏俱全”，当我们在建构一个软件系统框架时，所谓的几层结构，所谓的基础模块（通用模块、工具模块、数据访问模块……），包括写日志的模块，这些方法都是不用思考，放之四海而皆准的东西，直接搭建/拼凑起来再说。

然后呢？我想很多人就开始闷头做功能了——我是指只写功能代码，完成实际的业务逻辑。在做业务功能的时候，由于现代IDE的调试功能很强大，可以一行一行调试，看到运行状态、变量状态等等，所以此时对日志的需求和功用是极度不敏感，觉得此时可有可无。但是一旦业务功能做完了，基于各种各样的理由，工期紧啊，已经完成功能了啊，就直接转测不再继续完善了。其结果是，功能的确完成了，但是搭建的日志模块却几乎没有使用。完成了整个系统，只有不痛不痒的两三行日志，大多都是在搭建框架时写的“应用启动了”，“应用停止了”一类。后面就不用说了，都说回头补设计文档，有多少人补了？都说回头补注释，有多少人补了？既然已经转测了，既然已经上线了，就更不会再回头去写日志了。

后来，可想而知，当生产环境除了问题，由于没有日志，到底出了什么异常，就两眼一抹黑，没人能知道了。终于，临时解决了问题，意识到日志的重要性之后，急急回头翻出代码来写日志，可是当时做业务的逻辑、思考、陷阱、注意事项等等，都忘记的差不多了，写日志也就只能像看陌生代码一样，看表面，“进入了XXX方法”，“插入数据库完成”，只能写这样的日志了。而在我看来，这样的日志是不够的，这也是我最反感的写日志的方式，完全是为了写而写——也是不足以还原故障现场的，这个后续再说。

说到此可能你应该也看出来的，什么时候写日志是最佳时机呢？那就是在开发功能代码时。可以说，日志本身也是属于功能代码的一部分，只不过业务功能是给最终客户的，而日志是给运维、开发等用的。此时写日志有一个巨大的好处，那就是因为你是一边在思考，一边在开发，那么此时业务流转、可能的异常都会考虑得很完善，写日志的过程，也是反复思考和校验逻辑的过程，也就自然而然地会在日志中体现更多的关键信息。

日志是写给谁看的

  • 当然是给运维了啊，运维能够第一时间看到，比如日志中写端口被占用，马上改个端口就可以了！
  • 当然是给开发了啊，每次系统发生了异常，运维人员不是直接把日志给开发人员一丢就了事了吗？

在我看来，不论是运维，还是开发，再广泛地讲，包括白盒测试，都是需要看日志的。日志对不同的人，都有不同的使用价值。运维通过日志了解到程序基本的安装、环境依赖、加载情况、运行态信息等等；开发通过日志还可以了解到程序对业务处理的信息，每个业务的流程、环节、现场状态等等；白盒测试也可以通过日志了解到程序要求的非功能特性等等。

日志里都要写什么

明确了“为什么要写日志”和“日志写给谁看的”了之后，要回答“日志里都要写什么”就容易得多了。我们需要从多个侧面来想这个问题。

考虑使用者

正如前文说，日志可能面向运维、面向开发等等不同身份的人群。因此日志的内容上，就要为不同的人写入其关切的入不同内容。

考虑业务

这里的“业务”可能不一定是最终用户的业务，也可能是中间态的业务逻辑。当业务处理出现问题时，到底是程序的bug造成，还是错误的数据造成，或者是硬件、网络等资源的问题造成，这些都应当能够从日志中分析得出来。

一段日志，应当能够对故障现场的每一个细节都能在大脑思维里复盘。同时，日志不单单像流水账一样记录程序的运行过程，每行日志还不应该是孤立的，还应当是一个有机的整体，是有上下文的，有头有尾的。比如下面这一段日志：

log-example

日志中记录了一些关键事件以及一些关键信息。比如什么时候侦测到了新消息，有几个Handler可以去处理，每个Handler对应了哪个线程，每个线程对应在处理那种消息；有了某个处理过程的开始，就应当有对应的结束，如果涉及到多线程，还应当能够区分两行同样的日志，对应的不同线程和不同业务单据等等。而不仅仅是“侦测到消息”，“开始处理”，“处理完毕”这种简单的记录。

考虑运营

对于业务，一般我们需要后续的分析和运营，日志在这方面也有起到较大作用，因此这部分日志应当考虑以结构化、规范化的方式来记录，从而方便后续对日志进行自动化分析。

考虑生命周期

那么日志是越详细越好，记录得越多越好吗？是。也不是。

每一个软件系统都是有一定的生命周期的。刚测试上线的软件，一般最不稳定，最容易出现各种这样那样的问题，此时日志应当详细些。而长期运行了很久的软件，经过了时间、业务的大量考验，该出现的bug也已经修复得差不多了，几乎不会再出现什么问题，日志应当少一些。

怎么实现呢？很显然我们不能通过改代码，去掉写日志的代码之后重新发布来做这件事。常规地，我们通过日志分级来应对这个问题。通过不同的日志分级，以及日志输出开关，实时地调整日志输出的细节程度。因此，在我们编写输出日志的代码时，就务必要注意即将输出的日志应当是什么级别。Trace、Debug、Warning、Error、Fault，这些级别，应当对应不同重要程度、不同使用场景的细节。

考虑了以上三个方面，在开发完成之后，我们还应当切换不同的身份、角度以及配置不同的日志输出级别，来“设身处地”地审视输出的日志文件，是否能够满足要求，这样才能写一份好的日志记录。

日志的组织形式应该怎样

既然叫“日志”，那我们通常的组织形式变是以时间为顺序来组织的一系列文件。除此之外，还可以将日志写入数据库、外部分析系统等等。

考虑“Separation of Concerns”，日志的组织形式，也可以根据上文考虑的不同方面来组织，比如将Error及以上的日志冗余独立记录，将面向运维的启停、加载信息独立记录，将软件运行日志和业务处理日志分开记录等等。关键是“Concern”，编写记录日志的代码时，我们应该对这段代码的功能、重要性、在整个系统的角色有深刻的认知，从而才能以不同的“关切”来考虑日志应该怎么输出，怎么组织。

综上

当然，根据软件系统的不同，其日志的侧重点也可能不同。但总体来说，日志就如同飞机的黑匣子一样重要，我们应当重视日志输出的编写工作，而绝非仅仅是完成核心业务代码的编写。

发表于

以下以 VS 的编译工具包为例，实际上 VS IDE 本身也可以如此进行。

一、下载在线安装文件

  1. 进入下载页：https://www.visualstudio.com/zh-hans/downloads/
  2. 选择最底部的 Other Tools and Frameworks -> Visual Studio 2017 生成工具 并下载。
  3. 以管理员身份运行刚刚下载的在线安装文件，注意带参数：--layout "F:\software\VS2017 BuildTool\Offline" --lang zh-CN

此时将开始下载安装所需文件：（如果断电断网或者关闭了下载窗口，没关系，输入命令重头来过，还是会继续下载的）

二、离线安装

  1. 打开刚刚存放离线文件的路径，然后找到certificates文件夹并打开，依次安装该文件夹下的软件证书。

  2. 运行离线根目录下的安装程序，各版本位置如下：

    • 企业版：离线文件存储文件夹\vs_Enterprise.exe
    • 专业版：离线文件存储文件夹\vs_Professional.exe
    • 社区版：离线文件存储文件夹\vs_Community.exe

参考

https://docs.microsoft.com/zh-cn/visualstudio/install/create-an-offline-installation-of-visual-studio

https://www.ithome.com/html/win10/297093.htm

发表于

初中时，在电视里看office学习节目，对电脑无比神往。高二时，第一次开电脑上机课，两个人一台机学开机关机等基本操作，激动得大腿肌肉颤抖，在凳子上坐不住，坐两分钟蹲几分钟马步，实在会发抖，过了十几分钟才坐的住。这就是快感。

大学时，左边放着个水杯，码一阵代码后开启调试的间歇喝一口水，结果杯里的水喝完了，举着空杯喝一口空气。杯子放下继续码代码，直到第二次…第N次举着空水杯喝空气之后，仍然没有去把杯子续上，然而续水很远吗？不，水壶就在右手边。这就是快感。

临毕业，自己写一个博客程序，生生推倒重写3次，每一次都是质变。期间一个结构设计问题思考酝酿了很久，最终是半夜做梦突然来了灵感醒来，兴奋的再也睡不着了，马上一个激灵起来实现。整个博客程序完成之后无意看到了head first设计模式，各种我操我操的感叹，尼玛怎么跟我想的一样？这就是快感。

毕业后，特别是做自己的练手项目，无论白天黑夜，总跟自己说，这个问题5分钟就能解决，然而第N个5分钟过去了，需求已经早扩大得无边无际了，还在继续，直到天亮仍然放不下。这就是快感。

这个清明节，做了两个 visual studio 插件，三天假两天都是凌晨5点睡觉的。刚刚才收到无警告报告（手上的项目每几个小时会上报运营报告，凌晨2点是个check point），一抬头，天就亮了。这就是快感。

非计算机专业，纯自学一路走来，唯有这快感激励我走到今天，提供我码每一行代码的动力。这么多年来，很多朋友、同事接私单业余做也收益可观，但我只做过两个帮忙性质的单子，是的，十年只两个。摸着良心说，挣钱还真不是我码代码的第一原因——虽然做过的小产品已经很多了，但从来都没有转化为经济。我还买不起房，并不是来体验生活的富二代。

这种示例还很多…五指朝上地说，没有半句虚言。

快感，就是着了魔。

发表于

高性能

业务方面

  • 将同步业务转化为异步业务
  • 业务分级，柔性可用
  • 减少不必要的数据库请求
  • 业务解耦，降低关联性

应用方面

  • 前端高性能设计（略）
  • 使用缓存：多级缓存、分布式缓存
  • 预加载、懒加载、延迟初始化
  • 尽量减小交互接口数据包大小
  • 尽量减少序列化、对象克隆
  • 尽量减少跨进程、跨机器、跨网络访问
  • 尽量减少在同步业务中使用事务
  • 尽量减少锁的使用
    • 使用乐观锁
    • 尽量缩小锁的范围
    • 尽量将低性能逻辑放到锁的范围之外
  • 使用异步逻辑
  • 队列削峰，先接受，后处理
  • 尽量复用
    • 线程：线程池
    • 连接：长连接、连接池

数据库方面

  • 数据库读写分离
  • 优化 SQL 语句、表结构、索引等

硬件及部署方面

  • 负载均衡
  • 分离应用服务器和数据库服务器

高可用

业务方面

  • 快速拒绝：尽早拒绝不符合策略的请求
  • 灰度推广、灰度上线：按部门、分时段
  • 服务分级，柔性可用

应用方面

  • 自动重试机制
    • 单点重试
    • 多点重试
  • 超时机制
  • 幂等设计
  • 无状态设计
  • 容错机制
    • 登录时，创建 Staff 抛出“该员工不存在”
  • 提高编码质量，减少异常
  • 完善的测试准出
    • 功能
    • 性能

运维方面

  • 状态报告及预警
    • KeepAlive
  • 资源报告及预警
    • CPU、内存、硬盘、IO
  • 业务报告及预警
    • QPS、TPS、SQL查询
    • PV、UV
  • 日志

硬件及部署方面

  • 核心业务与非核心业务分开部署
  • 负载均衡、双机热备、主备
  • 异地多活

其他

  • 先思考，后动手。多思考，少蛮干。
  • 严格要求自己，将出手的产品当做孩子一样对待