2024年4月17日 随笔档案 -凯发k8网页登录

为了更好地分类阅读 52im.net 总计1000多篇精编文章，我将在每周三推送新的一期技术文集，本次是第38 期。

[- 1 -] 

[链接] 

[摘要] 本文分享的源码高仿了手机qq的这个效果，希望可以为有相同需求的im开发者同行节省点撸码时间。

[- 2 -] 

[链接] 

[摘要] libco在2013年的时候作为腾讯六大开源项目首次开源，ibco支持后台敏捷的同步风格编程模式，同时提供系统的高并发能力。

[- 3 -] 

[链接] 

[摘要] 分享java amr音频文件合并源码，全网最全。

[- 4 -]

[链接] 

[摘要] 本文主要是讲述资源混淆组件的用法以及性能，资源混淆组件不涉及编译过程，只需输入一个apk，可得到一个实现资源混淆后的apk

[- 5 -] 

[链接] 

[摘要] 本文主要介绍的是基于mqtt实现一个简单的android消息推送系统。更多推送技术资料请见：http://www.52im.net/forum.php?mod=collection&action=view&ctid=11

[- 6 -] 

[链接] 

[摘要] 微信的聊天界面是挺漂亮的，每条消息都带一个气泡，给人一种很清新的感觉，其实实现起来也不是那么的难，下面我们就来实现一下。

[- 7 -] 

[链接] 

[摘要] 今天为大家带来的是，可以在锁屏下弹窗显示消息来提醒用户，可用于移动端im或消息推送应用中。

[- 8 -] 

[链接] 

[摘要] 高仿ios版手机qq聊天界面中录音及振幅动画。

[- 9 -]  

[链接] 

[摘要] 页面整体采用了coordinatorlayout来实现详情页的顶部视差效。同时，这里我采用expandablelistview来实现多级列表，然后再解决它们的嵌套滑动问题。

[- 10 -] 

[链接] 

[摘要] 网上已经有一些文章分享了类似功能实现逻辑，但是几乎都是扩展edittext类，这种实现方式肯定不能进入我的首发阵容。你以为是因为它不符合面向对象六大原则？错，只因为它不够优雅！不够优雅！不够优雅！

[- 11 -] 

[链接] 

[摘要] 作为移动端im的王者，微信无疑处处是标杆，所以本次的消息时间显示格式，直接参照微信的实现逻辑准没错（随大流虽然没个性，但不至于非主流）。

[- 12 -] 

[链接] 

[摘要] 目前的app的动画效果是越来越炫了，很多主流app的图片预览返回都有类似功能，比较常见的是ios自带相册，微信朋友圈等等。自己项目中也有类似功能，最近整理了一下这个功能的代码，做个笔记记录，有兴趣的朋友可以在文末附件下载源码。

[- 13 -] 

[链接] 

[摘要] 本文分享的@人功能是针对web网页前端的，跟移动端原生代码的实现，从技术原理和实际实现上，还是有很大差异，所以如果想了解移动端im这种社交应用中的@人实现功能，可以读一下《android端im应用中的@人功能实现：仿微博、qq、微信，零入侵、高可扩展[图文 源码]》这篇文章。

[- 14 -] 

[链接] 

[摘要] mobileimsdk 是一套专门为移动端开发的开源im即时通讯框架，超轻量级、高度提炼，一套api优雅支持udp 、tcp 、websocket 三种协议，支持ios、android、h5、标准java平台，服务端基于netty编写。

[- 15 -] 

[链接] 

[摘要] 本篇主要是徒手撸im系列的开篇，主要讲解的是的im设计思路，不涉及实践编码，希望给你带来帮助。

👉52im社区本周新文：《》，欢迎阅读！👈

我是jack jiang，我为自已带盐！https://github.com/jackjiang2011/mobileimsdk/

本文由哔哩哔哩资深开发工程师黄山成分享，原题“千万长连消息系统”，本文进行了排版和内容优化等。

在当今数字娱乐时代，弹幕已经成为直播平台上不可或缺的互动元素之一。

用户通过发送弹幕、送礼等，可以实时在直播画面上展现自己的想法、评论和互动内容，从而丰富了用户观看体验。在这个过程中，实时向终端推送互动信息，就需要用到长连接。

长连接，顾名思义，是应用存活期间和服务端一直保持的网络数据通道，能够支持全双工上下行数据传输。其和请求响应模式的短连接服务最大的差异，在于它可以提供服务端主动给用户实时推送数据的能力。

本文将介绍b站基于golang实现的千万级长连接实时消息系统的架构设计与实践，包括长连接服务的框架设计，以及针对稳定性与高吞吐做的相关优化。

• 《》
• 《》
• 《》
• 《》
• 《》
• 《》
• 《》
• 《》
• 《》

3.1概述

长连接服务是多业务方共同使用一条长连接。

因为在设计时，需要考虑到不同业务方、不同业务场景对长连接服务的诉求，同时也要考虑长连接服务的边界，避免介入业务逻辑，影响后续长连接服务的迭代和发展。

长连接服务主要分为三个方面：

