Lenky个人站点

一，测试环境 $ cat /etc/issue Ubuntu 18.04.3 LTS \n \l $ uname -a Linux lenky-virtual-machine 5.0.0-27-generic #28~18.04.1-Ubuntu SMP Thu Aug 22 03:00:32 UTC 2019 x86_64 x86_64 x86_64... [阅读更多]

之前提到Netdata是一款不错的Linux实时监测工具，而本文提到的Prometheus是由谷歌研发的一款开源的监控软件，采用Go语言开发，使用者众多，据说很牛掰。 一，测试环境 $ cat /etc/issue Ubuntu 18.04.3... [阅读更多]

利用dlopen/dlsym/dlclose等接口可以在C语言程序中实现模块动态加载功能，Nginx就有这样的实现。在Go v1.8版本之前，可以利用一些开源项目来实现类似的功能(见参考链接)，但在Go... [阅读更多]

Netdata是一款不错的Linux实时监测工具，可以用来检测性能，也可以用来检测健康状态，具备Web形式的可视化展示界面。 当然，最重要的点是Netdata程序核心采用C语言编写，因此效率高，资源占用也相对较少。还有一些其他特性，请参考github链接。不过值得注意的是，Netdata是GPL授权，所以需要考虑下版权影响。 下面直接在Ubuntu测试环境里试用下Netdata。 一，测试环境 $... [阅读更多]

最近若有空就在时不时的翻看rpcx源码，期间看到一个有趣的工程： https://github.com/soheilhy/cmux 为什么说它有趣，因为在产品里也有实现过类似的功能，即端口多路复用功能，也就是说可以在同一个端口(比如tcp:8881端口)，监听多个不同服务(比如SSH和HTTPS等)，这带来的直接好处就是减少了对外开放端口个数，对安全、运维、管理来说都是有益的。 原理也简单，主要是特征匹配和文件描述符传递。首先，启动各个业务服务。然后，启动代理程序proxy并监听指定的端口(比如tcp:8881)。当连接过来后，代理程序proxy会对连接首包进行特征匹配，根据匹配结果将accept到的文件描述符传递到对应的业务服务。至此，后续该连接上的数据发送就直接由业务服务处理，不再经过proxy。可以看到，如果是长连接，在性能上的损耗并不大，因为只有首包要经过proxy。cmux属于这种方案。 还有一种方式是，所有数据都经过proxy，由proxy负责转发，也就是所谓的反向代理，此时可以在proxy里做一些通用的认证，安全检测等功能，但会有性能瓶颈的风险。 Over~ 参考： 1，https://github.com/soheilhy/cmux 2，https://www.sohu.com/a/341135783_657921 ... [阅读更多]

一，下载go语言支持包 下载地址：https://www.sourceinsight.com/pub/languages/golang.xclf 二，打开Source Insight... [阅读更多]

看到一篇有意思的文章，Mark下。 We’re right and the rest of the world is wrong. We (that is Erlang folks) are solving the right problem, the rest of the world (non Erlang people) are solving the wrong problem. 具体在这：《谈谈... [阅读更多]

网络上已经有很多介绍这方面的文章，可以查看参考或自行Google关键字”服务发现和负载均衡”，但我这里仍然做个Mark，毕竟这是微服务架构中极其重要的内容。 总结来看，客户端如何发现服务端只有两种方式，要么直接把服务端的地址告诉客户端，要么把一个第三方(也就是代理)的地方告诉客户端，然后让客户端去询问这个第三方其所需要的服务端地址在哪里。 直接告诉的方式不用讨论，因为很简单，而利用代理的方式稍显复杂，根据代理所处的不同部署位置而区分出不同的模式。 最经典的模式就是传统集中代理模式(Proxy... [阅读更多]

客户端与服务端要进行通信，至少得有一方知道另外一方的地址才行(一般是客户端知道服务端的监听地址)，比如在这篇文章http://lenky.info/?p=2840中的101basic示例里，就是在客户端和服务端的代码里直接硬编码(hardcode)了服务器的监听地址(localhost:8972)，从而客户端才能请求到服务端的服务。 直观来看，硬编码方式有很大缺点，比如如果服务地址发生变化则需要修改源码进行重新编译或启动。因此，一种改进的办法是服务端将服务地址放到配置文件，而客户端从配置文件中获取到对应的服务地址。基于这种思想，就有了服务注册与服务发现，即服务端(服务提供方)将提供服务的地址注册到服务注册中心，而客户端(服务请求方)则从服务注册中心获取服务地址，这种动态的管理方式无疑更加灵活且更加适应现在的云计算环境。 服务注册中心可以由很多软件来充当这个角色，在极其简单的环境下，文件系统(用配置文件存储服务地址)其实就可以，当然，考虑到高可用与一致性，可以有更好的选择，比如etcd等。 仍然是老套路，下面试用下rpcx结合etcd来做的服务注册与发现示例。 一，测试环境 二，安装Go环境 三，安装rpcx 四，下载测试代码 1，直接安装测试工程 $... [阅读更多]

前段时间看了下分布式RPC框架brpc，这两天在找分布式服务框架，也就是除了RPC功能外，期望还能有服务发现和服务治理的功能，经典的开源框架有dubbo，之前据说这货在阿里的团队都解散了(15年)，后来又据说开始维护了(17年底。具体见这里：https://www.zhihu.com/question/30884501，https://github.com/apache/dubbo)，但我想找个Go语言的类似框架，Google了下，发现有个rpcx(还有些其他框架，比如go-micro等)，看上去挺不错，而且是国人开发的，主要贡献者在微博工作(见参考)。 老套路，还是先试用下rpcx。 一，测试环境 $... [阅读更多]