一、概述 近几年，随着有赞业务的快速发展，应用数目与实例规模在快速地增加。有赞的服务注册与发现架构近几年也一直在快速平稳地演进，以支撑业务的发展。本文主要介绍有赞近几年服务注册与发现架构的演进过程。 有赞的后台业务应用主要是基于 Dubbo 框架开发的，因此，服务注册与发现的方案也都离不开对 Dubbo 服务模型的支持。近几年，Dubbo 社区也一直在演进服务注册与发现解决方案，但有赞的演进路线跟 Dubbo 社区并不相同。有赞根据内部独特的历史背景以及未来规划走出了具有自己特色的演进道路。 本文将分为三个阶段来介绍近几年有赞服务注册与发现架构的演进：接口级服务注册与发现，接口级服务注册与应用级服务发现，…
Read More概述 本文是根据有赞中间件团队多年的TCP网络编程实践经验总结而来，目的是为了避免应用因各种网络异常而出现各种非预期行为，从而造成非预期的影响，影响系统稳定性与可靠性。 本文不会涉及TCP的各个基础知识点，主要是总结一些TCP网络编程实践中可能碰到的一些问题，以及相应的经过实践验证的解决方案等。虽然本文档很多细节主要是针对于Linux系统，不过，大部分建议适合于所有系统。 本文共总结了16项建议，下面逐一进行介绍。 1. 服务端监听设置SO_REUSEADDR选项 当我们重启服务端程序的时候可能会碰到“address already in use”这样的报错信息，即地址已被使用，导致程序无法快速成功重启。老的进程关闭退出了，…
Read More很多系统的优化最后往往是对 DB 的优化，比如索引优化、并发控制，但如果提前剧透本次优化过程，其实最终只调整了一个bit，并且性能几乎翻倍，猜测很多人会觉得这是标题党在吊胃口，说实话剧情如此翻转笔者也没猜到。 背景 应用 T 的数据库连接池使用了 druid 1.1.20 (https://github.com/alibaba/druid) ，在压测时碰到 DB…
Read More背景 近几年，随着有赞用户的迅速增长和业务的快速发展，对业务开发人员要求越来越高，一方面要求为用户提供稳定的服务，一方面要求进行快速业务迭代。然而，随着公司业务复杂度和服务化整体规模的增长，单个业务功能涉及的微服务接口数、服务化调用链路长度都在迅速增加，业务的回归测试越来越难以覆盖到所有的调用链路和业务逻辑，通过仅在测试环境进行业务测试的方式来保证系统稳定性的难度越来越高。 基于系统稳定性和快速业务迭代的综合考虑，业务应用开发团队采取了新版本服务灰度上线的方式，即新版本服务并非全量发布到线上环境，而是发布少数几个实例进行灰度验证，没有问题后再全量发布。在部分核心服务进行接口升级和逻辑迁移时，还会通过在业务逻辑代码中增加黑白名单或者流量百分比控制的方式，逐步将旧版本接口实现迁移至新版本接口实现。该方式较好地权衡了服务稳定性和业务迭代效率，但仍存在以下问题： 需要业务开发人员在服务接口中编码大量与业务逻辑无关的黑白名单或流量百分比控制代码，对业务入侵比较大； 调整黑白名单或流量控制百分比，…
Read More前言 有赞发展初期，随着公司业务的增长，原本许多单机上定时执行的 crontab 任务越来越多，配置的维护成本变高，运行结果不能可视化，管理不统一，存在单点风险，运维和监控空白等等诸多弊端的显现，促使了第一代定时调度系统 Watchman 1.0 的诞生。Watchman 是一款集中式定时任务调度系统，根据业务提供的任务服务信息，参数和 cron 表达式，周期性发起回调。支持 Agent(…
Read More