扛住100亿次呼吁——怎么做一个“有把握”的春晚红包系统?

1.   春晚摇一摇活动方式

在通晓那么些连串以前,先看看羊年春晚有怎么着活动形式?春晚摇一摇复用了摇一摇入口,但提供了崭新的界面和相互内容。

 

图片 1

 

在羊年春晚摇一摇界面里,用户摇出手机后,可以看来影星拜年、全家福、好友贺卡等出色绝伦的活动页;也会有谈得来的“休息一下”,或让广大误以为中奖的“挂服务器”等独特用途的页面。

 

图片 2 图片 3 图片 4

 

世家最期待的肯定是摇红包,摇中红包的好运用户除了本人提取一份红包(种子红包)外,还能领取若干份用于分享给任何好友的红包(差距红包)。

 

图片 5 图片 6 图片 7

 

围绕那个移动,上面将会经过伍个处于项目不相同等级的里程碑版本来介绍我们统筹、落成这一体系经过中的一些构思和做法,特别是标题里关系的“有把握”是由何而来。

 

 

 

连日后得以

3.   面临的挑衅

 

原型系统看起来已经够用简单,效能也基本完备,是还是不是能够稍加修改后一向用在春晚实地呢?答案自然是十二分。那么难点来了:为何不行?

 

答问这一难题前,我们先看一下像样简单的移位背后,面临着怎么着挑战?

 

海量用户请求,估摸请求峰值1000万/秒

一千万/秒毕竟是多大的局面,可以经过下图更直观地感受下:

 

图片 8

注:抢火车票数量援引自公开数量

 

春晚全程互动,不明确因素多

那么些系统须要跟羊年春晚全程紧凑互动,从品种初步到甘休,有一密密麻麻的不显然因素会加大系统贯彻的复杂度:在开发阶段,针对节目与活动格局怎么同盟这一个难点的议论有大概不止到春晚前,怎么着使系统能服务多变的急需?在春晚实地,节目数目多,节目时长甚至顺序都有可能调整,怎么着成功现场节目与摇一摇活动无
缝衔接?

 

系统深度定制,成败在此一举

作为专为春晚统筹的种类,陈设上线后的确能运作的小时就唯有几个小时,那多少个钟头内,常规系统所倡导的灰度公布、先扛住再优化等做法并不是太适用。在那短短的时日内,只有一次机会:要么成功,要么战败。

 

全民中度关注,必须成功

春晚会有7亿左右的观众,我们对这一移动抱有很大希望,全民瞩目之下,只好成功,不大概战败。

 

l缺乏历史经验,把握不大

如此那般大型的移位,对大家而言是史无前例的,并从未太大的自信心。前边提到的一千万/秒的峰值是怎么着预计出来?各类环节会有微微用户参加?系统要求预留多少财富?这么些题材不会有现成的答案,都须要寻找与思维。

 

看得出,在近似不难的运动背后,隐藏了高大的挑战,以前若是的原型系统不太恐怕胜任,须要做更尖锐的优化。

 

亟需优化哪些环节?相比较理解的有七个:

 

图片 9

 

流量带宽

春晚摇一摇须要用到大方的多媒体能源,这么些能源都亟待从CDN下载。经过评估,带宽峰值必要是3Tb/s,会牵动巨大的带宽压力。尽管我们有无比的财富,带宽要求能被知足,客户端在摇一摇后下载财富所需的等待时间也会牵动很大的用户体验损害,是不足承受的。

 

连片质量

对接是后台系统的第②道关,全体请求都会到达接入。预计当晚会有3.5亿的在线,怎样尽大概维持外网接入质量?甚至在外网波动时也不受太大影响?

 

海量请求

一千万/秒的乞请从外网涌进来后,都被路由给摇一摇服务,约等于说摇一摇服务也将有一千万/秒的请求量。那意味须求保障系统内三个一千万/秒的高可用,在分布式系统内,那是个挺大的难题。

 

如若要对系统能不能最终赢得成功量化3个信心指数的话,那一个原型系统的信心指数是10。那些数字代表一旦春晚摇一摇接纳那套系统并拿到成功,大家认为九成是靠运气。也得以换种说法:拿那个序列到春晚摇一摇,百分之九十的或然会挂掉。

 

系统肯定不或者以运气为根基,这多少个难题怎么着解决?

 

 $ ./zkCli.sh