• 1）长连接建立、维护、管理；
• 2）下行数据推送；
• 3）上行数据转发（目前只有心跳，还没实际业务场景需求）。

3.2整体架构

长连接服务整体构架如上图所示，整体服务包含以下几个部分。

1）控制层：建连的前置调用，主要做接入合法性校验、身份校验和路由管控。

主要职责：

• 1）用户身份鉴权；
• 2）加密组装数据，生成合法token；
• 3）动态调度分配接入节点。

2）接入层：长连接核心服务，主要做卸载证书、协议对接和长连接维护。

主要职责：

• 1）卸载证书和协议；
• 2）负责和客户端建立并维护连接，管理连接id和roomid的映射关系；
• 3）处理上下行消息。

3）逻辑层：简化接入层，主要做长连的业务功能。

主要职责：

• 1）在线人数上报记录；
• 2）记录连接id各属性和各节点的映射关系。
• 4）消息分发层：消息推送到接入层。

主要职责：

• 1）消息封装、压缩和聚合推送给相应的边缘节点；

5）服务层：业务服务对接层，提供下行消息推送入口。

主要职责：

• 1）管控业务推送权限；
• 2）消息检测和重组装；
• 3）消息按一定策略限流，保护自身系统。

3.3核心流程

长连接主要是3个核心流程：

• 1）建立连接：由客户端发起，先通过控制层，获取该设备合法的token和接入点配置；
• 2）维持连接：主要是客户端定时发起心跳，来保证长连接活跃；
• 3）下行推送：下行推送由业务server发起，经由服务层根据相关标识确定连接标识和接入节点，经过消息分发层，把推送到对应的接入层，写入到指定连接上，然后下发到客户端。

3.4功能列表

结合b站业务场景，下行数据推送，提供如下通用功能：

• 1）用户级消息：指定推送给某些用户（比如给某个主播发送邀请pk消息）；
• 2）设备级消息：制定推送给某些设备（比如针对未登陆的设备，推送客户端日志上报指令）；
• 3）房间级消息：给某房间内的连接推送消息（比如给直播间的所有在线用户推送弹幕消息）；
• 4）分区消息：给某分区的房间推送消息（比如给某个分区下，所有开播的房间，推送某个营收活动）；
• 5）全区消息：给全平台用户推送消息（比如给全部在线用户推送活动通知）。

随着业务发展壮大，在线用户越来越多，长连系统的压力越来越大，尤其是热门赛事直播，比如s赛期间，全平台在线人数快达到千万，消息吞吐量有上亿，长连系统消息分发平均延迟耗时在1s左右，消息到达率达到99%，下面具体分析下长连做了哪些措施。

4.1网络协议

选择合适的网络协议对于长连接系统的性能至关重要：

• 1）：可以提供可靠的连接和数据传输，适用于对数据可靠性要求较高的场景；
• 2）：是一个不可靠的协议，但是传输效率高，适用于对数据可靠性要求不高的场景；
• 3）：也是实现双向通信而不增加太多的开销，更多的用于web端。

接入层拆分成协议模块和连接模块：

• 1）协议模块：和具体的通讯层协议交互，封装不同通讯协议的接口和逻辑差异。
• 2）连接模块：维护长连接业务连接状态，支持请求上行、下行等业务逻辑，维护连接各属性，以及和房间id的绑定关系。

针对以上第 1）点，协议模块同时给连接模块提供统一的数据接口，包括连接建立、数据读取、写入等。后续增加新协议，只要在协议模块做适配，不影响其他模块的长连业务逻辑。

优势在于：

• 1）业务逻辑和通讯协议做了隔离，方便迭代增加通讯协议，简化兼容多通讯协议的实现难度；
• 2）控制层可以根据客户端的实际情况，下发更优的通讯协议。

4.2负载均衡

采用负载均衡技术可以将请求分发到不同的服务器节点上处理，避免了单一节点的负载过高，提高了系统的扩展性和稳定性。

长连增加控制层，做负载均衡。控制层提供http短连接口，基于客户端和各边缘节点实际情况，根据就近原则，动态选择合适的接入节点。

接入层支持水平扩展，控制层可以实时增加、减少分配节点。在s赛期间，在线人数快到达千万时，平衡调度各接入节点，保障了各节点的cpu和内存都在稳定的范围内。

4.3消息队列

消息推送链路是：业务发送推送，经过服务层推到边缘节点，然后下发给客户端。

服务层实时分发到各边缘节点，如果是房间类型消息，需要推到多个边缘节点，服务层同时还要处理业务逻辑，很影响消息的吞吐量。

所以增加消息队列和消息分发层，消息分发层维护各边缘节点信息和推送消息，提高了系统的并发处理能力和稳定性，避免了因消息推送阻塞而导致的性能问题。

4.4消息聚合

当有热门赛事时，同时在线可能达到千万级别，一条弹幕消息就要扩散到千万个终端，假如在线的每个人每秒发一条，需要发送消息量就是1kw*1kw，消息量非常大，此时消息分发层和接入层，压力都会很大。

分析发现：这些消息都是同一个房间的，属于热点房间，比如s赛房间，观众数量是无法减少的，那只能在消息数上做文章。业务消息推送不能减少，又要减少扩散的消息数，就想到了消息聚合。

