腾讯云求崩（腾讯云stear）

IT服务网

作者

华为云服务器特价优惠火热进行中！

2核2G2兆仅需 38 元；4核4G3兆仅需 79 元。购买时间越长越优惠！更多配置及优惠价格请咨询客服。

合作流程：
1、点击链接注册/关联华为云账号：点击跳转
2、添加客服微信号：cloud7591，确定产品方案、价格方案、服务支持方案等；
3、客服协助购买，并拉微信技术服务群，享受一对一免费技术支持服务；
★技术专家在金蝶、华为、腾讯原厂有多年工作经验，并已从事云计算服务8年，可对域名、备案、网站搭建、系统部署、AI人工智能、云资源规划等上云常见问题提供更专业靠谱的服务，对相应产品提供更优惠的报价和方案，欢迎咨询。

本篇文章给大家谈谈腾讯云求崩，以及腾讯云stear对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

微信号：cloud7591
如需了解更多，欢迎添加客服微信咨询。
复制微信号

本文目录一览：

1、阿里云 vs. 腾讯云（2）
2、腾讯云异常宕机故障是什么原因？
3、腾讯云带宽告警问题排查及解决
4、腾讯云小微请求超时
5、腾讯云证书无法查看
6、Android Studio开发APP，同时使用了百度地图和腾讯云通信，打包之后APP运行崩溃，分开打包运行正常

阿里云 vs. 腾讯云（2）

昨天，中央经济工作会议明确了未来中国经济社会的发展方向。其中，强调了要加快数字化改造，促进传统产业升级。

我整理了一系列关于产业互联网的必争之地 - 云计算的材料。互联网还有下半场，路很长。

这系列文章共分4篇文章：

1）《阿里云 vs. 腾讯云》絮叨了云计算整体行业的发展

2）《阿里云 vs. 腾讯云（1）》分别絮叨了阿里云和腾讯云的发展，孰实孰虚，各位心里已有感受

3）本文将阐述阿里云和腾讯云为更好地发展云业务如何战略部署，孰高孰低

4）下一篇，将会对阿里云业绩预测和估值

———————————

内部的合与分

为了更好地发展云计算业务，阿里和腾讯对自己内部架构作了很多合并重组。

云计算业务的合并重组主要有2个原因：

- 减少两大部门之间的内耗和技术、产品重复建设。无论像阿里云和钉钉、京东智联云和京东数科，还是百度云和AI体系，两条业务线在起步时，各有侧重，但随着业务发展，二者的交集越来越多，都是用ABC（即：AI、大数据、云）为代表的数字化技术和SaaS等软件产品，为客户解决问题。而且随着目标客户群的不断重合，在客户需求解决手段和工具打造上，自然会大量趋同，造成产品和业务的重复建设

- 独立发展时间的窗口已结束。早期的各自独立运作，是为给足发展空间，壮大后再收回

巨头能否在新业务上成事，从来不在于对手有多强，而是取决于老一批既得利益者在公司内部话语权有多大，以及他们是否会妨碍新业务发展。

微软为啥错失移动互联网的快车，是反应慢还是没钱？主要原因是当时的微软PC业务线过于强势，早期不断限制甚至打压移动端团队，在内耗中错失了最佳时机。在微软内部，移动业务的推进，无疑是在革PC的命，既得利益者怎么可能坐得住？这个时候，只能在与过往核心业务没什么利益冲突的领域和人身上寻找突破，而微软抓住的这根新救命稻草，就是看起来人畜无害的云计算。

大规模的重组和革新，都集中体现着企业领导人的转型魄力，这当中必然刺刀见血。

企业最强大的地方，一定会成长出最大的软肋。当时阿里在内部推动云时，也遇到了2股阻力：

1）各个C端产品线对云信任度有限，担心随时可能崩掉

2）如果淘宝等产品架设在阿里云上，那原有的部分相关开发和运维人员不得不调岗甚至辞退

腾讯的CSIG（云与智慧产业事业群）与WXG（微信事业群）已有很多联动，但相比于阿里云领军人张建锋麾下的“云钉一体”，腾讯云汤道生似乎还需要跨越张小龙与WXG这座高山。

2020年前后那场云计算的内部收编，风暴几乎席卷国内各大互联网巨头。那么，为啥只有腾讯未对云部门进行合并重组？

企业微信之于腾讯云，好比钉钉之于阿里云，天生般配。

钉钉无主（阿里云前领军人“无招”被迫离开了阿里云，另一个小故事，此处先按下不表），易收编。

而企业微信扎根于张小龙领地，克制到极致。腾讯CSIG和企业微信，两者虽然进行了很多融合，但毕竟归属于不同事业群，各有发展路径，能否多年一直保持齐头并进，难说。

腾讯云前高管曾民总结：“我认为CSIG对抗友商最好的一张底牌，就是微信。马化腾也一直相信，腾讯做云和产业互联网的优势在于连接，从C到B，从消费者端倒逼产业方的改造升级。言下之意，就是借用微信和QQ之力，去对外做产业赋能。”