或 $ ./zkCli.sh -server 127.0.0.1:2181  

2.   V0.1原型系统

原型系统很粗略,但一度主导已毕了春晚摇一摇的须要。原型系统的架构见下图。

 

图片 10

 

连锁的处理流程如下:

 

  • 用户摇下手机后,客户端发生摇一摇请求,请求发到接入服务后,会被转载到摇一摇服务;

 

  • 摇一摇服务会依据现场节目标流程,经过一层层的逻辑判断,给客户端重返二个结出:歌星拜年、红包大概其余活动;

 

  • 假诺是摇到了红包,由于红包都以商店帮扶的,需要对集团形象举办显示,客户端会从CDN拉回那些公司的LOGO等财富,最后浮现出二个总体的红包;

 

  • 随后用户拆红包时,请求会进入红包系统,再到支付系统,最终到财付通系统形成一体系复杂的账务处理,最后拿到红包;

 

  • 用户还能分享红包,被分享的红包通过信息系统发给好友或群,其旁人能够再抢一轮;在这一进度中,安全系统保证红包活动的事情安全。

 

  • 上述数量的流动可以分下类:财富流、音信流、业务流和本金流。本文将重大聚焦在能源流和新闻流。

 

开行服务与查看服务场地:

 

 1 [zk: localhost:2181(CONNECTED) 3] ls /         #查看节点
 2 [zookeeper]
 3 [zk: localhost:2181(CONNECTED) 4] create /mynode1 myvalue1  #建立节点
 4 Created /mynode1
 5 [zk: localhost:2181(CONNECTED) 5] create /mynode2 myvalue2
 6 Created /mynode2
 7 [zk: localhost:2181(CONNECTED) 6] ls /
 8 [mynode1, mynode2, zookeeper]
 9 [zk: localhost:2181(CONNECTED) 7] get /mynode1       #获取节点的值
10 myvalue1
11 cZxid = 0x2
12 ctime = Thu Nov 17 00:49:22 CST 2016
13 mZxid = 0x2
14 mtime = Thu Nov 17 00:49:22 CST 2016
15 pZxid = 0x2
16 cversion = 0
17 dataVersion = 0
18 aclVersion = 0
19 ephemeralOwner = 0x0
20 dataLength = 8
21 numChildren = 0
22 [zk: localhost:2181(CONNECTED) 8] set /mynode1 myvalue11
23 cZxid = 0x2
24 ctime = Thu Nov 17 00:49:22 CST 2016
25 mZxid = 0x4
26 mtime = Thu Nov 17 00:50:58 CST 2016
27 pZxid = 0x2
28 cversion = 0
29 dataVersion = 1
30 aclVersion = 0
31 ephemeralOwner = 0x0
32 dataLength = 9
33 numChildren = 0
34 [zk: localhost:2181(CONNECTED) 9] set /mynode2 myvalue22
35 cZxid = 0x3
36 ctime = Thu Nov 17 00:49:33 CST 2016
37 mZxid = 0x5
38 mtime = Thu Nov 17 00:51:15 CST 2016
39 pZxid = 0x3
40 cversion = 0
41 dataVersion = 1
42 aclVersion = 0
43 ephemeralOwner = 0x0
44 dataLength = 9
45 numChildren = 0
46 [zk: localhost:2181(CONNECTED) 10] ls /
47 [mynode1, mynode2, zookeeper]
48 [zk: localhost:2181(CONNECTED) 11] get /mynode1
49 myvalue11
50 cZxid = 0x2
51 ctime = Thu Nov 17 00:49:22 CST 2016
52 mZxid = 0x4
53 mtime = Thu Nov 17 00:50:58 CST 2016
54 pZxid = 0x2
55 cversion = 0
56 dataVersion = 1
57 aclVersion = 0
58 ephemeralOwner = 0x0
59 dataLength = 9
60 numChildren = 0
61 [zk: localhost:2181(CONNECTED) 12] set /mynode1
62 [zk: localhost:2181(CONNECTED) 13] set /mynode2
63 [zk: localhost:2181(CONNECTED) 14] ls /
64 [mynode1, mynode2, zookeeper]
65 [zk: localhost:2181(CONNECTED) 15] get mynode1
66 Command failed: java.lang.IllegalArgumentException: Path must start with / character
67 [zk: localhost:2181(CONNECTED) 16] get /mynode1
68 myvalue11
69 cZxid = 0x2
70 ctime = Thu Nov 17 00:49:22 CST 2016
71 mZxid = 0x4
72 mtime = Thu Nov 17 00:50:58 CST 2016
73 pZxid = 0x2
74 cversion = 0
75 dataVersion = 1
76 aclVersion = 0
77 ephemeralOwner = 0x0
78 dataLength = 9
79 numChildren = 0
80 [zk: localhost:2181(CONNECTED) 17]             