针对房间消息，按照一定的规则进行消息聚合，批量推送：

消息聚合上线后，消息分发层对接入层调用qps下降60%左右，极大的降低了接入层和消息分发层的压力。

4.5压缩算法

消息聚合后，降低了消息的数量，但是增加了消息体的大小，影响了写入io，需要减少消息体大小，就想到了消息压缩。

压缩算法，选了市面上比较常用的两个：zlib和brotli，进行比较。

抓取了线上业务推送的数据，选择最高等级的压缩等级，进过压缩验证：

由此可见，brotli相比zlib有很大的优势，最后选择了brotli压缩算法。

选择在消息分发层进行消息压缩，避免在各接入节点多次重复压缩，浪费性能。上线后提升吞吐量的同时，也降低的宽带使用成本。

现在有些业务是强依赖长连推送消息，消息丢失，轻则影响用户体验，重则阻塞业务后续流程，进而影响业务流水。针对长连服务消息保障，做了如下工作。

5.1多活部署

多活部署，通过在不同地理位置部署相同的系统架构和服务，实现了系统在单一地域故障时的快速故障转移，从而提高了系统的稳定性和可用性。

长连服务部署，主要做了以下几点：

• 1）长连接在国内华东、华南、华北地域均部署了接入点，支持三大运营商；华南和华中自建机房也部署了接入点；为支持海外用户，增加了新加坡机房独立接入点；
• 2）针对业务场景不同，在云上节点和自建节点之间，实时切换，因为云上节点和自建机房的成本是不一样的，在保证服务质量的前提下，尽可能的控制成本。

目前线上运行过程中，偶尔会遇到单节点或机房的网络抖动，通过控制层，对有问题的节点，进行秒级摘流，大大减少了对业务的影响。

5.2高低消息通道

多业务消息接入长连接，但不同消息之间的重要性是不一样的，比如弹幕消息和邀请pk消息，丢失几条弹幕对用户体验不会影响很大，但如果邀请pk消息丢失，则会导致pk业务无法进行后续的流程。

针对不同等级的消息，采用了高低优消息通道。重要消息走高优通道，普通消息走低优通道。这样重要和普通消息进行了物理隔离，消息分发优先保证重要消息。

针对高优通道，做了双投递的保障，在接入层做幂等去重。首先重要消息是针对用户级别的，量不会很大，所以对接入层的压力不会增加很大。另外双投递的job是部署在多机房的，这也就降低单机房网络抖动造成的影响。

高低优通道上线后，遇到过内网出网抖动，当时内网部属的job节点推送消息异常，而云上高优job节点可正常推送，很好的保障了高优消息的到达，进而保障了高优业务不受影响。

5.3高达功能

高低优通道解决的是job到接入层的这一个环节，但消息推送联路涉及到多个环节，比如服务层到job、接入层到客户端。

针对整个链路，通过实现必达机制来确保终端的到达率，简称高达功能。

功能实现：

• 1）每条消息引入msgid，客户端收到消息后进行幂等去重和ack回执；
• 2）服务端针对msgid进行ack检测，针对未ack的，有效期内再次重试下发。

最终到达率 = (1-(1-r)^(n 1))，其中：r为广播单次到达率，n为最大重试次数。

例如：r = 97%、n=2，那么最终到达率可以达到(1-(1-0.97)^(2 1)) = 99.9973%

有些业务场景，需要用到用户进出房消息，比如用户a进入直播间，页面会显示欢迎用户a进入房间，或者是加入在线榜单。

1）进房消息会存在丢失，需要有补偿机制。想到可以通过连接心跳来补偿进房消息，但心跳是持续不断的，连接在线期间，业务希望只收到一次进房消息，所以进房消息需要有幂等机制。

2）出房消息也会存在丢失，如果丢失了，业务无法从在线榜单剔除用户，此时也需要有补偿机制。此时就需要增加连接的状态机，通过心跳维护状态机，当心跳丢失时，认为连接断开，用户退房。

统一长连接服务经历数次迭代后，目前基本功能已经趋于稳定，后续对长连接服务进行改善和优化。

主要集中在以下几个方向：

• 1）数据化：进一步完善长连接全链路网络质量数据统计和高价值消息全链路追踪的能力；
• 2）智能化：端上建联、接入点选择等能够根据实际环境进行自动化调整；
• 3）性能优化：接入层的连接模块中，处理上下行消息的携程进行共享，减少接入层的携程数，进一步提升单机性能和连接数；
• 4）功能扩展：新增离线消息功能等。

[1] 

[2] 

[3] 

[4] 

[5]  - 

[6]  - 

[7] 

[8] 

[9] 

[10] 

[11] 

[12] 

[13] 

[14] 

[15] 

[16] 

）

本次更新为次要版本更新，进行了bug修复和优化升级（更新历史详见：、）。

mobileimsdk 可能是市面上唯一同时支持 udp tcp websocket 三种协议的同类开源im框架。轻量级、高度提炼，历经10年、久经考验。客户端支持ios、android、java、h5、微信小程序、uniapp，服务端基于。

 是一套专为移动端开发的原创im通信层框架：

