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