7.   后记

 

2016.2.18 羊年春晚摇一摇

 

  • 全程摇动110亿次;
  • 峰值8.1亿/分钟,1400万/秒。

 

 

进去zookeeper目录下的conf目录,复制zoo_sample.cfg为zoo.cfg,并将内容改动如下(就是解压后的路径,其余的绝不改了,那一个途径一般与暗中认同的不比,要改)

羊年春晚摇一摇活动已经落下帷幕,以后回过头来看看这一老百姓出席的妙趣横生的位移背后,有着什么的后台系统?那么些系统又是怎么着被规划与已毕出来的?

 

4.1.  能源预下载

春晚采用的能源相比较多,也正如大,但大旨都以静态能源,是可以提明天下载到客户端的。保存到地点后,在须求使用的时候,客户端直接从地点加载,从而节省了集中在线下载所需的带宽需要,别的用户摇一摇时不再要求下载财富,可以有更好的用户体验。下图浮现了财富预下载进度。

 

图片 11

 

能源推送模块负责将财富上传到CDN,同时推送财富列表给客户端。推送进程基于微信音讯系统贯彻,可以在极长期内把财富列表推送给几亿的用户。

 

能源预下载要求缓解以下多少个难点:

 

 

  • 能源交付情况
  • 财富创新
  • 财富下载失利
  • 能源覆盖率
  • 离线能源安全

 

透过那套财富预下载系统,二〇一六.2.9 –
2015.2.18 时期,下发了能源6多少个,累计流量3.7PB,其中闲时峰值达到1Tb/s。

 

 

4.   V0.5 测试版

V0.5的对象就是为了消除V0.1原型系统里的多少个难点。

 

下载解压到(小编本人的)解压到 /usr/local 下

5.1.  宗旨体验是怎么着?

 

缘何V0.5测试版的信心指数唯有50?还有怎样没做到位?

 

反躬自省一下,可以窥见:V0.5测试版首要聚焦于如何处理海量的摇一摇请求,让用户可以快意的摇出红包,那摇出红包之后呢?V0.5测试版并未对那几个题材作进一步的沉思。

 

先看一下摇一摇的骨干体验——摇红包,摇红包涉及摇到红包、拆红包、分享红包、好友抢红包等等步骤。

 

稍加分析即可发现,前三步是自小编操作,后续是忘年交操作。从本人操作到相知操作之间是有自然时延的,那也就意味着那里其实尚可一定水平的不利体验——延时。

 

图片 12

 

V0.5测试版已经消除摇红包的标题,剩下就看拆红包和分享红包了。

 

把名字改成 zookeeper

5.   V0.8 预览版

root@kali:/usr/local/zookeeper/bin# ./zkServer.sh start
ZooKeeper JMX enabled by default
Using config: /usr/local/zookeeper/bin/../conf/zoo.cfg
Starting zookeeper ... STARTED
root@kali:/usr/local/zookeeper/bin# ./zkServer.sh status
ZooKeeper JMX enabled by default
Using config: /usr/local/zookeeper/bin/../conf/zoo.cfg
Mode: standalone

5.2.  怎样确保拆红包和分享红包的用户体验?

 

可以把拆红包和享受红包抽象一下,它们都以由七个部分构成:用户操作(消息流)和后台的红包处理逻辑(业务流)。对用户来说,他关怀的是操作是否中标,而不是后台的红包处理逻辑。由此那一个题材可以越发简化为:怎么着保险拆红包和分享红包的用户操作能学有所成?

 

咱俩在用户操作和红包处理逻辑之间进入了多少个中间层。这几个当中层包蕴红包简化逻辑和红包异步队列,完毕了消息流和业务流的异步化息争耦。

 

图片 13

 

红包简化逻辑

