腾讯云tfs（腾讯云服务器）
本文目录一览：
微信系统不崩的秘密
本报记者 任晓宁 北京报道
微信为什么没崩过？
12亿中国人都在使用微信，却很少有人思考过这个问题。其实，微信也曾徘徊在濒临崩溃的边缘，腾讯基础架构部运营管理支撑中心总监邹方明现在还记得2014年除夕，人们刚学会用微信发拜年视频，流量直接爆掉，系统濒临崩盘，公司上下所有人的压力都集中到他一个人身上，等他做出决定。他说，那是他最痛苦的时刻。
直到现在，在微信使用量最大的时刻，比如除夕，或是元旦、七夕、中秋，或是情人节，腾讯团队也会提前几个月筹备资源。前几年的高峰期，负责腾讯红包系统运维的肖攀甚至会拜一下QQ公仔，就像拜佛一样，求系统不崩。
现在，他们已经积累了一整套保证系统不崩的方法论。
腾讯10年维护微信系统不崩的故事，是一个从手忙脚乱到心平气和的成长故事，是一个技术系统从无到有的故事，也是一个国民级用户产品的技术秘密。腾讯技术团队向经济观察报讲述了这些故事，他们构建的系统，使用的技术，在运行中积累的经验教训，对于其他公司，或可提供些许借鉴。
濒临崩盘的时刻
一刀切关闭系统、还是继续寻找漏洞？是邹方明必须立刻做出的判断。
他是腾讯的老人，2006年进入腾讯，负责技术，一手搭建了QQ和微信的聊天图片、视频系统。但在2014年除夕微信流量爆发而濒临崩盘的时刻，他依旧承受不住这种压力。“系统全方位崩盘，流量也爆了，前端的系统就好像洪水一样的，后端的系统更脆弱，连着倒了三四个系统和平台，不光我们的平台倒了，底层存储的其他部门其他系统也倒了。”
体现在用户侧的感受是，用户在朋友圈把视频发出去了，但身边朋友一个都没看到。
用户投诉源源不断而来，邹方明需要立刻做出判断。他可以花更多时间去查一下到底是什么原因导致，彻底解决问题，或是干脆一刀割下去，先暂时限制视频功能。“哪个方案能够最快恢复服务，我事后在脑海里模拟了无数遍，也想不出哪一个更快。”
邹方明站在机房前，对着那台显示崩盘的电脑，身边的运维看着他，手指放在键盘上等待指令，老板在办公室一言不发，产品团队需要一个回复，公司外数以亿计的用户，所有人都在等待着他的指令。
虽然只有十几分钟，但每一秒都是煎熬。
邹方明最终决定一刀切。至少切断后，再次恢复，能给到用户继续使用的可能性。否则，不知道要排查多久才能真正找出问题。直到现在，他也不能说自己的选择是最正确的，但那是最快解决问题的选择。
微信诞生早期，上面的时刻时有发生。2015年，微信红包赞助春晚，除夕当天红包量级从10万级提升到10亿级，负责运维的肖攀，买了个QQ公仔，插上两根香，每当觉得心里不稳妥，就去公仔前拜一拜，祈求千万不要出事。
微信后期，一套成熟的稳定系统已经形成，依旧有不可预料的事情发生。2020年2月，腾讯会议在一个月时间增长1000倍，腾讯云副总裁、腾讯基础架构部总经理肖志立也遇到了难题，他的难题不是技术原因，而是物力资源跟不上。
当时，因为疫情，运营商的BGP带宽满足不了、外网IP地址满足不了，并且，由于设备供应商无法复工，设备也供应不了。
肖志立给联想打电话，询问能不能给库房供1万台机器，对方说不好意思，员工都回家了，疫情期间没有办法回来。
直到最后，新机器也没有送到。最终，还是只能死磕技术，通过软件的优化，把之前一个单元支持100路的技术，提升到支持200路，才解决了物理资源不足的难题。
一个从无到有的系统
12亿用户感知到的，是每天都在使用的微信这个产品。他们感知不到的地方，微信背后仅技术平台就包括图片平台、音视频传输平台、红包系统、小视频平台等等，这些平台接入腾讯内部超过90%的业务。
平台组合在一起，形成庞大的系统，基本能解决已知与未知的问题。这些平台的形成，不是一蹴而就的，而是经历了漫长的过程。
图片系统 历史 最悠久，早在2006年的QQ时代就开始使用。当年，QQ用户突破1000万，上线了QQ空间相册，产品很受欢迎，但对于技术团队来说，一个首先面对的问题就是：撑不住了。存储方案也好，流量方案也好，索引方案也好，都支撑不了用户诉求。“整个底层存储都已经疯掉了，”邹方明来到这个部门时，恰好经历了这样的时代。一些公司在近几年赞助春晚或遇到突发事件时，突然发现的问题，腾讯在十几年前也遇到过。现在微信、QQ系统的稳定，是当年吃亏后积累的经验教训。
用户对图片的诉求，延伸出了腾讯第一代存储系统，衍生了TFS，之后有了相册系统，不过，当时，他们还没有想到做技术平台。
不久，新矛盾爆发。QQ农场火爆后，每个用户都有很多头像，但原有的相册系统支撑不了图像高IO（输入输出）。这种情况下，邹方明把相册系统做了简单的分支，就叫头像系统。
头像系统和相册系统，都是图片，应该分开还是融合？内部当时有些焦灼，经过很长的PK，他们觉得，还是应该融合到一起。融合之后，腾讯有了第一个技术平台，图片平台。
相对于之前各自分离的系统，平台的优势在于成本。腾讯其他团队也在做图片服务，他们发现，花了这么多年研发精力，还不如接入到图片平台中，把研发团队的生产力解放出来。
腾讯的其他平台随后逐渐诞生。
2016年，视频平台诞生。2019年，音视频传输平台形成。期间还有红包系统、文件系统、网盘系统，用户最核心的几个场景平台，都由基础架构部搭建完成。
长期以来，腾讯在互联网公司中都以产品力著称，产品的背后，是技术平台的助力。
去年火爆的视频号就是一个典型案例，一年时间，视频号推出了一系列功能，产品人员提出功能需求后，技术人员第二天或者是第三天就能拿出方案，这离不开平台的服务和支撑。“产品有想法时，研发人员能够很快速做出一个模型，尽快做迭代和尝试。”邹方明解释，“能够在60分的基础上去做加法，产品技术团队可以把视角放在用户喜欢玩的玩法上面，放在终端体验的细节上面去，从而从整个研发的长周期中挣脱出来。”
微信诞生10年，背后的系统也有所不同。2016年之前，系统处于性能不足阶段，当时出现问题，无论是漏洞或是代码问题，事件爆发的根本原因是，系统能力不足导致的故障。
2016年之后，系统升级，此后再有热点，或是再有突然事件，对于技术来说，就只是量级提高了，都在系统可以支撑的范围内。
在云时代，系统的支撑能力又有了增加。QQ于2020年完全上云，整体都在云端。微信花了3年时间上云，今年会全部上云。上云的好处是，如果有突发情况要从其他的业务腾挪资源，速度快很多。“否则我们就得先把设备从A业务上下来，再添加到B业务去，再做测试验证，这样时间就长很多。”
微信10年，系统的基础建设主要朝着两个主要的目标在做。“一个是系统的 健康 性，比如你的熔断能力，自我恢复能力，每年我们都在找方法。另一个方向就是系统单位成本的承载能力。从字面上去解释，因为我们的资源团队、产品团队，都会给出一个固定的成本，这固定的10000台设备，能够支撑100万次请求，还是500万次请求，是每年都在持续优化和迭代的过程。我们会发现，只要你的承载能力强了，就可以把每个危急时刻变成不危急。”邹方明说。
产品不崩的方法论
不过，即使有了系统，也不能完全保证不崩。尤其对于一款12亿人使用的社交产品，任何时刻都有不可控性。
直到现在，腾讯技术团队也不敢打包票说系统完全可控。“推演也是算不过来的，总会算错的。比如说零点全国发红包的人到底有多少？公司发红包的量到底有多少？这个东西说实话不是那么好估了，这个时候我们就会想，有没有保底的大招，来使得这个访问量控制在系统可接受的范围之内，这是非常重要的保底措施。”肖志立说。
崩盘之前，技术部门会提前预演，策划好“剧本”，“剧本”是一种柔性控制，也可以统称为降级。微信用户有时在高峰期会觉得微信消息有延迟，或是朋友圈视频分辨率降低，就是一种降级。
当系统遭遇了远超预估的访问量，就要降级，比如朋友圈视频平时一个视频大概2兆，但高峰时刻可以先砍一刀，把2兆砍成1兆，让更多的人有视频可以看。
在不可预判的业务场景，他们基本上都会以这种方法去应对。“高突发的时候，用户不会用得那么爽，但能让90%用户觉得满意，不至于说突然量超过预期了，然后就立刻不行了”。
这个技术方法论被视为腾讯的保底大招，多年来屡试不爽。
如今只道是寻常
2021年春节，腾讯基础架构部在一片祥和中度过。除夕5点半，肖志立把当时留守的几十个兄弟拉到办公室对面的一个餐厅聚餐，吃到6点半，回来守着机器一起度过了除夕夜。
全程没有任何惊险时刻，无惊无喜。
肖志立依旧全程盯着。他每年春节前后都在，春节是最考验微信的时刻，在他们技术内部看来，平时吹什么牛，都不如扛过春晚的流量来的实在。“每次我也在想，我也不去敲代码，也不去做指令，为什么我要在？我能够感觉到就是崩盘了之后，大家都指着我去做‘要人命’的决定，出了故障我才有价值，没出故障我就像一个闲人。”邹方明已经记不清自己守过了多少个春晚，只是觉得很感慨。
在基础架构师的职业生涯里，非常重要的一点，就是在关键时刻做出关键决策。
2018年之后，微信很少再有关键时刻。这一年，微信红包的用户量基本上接近于微信的用户量，之后的增长基本上已经平稳。
肖攀最近两年也没有再拜过QQ公仔了，“都比较有信心。”
现在的系统，已经不再需要大的变动。并且多年春节经验后，团队值班的手段和策略都是已经完备和成熟的，还可以提前预判事件。比如今年，他们预测云年夜饭会提前导致一个小高峰，果然，当晚7点的流量是往年5倍，因为已经提前预测，今年也平稳度过。
对于现在的腾讯技术团队，不再有惊心动魄的故事发生。
架构师的经验教训
微信成立10年，腾讯技术团队也跟着走了10年，他们经历高压，经历崩溃，经历焦虑，到现在视为寻常，一路走来，他们见证微信用户从0涨到12亿用户，与有荣焉。“做技术支撑的团队，一定要有一个好的心态，就是你不在聚光灯下，但是我们心里面知道今天在台上的产品那么成功，跟我们是有很大关系的，自己的内心要足够强大，要相信这一点。”
他们也摸索出了足够多和业务部门沟通的方法。邹方明经常给团队灌输的理念是，除非你有确凿的依据能证明你是对的，不然你就先听业务部门的。
目前，微信背后的技术系统已经接近完善，“没有特别明显的缺陷和短板。”肖志立对此很自信。
不过，技术团队依旧存在焦虑感。其实，腾讯这支技术团队一直很稳定，腾讯内部架构几经大动，技术部门始终没变。他们经历了文字互联网时代、图片互联网时代，到了视频互联网时代，再到现在的实时音视频互联网时代，技术一直在演进，内容越来越丰富，实时性越来越强。这对于背后系统承载能力的要求，对于稳定性、延时的要求，也要比原来高很多，技术永无止境，他们也永远等待攻克下一个难关。
邹方明还在持续学习中。他经常参加线下活动，在一些论坛或峰会上，奔到现场面对面和业界大牛交流取经，“我们不能够关着门做，你必须要到外面找一些可学习的点，业界的大牛很多，他们会有很多比较好的创意和方法论。”“你永远不知道什么时候冒出一个新的东西。”肖志立很感慨，“作为支撑团队，我们得有这种魄力和能力，能够在弹药不够的情况下支持业务团队打胜仗。”
我公司购买了运输进项发票，税务检查，如税务要求查是否是真实性应该怎么查
税务检查运输进项发票真实性的查看方法如下：
1、调取注销清算报告，汇算清缴报告；
2、查询注册资本金印花税、地税是否上交；
3、税局专管员批复之前把电子账、报表上传到报税的网站，即能够查询。
运输发票税额是对增值税一般纳税人外购货物或销售货物（固定资产除外）所支付的运输费用（代垫运费除外），根据运费结算单据（普通发票）所列运费金额，依9%的扣除率计算进项税额准予扣除，但随同运费支付的装卸费、保险费等其他杂费不得计算扣除进项税额。发票是指一切单位和个人在购销商品、提供或接受服务以及从事其他经营活动中，所开具和收取的业务凭证，是会计核算的原始依据，也是审计机关、税务机关执法检查的重要依据。收据才是收付款凭证，发票只能证明业务发生了，不能证明款项是否收付。
发票是指经济活动中，由出售方向购买方签发的文本，内容包括向购买者提供产品或服务的名称、质量、协议价格。除了预付款以外，发票必须具备的要素是根据议定条件由购买方向出售方付款，必须包含日期和数量，是会计账务的重要凭证。中国会计制度规定有效的购买产品或服务的发票称为税务发票。政府部门收费、征款的凭证各个时期和不同收费征款项目称呼不一样，但多被统称为行政事业收费收款收据。为内部审计及核数，每一张发票都必须有独一无二的流水账号码，防止发票重复或跳号。
《中华人民共和国税收征收管理法》第三条 税收的开征、停征以及减税、免税、退税、补税，依照法律的规定执行；法律授权国务院规定的，依照国务院制定的行政法规的规定执行。任何机关、单位和个人不得违反法律、行政法规的规定，擅自作出税收开征、停征以及减税、免税、退税、补税和其他同税收法律、行政法规相抵触的决定。
delphi 分布式架构怎么学
由于分布式系统所涉及到的领域众多，知识庞杂，很多新人在最初往往找不到头绪，不知道从何处下手来一步步学习分布式架构。
本文试图通过一个最简单的、常用的分布式系统，来阐述分布式系统中的一些基本问题。
负载均衡
分布式缓存
分布式文件系统/CDN
分布式RPC
分布式数据库/Nosql
分布式消息中间件
分布式session问题
-总结
下图为一个中大型网站/App的基本架构：
在这个架构中，涉及到以上所列的基本问题：
负载均衡
负载均衡是分布式系统中的一个最最基本的问题。在上图中：
网关需要把请求分发给不同的Tomcat；
Tomcat需要把收到的请求，分发给不同的Service；
这都需要负载均衡。一句话：凡是请求从一个入口进来，需要分发给后端不同的机器时，就需要负载均衡。
局域网负载均衡
在上图中，负载均衡发生在局域网内部。在这里，常用的网关软件有Nginx/HAProxy/F5/LVS/各种云上的SLB等。
广域网负载均衡
在上图之外，还有广域网负载均衡。这通常发生在域名服务器上，而不是局域网内部。
同1个域名，映射到不同的局域网集群。
负载均衡算法
常用的负载均衡算法：随机，轮询（Round Robin)，最小资源数，hash。
分布式缓存
在上图中，当DB负载过高，我需要为Service机器加缓存时，就遇到一个基本问题：
如果使用local的内存做缓存，则其他Service机器就没办法共用此缓存。
因次，我需要一个可以让所有Service机器共享的缓存，这就是分布式缓存。
常用的分布式缓存组件：Memcached/Redis/Tair等
分布式文件系统
在上图中，当我要存储客户端上传的图片文件时，就会遇到另一个基本问题：我不能把图片存在每个Tomcat的本地文件系统里面，这样的话，其他机器就没办法访问了。我需要一个让所有机器可以共享的文件系统，这就是分布式文件系统。
常用的分布式文件系统：MogileFS/TFS/HDFS/Amazon S3/OpenStack Swift等
当使用了分布式文件系统，对外提供图片url访问服务时，就会遇到另一个基本问题：如果每次文件的访问，都要到分布式文件系统里面去取，效率和负载就可能成为问题。
为此，就需要引入CDN。
常用的CDN厂商，比如ChinCache。当然，现在的各种云存储，比如七牛云，阿里云，腾讯云，已经自带了CDN。
分布式RPC
分布式系统的一个基本问题就是：机器与机器之间如何通信？ 我们都知道底层原理是TCP/IP，Socket。
但一般很少有人会去裸写Socket，实现机器之间的通信。这里，最常用的组件就是RPC。
最简单的实现RPC的方式就是使用http。当然，业界有很多成熟的开源RPC框架，如Facebook的Thrift, 阿里的Dubbo，点评的Pigeon。。
在RPC内部，一般都自己实现了负载均衡。还有更复杂的，如多版本，服务降级等。
补充一句：虽然底层原理都是Socket，但使用不同框架/组件时，通常都有其自己的跨机器通信方式，比如Mysql JDBC，RPC， 消息中间件等。
分布式数据库
在上图中，DB是单一节点。当访问量达到一定程度，就会涉及到Mysql的分库分表问题。
分库/分表之后，就会涉及到join的问题，分布式事务的问题。
关于分库分表，业界也早有成熟方案。对上层屏蔽分库分表，sql的执行，像是在单库一样。
还有像MongoDB这种Nosql数据库，天生是分布式的。但同样会面对Mysql分库分表所要面对的问题。
还有像阿里的OceanBase，有Mysql的强一致性保证，又是分布式的，还可以支持分布式事务。
分布式消息中间件
在上图中，没有提及到消息中间件。相对其他基本问题，这个需要一个更适合的业务场景来谈，在以后的章节中，会再详述。
常用的消息中间件，比如老一辈的ActiveMQ/RabbitMQ， 新一点的，阿里的RocketMQ，LinkedIn的Kafka等。
消息中间件的一个典型场景就是：通过最终一致性，解决上面的分布式事务问题。
分布式session问题
在传统的单机版应用中，我们经常使用session。而当单机扩展到多机，单机的session就没办法被其他机器所访问。
此时就需要使用分布式session，把session存放在一个所有Tomcat都可以访问的地方。
关于分布式session，业界早有成熟方案，在此不再详述。
总结
本文罗列了分布式系统的各种基本问题和业界常用的技术，希望建立起分布式系统的一个宏观图谱。
发表评论
暂时没有评论，来抢沙发吧~