有赞发号器多机房方案

有赞发号器多机房方案 发号器一般用来产生全局唯一 ID,有赞发号器的设计及背景参见文章《如何做一个靠谱的发号器》,本文在此基础上进行扩展,提供多机房发号与集群拆分能力,下文中使用 March 表示发号器服务。 图1 展示了改造前发号器双机房的架构,其中:控制台负责管理发号器配置,March 包括主备节点,主节点负责发号,备节点进行灾备,etcd 作为持久化存储。 图1. 发号器架构 问题 根据图1 架构可以看出,…

Read More

Service Mesh在有赞的实践与发展

Service Mesh的概念自2017年初提出之后,受到了业界的广泛关注,作为微服务的下一代发展架构在社区迅速发酵,并且孵化出了诸如Istio等广受业界关注的面向于云原生(Cloud Native)的微服务架构。目前阿里、华为云、腾讯云都在Service Mesh上投入了大量精力进行研发和推广。阐述和讨论Service Mesh架构的文章目前网络上已经非常丰富,在此不再赘述。本文主要阐述Service Mesh架构在有赞是如何一步步发展和落地的,期望能够给读者带来一定的思考和借鉴意义,并对Service Mesh架构能够解决的问题和应用场景有进一步的了解。同时,有赞Service Mesh架构发展的过程也正是有赞微服务架构的演进过程,期待能够给正在进行微服务改造的团队带来一定的启发和思考。 缘起…

Read More

有赞NSQ多集群多机房设计

Overview 从有赞双机房开始到金融云架构,针对业务方在多机房的应该部署以及消息发送订阅需求,需要NSQ针对双机房以及多机房部署提供消息发送与订阅服务。本文主要介绍了NSQ双机房以及多机房设计以及经验总结。 场景和需求 下图1是一个机房内基本的NSQ消息生产和消费的部署。一个机房内生产者往NSQ集群发消息,多个消费者订阅消息。 双机房场景下,业务的生产和消费在两个机房都有部署,也有可能部署在不同机房中,如下图2。 对于生产者和消费者,在满足升级房生产消费的同时,NSQ的双机房方案需要做到业务方无感知,尽量降低业务方的使用成本。同时,NSQ的双机方案署要能够实现topic切换,当某一机房不可用时,通过切换机房能够尽快恢复消息生产和消费。 NSQ双机房设计 我们结合NSQ中的服务发现组件nsqlookupd的功能实现NSQ的双机房功能。nsqlookupd是NSQ组件中用于topic生产以及channel订阅的额服务发现的组件,消息生产者/…

Read More

数据库连接池配置(案例及排查指南)

引言 想必本文的读者对数据库都不会陌生,由于数据库良好的特性和服务的稳定性,使得我们的工作几乎离不开,而数据库连接池因为连接复用的优势也被广泛的使用,但凡事不可能只有好处而没有代价,使用连接池一个最直接的代价就是需要配置一堆的参数。其实很多时候这个复杂度也不存在,只要找个工程把配置拷贝一份,改一下用户名密码也就能工作了,因为之前的配置都正常工作了一段时间基本也没问题了,这个逻辑本身没毛病,但有个前提至少知道配了什么,不然问题来了都不知道如何应对。本文以 druid 1.1.5 (https://github.com/alibaba/druid) 连接池为例来阐述几个参数的重要性及如果避免踩坑,…

Read More

有赞透明多级缓存解决方案(TMC)

一、引子 1-1. TMC 是什么 TMC ,即“透明多级缓存( Transparent Multilevel Cache )”,是有赞 PaaS 团队给公司内应用提供的整体缓存解决方案。 TMC 在通用“分布式缓存解决方案(如 CodisProxy + Redis ,如有赞自研分布式缓存系统 zanKV )”基础上,增加了以下功能: 应用层热点探测…

Read More