由此一些算法设计,红包简化逻辑可以通过本地统计完结对红包请求是或不是合法的开始判断,合法请求放入异步队列,然后就可以回去客户端处理成功;

 

红包异步队列

红包异步队列存储来自简化逻辑的呼吁。在存储上,异步队列使用3机方案,3机写2份成功即算入队成功。异步队列的拍卖逻辑会从队列取出请求继续发起对红包系统的调用,落成后续的红包逻辑。在红包系统故障时,会有妥善的重试策略,确保在系统复苏后重试成功。

 

紧接服务、红包简化逻辑服务、红包异步队列构成了所谓的“铁三角”,可以在红包系统出现严重难点时,爱戴用户体验在较长期内基本不受损,争取到修复故障的尊贵时间。

 

事实上再精心想想一下,“铁三角”仍能够做得更强:把红包简化逻辑再度拆分为主干的业务逻辑和地点透传队列。业务逻辑完结红包合法性校验后,把请求写
入本半夏件队列,本和姑件队列再透传给红包异步队列落成后续处理。那样尽管红包异步队列出现意外抖动,也不会影响到用户操作结果。

 

图片 14

 

V0.8预览版已经基本成型,信心指数达到70。

 

图片 15

 

然后,

6.   V1.0 正式版

大家领略设计≠达成,为确保最后落到实处和线上系统运营符合设计预期,大家还做了:

 

全程压测

未经压测的系统是很危险的,无法真正精通系统在压力下的显示是还是不是符合预期?系统的终点在哪?为此,大家建立3个压测环境,对系统进行不间断的压测。系统布局后,在现网环境也开展了多轮真实压测。

 

专题CODE REVIEW

多部门共同做了专题CODE REVIEW,在代码层面对重大路径做了细密的评估。

 

里面演练

客户端公布流程较长,周全铺开版本需求更长的时日,做不到像服务器一样可以连忙上线fix难题。由此在昭示客户端前,除了测试外,几回次的真人真事演练是老大要求的。

 

线上预热

在二〇一五.2.12和二〇一五.2.15,最后争取到了四次预热的机会,对系统举行了实战验证。

 

 

2015.2.12

2015.2.15

摇一摇总次数(次)

3.1亿

4000万

摇一摇峰值(次/分)

5000万

1700万

摇一摇峰值(次/秒)

100万

43万

发放红包速率(个/秒)

5万

5万

 

因为预热规模的原由,摇一摇峰值并未达标预估值。但发放红包的速率一向保持在5万/秒的预设值,对后端“铁三角”和后来的红包系统开展了充裕的印证。

 

复盘与调整

历次演练和预热都以高雅的时机,不仅那几个出分外的模块,那一个看起来表现符合规律的模块,也得以因而复盘和演绎,确认是或不是完全符合预期,挖掘出只怕的隐患点,进而缓解。

 

最终,大家揭发了V1.0正式版。

 

图片 16

 

V1.0规范版架构上与V0.8预览版并无例外,但是信心指数加到了80。

 

咱俩觉得剩下的十分二里,有十分之一展以后对突发意况的预案与实地处置。系统那样小幅与复杂,是或不是还有没悟出、未爆出出来、还做得不够恐怕在简单能源内无法消除的标题?这个标题若是假如出现了,是或不是有大概最终左右了全方位层面?所以最终的1/10就是靠运气,别出现这么些难点。

 

dataDir=/usr/local/zookeeper

图片 17

开拓客户端

4.4.   预估带来的题材

 

从那之后,V0.1原型系统后边提到的多个难点均已消除,1000万/秒的雅量请求可以扛住。但是,1000万/秒是预估的,假设最后来了三千万如何是好?六千万呢?看起来数字有点莫明其妙,但真有1亿依然几亿用户在不停的摇,也照旧有或然出现的。

 

对于3000万/秒,大家实在并不担心,接入服务经过不断的优化,可以在提供容灾冗余的底蕴上,仍有2500万/秒的吞吐能力。

 

然则五千万/秒大大超出了后台服务力量,如何是好?

 

海量服务之道有个过载爱抚,假设无法硬扛,能够落成自个儿爱慕。一言以蔽之就是前者体贴后端,后端拒绝前端。

 

图片 18

 

客户端在服务走访不了、服务走访超时和劳务限速时积极减少请求。

 