“云厂商的政企客户，无论是政府、银行还是品牌商，服务的都是普罗大众，这些机构要生存，也需要拓新，也要留存，更要创收，因此谁能帮他们解决用户端的痛点，服务好用户，更愿意为此买单。这是CSIG理论上的核心优势所在：既可在基础设施层帮客户上云，也可在应用层提供企微和SaaS软件，更是能借微信之力帮客户做引流和转化。前两项，谁都可做；最后一项，腾讯专属。”

从宏观层看，这是一条非常理想的模式，但在微观的实操中，阻碍不少。

“战略上虽然是通的，总办也在大力推动CSIG和微信乃至CDG（企业发展事业群）、TEG（技术工程事业群），在业务上的不断协同和互相支撑。但在很多具体的项目执行当中，跨事业群的协作，和跨公司协作无异。微信的流量和资源，并没有那么好拿，最后得花钱去买，好在会给内部优惠价。”

此时的CSIG，理论上的竞争力，在微信手上。而核心基础技术产品，又有不少来自TEG。虽然CSIG没有经历像阿里云和京东云一样合并重组的阵痛，但在未来的发展过程中，不可避免地感受到“王炸之牌”不在自己手中的郁闷。

这对正在发展壮大的CSIG而言，无异于戴着镣铐。

其实，从这些年的腾讯组织调整动作来看，腾讯是主张给各个事业群戴镣铐的。对集团管理而言，是好事，对事业群实现了分权而治，更好卡住各事业部的脖子，强化集团的控制力。

因此，腾讯也是所有互联网巨头当中，独立拆分子公司最少的企业——每个业务单元，都极度依赖微信和QQ的流量，被拴着镣铐，戴着枷锁，并不具备独立自主的能力。

还有一点，腾讯也是所有巨头中，扶持自家员工成为VP级高管最多的企业，近十年来极少空降VP级高管。这种土生土长出来的高管，相对而言更听话，协作意识更强，但缺少单打独斗的本事。这种高管培养体系也直接影响着腾讯组织架构的设计逻辑。

相反，阿里、百度、京东之流，每条大业务线保持较高的独立性，高管团队空降者不少，子业务线反而更容易独立拆分。像张勇、蒋凡、俞永福这些新一代核心管理者和业务骨干，都不是从阿里生长出来的。

综上，导致腾讯的组织文化稳健巩固。但另一方面，目前的腾讯云在国内与国际的市场份额都与阿里云相差甚远。

反观云钉一体化后的阿里云，接任者叶军提出了全面开放。以前“独立软件开发商”（“ISV”）要入驻钉钉，有各种要求和限制，比如企业必须注册两年以上，累积“钉钉分”等。

叶军上任后，把这些要求一一砍掉，半年内ISV合作数量翻了一翻。To B业务早期走封闭道路是正确的，亲自摸清各种坑后，更清楚哪些路需要自己走，哪些要绕道而行，哪些需借助外力。但如果一味封闭下去，想全盘通吃，一方面会很快进入增长瓶颈，第二是得罪链条上的很多玩家。

To C领域你可以把整个链条改造和颠覆掉，但To B你不得不在别人给你制定的规则下面动弹，毕竟你是服务者。除非你自己建设一套生态。而此时的阿里云，正依仗着“云钉一体”走在生态建设的道路上。

——————————

结语

阿里云2020年就突破了2万名员工。不出意外，腾讯CSIG2021年末也将突破2万名员工。2万名员工是什么概念？

腾讯全公司首次迈入2万人大关是在2012年，那时的腾讯已成立14年，QQ处于巅峰，微信大获成功。腾讯CSIG不过是一个成立刚满3年的子事业群，现在就即将超过了这个数，非常可怕。

当前的互联网巨头们，正围绕着云，上演了一出又一出好戏，暗流涌动、暗藏玄机。动荡之后，云计算正式进入了下半场。

这也将是开放者阿里云、腾讯云+微信孪生组合、华为军团、百度AIG体系、京东科技，携各家所长，正面交锋的终极之战。

腾讯云异常宕机故障是什么原因？

7月24日上午消息，腾讯云服务今日出现异常宕机事故，导致部分用户无法访问微信接口，业务崩溃。官方称，目前监控到广州区域部分用户资源访问失败，初步确定运营商光缆中断，运营商反馈预计上午恢复。

据多位网友反映，今日上午，官网无法登录或者登录缓慢，服务器访问不了微信接口，业务崩溃。腾讯云官方表示，目前监控到广州区域部分用户资源访问失败，控制台登录异常，初步确定运营商光缆中断，运营商已经找到断点正在连线中，运营商反馈预计30-40分钟恢复。

腾讯云客服告诉称，此次事故始于早晨8点，但截止11时，仍有客户反馈无法登录。

