如何写出优雅的 Golang 代码

发布于
https://draveness.me/golang-101

评论

发表评论

此博客中的热门博文

打造一个可国内访问的Blogger（Blogspot）方法

发布于
  Blog‍‌‍‌​‌‌‌‌​‌​‍‌​‍‌‍‍​‌‌‍‌​‌‍​‍‌​​‍‌‌‌​‌‍‌‌​‍‍‍​‍‍‌​​‍‌‍‌​‍‌‍‍​‌‌‍‌​‌‍​‍‌​​‍​‍‍‍​‌‍‍‌ger,一个干爽、免费的博客发布平台，作为主流的发布，提供免费的托管，免去了Typecho&Wordpress高昂的服务器费用，避免了Hexo&Jekyll静态博客无后台的缺陷，与CSDN、简书相比，可以绑定域名，界面干净，无广告【当然可以自己放自己的广告】。 实际上，当今写博客的软件数不胜数，主要分为一下三类： 服务器部署：典型代表：Wordpress\Typecho 无服务器托管：典型代表：Hexo\Jekyll\Gidea\Hugo\Hola等等 集成型网站：Blogger、简书、CSDN、cnblog、wodemo等等 上面所有软件，优缺点都有，具体看个人选择 当然，个人认为Typecho适合做个人博客，Hexo可以作为要求不高的人。集成性网站最主要的是只要安安心心写文章，不用管后端乱七八糟的代码。当然，最有问题的是大多数都不支持绑定域名，而且经常往网站上塞广告，自定义范围也不够。 接下来，我们扯扯集成博客中的一股清流：Blogger Blogger.com是由Pyra Labs公司创立，是目前全球用户数量最多的个人网志服务提供商。Pyra Labs和Blogger.com均被Google公司收购，成为其旗下的一项服务内容。 Blogger提供免费主机Blogspot.com存放博客，用户不必写任何代码或者安装服务器软件或脚本，通过所见即所得界面轻松地创建、发布、维护和修改自己的网志。 Blogger允许有经验的用户自行设计博客界面，其模板支持使用HTML和CSS进行编辑 实际上，由于Blogger托管于谷歌，写作域名  www.blogger.com  和托管域名  *.blogspot.com  均被MainLand所Ban。但是接下来来，我会讲讲如何打造一个能在国内大陆访问的Blogger 1. 注册Blogger 众所周知，请善用技术上网。 用谷歌账号登录 ( https://www.blogger.com ) ，没有？不是⑧不是吧不是扒，都0202年了，还不会去注册一个谷歌账号？ 进入控制台，新建一个博客： 绑...
阅读全文

ELK实时日志分析平台环境部署--完整记录

发布于
在日常运维工作中，对于系统和业务日志的处理尤为重要。今天，在这里分享一下自己部署的ELK（+Redis）-开源实时日志分析平台的记录过程 （仅依据本人的实际操作为例说明，如有误述，敬请指出） ~ ================概念介绍================ 日志主要包括系统日志、应用程序日志和安全日志。系统运维和开发人员可以通过日志了解服务器软硬件信息、检查配置过程中的错误及错误发生的原因。经常分析日志可以了解服务器的负荷，性能安全性，从而及时采取措施纠正错误。 通常，日志被分散在储存不同的设备上。如果你管理数十上百台服务器，你还在使用依次登录每台机器的传统方法查阅日志。这样是不是感觉很繁琐和效率低下。当务之急我们使用集中化的日志管理，例如：开源的syslog，将所有服务器上的日志收集汇总。 集中化管理日志后，日志的统计和检索又成为一件比较麻烦的事情，一般我们使用grep、awk和wc等Linux命令能实现检索和统计，但是对于要求更高的查询、排序和统计等要求和庞大的机器数量依然使用这样的方法难免有点力不从心。 通过我们需要对日志进行集中化管理，将所有机器上的日志信息收集、汇总到一起。 完整的日志数据具有非常重要的作用： 1）信息查找 。通过检索日志信息，定位相应的bug，找出解决方案。 2）服务诊断 。通过对日志信息进行统计、分析，了解服务器的负荷和服务运行状态，找出耗时请求进行优化等等。 3）数据分析 。如果是格式化的log，可以做进一步的数据分析，统计、聚合出有意义的信息，比如根据请求中的商品id，找出TOP10用户感兴趣商品。 开源实时日志分析ELK平台能够完美的解决我们上述的问题， ELK由ElasticSearch、Logstash和Kiabana三个开源工具 组成： 1）ElasticSearch 是一个基于Lucene的开源分布式搜索服务器。它的特点有：分布式，零配置，自动发现，索引自动分片，索引副本机制，restful风格接口，多数据源，自动搜索负载等。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。Elasticsearch是用Java开发的，并作为Apache许可条款下的开放源码发布，是第二流行的企业搜索引擎。设计用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。 在ela...
阅读全文

CentOS 7 下安装KVM和WebVirtCloud管理面板

发布于
写在前面 本教程依据官方Wiki和现有教程以及自身实践编写而成，更正了官网Wiki的部分错误并简化了内容，适合一把梭操作，转载请标注来源。 WebVirtCloud 开源地址: https://github.com/retspen/webvirtcloud 感谢 @a350064 KVM安装 检查环境是否支持KVM cat /proc/cpuinfo | egrep 'vmx|svm' 若环境支持则有内容返回 关闭SELinux vi /etc/sysconfig/selinux 修改   SELinux=enforcing   为   SELinux=disabled 安装KVM环境 使用yum软件包管理器进行安装 yum -y install qemu-kvm python-virtinst libvirt libvirt-python virt-manager libguestfs-tools bridge-utils virt-install 检查KVM模块是否被加载 lsmod | grep kvm 若被正确加载则返回如下 kvm_intel 249856 0 kvm 655360 1 kvm_intel irqbypass 16384 1 kvm 配置 libvirt 启用TCP服务 命令行输入: LIBVIRTD_CONFIG=/etc/libvirt/libvirtd.conf LIBVIRTD_ARGS="--listen" 修改   /etc/sysconfig/libvirtd   文件 去除   LIBVIRTD_ARGS="--listen"   前的#号 修改   /etc/libvirt/libvirtd.conf   文件 listen_tls = 0 listen_tcp = 1 tcp_port = "16509" auth_tcp = "none" 若为单机运行则需修改为   listen_addr = "127.0.0.1" 否则需修改为 listen_addr = "0.0.0.0" 开启服务并...
阅读全文

Linux测试端口的连通性的四种方法

发布于
Linux系统有时候需要测试某个端口的连通性，用户可以参考如下方法来测试。 方法一、telnet法  telnet为用户提供了在本地计算机上完成远程主机工作的能力，因此可以通过telnet来测试端口的连通性，具体用法格式： telnet ip port 说明： ip： 是测试主机的ip地址 port： 是端口，比如80 如果telnet连接不存在的端口，那会如下图所示。 如果telnet 连接存在端口会出现如下图所示的内容，下图中以80端口为例。 方法二、ssh法 SSH 是目前较可靠，专为远程登录会话和其他网络服务提供安全性的协议,在linux上可以通过ssh命令来测试端口的连通性，具体用法格式如下： 用法: ssh -v -p port username@ip 说明： -v 调试模式(会打印日志). -p 指定端口 username: 远程主机的登录用户 ip: 远程主机 如果远程主机开通了相应的端口，会有如下图所示的建立成功的提示。 如果远程主机没有开通相应的端口，则如下图所示 方法三、curl法 curl是利用URL语法在命令行方式下工作的开源文件传输工具。也可以用来测试端口的连通性，具体用法: curl ip:port 说明： ip ：是测试主机的ip地址 port： 是端口，比如80 如果远程主机开通了相应的端口，都会输出信息，如果没有开通相应的端口，则没有任何提示，需要CTRL+C断开。 方法四、wget方法 wget是一个从网络上自动下载文件的自由工具 ，支持通过HTTP、HTTPS、FTP三个最常见的TCP/IP协议下载 ，并可以使用HTTP代理。wget名称的由来是 “World Wide Web”与“get”的结 合，它也可以用来测试端口的连通性具体用法: wget ip:port 说明： ip： 是测试主机的ip地址 port： 是端口，比如80 如果远程主机不存在端口则会一直提示连接主机。 如果远程主机存在端口则会看到相应的信息，如下图所示。 来源：https://www.jb51.net/LINUXjishu/558029.html
阅读全文

从零开始学习iftop流量监控（找出服务器耗费流量最多的ip和端口）

发布于
一、iftop是什么 iftop是类似于top的实时流量监控工具。 作用：监控网卡的实时流量（可以指定网段）、反向解析IP、显示端口信息等 官网： http://www.ex-parrot.com/~pdw/iftop/ 二、界面说明 =>代表发送数据，<= 代表接收数据 TX：发送流量 RX：接收流量 TOTAL：总流量 Cumm：运行iftop到目前时间的总流量 peak：流量峰值 rates：分别表示过去 2s 10s 40s 的平均流量 三、常用参数 -i 指定需要检测的网卡， 如果有多个网络接口，则需要注意网络接口的选择，如：# iftop -i eth1 -B 将输出以byte为单位显示网卡流量，默认是bit -n 将输出的主机信息都通过IP显示，不进行DNS解析 -N 只显示连接端口号，不显示端口对应的服务名称 -F 显示特定网段的网卡进出流量 如iftop -F 192.168.85.0/24 -h 帮助，显示参数信息 -p 以混杂模式运行iftop，此时iftop可以用作网络嗅探器 ; -P 显示主机以及端口信息 -m 设置输出界面中最上面的流量刻度最大值，流量刻度分5个大段显示 如：# iftop -m 100M -f 使用筛选码选择数据包来计数 如iftop -f filter code -b 不显示流量图形条 -c 指定可选的配置文件 如iftop -c config file -t 使用不带ncurses的文本界面， 以下两个是只和-t一起用的： -s num num秒后打印一次文本输出然后退出，-t -s 60组合使用，表示取60秒网络流量输出到终端 -L num 打印的行数 -f 参数支持tcpdump的语法，可以使用各种过滤条件。 四、进入界面后的操作 一般参数 P 切换暂停/继续显示 h 在交互界面/状态输出界面之间切换 b 切换是否显示平均流量图形条 B 切换显示 2s 10s 和 40s 内的平均流量 T 切换是否显示每个连接的总流量 j/k 向上或向下滚动屏幕显示当前的连接信息 f 编辑筛选码 l 打开iftop输出过滤功能 ，如输入要显示...
阅读全文

编写 docker-entrypoint.sh 入口文件

发布于
在 docker 的官方 Registry 中(store.docker.com) 流行的第三方应用在自己的页面中都提供了 dockerfile 的链接. 而很多 dockerfile 的 ENTRYPOINT 命令都是这么写的 ["docker-entrypoint.sh"] 本篇文章就扫盲下 docker-entrypoint.sh 的特殊用法和设计逻辑 MySQL set -e 你写的每个脚本都应该在文件开头加上 set -e , 这句语句告诉bash如果任何语句的执行结果不是 true 则应该退出. 这样的好处是防止错误像滚雪球般变大导致一个致命的错误, 而这些错误本应该在之前就被处理掉. 如果要增加可读性, 可以使用 set -o errexit , 它的作用与 set -e 相同 set -o pipefail 设计用途同上, 就是希望在执行错误之后立即退出, 不要再向下执行了. 而 -o pipefail 的作用域是管道, 也就是说在 Linux 脚本中的管道, 如果前面的命令执行出了问题, 应该立即退出 shopt -s nullglob 在使用 Linux 中的通配符时 * ?等 如果没有匹配到任何文件, 不会报 No such file or directory 而是将命令后面的参数去掉执行 if [ “${1:0:1}” = ‘-‘ ]; then… 这是一个判断语句, 在官方文件中, 上一行已经给出了注释: if command starts with an option, prepend mysqld 这个判断语句是 ${1:0:1} 意思是判断 $1(调用该脚本的第一个参数), 偏移量0(不偏移), 取一个字符(取字符串的长度) 如果判断出来调用这个脚本后面所跟的参数第一个字符是 - 中横线的话, 就认为后面的所有字符串都是 mysqld 的启动参数 上面的这个操作类似于 Python 的字符串切片 set – mysqld “$@” 在上面判断完第一个参数是 - 开头之后, 紧接着就执行了 set -- mysqld "$@" 这个命令. 使用了 set -- 的用法. set — 会将他后面所有以空格区分的字符串, 按顺序分别存储到$1,...
阅读全文

一个轻量级通用的数据同步方案

发布于
在不同的数据库系统之间做数据同步是大数据领域里常见的需求。一个典型的场景是，业务系统因为需要事务和随机查询，一般会使用 MySQL 这种数据库；数据仓库使用 Hive；ETL 之后的结果再放到 MySQL、AWS Redshift 等系统给 BI 和报表工具使用。 首先梳理一下需求和目标： 实时性：非实时，离线同步，一般为 T+1，或最细到小时粒度 扩展性：需要支持多种异构数据源，如 MySQL, Hive, ElasticSearch 等 性能要求：因为是离线系统，对性能要求无严格要求，但最好尽可能快，并有可能调优 复杂度：复杂度低，依赖少，易使用，易运维 功能要求：要满足全量同步和增量数据同步 解决方案 数据同步并不是一个特殊的问题，简化一下其实就是两个操作：读和写。与之类似的是数据库备份和恢复，很多数据库系统都自带这种工具，比如 MySQL 的 mysqldump 和 mysqlimport ，MongoDB 的 mongodump 和 mongorestore 等。这些工具一般为了性能而使用特殊的编码格式，不会考虑通用性。但一个通用的数据同步系统，可以采用同样的思路来实现。 上图描述的就是本文的解决方案，即把读写拆分，通过 CSV 文件来过度。 扩展性 这种设计的核心是把数据同步抽象成导出（读）和导入（写）两个过程，完全解耦，因此具有很好的扩展性。每种数据源只需要实现读写两种操作即可。以常见的数据源为例，看看分别如何实现从 CSV 导入数据（导出到 CSV 很容易，使用任意编程语言都可实现）。 数据源 导入 CSV MySQL 使用 LOAD DATA LOCAL INFILE 批量加载，或读取文件运行 INSERT 语句 AWS Redshift 以 AWS S3 为中转，使用 COPY 命令批量加载 Hive 建表时指定 Serde 为 org.apache.hadoop.hive.serde2.OpenCSVSerde ，或者在导入前把 CSV 先转换成默认的 TEXTFILE 格式；然后使用 LOAD DATA [LOCAL] INPATH 批量加载。 ElasticSearch 读取文件，批量插入 FTP, AWS S...
阅读全文

kubernetes中部署mysql高可用集群

发布于
很多软件后端使用的存储都是mysql，当这些软件系统在生产环境部署时，都会面临一个严峻问题，需要在生产环境中部署一个高可用的mysql集群服务。刚好在最近一周的工作中，需要在kubernetes环境中搭建mysql高可用集群，这里记录一下。 搭建MySQL集群 MySQL的主从半同步复制方案、Galera集群方案以前都也实践过，感觉都不是太友好，配置比较麻烦，而且发生故障转移时经常需要人工参与。所以这里还是采用MySQL官方推荐的Group Replication集群方案。关于MySQL Group Replication集群的架构设计可以看 官方文档 ，懒得看英文的话，也可以看我之前整理出的 资料 。另外kubedb网页上也有介绍 MySQL几种高可用方案的构架方案 ，也比较有意思。 之前的博文 也讲过在非容器环境搭建MySQL Group Replication集群，现在在Kubernetes的容器环境配合kubedb，搭建更方便了，命令如下： 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 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 # 添加appscode的helm仓库 $ helm repo add appscode https://charts.appscode.com/stable/ $ helm repo update # 部署kubedb $ helm install appscode/kubedb --namespace kube-system --name kube...
阅读全文

如何去做code review

发布于
Google 前几天公开了一篇谷歌的工程实践文档。而且文档的内容都是跟 code review 相关的内容，里面包含了 Google 工程师如何进行 code review 的内容，以及 code review 指南。 原文地址: google.github.io/eng-practic… 本文的名词解释： cr: code review cl: change list，指这次改动 reviewer: cr的那个review人 nit: 全称nitpick，意思是鸡蛋里挑骨头 作者: 也就是本次CL的开发者，原文中是以author来称开发者的。以老外的思维，意思是“CL的作者” 如果嫌文章太长，可以直接到 后面 看总结 cr的标准 cr(Code review)主要目的在于确保Google 的代码库代码质量越来越好。而所有相关的工具与流程皆是因应这个目的而生。为达到此目的，势必需要做出一连串的权衡与取舍 首先，开发人员必须能够在自己负责的任务上有所进展。如果你从来没有向代码库提交改进过的代码，那么代码库就永远不会改进。另外，如果一个reviewer使cr都很难进行的话，那么开发人员就不愿意在将来进行改进。 另一方面，reviewer有责任确保每个change list（ 下称CL ）的质量，保证其代码库的整体代码质量不会越来越差。这可能很棘手，因为通常会随着时间的推移，代码需要降级才能让代码运行起来，特别是当团队受到严重的时间限制时，大家觉得必须走捷径才能实现他们的目标。 此外，reviewer对他们正在review的代码拥有所有权和责任。他们希望确保代码保持一致、可维护，以及下文的“ 在cr中可以得到什么 ”中提到的内容。 因此，我们有以下规则，作为我们在cr中所期望的标准： 一般来说，当CL存在的时候，reviewer应该赞成它，此时它肯定会提高正在工作的系统的整体代码质量，即使这个CL并不完美。这是所有cr中的首要原则。当然，这是有局限性的。例如，如果一个CL添加了一个reviewer不希望在其系统中使用的功能，那么reviewer当然可以拒绝，即使代码设计得很好。 这里的一个关键点是，没有“完美”的代码，只有更好的代码。reviewer不应该要求作者在approve之前对一篇文章的每一小段进行润色。相反，revie...
阅读全文