• 历经10年、久经考验；
• 超轻量级、高度提炼，lib包50kb以内；
• 精心封装，一套api同时支持udp、tcp、websocket三种协议（可能是全网唯一开源的）；
• 客户端支持 ios、android、标准java、、、；
• 服务端基于netty，性能卓越、易于扩展；
• 可与姊妹工程  无缝互通实现网页端聊天或推送等；
• 可应用于跨设备、跨网络的聊天app、企业oa、消息推送等各种场景。

mobileimsdk工程始于2013年10月，历经10年，起初用作某产品的即时通讯底层实现，完全从零开发，技术自主可控！

您可能需要：。

oschina.net

• 源码托管： 

• 项目资料： 

github.com

• 源码托管： 

• 项目资料： 

让开发者专注于应用逻辑的开发，底层复杂的即时通讯算法交由sdk开发人员，从而解偶即时通讯应用开发的复杂性。

整套mobileimsdk框架由以下7部分组成：

1. android客户端sdk：用于android版即时通讯客户端，支持android 4.0及以上，；
2. ios客户端sdk：用于开发ios版即时通讯客户端，支持ios 12.0及以上，；
3. java客户端sdk：用于开发跨平台的pc端即时通讯客户端，支持java 16及以上，；
4. h5客户端sdk：；
5. 微信小程序端sdk：；
6. uniapp端sdk：；
7. 服务端sdk：用于开发即时通讯服务端，支持java 1.7及以上版本，。

整套mobileimsdk框架的架构组成：

 另外：mobileimsdk可与姊妹工程  无缝互通，从而实现web网页端聊天或推送等。

【重要说明】：

mobileimsdk v6.5 为次要版本，进行了若干优化！  （）

【新增重要特性】：

• 1. [android端] 新增了demo中当app处于后台时，收到消息时显示系统通知的功能。

【解决的bug】：

• 1. [服务端] 尝试解决极小几率下android端会误把“自已”踢掉的问题。

【其它优化和提升】：

• 1. [服务端] 升级了log4j2等基础库，解决基础库低版中带来的安全漏洞风险；
• 2. [服务端] 服务端sdk和demo工程已迁移至idea；
• 3. [java端] java桌面端的tcp和udp两种协议的sdk和demo工程已迁移至idea；
• 4. [android端] 提升targetsdkversion至34（即android 14）；
• 5. [android端] 解决了demo中绑定前台服务在android 14中崩溃等问题。
• 6. [ios端] 提升最低系统支持版本为ios 12；
• 7. [ios端] 优化了json解析库中的一处过时api调用。

【最新版本源码地址】：

• gitee：
• github：

8.1 示例1：基于mobileimsdk的移动端im rainbowchat（）：

8.2 示例2：基于mobileimsdk-web的web端im rainbowchat-web（）：

本文由腾讯技术团队peter分享，原题“腾讯网关tgw架构演进之路”，下文进行了排版和内容优化等。

tgw全称tencent gateway，是一套实现多网统一接入，支持自动负载均衡的系统， 是公司有10 年历史的网关，因此tgw也被称为公司公网的桥头堡。

本文从腾讯公网tgw网关系统的应用场景、背景需求讲起，重点解析了从山海1.0架构到山海2.0架构需要解决的问题和架构规划与设计实现，以及对于未来tgw山海网关的发展和演进方向。

 

技术交流：

- 移动端im开发入门文章：《》

- 开源im框架源码：（）

（本文已同步发布于：）

本文是专题系列文章的第11篇，总目录如下：

1. 《》
2. 《》
3. 《》
4. 《》
5. 《》
6. 《》
7. 《》
8. 《》
9. 《》
10. 《》
11. 《》（* 本文）

tgw全称tencent gateway，是一套实现多网统一接入、支持自动负载均衡的系统， 是公司有10 年历史的网关，因此tgw也被称为公司公网的桥头堡。它对外连接了各大运营商并支撑公有云上eip、clb等产品功能，对内提供了公网网络的接入功能，如为游戏、微信等业务提供公网接入服务。

tgw主要有两大产品：

• 1）弹性eip（比如购买一台虚拟机cvm或是一个nat实例后，通过eip连通外网）；
• 2）四层clb。

四层clb一般分为内网clb和外网clb：

• 1）内网clb是在vpc内创建一个clb实例，把多个cvm服务挂在了内网clb上，为后端rs提供负载均衡的能力；
• 2）外网clb面对的是公网侧负载均衡的需求。

当在内部部署clb集群时，可分为ipv4或者ipv6两大类，根据物理网络类型又细分为bgp和三网两类。三网指这些ip地址是静态的，不像bgp一样能够在多个运营商之间同时进行广播。

以上就是四层tgw产品及功能，山海网关在原有产品基础上做了网络架构方面的演进。

具体介绍下eip和clb两个产品。

过去clb和eip使用不同的ip地址池，导致资源池上的隔离问题。使得我们无法把eip地址绑定到公有云clb实例上。

