5 31
consul集群搭建与Golang服务发现示例

传统单机应用动态性不强,不会频繁地更新和重新发布,也较少地进行自动伸缩。但随着互联网分布式系统的普及,服务与服务之间的伸缩性和可扩展性的要求也越来越大。为了满足服务的垂直和水平的扩张,以往一般使用预定义的端口配置服务,当新的服务需要上线或当期服务需要冗余扩展的时候,我们需要静态化地“注册”相关ip与端口信息到一个地方,再通过程序之间定时“更新”的方法去同步信息,但这种手段问题是非常多的,例如我们需要连接kafka的master的时候,如果服务信息发生变更,客户端是很难知道的。其中一个简单粗暴的方法是配置hosts文件,使用预定义的“域名”作为服务的连接依据,但这样也是麻烦的,服务变更的时候,要手动更改hosts文件,当服务器上的服务相对多的情况下,维护量就想当恐怖了。

其实就一句话:服务多,问题多

5 4
golang reflect实践

之前看过很多Go技术的文章和一些技术群里面的交流,主流意见都是认为反射(reflect)是导致性能的主要元凶,叫开发者少用为妙;主要是他们使用反射的业务场景离不开下面的情况:

  • reflect涉及到内存分配以及后续的GC

  • reflect实现里面有大量的枚举,也就是for循环,比如类型之类的

一开始我也“遵循”的,直到最近项目需要,越来越多的场景需要用到反射机制才能灵活应对,毕竟某些情况某些情景下性能不是特别高的要求,模块的灵活性扩展性(够有能力处理各种输入类型,而这些类型可能无法共享同一个接口,也可能布局未知)才是占据重要的位置。反射不但指计算机程序在运行时(Run time)可以访问、检测和修改它本身状态或行为的一种能力,也是元编程的一种形式,我们常见的RPC库或者一些ORM框架基本都是使用反射来实现核心的功能,所以本文主要是最近使用反射的一些总结

4 27
如何把panic信息重定向

根据“墨菲定律”,我们编写的后台的服务都有出现crash的可能,一种情况是Go的后台服务我们经常也会遇到panic的情况。出问题不可怕,我们需要分析并解决问题,不过panic处理的信息,默认是直接标准输出的,我们希望能捕获它指向我们特定的文件以便能做后续问题的跟踪排查,而不是一次性输出难以跟踪。

4 24
使用Go开发一个简单反向代理服务

最近,团队的小伙伴反映,我们这边一个短连接服务在一台普通的服务器上吞吐量受到限制,所以把服务迁移到高性能机器上,虽然硬件是数倍的提升但压测发现吞吐量并没有预期的效果。

结合后台服务本身的特点初步原因分析:

  • 1、从下往上看:服务属于计算IO密集型,性能瓶颈多在于计算请求,但高配机压测过程中,受到单实例模块之间通讯采用串行调用的特点,虽然单点请求计算性能有很大提速,但总体并行上不去,CPU利用率低

  • 2、从上往下看: 吞吐量受服务器的接受能力影响很大,由于短连接接入层目前只有一个实例,无论部署在中配或是高配,除非是多实例模式或者类似nginx这种多worker工作模型,一般情况下,单实例accept的效果有限,高并发时容易成为瓶颈

  • 3、从服务进程的角度看,单个web api的请求accept队列(backlog)是有限制的,如果多实例部署也许能补短。

分析到这里,很多人都想到可以通过扩容+分布式通讯的方式来弥补短板。是的,方法是摆在面前,但是你想到一个方法不难,难的是你要如何去验证你的想法。毕竟对于一个成熟的产品技术框架,不是随便都能重构的,一定要数据说话。

不过如何调优不是本文的目的,本文的目的是如何使用Go来快速实现一个反向代理服务来验证前面的背景想法。

后一页