接通服务可以在意识有些客户端请求过于频仍时,会自动顺延回包,直接达到拉大请求间隔的意义,最后兑未来后台把客户端请求频率限制在创制限定内;别的,接入服务会计算机器的CPU使用意况,CPU使用率到达不相同预设阈值时,会自行回到不同档次的限速给客户端,通过客户端合作达成限速。

 

透过这个点子,在请求量超预期时,系统会自行降级,从而已毕自保。

 

综上,可以拿到V0.5测试版的架构,信心指数50。

 

图片 19

http://zookeeper.apache.org/releases.html#download

4.3.  连片服务内置“摇一摇”

4.3.1. 架构变动

 

面前提到,系统需求面对估算一千万/秒从外网的央求,同时还索要在内网转载同样是1000万/秒的呼吁给摇一摇服务,除此之外,还须求在各个很是情况下保险高可用。在这么海量请求之下,在那个分布式系统中,任何一点互连网或劳务的不安都可能是惨痛的,那里边的劳碌程度不问可知。

 

方正消除这一题材的老本过高,大家接纳了去掉摇一摇服务——把摇一摇逻辑集成到了联网服务,从而去掉了一千万/秒的转向呼吁。

 

但诸如此类做,有壹个前提:不只怕减低接入服务的安居乐业。因为不单是春晚摇一摇请求,微信音信收发等基础成效的呼吁也急需经过联网服务来中转,借使嵌入的摇一摇逻辑把接入服务拖垮,将进寸退尺。

 

连接服务的架构刚好有助于缓解那个难点。

 

图片 20

 

如上图所示,接入服务有二个网络IO模块,这一个模块维护了来自客户端的TCP连接,收发数据,负责跟客户端通信。互联网IO模块是作为独立的经过组运
作的,收到的哀求通过本机共享内存发给接入逻辑模块处理。接入逻辑模块也是一组独立运维的长河,平日景况下是由请求中转逻辑通过OdysseyPC把请求转载给其他逻
辑服务器处理。将来摇一摇逻辑作为嵌入逻辑,整合到了联网逻辑模块。由于网络IO模块与连片逻辑模块相互隔离,可以独自对连接逻辑模块举行升级,不会潜移默化
到已有的网络连接,那大大下跌了摆设逻辑带来的高危机。

 

但如此还不够,仍能把停放到连片逻辑模块里的摇一摇逻辑尽只怕简化,只保留比较简单、稳定、只须要单机总结即可成功的轻量逻辑;把别的较复杂、只怕必要常常转移、或索要跨机访问的逻辑独立为摇一摇agent,作为独立运维的进度,通过本机共享内存与嵌入摇一摇逻辑通信。

 

4.3.2. 摇一摇逻辑已毕

紧接服务架构的修改使得内置摇一摇逻辑变得大概,剩下的就是怎样达成春晚摇一摇逻辑?春晚摇一摇逻辑最重视的是摇红包,摇红包则需求重点消除以下难题:

 

 红包怎么发放?

 

图片 21

 

不无红包都源自红包系统,但为了在运维时不借助红包系统,红包系统生成的种子红包文件被提前安排到了连接服务。为保证红包文件不会被再一次发放,有个
文件切分程序达成不相同机器的文本切分,每台机只保留自身索要处理的那部分红包;其它,为了保障红包不漏,还有另二个顺序已毕具有机器红包文件的联结校验。

 

摇到红包的用户一旦采纳不分享红包,那个红包会被红包系统回收,一部分当做种子红包经由摇一摇agent回流到联网服务开展发放。

 

摇一摇agent会依照预设的策略给停放的摇一摇逻辑提供可发出的种子红包。红包是每秒匀速下发的,可以规范控制全局红包下发速度,保持在红包/支付种类能健康处理的界定之内。

 

 怎么着保持安全?

单用户红包个数限制

 

政工要求逐个用户最多可以领取3个红包,并且各个赞助商最多三个。常规已毕里,须求在后台存储用户领取记录,每便摇一摇请求时取出来计算,若是得到红包还需求创新存储。但此间增加了对存储的器重,海量请求下,稳定性不易维持。我们借鉴了HTTP协议的老板KIE,在摇一摇协议里也兑现了接近的机
制:后台可以写入用户的红包领取景况到总经理KIE,交由客户端保存,客户端在下次恳请时带上来,服务器再取出来判断。那就无需后台存储也能够达成平等的
目标。

 