例如：一个创业公司最初只购买一台虚拟机并挂载一个公网eip来提供服务。随着用户量的增长，如果想将这个eip地址迁移到一个公网clb实例上，在原有架构下是无法实现这种迁移的。

此外：eip和clb部署在每个机房，因此在每个机房都需要建立eip出口。但是各个机房的公网出口之间缺无法相互容灾。

所以这种情形下，我们确定了产品的目标：

• 1）希望将所有公网出口整合到一到两个机房之内，以避免重复建设，节省成本；
• 2）通过将出口集中，我们可以将对应的网关服务器也进行集中，进而提高设备的利用率；
• 3）通过这样的布局可实现跨机房的容灾方案。

因此：最早的region eip（reip）计划应运而生。

以北京这类大型region为例的：我们将eip专区建设到位于两个城市的超核机房。这两个机房通常会放置物理网络的交换设备，并为各自设立了一个reip专区。在reip专区内部署region eip集群。为了实现跨az容灾，两个机房的集群之间借助大小网段实现互相备份容灾的能力。一旦其中一个机房的集群发生故障或出现网络问题，另一个机房的集群可以立即承担起容灾任务。

同时：因为新的region eip的网络架构跟原来的网络架构不一样，通过网络架构升级以及机型升级，我们能够把单台region eip的性能做到原有单台eip性能的5倍。这样我们通过容量的提升进一步提升了设备利用率，在完成全量region eip后，设备数量会从3000 台缩减至700 台。同时原有的clb集群还保留在各个机房不变，这些clb集群的外网接入能力由region eip承担。

5.1概述

公网clb最早是有公网接入能力的。引入到region eip之后，当初设想是公网clb不再演进，尽量让存量用户迁移到另外一种形式，上层是region eip，下层是内网clb。用户先买一个内网clb，如果需要对公网提供服务就再买一个弹性eip，把eip跟内网clb绑定在一起，提供clb公网的能力，替代原有的公网clb，这是最早公网clb的替代方案。

两个方案的区别是：原有公网clb，用户仅看到一个clb实例。新的模式下，用户看到的是两个实例：一个eip 一个内网clb，两个实例都可以独立运营管理。这就是我们最早的两层架构设想，想把公网clb跟外网解耦。

但是，真正去跟用户或产品交流时，这个想法遇到了比较大的挑战：

1）用户体验的改变：以前公网clb用户看到是一个实例，但是现在用户看到两个实例，必然会给用户带来一些适配工作。比如用户进行创建、管理实例时，api不一样了。以前使用通过自动化脚本创建公网clb实例的，现在脚本还要改变去适配新的api。

2）用户习惯改变：以前用户习惯在一个实例下，点击页面，就能够查看流量、链接数等监控信息。现在eip流量需要到reip查看，而链接数还需在clb产品上看。

3）存量客户无法迁移：原来客户买的公网clb实例，是无法直接无感知迁移到内网clb reip这种新形式的。

在这些挑战下，这个替代方案没能真正落地。结合用户的要求，我们最终跟产品定下的策略是：公网clb保持不变。原有的公网clb继续保留，同时如果用户新增的公网clb需求，也要继续支持。

5.2公网clb模型

那么，公网clb到底怎么演变？

我们的初衷并不是把公网clb这个产品摒弃掉，而是要收敛公网入口。所以我们针对这个初始需求，提出了上面这个两级架构模型。

首先：用reip将公网流量先引进来，再将这个流量通过隧道报文的形式转发给原有的公网clb集群，这样公网clb不需要原有外网接入的能力，不需要再跟外网打交道，可以演变成只在机房内部的集群；同时因为公网clb的流量都会经过reip，reip自然也就是公网clb的流量入口。从而达到我们最初收敛公网入口的目的。这样的架构升级，可实现用户无感知。架构升级切换过程中，用户在访问公网clb，不会出现卡顿或者重连的现象。

这个架构模型也有一定的局限性的。公网clb实例只能承载公网的流量，无法像上文提到的两层rerp clb那样，内外网随时进行转化。reip clb实例中的clb既承载内网侧clb的流量，又承载公网侧clb的流量。

借助这个两级架构模型，我们能够把公网clb保留下来，并且通过reip把公网入口收敛。

进一步思考并完善，我们提出了下面的想法：跟产品进行解耦。

以前我们一个地区上线公网clb产品，底层就要搭建有一个公网clb的集群去支持。用户需要内网clb服务，就要对应搭建个内网clb的集群。底层集群类型跟产品是强耦合，有ipv4/ipv6， 公网/内网、bgp/三网组合出的多个产品形态。

这种模式在小地域部署，因为产品业务的流量小，集群利用率低，就会造成很大的成本压力。

为了应对这种小带宽低成本的诉求，我们将clb reip的模型进一步抽象，引入山海架构：我们只建设clb和reip两类集群。通过这两类集群上的不同实例组合，满足多个产品形态的要求。从而实现产品形态和底层物理网络集群类型解耦。

解耦合的方式是：clb和reip通过不同的实例类型，组合出不同的产品形态。