今年5月中旬，腾讯发布2018年第一季度综合业绩。称在云计算服务方面，同比增长超100%，主要由于游戏、视频、电子商务及O2O行业的增长所推动。

来源：新浪！

腾讯云求崩（腾讯云stear）

腾讯云带宽告警问题排查及解决

产品服务器设置了「外网带宽使用率 = 100%，统计粒度5分钟，连续1次满足条件则每1小时告警一次」告警策略，基本上我每天都收到多条告警信息。

放大一点查看数据：

服务器部署了 web 服务和用于存储图片资源，报表导出和资源（平均200KB左右，非 kb）一张，部分页面有时候会放好几张图片展示。如果是连续的浏览充电站、商城，或者导出报表，是很容易触发2次峰值而导致报警的。

刚才只是大约估计了一下可能的情况，排查问题还是要系统地去看，需要挑选了告警的时间区间，分别进行数据统计。

我们服务器对外的带宽服务有：

WEB 服务比较简单，nginx 上都有日志，可以通过日志的 bodysize 统计。其他两个是通过 socket 的，持续通讯的，所以我选择了数据日志的 log 进行大概统计。

以下是我的 nginx access.log 日志格式：

可以通过配置调整 ngx_http_log_module 的 log format，如:

可以看出 nginx 日志的 body_bytes_sent 是字节，所以可以通过以下指令查看数据量（$10 是 body_bytes_sent 所在位置，需要根据实际调整；grep 内容是某一分钟的时间）：

最终实际查看一天下来的流量也400MB，几个高峰的分钟段也就几M，都在预期合理的范围，并且形成不了持续的拥堵情况。

Web Socket 只有 connect 时的信息会写在 nginx access log 上，不过平时通讯的信息都有手动写相应的 access log（注意排除业务的log信息）。经统计 web socket 的 access log 比较小，一天只有十几M的数据，基本可以忽略。

注意：心跳包也需要统计进去。

桩agent 是通过端口直连的，没有经过 nginx，log 比较分散，统计了几个大的agent的 log（只统计 access log），占用的大小都不大，基本不形成高峰。但由于数量多，没有最终确定某个时间段的高峰值。

通过 nginx 配置，限制最大的带宽，可以稍微缓解一次访问的压力。避免一个大文件的访问，就长期占用了所有的外网带宽。

Nginx 限流有两种方式：

ngx_http_limit_req_module 模块提供限制请求处理速率能力，使用了漏桶算法(leaky bucket)。下面例子使用 nginx limit_req_zone 和 limit_req 两个指令，限制单个IP的请求处理速率。

==在 nginx.conf http 中添加限流配置：==

==配置 server，使用 limit_req 指令应用限流==

上面例子限制 10r/s，如果有时正常流量突然增大，超出的请求将被拒绝，无法处理突发流量，可以结合 burst 参数使用来解决该问题。

burst 译为突发、爆发，表示在超过设定的处理速率后能额外处理的请求数。当 rate=10r/s 时，将1s拆成10份，即每100ms可处理1个请求。

此处，burst=20 ，若同时有21个请求到达，Nginx 会处理第一个请求，剩余20个请求将放入队列，然后每隔100ms从队列中获取一个请求进行处理。若请求数大于21，将拒绝处理多余的请求，直接返回503.

不过，单独使用 burst 参数并不实用。假设 burst=50 ，rate依然为10r/s，排队中的50个请求虽然每100ms会处理一个，但第50个请求却需要等待 50 * 100ms即 5s，这么长的处理时间自然难以接受。

因此，burst 往往结合 nodelay 一起使用。

nodelay 针对的是 burst 参数，burst=20 nodelay 表示这20个请求立马处理，不能延迟，相当于特事特办。不过，即使这20个突发请求立马处理结束，后续来了请求也不会立马处理。burst=20 相当于缓存队列中占了20个坑，即使请求被处理了，这20个位置这只能按 100ms一个来释放。

这就达到了速率稳定，但突然流量也能正常处理的效果。

ngx_http_limit_conn_module 提供了限制连接数的能力，利用 limit_conn_zone 和 limit_conn 两个指令即可。下面是 Nginx 官方例子：

limit_conn perip 10 作用的key 是 $binary_remote_addr，表示限制单个IP同时最多能持有10个连接。

limit_conn perserver 100 作用的key是 $server_name，表示虚拟主机(server) 同时能处理并发连接的总数。

需要注意的是：只有当 request header 被后端server处理后，这个连接才进行计数。

使用独立的云存储，专门存放资源文件。

Agent 与桩之间是通过外网连接的，可以考虑多加一台服务器，与产品服务是一个内网的。Agent 先连接到一台转发服务器，与 ECMP直接通过内网连接。

端口转发参考：《Agent端口映像》

略

鉴于当前告警实际对访问的影响可忽略，将触发次数调整为2次再告警。（后面再也没有收到告警了~）

《 Nginx 的两种限流方式》

《常用的服务器日志分析命令》