图片 22

 

破解协议的黑心用户

 

协和总是有只怕被破解的,恶意用户可以创设自动机,绕开高管KIE检测机制。所以首席执行官KIE检测机制只好用来绝半数以上用到正规客户端的用户。对于破解协议的黑心用户可以经过在本机存储红包下发记录来打击。

 

图片 23

 

 游击战

就算如此连着服务使用长连接,但恶意用户可以不停重连,变换不相同的服务器来赢得红包,针对这种气象,大家设计了红包发给汇总服务,可以在具有连接服务上一同已经落成红包领取上限的用户。

图片 24

如上策略依次推进,后一步较前一步更透彻一层消除难题,不过在陈设上,前一步并不借助于后一步,即便后边的步骤出现故障无法按预期进展,也不会潜移默化前边的结果,在最差的景色下,系统如故可以确保单用户红包个数限制的必要。

 

 什么与春晚实地同步互动?

春晚摇一摇系统必要合营春晚实地节目进行互动,春晚切换节目大概主持人举行移动的口播时,系统都亟需一起切换活动安插。

 

此处一是讲求飞快,二是要求平安。为此大家设计了那般一个配置种类。

 

图片 25

 

春晚现场有2个配备前台,现场人士可以由此那些布局前台发送变更指令到后台。后台有日本东京和卡塔尔多哈多个接收点,每一种接收点由远在不一致园区的3组冗余的配
置服务组合。配置服务接受到布署后会同步到另一接收点,同时以文件方式下发到独具连接服务。为确保联合成功,使用了奥德赛PC/陆风X8SYNC/变更系统多少个冗余
变更通道来还要改变配置。从配置前台发起变更,到衔接服务加载配置,全程可以在10秒内完毕。

 

看起来很快和安乐都知足了,是或不是就曾经够用了?请想想以下卓殊境况:

 

 

  • 春晚前台无法工作或互联网故障,指令不能发给配置服务;
  • 不无配置服务均不能工作或互联网故障,配置不可以一起给接入服务。

 

那几个尤其在春晚节目进程中权且出现以来,一般情状下影响并不大,大家可以一时半刻手工变更配置,赢得丰裕时间去修复系统。不过,借使这时主持人正在号召
大家拿起手机抢红包,大家是一贯不丰富的把握可以在极长时间内做到全系统的配置变更的,也等于说极有可能破产,关键配置变更不了,红包根本出不来。还有
一序列似的景况,就是抢红包开端后,也因为布署变更难点,停止不了,没办法切回其余活动,损坏用户体验。

 

本着口播抢红包这些关键点,大家选拔那样的配备变更策略:使用抢红包倒计时配置,到点后自行初叶抢红包时段,经过预设的年华后,又自行终止。其它,
由于春晚节目标口播时间点具备不鲜明,大家制订了转移策略,在节目进度中可以逐渐矫正倒计时。于是这一根本配置就只与时间相关,机器时间相对简单保障,
通过NTP就可以达到充足精度的时光同步,大家还对机械时间进行集中监督,可以发现并处理机器时间现身非常的机械。

 

进入Zookeeper/bin目录

4.2.  外网接入梳理

要力保接入质量,除了需求保险接入服务自个儿的平安性外,须要达成:

 

  • 怀有在少数外网接入出现波动的时候,能半自动切换成健康接入服务的能力;
  • 维持网络与服务具有充分的冗余体量。

微信客户端已经持有了外网自动容灾切换的能力,下边再看一下种类的外网安插情状。

 

图片 26

 

大家再次梳理了外网的布局,最终在巴黎IDC和卡塔尔多哈IDC各设置了几个TGW接入集群。每一个IDC都在一个不一致的园区分别配备了电信、移动和联通的外网接入线路。

 

除此以外,接入服务也拓展了权且扩展,两地共有638台接入服务器,最多援救14.6亿的同时在线。

 

 tickTime:Zookeeper 服务器之间或客户端与服务器之间心跳的小时间隔。
dataDir:Zookeeper 保存数据的目录,暗许情状下,Zookeeper
将写多少的日记文件也保留在那么些目录里。
clientPort:Zookeeper 服务器监听端口,用来接受客户端的拜会请求。

发表评论

电子邮件地址不会被公开。 必填项已用*标注