山海架构在tgw内部做闭环，不涉及到产品侧和用户侧的改动。整个过程升级，对产品侧不做任何接口上的更新。因为产品侧的api接口保持不变，对用户侧就可以做到完全无感知。在产品侧保持不变，就需要我们在内部管控，识别接入用户实例是哪种形态的产品，拆分成不同形式的clb和reip的实例。其他的相关功能的比如流量统计、限速等模块也都要适配不同的产品形态，通过模块的适配，做到山海架构对上层产品侧应用的透明。

山海架构1.0归纳起来有两个重点：收敛公网入口和集群类型归一。

1）reip：部署在城核机房，同时承载的是clb和reip两类产品的公网流量。之前eip，在物理网络上有bgp 三网、v4/v6等多种集群类型。reip借助vlan的隔离支持，把所有的网络类型都集中到一种reip集群上来，我们称之为全通集群。在物理网络层面实现网络类型的归一， 然后再通过软件层的适配，实现reip支持多通类型的网络接入能力。

2）clb：在山海两级架构下，reip集群处理公网侧的各种场景组合，clb集群通过隧道与reip处理公网流量。之前一个机房如果要把所有的产品能力支持起来，大概有7种集群类型。现在clb集群可以用一种集群类型来支持所有的产品的公网clb产品，以及内网clb产品的能力。我们把三网 bgp以及内外网还有v4v6等集群类型都用一种类型来支持，山海架构完全落地后，开区的最小服务器数量可以降低到8台服务器，来承载所有的eip和clb产品需求。

归纳起来一句话：对于用户来说，产品形态没有改变，用户使用习惯也没有改变。而在底层，我们把集群类型收敛到一个clb集群和一个reip集群上。

在山海架构演进中，有许多技术点，本文选取限速技术进行分享。

首先region eip支持三网。以前bgp跟三网分开独立支持，山海网关统一用region eip支持。region eip本身的网络架构分成两个机房，每个机房放4台tgw设备，每个eip只会走左边或者右边。一个eip进来的流量经过上面这层交换机时，经过了ecmp分流，然后分到了4台设备上。这样对每个eip其实是采用了分布式限速。

限速有两个要求：

• 1）精确性，限速上下浮动要小，要限得准；
• 2）要有容灾能力。

限速最极端的精准就是把它放到单点上去做限速，但是单点限速就会面临单点故障和容灾的问题。在x86服务器上，使用的是分布式限速，一个eip均分到4台服务器上，每五秒钟做一次流量的的汇总统计，通过流量比例计算将这个eip的带宽配额，重新分配并分发到4台设备上，以此来实现集群上的限速。在单台设备上，也是没隔一段时间，就重新计算配额并分配到每个cpu核上，我们目前用的是300毫秒周期。

需要说明的是：在限速的实现上，业务有多重实现方式，我们了解到有的实现的是静态分配，比如120兆的带宽，4台设备，我们每台设备分40m(三分之一)的带宽。1/3而不是1/4的带宽，目的是防止某一台设备断了之后，用户总带宽不达标，影响用户体验。在单台设备上限速，也有另外一种实现方式，大小桶。比如限速1m的带宽，那么每个核第一次取回100k或者200k配额。后续报文处理时候，先消耗上次取回的配额，如果带宽配额消耗光了，再重新取。周期调整跟大小桶这两种实现方式各有优缺点。从资源消耗来说，300毫秒周期的资源消耗相对会更少一些，两者大概有10%左右的性能偏差。

限速上另一诉求：小带宽的限速的精准限速。

大带宽比如100兆，分到每个核上相对富裕。小带宽如一m带宽，一秒钟100k字节等，分到四台机器再分到几十个核上，每个核都可能不到一个大报，这时候再去做精准限速就会非常困难，因为既然要提前分配资源，资源那么少，分配到单核上，可能一个包都过不去，但凡有一个报文过去了，又可能超了。所以在小带宽限速时，我们把它退化成类似于单点限速的模式。由于入方向带宽最小也是100兆，因此保持原有的分布式限速不变。只对出方向小带宽，使用单点限速。方案是这样的：

每台reip有自己一个独享的内网地址，只有这台服务器故障时候，这个地址的流量才被分发到其他三台服务器。

入方向流量被分到四台reip服务器后，reip处理完通过tunnel转发给母机。隧道的外层源地址，只使用其中一台reip服务器的独享的ip地址。每个外网ip地址在挂载到集群下管理时候，就确定下来了。

母机在接受到网关发过去的流量，解析外层报文地址，并记录在本地会话表里，我们称之为母机的自学习能力。当母机侧转发出方向报文时，就只会使用本地学习并记录的外层地址去封装隧道。这样出方向的流量，就回到单台tgw设备上，实现了单点限速。

独享的内网地址本身是有容灾能力：

• 1）当其服务器故障了，流量就被分散到集群其他服务器，放弃单点限速；
• 2）当服务器被修复上线后，又可以重新变成精准的单点限速。

这样保证小带宽精准限速的同时，又避免了单点故障。

在限速过程中，还有一个问题，因为clb集群原来的限速是在clb集群上自己做的，引入山海之后，reip上有限速能力，那么公网clb的限速要不要挪到reip上？

我们经过多次讨论， 最终还是维持**这个限速在公网clb上不变。

这里有几种场景考量：

1）内外网攻击：如果我们把它放到reip上，这里可以扛住外网的攻击，但同时内网的攻击我们是防不住的，因为公网clb上没有限速后，流量内网的攻击就会先把clb上压过载，导致丢包，影响业务的稳定性。

2）有效流量的准确统计：原有架构下，从公网流量首先到达clb，我们需要检查公网clb上与port对应的服务是否已配置规则并启用。如果没有启用，则将报文直接丢弃且不记录为公网clb的带宽使用量。山海架构下，如果先经过region eip限速，这类无服务访问流量（如恶意攻击和垃圾流量）也将占用限速资源。尽管这部分限速流量会送达至clb集群，但由于缺乏相应凯发k8网页登录的服务支持，它们最终还是将被丢弃。结果导致用户带宽不及预期。比如用户购买10m带宽，实际有效运行的仅有8m流量，而其余2m被无服务流量占用了。

3）多重限速的影响：还有一个这个场景中，当region eip实施带宽限速后，这些流量最终可能进入公网clb。然而，由于clb的规格限制，例如新建连接数或并发连接数已达到上限，部分数据包可能会被丢弃。这些丢失的数据包已经消耗了购买的公网带宽，从而导致用户观察到的公网clb流量带宽未达到预期。因此，我们保留公网clb限速功能不变，仅进行引流调整。

clb产品及reip产品，在使用山海1.0之后的几点优势。

1）clb产品本身支持热迁移，扩容到山海热迁移，不会引起用户的断流，有助于运维做用户产品升级迭代。这方面有个典型案例，比如某台设备坏了或者发现某台设备上有问题，需要把流量迁走的时候，我们可以不用中断用户的流量的。我们了解到，以前有的竞品，因为热迁移做的不是特别完善，在设备出现问题或者是需要升级版本的时候，常选择低峰期做升级。

2）eip在做限速的时候，在出方向时是小带宽，可以做到比较精准的限速。好处是用户做压测或测试的时，带宽不会抖动影响自己的业务的稳定性。

3）高低优先级限速。用户买一些比较小的比如10m带宽或者5m带宽，用来服务本身业务，同时也会ssh或者远程桌面登录eip；因为一起我们是做无差别的限速丢包的话，这样会造成它本身的控制流量，如远程桌面的流量也会被丢包，造成登录的卡顿。用户需要在不超限速的前提下，优先保证远程桌面不卡，然后再提供其他的下载服务。我们把流量根据端口进行区分，比如22端口或者是远程桌面的3389端口的流量，标记为高优先级。在做限速时，只要高优先流量不超限速，就全部放行。当高优先级流量再叠加上低优先级的流量超限速时，把低优先级的流量丢掉，这样ssh访问服务器的时候能够非常顺畅。

4）山海架构上线后，基于vip粒度的调度，可以让调度更加灵活。比如原来一个集群为了节省路由条目，我们按照一个网段发路由，不是每个vip都发路由的。山海两级架构之后，没有了这个限制，就可以按照vip，把clb实例调度到不同clb集群。这样如果用户需要一个特别大规格的vip的时候，我们可用一个集群的能力去扛用户一个vip，从而满足超大规格实例的诉求。当然真实使用产品时，很少有客户把上百g的流量用一个vip来承载。用户出于容灾考虑，通常不会把所有的鸡蛋放到一个篮子里。

9.1概述

如前所述：山海 1.0 主要目标是整合公共网络并将所有公网出口集中在城市核心机房内。至于剩余的 clb 群集，我们会继续将其保存在原有各机房的专区里。这是因为网关设备有其与服务器不同的网络诉求，例如普通服务器不能提供发布动态路由，并通过动态路由引流处理业务流量。

再比如：网关专区的收敛比1:1，而服务器虽然带宽也是100g， 但其收敛比率往往小于1：1。

在这种情况下，我们不能简单地将 clb 网关群集群平移放置到服务器区。因此，clb 网关群集通常在构建每个机房时，预先规划并预留相应的网关专区。机房建设起来后，如业务量小，又会因预留资源空置造成浪费。目前专区闲置机位也是一笔较大的费用。

同时，还有一种临时扩容的需求场景，例如vip大客户，临时会有大流量的转发需求，这时常态运营水位没法满足需要，需要调配设备做集群扩容。如果本机房的设备不够还需要跨机房搬迁，搬迁周期比较长，对我们运营压力会很大。

所以，我们希望通过山海2.0能把专区建设的空置率降下来，同时提升弹性，能够低成本的快速扩缩容。

9.2引流交换机

在山海 2.0里，我们采用了“引流交换机”。在每个机房的建设时，我们可以放置两组共四台引流交换机。

考虑到单个交换机的容量可以达到 1 t 以上，有四台交换机工作，一个机房能够承受大约 4t~ 6t 的流量峰值。这意味着后续无需再额外扩容，一次性的建设和布局就可以满足长期的需求。相比于 clb 群集占用的机位空间，四台交换机所需的机位显著减少。

我们把原来clb集群对外声明路由的能力放到了引流交换机上，把clb服务器用用通用服务器区的设备来代替。考虑收敛比和容灾，不会把一个集群放到一两个机架上，会相对分散些，更不会把整个机架全部再用成clb集群。这样clb集群不再单独建设网关专区，引流交换机把路由声明发出去，通过隧道跟clb设备转发流量。

9.3山海2.0的变化

我们以内网clb为例，原来一台虚拟机访问clb集群，clb集群把它的流量转到对应的rs。

引入交换机之后，其进出两个方向都会有变化：入方向（访问lb方向），虚拟机的流量先被引流到了引流交换机，交换机把报文做一次封装，然后发送给对应的服务器，进行负载均衡转换。最后处理后的结果，被转发给真正的rs。原来的两跳访问变成了现在的三跳。同样反方向流量返回时，rs的流量先回到引流交换机，然后被分发到对应的ld设备上。ld处理完之后，再把报文直接转到client虚拟机上。借助引流交换机的中转，我们就能够让负载均衡的专区设备的放到普通的服务器区里。

另外：这里的clb服务器，可以跟其他的网关包括母机复用一些相同机型的服务器，当需要扩容时，就可以使用通用服务器。而不像以前clb既有自己独立的机型，又对服务器的物理位置有要求。有了引流交换机跟ld之间是做隧道传输，ld具体的物理位置就没有像原来一样有硬性的要求。这样clb可以通过通用服务器区域，调配服务器。

最后一项是：原有跟reip类似的，clb设备做路由通告时，也是按照网段通告，有引流交换机之后，我们可以在引流交换机上去做细粒度的调度，一个vip或是几个vip放到一个集群。还可以在引流交换机上做更细粒度的调度，如ip port这样的五元组的粒度的调度。

目前网关设备最重要也是最大的一个方向就是做高性能、硬件卸载。依赖硬件来实现高性能的转发。

网关设备分为有状态和无状态两种：

• 1）无状态设备就像ip转换一样，只要依据规则，任何时刻来了报文，转换出来的形式都是固定的；
• 2）有状态设备是需要记录tcp、 udp状态，记录转发到后端设备，当不同的时间转发即使相同的类型的流量，它转发的目的地也不一样，转换的格式也可能不一样。

硬件卸载在有状态和无状态时，基本上用到的设备都是dpu和交换机，用到的介质几乎都是fpga。

fpga和asic本质上是一个东西，无论友商还是我们自己内部研发，更多的是fpga上做功能，并小规模的灰度上线验证，一旦稳定下来，就转化成批量的asic，以此来降低成本。

dpu和交换机在无状态设备上，交换机相对更有优势，因为无状态设备对容量的要求相对小些，像eip网关以及内部无状态的网关大多用交换机形态实现。dpu目前更多的用在母机侧，做有状态类的网络处理。当然， 采用dpu不仅仅局限网络诉求，还有存储安全等其他需求。去年英特尔宣布已不再进行交换机tf芯片的演进迭代，大家对交换机的质疑会增大。

所以，也衍化了另一种方案：在一台额外的服务器中插入 dpu 网卡以实现卸载功能。

但不同方案有不同的优缺点：

1）使用交换机的最大优势在于其强大的交换性能（可达 1t或几个t及更高），可支持很大的接入容量。但是，交换机仅能是一个底座，若要扩展容量仍需依赖 fpga 技术。

2） dpu 的优点则包括成熟的产业链、庞大的产量以及稳定的供应保障；此外，由于 dpu 在母机侧已被广泛验证和采用，许多功能的实现都相对固定。

这是两种方案各自的优缺点。

在两个产品运用负载均衡状态的交换上，业内不同的厂家也有不同的玩法，有的是交换机，有的是dpu。当前，无论是交换机还是 dpu，都依赖fpga(asic)来做大容量的会话管理，同时越来越多的设备或多或少的支持p4。在 x86 上进行编程时，通常选择 dpdk。

相较之下：使用 p4 进行编程的门槛较低。p4 编写一般功能需求的代码非常简单快捷，只需一两周时间即可完成，甚至对于熟练者来说，可以在几个小时就开发出一个小功能。虽然充分发挥硬件的性能，p4类芯片还需要进行很深入细节的研究，但p4还是大大降低了数据面编程的门槛，特别是在高性能转发的需求方面。

另一个特点是：小型化。大家过去比较关注数据中心和海量数据的优化问题，随着业务发展，逐步转向降低运营成本和提高效率的场景，开设小型站点。这类小型站点，是典型的“麻雀虽小，五脏俱全”，希望用尽量少的设备成本来满足各种功能需求。所以我们将设备设计为具有较小规格的产品系列，并在易用性上进行改进，通过集群合并、虚拟机等承担更多的任务负载。这样在业务规模和流量不大，也能以较少的资源应对较高的功能性需求。一旦业务规模扩大，我们可将这些小型站点升级为传统的数据中心级物理设备。

以上未来网关两个主要的方向。

[1] 

[2] 

[3] 

[4] 

[5] 

[6] 

[7] 

[8] 

[9] 

[10] 

[11] 

）