即时通讯

本文由ELab团队公众号受权公布，原题《Rust语言在IM客户端的实际》，来自抖音电商前端团队的分享，本文有订正和改变。1、引言本文将介绍飞鸽IM前端团队如何联合Rust对飞鸽客户端接待能力进行的技术晋升，一步步从概念验证、门路合成到分工开发，再到最初上线收益论证，并分享了其中遇到的技术挑战与经验总结等。本我的项目是一个长周期的简单我的项目，置信本我的项目落地的教训对其他同学及团队能有所借鉴。技术交换： 挪动端IM开发入门文章：《新手入门一篇就够：从零开发挪动端IM》开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）（本文已同步公布于：http://www.52im.net/thread-4620-1-1.html）2、技术背景飞鸽是在抖音电商业务上面向商家和用户的聊天工具，其拉通售前、售中、售后渠道，为商家履约提供重要撑持。对于飞鸽桌面端IM而言，咱们会面临很多根底挑战，比方做好会话稳定性、操作流畅性、冷启动速度等，而在满足98%以上的用户需要且业务趋于稳定后，一些在冲刺后遗留的性能天花板问题裸露在咱们背后，其中 高并发接待 & 多开是两个重要的挑战，是旧账与难啃的硬骨头。为何继续会有这些挑战存在？1）历史技术选型，蕴含者老本、人力、效率等考量，飞鸽客户端应用的技术栈是react + electron：* im sdk与业务渲染代码都由 js 编写，im sdk同时是cpu密集型 & io 密集型的组件，在高并发场景下，渲染频率也比拟高，业务与sdk互相抢占cpu资源与io资源，导致收发音讯慢、操作卡顿（高并发限度）。* 因为im sdk运行在webview中，所以收发音讯依赖webview存活，故多开账号 = 多个webview，内存老本线性增长。2）im页面在web层面屡次优化后已靠近架构下限，无奈基于现有架构做更多天花板的冲破。对于以上这些挑战，咱们给出的解法是：对现有架构进行调整，应用Rust语言对im sdk进行重写，彻底解除这一块的性能瓶颈！ 3、为什么选Rust语言？飞鸽im sdk是一个对运行稳定性要求高的组件，其工程量大、逻辑简单，对于异步个性应用十分频繁，其对于内存平安、 线程平安有着比拟严格的要求。如果应用C++，作为老手并没有把握可能将简单的IM SDK少bug的编写下来（团队限度）。Rust学习曲线尽管平缓，然而其为平安设计的各类语言个性、弱小的编译器，可能将新人编写代码的问题数降到最低（逻辑问题除外）。并且飞书团队提供了客户端的rust生态库，帮忙咱们解决很多的基建问题，所以这里应用Rust是相当适合的。Rust学习成长曲线： 4、飞鸽IM客户端历史架构的问题如背景中所形容，历史架构存在这两个问题：1）IM SDK 与 业务JS代码共用Weview资源，接待密集的时候，sdk与业务，相互抢占cpu与io资源，导致容易卡顿、音讯提早；2）多开的账号必须依赖IM Webview存活（否则无奈收到音讯），内存线性增长。 5、飞鸽IM客户端新架构与预期指标具体是：1）Rust独立过程承当所有的im sdk的计算压力，能够大幅加重js线程压力，可晋升压力场景接待体验；2）Rust im SDK 解除浏览器中的IO限度（如同域名并发数限度）；3）解除Webview存活依赖，依附rust过程也可收音讯，为更多账号的多开能力提供了铺垫。 6、先用Rust进行技术可行性验证为了验证揣测切实可行，咱们提前做了齐备的POC验证。在POC中，咱们针对“单过程单线程模型”、“多过程模型”、“多线程模型”，这三种模型搭建了mvp demo，即繁难的客服聊天模型，并进行压力测试，并监测其内存、cpu等指标。通过POC，咱们得出的论断是：具体就是：1）rust 整体优于 js，计算占比越重，劣势越显著（低压时cpu差异能达到3倍以上）；2）架构选型上，rust过程独立是最好的计划，稳定性更优、性能损耗相差较小。 7、新架构开始施行路要一步步走，整个我的项目粗估下来会有上百的工作日，作为业务团队，咱们无奈在短期内投入大量的资源去做这个我的项目，所以须要一步一步拆解、验证、拿收益。团队内native开发资源无限，这件事件的进行也须要团队进行学习、成长。上面咱们将具体分享这个过程 。 8、新架构施行阶段1：Rust SDK工程基建造房子先得有一个地基 —— Rust工程的根底建设，是Native业务的前置条件！桌面端同学牵头搭建了整个RustSDK地基，地基解决的问题如下图所示：须要做的工作：1）业务容器：有法则的组织代码构造，进行业务隔离、资源隔离；2）跨过程调用封装：升高业务调用难度；3）建设日志零碎、日志回捞：升高排查问题的难度；4）构建跨平台异步执行环境：简化异步代码编写，底层封装，便于跨平台代码迁徙；5）跨平台编译，跨平台集成；6）... ... 9、新架构施行阶段2：IM根底能力夯实在领有一部分地基后，咱们开始针对IM SDK的根底能力进行实现和验证。因为只有实现根底能力验证之后，咱们才会有信念在新的架构上叠加更多的性能。这阶段咱们关注以下指标（ 心愿其存在优化，至多不劣化）：1）长链在线率；2）音讯发送成功率；3）卡顿率；4）Rust过程解体率、无响应率。仅实现长链能力下沉，验证&晋升其稳固：本阶段论证后果如下：1）Rust Crash率， 达成预期；2）Rust无响应率 - 未达预期，可优化；3）长链在线率 - 达成预期，然而存在优化空间；4）卡顿率 - 不劣化 达成预期；5）音讯发送成功率 - 不劣化，达成预期。这阶段的工作是考验急躁的，因为这个阶段并不能带来实质性的用户体验晋升、也无奈拿到显著的晋升数据，只是作为两头阶段，它有存在的必要性。这阶段后，在稳定性治理、根底能力验证、 Rust 语言教训、指标制订合理性这几方面，咱们踩上了一个更牢固的台阶，更有信念去进行更简单的下一阶段。 10、 新架构施行阶段3：应用Rust实现IM SDK全副能力夯实根底后，咱们开始发力冲刺，大刀阔斧的对IM SDK进行从新设计、实现、联调以及上线。此阶段要实现im sdk的全副能力、 并对线上运行的js im sdk进行替换。因为飞鸽im对于通信模块的稳固水平要求是很高的，替换过程就像是在高速行驶的车辆上替换轮胎，如果呈现问题也容易导致大量的客服负面反馈。因而，新rust sdk的稳定性、异样问题时的兜底计划、灰度时的监控察看、对新增反馈的注意都很重要，放量过程会存在肯定精神压力。工作内容大抵如下。1）多实例的Rust IM SDK设计（商家单聊、群聊、平台客服）、Js -> Rust IMSDK跨端调用协定设计：a）剖析、拆解所有Js Im SDK至今具备的能力，并以贴合Rust的形式从新设计；b）须要在协定设计中，尽可能的合并 & 简化 Js -> Rust的调用，以缩小IPC通信老本。2）开发：a）Rust IM SDK外围实现；b）Rust\Js适配同学严密单干，依据协定进行业务实现、业务适配；c）亲密沟通，发现问题及时纠偏；d）编写单测；3）测试：a）各类IM场景回归测试；b）性能进行验证。4）异样兜底计划实现：设计数据冗余，当Rust过程呈现解体、无响应、不可复原的网络谬误时，辨认并fallback到 web版本，应用冗余数据疾速复原im sdk失常运行状态，确保用户体验。5）稳当的上线计划 & 稳定性治理。6）调用&适配优化，联合Native能力进一步性能优化。7）后果回收。8）其中各个步骤都会存在一些挑战，在后前面的内容会提到。调用简化模型：IM Core简化模型： ...

为了更好地分类浏览 52im.net 总计1000多篇精编文章，我将在每周三推送新的一期技术文集，本次是第34 期。[- 1 -] 疾速裂变：见证微信弱小后盾架构从0到1的演进历程（一） [链接] http://www.52im.net/thread-168-1-1.html [摘要] 2个月的开发工夫，微信后盾零碎经验了从0到1的过程。从小步慢跑到疾速成长，经验了平台化到走出国门，微信交出的这份优异答卷，解题思路是怎么的？ [- 2 -] 如何保障IM实时音讯的“时序性”与“一致性”？ [链接] http://www.52im.net/thread-714-1-1.html [摘要] 实时音讯时序和一致性是分布式系统架构设计中十分难的问题（尤其IM利用这种以音讯为核心的利用状态），艰难在哪？有什么常见优化实际？这就是本文要探讨的内容。 [- 3 -] IM单聊和群聊中的在线状态同步应该用“推”还是“拉”？ [链接] http://www.52im.net/thread-715-1-1.html [摘要] “用户在线状态的一致性”（单聊好友在线状态、群聊用户在线状态）是IM应用领域比拟难解决的一个技术问题，如何精准实时的取得好友、群友的在线状态，是明天将要探讨的话题。 [- 4 -]IM群聊音讯如此简单，如何保障不丢不重？ [链接] http://www.52im.net/thread-753-1-1.html [摘要] 因为“音讯风暴扩散系数”的存在（概念详见《IM单聊和群聊中的在线状态同步应该用“推”还是“拉”？》），群音讯的复杂度要远高于一对一的单聊音讯。群音讯的实时性、可达性、离线音讯是明天将要探讨的外围话题。 [- 5 -] 微信后盾团队：微信后盾异步音讯队列的优化降级实际分享 [链接] http://www.52im.net/thread-801-1-1.html [摘要] 本文分享了该组件2.0版本的性能特点及优化实际，心愿能为相似业务（比方挪动端IM零碎等）的音讯队列设计提供肯定的参考。 [- 6 -] 挪动端IM中大规模群音讯的推送如何保障效率、实时性？ [链接] http://www.52im.net/thread-1221-1-1.html [摘要] 当然，理论在生产环境下，群音讯的发送都会想尽办法进行压缩，并发展各种改善性能的解决方法，而不是像上述举例里的间接扩散写（即2000人群里，一条音讯被简略地复制为2000条一对一的音讯投递）。具体有哪些优先策略？本文或者能够带给你一些启发。 [- 7 -] 古代IM零碎中聊天音讯的同步和存储计划探讨 [链接] http://www.52im.net/thread-1230-1-1.html [摘要] 本文内容次要波及IM零碎中的音讯零碎架构，探讨一种实用于大用户量的音讯同步以及存储系统的架构实现，可能反对音讯零碎中的高级个性『多端同步』以及『音讯漫游』。在性能和规模上，可能做到全量音讯云端存储，百万TPS以及毫秒级提早的音讯同步能力。 [- 8 -] 对于IM即时通讯群聊音讯的乱序问题探讨 [链接] http://www.52im.net/thread-1436-1-1.html [摘要] 问题形容：客户端A、B、C，服务端S，例如：A发三条群音讯，B、C收到的音讯都是乱序，目前问题：A发第一条音讯失败之后排到队列，这时服务端还在继续发消息，那么第二条音讯送达到B、C，而后客户端最先显示的就不是第一条音讯，导致乱序呈现。 [- 9 -] IM群聊音讯的已读回执性能该怎么实现？ ...

为了更好地分类浏览 52im.net 总计1000多篇精编文章，我将在每周三推送新的一期技术文集，本次是第33 期。[- 1 -] IM开发技术学习：揭秘微信朋友圈这种信息推流背地的零碎设计 [链接] http://www.52im.net/thread-3675-1-1.html [摘要] 本文将重点探讨的是“关注”性能对应的技术实现：先总结罕用的基于工夫线Feed流的后盾技术实现计划，再联合具体的业务场景，依据理论需要在根本设计思路上做一些灵便的使用。 [- 2 -] 阿里IM技术分享(六)：闲鱼亿级IM音讯零碎的离线推送达到率优化 [链接] http://www.52im.net/thread-3748-1-1.html [摘要] 本文将要分享的是闲鱼IM音讯在解决离线推送的达到率方面的技术实际，内容包含问题剖析和技术优化思路等，心愿能带给你启发。 [- 3 -] 阿里IM技术分享(七)：闲鱼IM的在线、离线聊天数据同步机制优化实际 [链接] http://www.52im.net/thread-3856-1-1.html [摘要] 本篇将要分享的是闲鱼IM零碎中在线和离线聊天音讯数据的同步机制上所遇到的一些问题，以及实践性的解决方案。 [- 4 -] 探探的IM长连贯技术实际：技术选型、架构设计、性能优化 [链接] http://www.52im.net/thread-3780-1-1.html [摘要] 本文将要分享的是陌生人社交利用探探的IM长连贯模块从技术选型到架构设计，再到性能优化的整个技术实际过程和经验总结。 [- 5 -] IM开发干货分享：浅谈IM零碎中离线音讯、历史音讯的最佳实际 [链接] http://www.52im.net/thread-3887-1-1.html [摘要] 本文将基于IM音讯零碎的技术实际，分享对于离线音讯和历史音讯的正确理解，以及具体的技术配合和实际，心愿能为你的离线音讯和历史音讯技术设计带来最佳实际灵感。 [- 6 -] IM开发干货分享：IM客户端不同版本兼容运行的技术思路和实际总结 [链接] http://www.52im.net/thread-4202-1-1.html [摘要] 本文将基于笔者的IM产品开发和经营实际，为你分享如何实现不同APP客户端版本与服务端通信的兼容性解决计划。 [- 7 -] 字符编码那点事：疾速了解ASCII、Unicode、GBK和UTF-8 [链接] http://www.52im.net/thread-1693-1-1.html [摘要] 字符编码是计算机技术的基石，对于程序员来说尤其重要，字符编码的常识是必须要懂的。 [- 8 -] IM开发基础知识补课(八)：史上最艰深，彻底搞懂字符乱码问题的实质 [链接] http://www.52im.net/thread-2868-1-1.html [摘要] 对于乱码这个看似不起眼，但并不是一两话能讲清楚的问题，是很有必要从本源理解字符集和编码原理，知其然知其所以然显然是一个优良码农的根本素养，所以，便有了本文，心愿能帮忙到你。 [- 9 -] 史诗级计算机字符编码常识分享，万字长文，一文即懂！ ...

本文由去哪儿网技术团队田文琦分享，本文有订正和改变。1、引言本文针对去哪儿网酒店业务网关的吞吐率降落、响应工夫回升等问题，进行全流程异步化、服务编排计划等措施，进行了高性能网关的技术优化实际。技术交换： 挪动端IM开发入门文章：《新手入门一篇就够：从零开发挪动端IM》开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）（本文已同步公布于：http://www.52im.net/thread-4618-1-1.html）2、作者介绍田文琦：2021年9月退出去哪儿网机票目的地事业群，负责软件研发工程师，现负责国内酒店主站技术团队。次要关注高并发、高性能、高可用相干技术和零碎架构。主导的酒店业务网关优化我的项目，荣获22年去哪儿网技术核心TC我的项目三等奖。 3、专题目录本文是专题系列文章的第9篇，总目录如下：《长连贯网关技术专题(一)：京东京麦的生产级TCP网关技术实际总结》《长连贯网关技术专题(二)：知乎千万级并发的高性能长连贯网关技术实际》《长连贯网关技术专题(三)：手淘亿级挪动端接入层网关的技术演进之路》《长连贯网关技术专题(四)：爱奇艺WebSocket实时推送网关技术实际》《长连贯网关技术专题(五)：喜马拉雅自研亿级API网关技术实际》《长连贯网关技术专题(六)：石墨文档单机50万WebSocket长连贯架构实际》《长连贯网关技术专题(七)：小米小爱单机120万长连贯接入层的架构演进》《长连贯网关技术专题(八)：B站基于微服务的API网关从0到1的演进之路》《长连贯网关技术专题(九)：去哪儿网酒店高性能业务网关技术实际》（* 本文） 4、技术背景近来，Qunar 酒店的整体技术架构在基于 DDD 指导思想下，始终在进行调整。其中最次要的一个调整就是蕴含外围畛域的团队交出各自的“应用层”，对立交给上游网关团队，组成对立的应用层。这种由多个网关合并成大前台(酒店业务网关)的交融，带来的益处是外围零碎边界清晰了，然而对酒店业务网关来说，也带来了不小的困扰。零碎面临的压力次要来自两方面： 1）首先，一次性新增了几十万行大量硬编码、长期兼容、聚合业务规定的简单代码且代码格调迥异，有些甚至是跨语言的代码迁徙；2）其次，后续的复杂多变的应用层业务需要，之前扩散在各个子网关中，当初在源源不断地汇总叠加到酒店业务网关。这就导致了一系列的问题：1）业务网关吞吐性能变差：应答流量尖峰期间的单机最大吞吐量与合并之前相比，降落了20%2）外部业务逻辑处理速度变差：主流程业务逻辑的解决工夫与合并之前相比，上涨了10%。3）代码难以保护、开发效率低：主站外部各个模块之间重大耦合，边界不清，批改扩散问题非常明显，给后续的迭代减少了保护老本，开发新需要的效率也不高。酒店业务网关作为间接面对用户的零碎，呈现任何问题都会被放大百倍，上述这些问题亟待解决。5、吞吐量降落问题剖析现有零碎尽管业务解决局部是异步化的，然而并不是全链路异步化（如下图所示）。同步 servlet 容器，servlet 线程与业务逻辑线程是同一个，高峰期流量上涨或者尤其是遇到流量尖峰的时候，servlet 容器线程被阻塞的时候，咱们服务的吞吐量就会显著降落。业务解决尽管应用了线程池的确能实现异步调用的成果，也能压缩同步期待的工夫，然而也有一些缺点。比方： 1）CPU 资源大量节约在阻塞期待上，导致 CPU 资源利用率低；2）为了减少并发度，会引入更多额定的线程池，随着 CPU 调度线程数的减少，会导致更重大的资源争用，上下文切换占用 CPU 资源；3）线程池中的线程都是阻塞的，硬件资源无奈充分利用，零碎吞吐量容易达到瓶颈。6、响应工夫上涨问题剖析后期为了疾速落地酒店 DDD 架构，合并大前台的重构中，并没有做到一步到位的设计。为了保障我的项目品质，将整个过程切分为了迁徙+重构两个步骤。迁徙之后，整个酒店业务网关的外部代码构造是割裂、凌乱的。总结如下：咱们最外围的一个接口会调用70多个上游接口，上述问题：边界不清、不内聚、各种反复调用、依赖阻塞等问题导致了外围接口的响应工夫有显著上涨。 7、 解决方案Part1：全流程异步化晋升吞吐量全流程异步化计划，咱们次要采纳的是 Spring WebFlux。 7.1抉择的理由1）响应式编程模型：Spring WebFlux 基于响应式编程模型，应用异步非阻塞式 I/O，能够更高效地解决并发申请，进步应用程序的吞吐量和响应速度。同时，响应式编程模型可能更好地解决高负载状况下的申请，升高零碎的资源耗费。2）高性能：Spring WebFlux 应用 Reactor 库实现响应式编程模型，能够解决大量的并发申请，具备杰出的性能体现。与传统的 Spring MVC 框架相比，Spring WebFlux 能够更好地利用多核 CPU 和内存资源，以实现更高的性能和吞吐量。3）可扩展性：Spring WebFlux 不仅能够应用 Tomcat、Jetty 等惯例 Web 服务器，还能够应用 Netty 或 Undertow 等基于 NIO 的 Web 服务器实现，与其它非阻塞式 I/O 的框架联合应用，能够更容易地构建可扩大的应用程序。4）反对函数式编程：Spring WebFlux 反对函数式编程，应用函数式编程能够更好地解决简单的业务逻辑，并进步代码的可读性和可维护性。5）50与 Spring 生态系统无缝集成：Spring WebFlux 能够与 Spring Boot、Spring Security、Spring Data 等 Spring 生态系统的组件无缝集成，提供了残缺的 Web 利用程序开发体验。 ...

本文由阮一峰(ruanyifeng.com）分享，本文收录时有内容订正和排版优化。1、引言明天中午，我忽然想搞清楚 Unicode 和 UTF-8 之间的关系，就开始查资料。这个问题比我设想的简单，午饭后始终看到早晨9点，才算初步搞清楚。上面就是我的总结，次要用来整顿本人的思路。我尽量写得通俗易懂，心愿能对其余敌人有用。毕竟，字符编码是计算机技术的*石，对于程序员来说尤其重要，字符编码的常识是必须要懂的。  技术交换： 挪动端IM开发入门文章：《新手入门一篇就够：从零开发挪动端IM》开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）（本文已同步公布于：http://www.52im.net/thread-4433-1-1.html）2、专题目录本文是“字符编码技术专题”系列文章的第 1 篇，总目录如下：《字符编码技术专题(一)：疾速了解ASCII、Unicode、GBK和UTF-8》（* 本文）《字符编码技术专题(二)：史诗级计算机字符编码常识入门，一文即懂！》《字符编码技术专题(三)：彻底搞懂字符乱码的实质，一篇就够！》《字符编码技术专题(四)：史上最艰深大小端字节序详解，一文即懂！》《字符编码技术专题(五)：前端必读的计算机字符编码常识入门》 3、基础知识计算机中贮存的信息都是用二进制数示意的；而咱们在屏幕上看到的英文、汉字等字符是二进制数转换之后的后果。艰深的说，依照何种规定将字符存储在计算机中，如'a'用什么示意，称为"编码"；反之，将存储在计算机中的二进制数解析显示进去，称为"解码"，如同密码学中的加密和解密。在解码过程中，如果应用了谬误的解码规定，则导致'a'解析成'b'或者乱码。 字符集（Charset）：是一个零碎反对的所有形象字符的汇合。字符是各种文字和符号的总称，包含各国家文字、标点符号、图形符号、数字等。 字符编码（Character Encoding）：是一套法令，应用该法令可能对自然语言的字符的一个汇合（如字母表或音节表），与其余货色的一个汇合（如号码或电脉冲）进行配对。即在符号汇合与数字零碎之间建设对应关系，它是信息处理的一项本技术。通常人们用符号汇合（个别状况下就是文字）来表白信息。而以计算机为础的信息处理系统则是利用元件（硬件）不同状态的组合来存储和解决信息的。元件不同状态的组合能代表数字零碎的数字，因而字符编码就是将符号转换为计算机能够承受的数字零碎的数，称为数字代码。 常见字符集名称：ASCII字符集、GB2312字符集、BIG5字符集、GB18030字符集、Unicode字符集等。计算机要精确的解决各种字符集文字，须要进行字符编码，以便计算机可能辨认和存储各种文字。 4、ASCII 码咱们晓得，计算机外部，所有信息最终都是一个二进制值。每一个二进制位（bit）有0和1两种状态，因而八个二进制位就能够组合出256种状态，这被称为一个字节（byte）。也就是说，一个字节一共能够用来示意256种不同的状态，每一个状态对应一个符号，就是256个符号，从00000000到11111111。上个世纪60年代，美国制订了一套字符编码，对英语字符与二进制位之间的关系，做了对立规定。这被称为 ASCII 码，始终沿用至今。ASCII 码一共规定了128个字符的编码，比方空格SPACE是32（二进制00100000），大写的字母A是65（二进制01000001）。这128个符号（包含32个不能打印进去的管制符号），只占用了一个字节的前面7位，最后面的一位对立规定为0。▲ ASCII编码表 5、非 ASCII 编码英语用128个符号编码就够了，然而用来示意其余语言，128个符号是不够的。比方，在法语中，字母上方有注音符号，它就无奈用 ASCII 码示意。于是，一些欧洲国家就决定，利用字节中闲置的最高位编入新的符号。比方，法语中的é的编码为130（二进制10000010）。这样一来，这些欧洲国家应用的编码体系，能够示意最多256个符号。▲ 扩大ASCII编码表然而，这里又呈现了新的问题。不同的国家有不同的字母，因而，哪怕它们都应用256个符号的编码方式，代表的字母却不一样。比方，130在法语编码中代表了é，在希伯来语编码中却代表了字母Gimel ()，在俄语编码中又会代表另一个符号。然而不管怎样，所有这些编码方式中，0--127示意的符号是一样的，不一样的只是128--255的这一段。至于亚洲国家的文字，应用的符号就更多了，汉字就多达10万左右。一个字节只能示意256种符号，必定是不够的，就必须应用多个字节表白一个符号。比方，简体中文常见的编码方式是 GB2312，应用两个字节示意一个汉字，所以实践上最多能够示意 256 x 256 = 65536 个符号。中文编码的问题比较复杂，将在文末探讨。这里先理解下，尽管都是用多个字节示意一个符号，然而GB类的汉字编码与后文的 Unicode 和 UTF-8 是毫无关系的。 6、Unicode正如上一节所说，世界上存在着多种编码方式，同一个二进制数字能够被解释成不同的符号。因而，要想关上一个文本文件，就必须晓得它的编码方式，否则用谬误的编码方式解读，就会呈现乱码。为什么电子邮件经常呈现乱码？就是因为发信人和收信人应用的编码方式不一样。能够设想，如果有一种编码，将世界上所有的符号都纳入其中。每一个符号都给予一个举世无双的编码，那么乱码问题就会隐没。这就是 Unicode，就像它的名字都示意的，这是一种所有符号的编码。Unicode 当然是一个很大的汇合，当初的规模能够包容100多万个符号。每个符号的编码都不一样，比方，U+0639示意阿拉伯字母Ain，U+0041示意英语的大写字母A，U+4E25示意汉字严。具体的符号对应表，能够查问unicode.org，或者专门的汉字对应表。 7、Unicode 的问题须要留神的是，Unicode 只是一个符号集，它只规定了符号的二进制代码，却没有规定这个二进制代码应该如何存储。比方，汉字严的 Unicode 是十六进制数4E25，转换成二进制数足足有15位（100111000100101），也就是说，这个符号的示意至多须要2个字节。示意其余更大的符号，可能须要3个字节或者4个字节，甚至更多。这里就有两个重大的问题，第一个问题是，如何能力区别 Unicode 和 ASCII ？计算机怎么晓得三个字节示意一个符号，而不是别离示意三个符号呢？第二个问题是，咱们曾经晓得，英文字母只用一个字节示意就够了，如果 Unicode 对立规定，每个符号用三个或四个字节示意，那么每个英文字母前都必然有二到三个字节是0，这对于存储来说是极大的节约，文本文件的大小会因而大出二三倍，这是无奈承受的。它们造成的后果是：1）呈现了 Unicode 的多种存储形式，也就是说有许多种不同的二进制格局，能够用来示意 Unicode。2）Unicode 在很长一段时间内无奈推广，直到互联网的呈现。 8、UTF-8互联网的遍及，强烈要求呈现一种对立的编码方式。UTF-8 就是在互联网上应用最广的一种 Unicode 的实现形式。其余实现形式还包含 UTF-16（字符用两个字节或四个字节示意）和 UTF-32（字符用四个字节示意），不过在互联网上*本不必。反复一遍，这里的关系是，UTF-8 是 Unicode 的实现形式之一。UTF-8 最大的一个特点，就是它是一种变长的编码方式。它能够应用1~4个字节示意一个符号，依据不同的符号而变动字节长度。 UTF-8 的编码规定很简略，只有二条：1）对于单字节的符号：字节的第一位设为0，前面7位为这个符号的 Unicode 码。因而对于英语字母，UTF-8 编码和 ASCII 码是雷同的；2）对于n字节的符号（n > 1）：第一个字节的前n位都设为1，第n + 1位设为0，前面字节的前两位一律设为10。剩下的没有提及的二进制位，全副为这个符号的 Unicode 码。下表总结了编码规定，字母x示意可用编码的位： ...

本文由腾讯WXG客户端开发工程师yecong分享，本文做了订正和改变。1、引言绝对于传统的生产级IM利用，企业级IM利用的非凡之外在于它的用户关系是依照所属企业的组织架构来关联的起来，而组织架构的大小是无奈预设下限的，这也要求企业级IM利用在遇到真正的超大规模组织架构时，如何保障它的利用性能不受限于（或者说是尽可能不受限于）企业架构规模，这是个比拟有难度的技术问题。本文次要分享的是企业微信在百对百万级大规模组织架构（后文简称大架构）时，是如何对客户端进行性能优化过程的，心愿带给你启发。内容分成两局部讲述，第一局部是短线迭代的优化，次要是并发性能的优化。第二局部是长线迭代的优化，次要是从业务模式上做了根本性优化。以下是相干文章，举荐一并浏览：《企业微信客户端中组织架构数据的同步更新计划优化实战》《企业微信的IM架构设计揭秘：音讯模型、万人群、已读回执、音讯撤回等》《钉钉——基于IM技术的新一代企业OA平台的技术挑战(视频+PPT) [附件下载]》《阿里钉钉技术分享：企业级IM王者——钉钉在后端架构上的过人之处》  技术交换： 挪动端IM开发入门文章：《新手入门一篇就够：从零开发挪动端IM》开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）（本文已同步公布于：http://www.52im.net/thread-4437-1-1.html）2、100万级组织架构时的性能问题当私有化的组织架构回升到100W的量级时，呈现了重大影响组织架构应用的问题：关上二级部门时，加载迟缓。如图所示，loading可能继续一分钟以上： 3、100万级组织架构的问题剖析咱们剖析一下加载二级部门的流程。上面是加载二级部门的流程图：1）如果素来没加载过该部门，须要从服务端拉取部门下的节点详情（这里是因为之前咱们曾经做了优化，首次登录时只拉取了部门的节点ID，没有拉取详情）；2）如果加载过该部门，就间接从DB读取该部门的数据，而后返回UI展现。当只有一条DB线程时，组织架构更新的工作，可能会插入到加载二级部门的工作的后面。而在百万级别的组织架构中，全量更新的DB工作有可能比拟久，全量更新的插入或者更新节点可能比拟多，导致原本很快能够实现的二级部门加载工作，要排队比拟久能力执行完。上面是组织架构全量更新的流程图：在这里，读写并发上呈现了显著的瓶颈。起因总结如下：1）加载二级部门和全量更新共用一条DB线程；2）当全量更新大量节点时，全量更新的低优先级工作卡住加载二级部门的高优先级工作。 4、针对100万级组织架构的优化计划4.1根本读写拆散为了进步组织架构在大规模数据下的读写并发性能，咱们开启了wal模式，把读写工作别离放在不同的线程中执行。针对加载二级部门的流程，能够在读线程中读取部门的详情节点，而组织架构更新能够在写线程中独自执行。因为加载二级部门的原流程是拉取数据、写入DB、再从DB读取数据，而且wal只反对一写多读，因而咱们调整了缓存策略，把保留节点详情的写工作提早到流程最初，优先结构了cache返回UI。这样从DB中读出数据的读工作，就不须要期待保留节点详情的写工作。防止了保留节点的写工作再次被其余写工作阻塞，读工作又被保留节点的写工作阻塞，进化成串行操作。 4.2WAL机制的原理调用方批改的数据并不间接写入到数据库文件中，而是写入到另外一个称为WAL的文件中，而后在随后的某个工夫点被写回到数据库文件中。在这个工夫点的回写操作，会升高数据库过后的读写性能。然而通过设置对WAL文件大小的限度，这种性能影响是可控的。实际上线后也没有遇到因为checkpoint同步导致数据库慢的反馈。 4.3缓存策略写策略的步骤：先更新缓存中的数据，再更新数据库中的数据。读策略的步骤：1）如果读取的数据命中了缓存，则间接返回数据；2）如果读取的数据没有命中缓存，则从数据库中读取数据，而后将数据写入到缓存，并且返回给UI。 4.4计划总结 5、100万级优化后的成果  在优化前，只有52%的用户能在1s内加载完二级部门。上线之后，93%的用户都能在1s内关上二级部门。耗时小于1s的用户占比晋升40%！ 6、当对面300万组织架构时的问题6.1概述当业务进一步倒退时，咱们预估将来将要达到300W量级的组织架构。于是咱们就开始提前布局如何能在组织架构数量始终增长的状况下，还能让组织架构晦涩好用。 6.2问题次要是：1）选人控件闪退和ANR；2）组织架构全量更新闪退。在300w的组织架构环境中，旧的组织架构加载计划，在全量更新、选人控件中均呈现了占用内存过大甚至闪退的问题。而且旧计划的加载工夫会随着节点数量的减少，不可避免地成正比增长。 6.3剖析以后计划的耗时、内存占用与用户组织架构的大小成正比，单点优化无奈满足组织架构持续增长的需要。具体来说，会造成上面的一些问题：1）选人控件会加载全量的组织架构ID树，数量过多时容易产生闪退和ANR；2）组织架构全量更新占用内存过大，造成闪退。因而，咱们须要一个新的业务模式，即使总的组织架构规模始终上涨的状况下，也能维持较好的性能。 7、针对300万组织架构的优化计划比拟容易想到的一个计划是web加载的模式，不保留本地数据，然而体验比拟差，每层都会出loading。分割到咱们的具体业务，因为私有化对不同的部门，划分出了具备意义的独立组织机构——单位。单位是具备治理意义的部门，不同单位能够独立加载。而每个人，也领有主单位和兼岗单位。所以能够依照单位加载的形式，从根本上解决目前组织架构面临的瓶颈。按单位加载，能够简略了解为按部门加载：概念定义：1）单位：政府行政组织构造中的职能部门，组建架构并承当对应责任；2）主单位：“我”所在的单位；3）其余单位：除了“我”所在的其余单位；4）骨架：通讯录骨架蕴含了所有的单位节点；5）一般部门：不属于任何单位的部门节点。下图是组织架构树的示意图：如上图所示：蓝色节点是优先加载的本单位，灰色节点是其余单位，红色节点是骨架。不同的单位独立加载。 8、300万优化计划中的“按单位加载”技术思路8.1加载策略接下来咱们看看加载策略。第一：是对本人所在的主单位（蓝色节点），每次唤醒时就会更新，跟旧组织架构的逻辑相似，然而会限度拉取节点的数量。第二：对于其余单位（灰色节点），点击到该单位时才会拉取，2个小时后会淘汰删除，防止数据表过大。第三：对于骨架（红色节点），会全量加载节点ID，再拉取节点详情。拉取策略限度了可能拉取的节点详情数量，如果单位节点数量超过了限度，首先拉取全量ID，再依照优先规定，拉取配置的节点详请数量。 8.2加载流程加载的流程是先拉取本人的单位列表，而后拉取每个单位的全量通讯录ID，再依照后盾策略，拉取所需的具体节点，最初拉取骨架。如果点击到主单位：1）如果只有ID没有节点，会立即拉取节点详情返回界面；2）如果ID和节点详情都有，能够间接返回UI展现，而后提早刷新节点。如果是点击到其余单位：可能呈现ID和详情都没有的状况，须要拉取其余单位的节点，界面loading期待。如果是骨架：就肯定有节点和详情，只须要提早刷新。 9、300万优化计划的分层设计思路接下来咱们看看如何分层。在300万量级的大规模组织架构下，挪动端和pc端都呈现了组织架构卡顿、闪退的问题，所以咱们心愿可能开发一套各端共用的逻辑，对立保护。第一：是要抽取公共的根底库，包含boost库、工作框架、线程治理框架等。第二：是设计公共的数据结构。第三：因为不同端的网络库差别比拟大，这里不好齐全共用，所以须要抽取网络工作接口，由各端独立实现。具体到框架图，咱们从下往上看：1）底层是根底库；2）接着是C++实现的跨平台业务层；3）Service层是挪动端和pc端离开实现，次要是做接口调用和回调的简略封装；4）下层则各端界面实现。下层界面为了兼容新旧两套组织架构，也做了接口形象，能够通过开关自在切换。这样长处就是有对立的业务逻辑代码、DB设计和线程治理。关键点：1）抽取公共根底库；2）形象公共的数据结构；3）形象网络层和数据库层接口。长处：对立的业务逻辑代码、DB设计、线程治理。 10、300万优化计划的整体架构设计思路在具体实现之前，咱们来看看架构设计的一些概念。 10.1架构整洁之道1）业务实体和用例：要害业务逻辑和要害业务数据是严密相干的，所以它们很适宜被放在同一个对象中解决。咱们将这种对象称为“业务实体”。业务实体这个概念中应该只有业务逻辑，没有别的，与数据库、用户界面、第三方框架等内容无关。用例所形容的是某种特定利用情景下的业务逻辑，能够了解为：输出 + 业务实体 + 输入 = 用例。2）软件架构：软件的零碎架构应该为该零碎的用例提供反对。一个良好的架构设计应该围绕着用例来开展，这样的架构设计能够在脱离框架、工具以及应用环境的状况下残缺地形容用例。3）整洁架构：下图的同心圆别离代表了软件系统中的不同档次，越凑近核心，其所在的软件档次就越高。基本上，外层圆代表的是机制，内层圆代表的是策略。这其中有一条贯通整个架构设计的规定，即依赖关系规定： 10.2咱们的架构咱们的类图与架构设计概念的对应关系如下：1）业务实体：ArchTask；2）用例：ArchProto；3）模型层：即最外层，各种第三方框架，如DbInterface（数据库模块）、ArchLogicHandler（网络模块）等。咱们从一次具体的业务调用流程来看看这样设计的意义。上面是从UI发动的一次架构更新流程，大家能够次要关注控制流是怎么穿梭各层的边界：控制流从最外层的用户界面开始，穿过用例（Arch），最初调用最外层的组件：网络模块和数据库模块。然而咱们源码中的依赖方向却都是向内指向用例的。这里，咱们采纳的是依赖反转准则（DIP）来解决这种相同性。咱们能够通过调整代码中的接口和继承关系，利用源码中的依赖关系，限度控制流只能在正确的中央跨域架构边界。在下面的流程图中，次要有两个利用依赖反转准则的中央：1）CalcPreLoadArchIDs是从SyncUnitArchTask（业务实体）调用调用到ArchProto（用例）。业务实体这样的高层概念，是毋庸理解像用例这样的底层概念的。反之，底层业务用例却须要理解高层的业务实体。所以在SyncUnitArchTask中，其实是通过调用ArchProto的接口来调用CalcPreLoadArchIDs。SyncUnitArchTask中的调用代码如下： arch_service_context_->CalcPreLoadArchIDs(unit_id_, arch_service_context_->GetCurrentVid(), other_unit_click_partyid_, vecHashNode, all_tmp_ids, arch_ids, ptr_map_);ArchProto会在Task初始化时，把本人设置进Task中，给各类型的Task反向调用。classArchProto : publicArchServiceContext{...};2）最外层的模型层个别是由工具、数据库、网络框架等组成的。框架与驱动程序层中蕴含了所有的实现细节。从零碎架构的角度看，工具通常是无关紧要的，因为这只是一个底层的实现细节，一种达成指标的伎俩。当Task须要调用网络模块收发申请或者调用数据库模块获取数据时，为了防止内层策略依赖外层机制，Task只会调用外层工具的接口层，而不会依赖实现细节。这样的架构设计给咱们带来的益处是，咱们能够轻松替换框架，而不影响内层策略。比方在桌面端，咱们会有另外一套齐全不同的网络模块实现，只须要挂接不同的网络实现子类，咱们就能够在桌面端复用新的大架构模块。良好的架构设计应该尽可能地容许用户推延和延后决定采纳什么框架、数据库、网络框架以及其余与环境相干的工具。总之，良好的架构设计应该只关注用例，并能将它们与其余的周边因素隔离。 10.3新旧组织架构模块的交互大架构跨平台层，跟原来的组织架构模块是怎么交互的呢？原来的组织架构的数据表次要分成三局部：1）部门表；2）人员信息表；3）部门人员关系表。而呈现性能问题的次要在于关系表上。所以数据设计上，人员信息保留在原组织架构底层，部门人员关系表、部门表在大架构底层。表结构设计：1）次要组成：人员信息表、部门表、部门人员关系表；2）大架构底层保留部门和部门人员关系表，人员信息保留在原组织架构底层。大架构底层与原组织架构底层的业务关联：1）人员展现的部门链路如何获取？从大架构底层获取，因为关系表寄存在大架构底层；2）搜寻如何做？部门名字保留到原组织架构底层，复用原组织架构底层的索引建设逻辑。 11、300万优化计划的双DB切换模式11.1旧的读写表切换形式旧计划里组织架构的全量更新流程：当后盾通知客户端须要全量更新时，客户端会将所有节点标为待删除，而后同步后盾的节点，革除待删除标记。同步实现后，将写表的数据同步到读表，更新版本号。最初UI就能够从读表中读取到最新的数据。而之前通过用户日志案例剖析，最长的耗时次要是在将写表的数据拷贝到读表下面。在这个过程中，大架构下局部用户的日志里有更新57w节点的数据用了2个半小时的状况，而且这个步骤是原子操作，如果不可能一次实现，下次还得从新执行。原有流程里，读表和写表是固定的，导致全量更新须要等读表同步完数据，界面能力读到新数据。剖析：写表同步数据到读表耗时很久，当全量更新时，如果有大量节点须要更新，会耗时很长。毛病：写表和读表固定，全量更新须要等数据同步实现，界面能力读取到新数据。 11.2新的双DB切换形式针对旧计划中读写表同步过久的问题，大架构计划里咱们换成了双DB切换的模式。上面是咱们的状态机设计和业务代码获取表名的逻辑。这样批改之后，不须要等读写表同步完，UI就能够读取到最新数据。而同步的过程能够在后盾缓缓实现，并且不会受原子性操作的限度。业务代码获取读表的逻辑，也收拢到了一个函数。  因为单位模式下，每个单位的节点数量都不会很多，而且大多数用户只会加载日常有交换的几个单位，所以读写表同步这里，咱们采纳了把原表删掉，全量拷贝的形式。 12、200万级优化后的成果对于耗时，优化前应用全量加载的形式使得耗时很长，而优化后采纳的“本单位+骨架”的预加载逻辑使得加载耗时大幅度减小。优化后的内存占用大小在各场景下均有减小，通讯录页面的晦涩度也失去了肯定的晋升。耗时：CPU占用率：内存占用大小：卡顿： 13、相干材料[1] 企业微信客户端中组织架构数据的同步更新计划优化实战[2] 企业微信的IM架构设计揭秘：音讯模型、万人群、已读回执、音讯撤回等[3] 钉钉——基于IM技术的新一代企业OA平台的技术挑战(视频+PPT) [附件下载]》[4] 阿里钉钉技术分享：企业级IM王者——钉钉在后端架构上的过人之处》[5] 深度解密钉钉即时消息服务DTIM的技术设计[6] 深度揭密RocketMQ在钉钉IM零碎中的利用实际[7] IM开发干货分享：万字长文，详解IM“音讯“列表卡顿优化实际[8] 手Q客户端针对2020年春节红包的技术实际[9] 挪动端IM实际：Android版微信如何大幅晋升交互性能（一）[10] 挪动端IM实际：Android版微信如何大幅晋升交互性能（二）[11] 挪动端IM实际：iOS版微信的多设施字体适配计划探讨[12] 爱奇艺技术分享：爱奇艺Android客户端启动速度优化实际总结[13] 微信团队分享：微信领取代码重构带来的挪动端软件架构上的思考 （本文已同步公布于：http://www.52im.net/thread-4437-1-1.html）

为了更好地分类浏览 52im.net 总计1000多篇精编文章，我将在每周三推送新的一期技术文集，本次是第21 期。[- 1 -] 新手入门：零根底了解大型分布式架构的演进历史、技术原理、最佳实际 [链接] http://www.52im.net/thread-2007-1-1.html [摘要] 本文咱们就来聊聊分布式架构的演进过程，心愿能给大家带来眼前一亮的感觉。 [- 2 -] 一篇读懂分布式架构下的负载平衡技术：分类、原理、算法、常见计划等 [链接] http://www.52im.net/thread-2494-1-1.html [摘要] 本文将从负载平衡技术的分类、技术原理、常见实现算法、罕用计划等动手，为您具体解说负载平衡技术的方方面面。这其中，四层和七层负载平衡技术最为罕用，它们也是本文介绍的重点。 [- 3 -] 从老手到架构师，一篇就够：从100到1000万高并发的架构演进之路 [链接] http://www.52im.net/thread-2665-1-1.html [摘要] 本文以设计淘宝网的后盾架构为例，介绍从一百个并发到千万级并发状况下服务端的架构的14次演进过程，同时列举出每个演进阶段会遇到的相干技术，让大家对架构的演进有一个整体的认知。 [- 4 -] 腾讯资深架构师干货总结：一文读懂大型分布式系统设计的方方面面 [链接] http://www.52im.net/thread-1811-1-1.html [摘要] 本文联合作者多年的互联网零碎设计实践经验，从最根本的技术概念开始，带你探寻服务器端零碎架构的方方面面。 [- 5 -] 疾速了解高性能HTTP服务端的负载平衡技术原理 [链接] http://www.52im.net/thread-1950-1-1.html [摘要] 本文将以简洁艰深的文字，为你解说支流的HTTP服务端实现负载平衡的常见计划，以及具体到计划中的负载平衡算法的实现原理。了解和把握这些计划、算法原理，有助于您今后的互联网项的技术选型和架构设计，因为没有哪一种计划和算法能解决所有问题，只有针对特定的场景应用适合的计划和算法才是最理智的抉择。 [- 6 -] 知乎技术分享：从单机到2000万QPS并发的Redis高性能缓存实际之路 [链接] http://www.52im.net/thread-1968-1-1.html [摘要] 本文作者陈鹏是该零碎的负责人，本次文章深刻介绍了该零碎的方方面面，值得互联网后端程序员认真钻研。 [- 7 -] 阿里技术分享：深度揭秘阿里数据库技术计划的10年变迁史 [链接] http://www.52im.net/thread-2050-1-1.html [摘要] 阿里数据库事业部研究员张瑞，将为你讲述双11数据库技术鲜为人知的故事。在零点交易数字一次次晋升的背地，既是数据库技术的一次次冲破，也见证了阿里技术人永不言败的精力，每一次化“不可能”为“可能”的过程都是阿里技术人对技术的不懈谋求。 [- 8 -] 阿里技术分享：阿里自研金融级数据库OceanBase的艰苦成长之路 [链接] http://www.52im.net/thread-2072-1-1.html [摘要] OceanBase 是蚂蚁金服自研的分布式数据库，在其 9 年的倒退历程里，从艰巨上线到找不到业务场景濒临遣散，最初在双十一的流量考验下浴火重生，成为蚂蚁金服全副外围零碎的承载数据库。这一路走来的艰苦和故事，蚂蚁金服高级研究员、OceanBase 团队负责人阳振坤将为你娓娓道来。 ...

本文由vivo 互联网服务器团队Yu Quan分享，本文收录时有内容订正和从新排版。1、引言现在，Android端的即时通讯IM这类利用想实现离线音讯推送，难度越来越大（详见《Android P正式版行将到来：后盾利用保活、音讯推送的真正噩梦》、《Android保活从入门到放弃：乖乖疏导用户加白名单吧》）。于是，应用手机厂商自建的ROOM级音讯推送通道进行IM离线音讯推送是个不得不面对的问题，咱们也正好借此文机会，一窥支流手机厂商的ROOM级推送通道的技术实现吧。vivo手机的厂商级音讯推送零碎的现状是最高推送速度140w/s，单日最大音讯量200亿，端到端秒级在线送达率99.9%。同时推送零碎具备不可提前预知的突发大流量特点。本文将要分享的是vivo技术团队针对音讯推送零碎的高并发、高时效、突发流量等特点，从长连贯层容灾、逻辑层容灾、流量容灾、存储容灾等方面动手，如何保障百亿级厂商音讯推送平台的高可用性的。 举荐浏览：vivo技术团队分享的另一篇音讯推送技术文章《vivo手机上的零碎级音讯推送平台的架构设计实际》。 技术交换： 挪动端IM开发入门文章：《新手入门一篇就够：从零开发挪动端IM》开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）（本文已同步公布于：http://www.52im.net/thread-4416-1-1.html）2、推送零碎介绍vivo推送平台是vivo公司向开发者提供的音讯推送服务，通过在云端与客户端之间建设一条稳固、牢靠的长连贯，为开发者提供向客户端利用实时推送音讯的服务，反对百亿级的告诉/音讯推送，秒级触达移动用户。推送零碎次要由3局部组成：1）接入网关；2）逻辑推送节点；3）长连贯。其中，长连贯负责与用户手机终端建设连贯，及时把音讯送达到手机终端。推送零碎的特点是：1）并发高；2）音讯量大；3）送达及时性较高。上面将针对这几个方面来分享咱们的技术实际。 3、长连贯层容灾的技术实现长连贯是推送零碎最重要的局部，长连贯的稳定性间接决定了推送零碎的推送品质和性能。因而，须要对长连贯层做好容灾和实时调度能力。 3.1面临的问题原有推送零碎架构是长连贯层都部署在华东，所有vivo IDC逻辑节点通过VPC与华东的Broker建设连贯，手机端跟华东的broker进行长连贯通信。这种部署形式存在以下问题。1）问题一：华北、华南手机都须要连贯华东的Broker，地区跨度大，长连贯网络稳定性和时效性绝对较差。2）问题二：逻辑层跟华东的Broker之间由一条VPC连贯，随着业务的倒退，推送流量越来越大，带宽会呈现瓶颈，有超限丢包的危险。另外当该VPC呈现故障时，会造成全网音讯无奈送达。注：长连贯层节点名为Broker。原始长连贯架构图： 3.2解决办法基于以上架构存在问题，咱们对架构进行了优化。行将Broker进行三地部署，别离部署在华北、华东、华南。华北、华东、华南三地用户采纳就近接入形式。优化后的架构，不仅能够保障长连贯网络稳定性和时效性。同时具备较强的容灾能力，华东、华南Broker通过云网跟华北Broker连贯，华北Broker通过VPC与vivo IDC连贯。当华北、华东、华南某个地区Broker集群故障或者公网故障，不会影响到全网设施收发音讯。三地部署后的架构图： 3.3进一步优化然而上述这种形式还是存在一个问题，就是某个地区Broker集群故障或者公网故障，会呈现该区域局部设施无奈收到推送音讯的状况。针对上述单个地区异样导致该区域局部设施无奈收到推送音讯的问题，咱们设计了一套流量调度零碎，能够做到实时流量调度和切换。global scheduler节点负责策略调度和治理。vivo phone进行注册时：dispatcher会下发多个地区的ip地址，默认状况下，进行就近连贯。单屡次连贯失败后，尝试连贯其余ip。当某个地区Broker呈现长连接数瓶颈或者VPC呈现故障，能够通过global scheduler节点下发策略，让该故障地区的设施从新从dispatcher获取新的ip集的ip，与其余地区Broker建设长连贯，逻辑节点下发音讯到重连后的Broker。等到该地区复原后，能够从新再下发策略，进行回调。流量调度零碎图： 4、逻辑层容灾的技术实现长连贯层做好容灾后，逻辑层也须要做相应容灾。之前咱们逻辑层都部署在一个机房，不具备机房间容灾能力，当一个机房呈现断电危险，会呈现服务整体不可用问题，因而咱们做"同城双活"部署计划革新。逻辑层单活架构：逻辑层别离在vivo IDC1和vivo IDC2进行部署，网关层依据路由规定将流量依照肯定比例别离下发到两个IDC，实现逻辑层同城双活。咱们发现：数据中心还是只有一个，部署在vivo IDC1，依据老本、收益，以及多数据中心数据同步提早问题综合思考，数据中心临时还是以单数据中心为主。逻辑层双活架构： 5、流量容灾的技术实现5.1概述做好零碎架构的容灾能力后，推送零碎的网关层还须要应答突发流量做相应的应答措施，做好流量管制，保证系统稳定性。历史上，咱们已经因为热点和突发新闻事件，并发推送流量微小，导致服务出现异常，可用性升高问题。为了应答突发大流量，保障突发流量的状况下，零碎可用性不变，同时能兼顾性能和老本。为此，咱们别离比照了设计了以下两种计划。 5.2惯例计划惯例的计划是个别是依据历史状况估算冗余部署大量机器，来应答突发流量。单这种形式老本较高，突发流量可能只继续5分钟或更短时间，而零碎为了满足5分钟突发流量，须要冗余部署大量机器。一旦流量超过了部署机器可承当的下限，无奈及时扩容，可能导致可用性降落，甚至呈现雪崩效应。传统计划下的推送架构：那如何设计一套既能够管制老本，面对突发大流量弹性扩容，又保障音讯不漏并兼顾推送性能的计划呢？ 5.3优化计划优化后的计划：1）在原有架构的根底上，在接入层减少缓冲通道，当流量洪峰到来时，对于零碎可解决的下限能力外的流量，打入缓冲队列；2）通过音讯队列模式，减少bypass接入层，限速生产音讯队列；3）在流量洪峰过来后，晋升bypass生产速度，解决缓存队列音讯；4）bypass接入层通过docker部署，反对动静扩缩容，默认最小化集群，当音讯队列积压很多，并且上游有能力解决时，晋升生产速度，bypass依据CPU负载动静扩容，疾速生产音讯队列；5）处理完毕后动静缩容。音讯队列：选用吞吐量较大的KAFKA中间件，并且与离线计算KAFKA集群共用，能充分利用资源。bypass接入层：采纳docker部署，反对依据CPU负载和工夫动静扩缩容。默认最小集群部署。对于已知的流量顶峰时段，能够提前扩容服务，保障流量疾速解决。未知时段流量顶峰，能够bypass接入层，依据CPU负载状况进行动静扩缩容。减少缓存队列后的推送架构： 5.4进一步优化进行上述革新后：还存在一个问题，就是如何进行接入层全局控速。咱们采纳的形式是：收集上游推送节点的推送流量状况。比方：流量达到零碎可接受下限的80%时下发限速指令，调整接入层推送速度。让音讯先积压在音讯队列，等到上游流量升高之后，下发解除限速指令，让bypass接入层减速生产音讯队列，进行推送。减少控速后的推送架构：优化后计划与传统计划比照： 6、存储容灾的技术实现6.1问题做好并发流量管制后，能很好的预发突发热点问题。但在推送零碎外部，因为应用Redis集群缓存音讯，呈现过因为Redis集群故障导致音讯无奈及时送达问题。因而：咱们思考对Redis集群做相干容灾方案设计，实现零碎在Redis集群故障期间，也能及时推送音讯并保障音讯不失落。推送音讯体缓存在Redis集群中，推送时从Redis中获取音讯体，如果Redis集群宕机，或者内存故障，会导致离线音讯体失落。 6.2计划原有音讯流程：1）计划一：引入另一个对等Redis集群，采纳推送双写形式，双写两个Redis集群。该计划须要冗余部署规模对等的备Redis集群。推送零碎须要双写Redis操作。2）计划二：原有Redis集群，采纳RDB+AOF形式同步到另一个备Redis集群。该计划不在须要推送零碎双写Redis革新，间接利用将原有Redis集群数据同步到另一个备Redis集群。也须要冗余部署规模对等的备Redis集群。可能存在局部数据同步提早导致推送失败问题。3）计划三：利用另一个分布式存储系统，磁盘KV，兼容Redis协定，同时具备长久化能力。能够保障音讯体不失落。然而为了节省成本，不再间接应用Redis集群对等资源。而是依据推送特点，推送分为单推、群推。单推是一对一推送，一个用户一条音讯体。群推是一对多推送，一个音讯体对应多个用户。群推往往是工作级别推送。因而咱们应用一个绝对小一些的磁盘KV集群，次要用于冗余存储，群推音讯体，即工作级别的音讯。对于单推，还是只保留到Redis中，不进行冗余存储。如果Redis集群故障，对于单推音讯，推送零碎能够携带音讯体往上游推送，确保音讯能够持续下发。对于群推音讯，因为音讯体冗余存储在磁盘KV中，当Redis集群故障后，能够降级到读取磁盘KV。 6.3优化计划三还存在一个问题，就是磁盘KV的写入性能和Redis集群不是一个数量级，特地是时延，磁盘KV在均匀在5ms左右。而Redis集群却在0.5ms。如果在推送系统对群推音讯体进行双写。这个时延是不能承受的。因而只能采纳异步写入磁盘KV的形式。这里将备份群推音讯体，先写入消息中间件KAFKA，由bypass节点生产KAKFA进行异步写入磁盘KV。这样在应用的灾备磁盘KV资源较少的前提下，保障推送零碎的高并发能力，同时能够保障群推音讯体不失落，Redis异样时，单推音讯携带音讯体推送，群推音讯体读取磁盘KV。存储容灾计划比照： 7、本文小结本文从长连贯层容灾、逻辑层容灾、流量容灾、存储容灾等几个方面讲述了推送零碎容灾建设过程。零碎容灾须要依据业务倒退，老本收益，实现难度等多方面思考。以后咱们长连贯层已具备三地部署，逻辑层具备同城双活，数据中心为单数据中心。后续咱们会继续钻研和布局双数据中心，两地三核心部署架构形式来逐渐增强推送零碎容灾能力。 8、参考资料[1] vivo手机上的零碎级音讯推送平台的架构设计实际[2] 魅族2500万长连贯的实时音讯推送架构的技术实际分享[3] 专访魅族架构师：海量长连贯的实时音讯推送零碎的心得体会[4] 百万在线的美拍直播弹幕零碎的实时推送技术实际之路[5] 京东京麦商家开放平台的音讯推送架构演进之路[6] 解密“达达-京东到家”的订单即时派发技术原理和实际[7] 长连贯网关技术专题(四)：爱奇艺WebSocket实时推送网关技术实际[8] 喜马拉雅亿级用户量的离线音讯推送零碎架构设计实际[9] 微信直播聊天室单房间1500万在线的音讯架构演进之路[10] 百度直播的海量用户实时音讯零碎架构演进实际[11] 音讯推送技术干货：美团实时音讯推送服务的技术演进之路[12] 技术干货：从零开始，教你设计一个百万级的音讯推送零碎 9、vivo技术团队分享的其它文章《IM音讯ID技术专题(七)：深度解密vivo的自研分布式ID服务(鲁班)》《直播零碎聊天技术(八)：vivo直播零碎中IM音讯模块的架构实际》《IM跨平台技术学习(三)：vivo的Electron技术栈选型、全方位实际总结》《vivo手机上的零碎级音讯推送平台的架构设计实际》 （本文已同步公布于：http://www.52im.net/thread-4416-1-1.html）

为了更好地分类浏览 52im.net 总计1000多篇精编文章，我将在每周三推送新的一期技术文集，本次是第19 期。[-1-] 微信后盾基于工夫序的新一代海量数据存储架构的设计实际 [链接] http://www.52im.net/thread-2970-1-1.html [摘要] 时隔3年，微信再次分享了基于工夫序的新一代海量数据存储架构的设计实际（能够认为是《微信后盾基于工夫序的海量数据冷热分级架构设计实际》一文中所述架构的升级版），心愿能带给你启发。 [-2-] 阿里技术分享：电商IM音讯平台，在群聊、直播场景下的技术实际 [链接] http://www.52im.net/thread-3252-1-1.html [摘要] 本文来自淘宝音讯业务团队的技术实际分享，剖析了电商IM音讯平台在非传统IM利用场景下的高发并、强互动群聊和直播业务中的技术特点，总结并分享了在这些场景下实现大量多对多实时音讯散发投递的一些架构方面的设计实际。 [-3-] 瓜子IM智能客服零碎的数据架构设计（整顿自现场演讲，有配套PPT） [链接] http://www.52im.net/thread-2807-1-1.html [摘要] 此次演讲，从数据架构层面解说零碎遇到的挑战及解决办法。 [-4-]阿里钉钉技术分享：企业级IM王者——钉钉在后端架构上的过人之处 [链接] http://www.52im.net/thread-2848-1-1.html [摘要] 业界的 IM 产品在性能上同质化较高，而企业级的 IM 产品对于高可用、安全性又有更高的要求，如何打造具备差异化的产品，又在高可用、安全性、数据一致性等方面具备较高的品质，是企业级 IM 产品胜利的要害。钉钉在过来短短几年工夫里，用户数已破 2 亿，企业组织数破千万，钉钉是在布局企业级 IM 产品的架构上有何过人之处？本文将围绕这个话题进行开展。 [-5-] 从游击队到正规军(一)：马蜂窝旅游网的IM零碎架构演进之路 [链接] http://www.52im.net/thread-2675-1-1.html [摘要] 本文将分享马蜂窝旅游网的IM零碎架构从零演进的整个过程，心愿能给你的IM技术选型和计划确定带来启发。 [-6 -] 从游击队到正规军(二)：马蜂窝旅游网的IM客户端架构演进和实际总结 [链接] http://www.52im.net/thread-2796-1-1.html [摘要] 本文由马蜂窝电商业务 IM 挪动端研发团队分享了马蜂窝电商业务 IM 挪动端的架构演进过程，以及在IM技术力量和资源无限的状况下所踩过的坑等。 [-7-] 从游击队到正规军(三)：基于Go的马蜂窝旅游网分布式IM零碎技术实际 [链接] http://www.52im.net/thread-2909-1-1.html [摘要] 本文咱们将联合马蜂窝游览电商IM零碎的倒退历程，独自介绍基于Go重构分布式IM零碎过程中的实际和总结（本文相当于《从游击队到正规军(一)：马蜂窝旅游网的IM零碎架构演进之路》一文的进阶篇），心愿能够给有类似问题的敌人一些借鉴。 [-8 -] 微信技术分享：微信的海量IM聊天音讯序列号生成实际（容灾计划篇） [链接] http://www.52im.net/thread-1999-1-1.html [摘要] 本篇将会介绍 seqsvr 分布式容灾架构的演变。 [-9 -] 一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实际 ...

本文由网易云信资深服务端开发工程师曹佳俊分享，本文收录时有内容订正和从新排版。1、引言聊天室是一类十分重要的 IM 业务状态，不同于单聊和群聊，聊天室是一种大规模的实时音讯散发零碎。聊天室有多种技术实现计划，业界也有一些开源的实现，每种实现都有本人的特点和利用场景。本文将分享网易云信针对海量用户IM聊天室的架构设计与利用实际，心愿能带给你启发。 技术交换： 挪动端IM开发入门文章：《新手入门一篇就够：从零开发挪动端IM》开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）（本文已同步公布于：http://www.52im.net/thread-4404-1-1.html） 2、本文作者曹佳俊：网易云信资深服务端开发工程师，中科院研究生毕业后退出网易，始终在网易云信负责 IM 服务器相干的开发工作。对 IM 零碎构建以及相干中间件的开发有丰盛的实战经验。 3、聊天室整体架构首先，咱们先来看一下网易云信以后聊天室的具体技术架构，以及咱们在架构降级优化过程中做的一些事件。如下图，是网易云信聊天室的技术架构：次要包含以下局部：1）接入层的 ChatLink；2）网络传输层的 WE-CAN、WE-CAN bridge；3）调度层的 Dispatcher；4）服务层的 Callback、Queue、Presence、Tag、History 等；5）CDN 散发层的 CDN Manager、CDN Pusher、CDN Source。上面，咱们针对每一层开展详细分析。 4、聊天室的接入层接入层依据客户端的类型不同会有不同的实现，例如常见客户端（iOS、Andriod、Windows、Mac 等）基于公有二进制协定，Web 端基于 Websocket 协定实现。接入层作为间隔客户端的最初一公里，其接入速度、品质以及数据安全都是至关重要的，上面咱们逐个探讨。1）接入速度和品质：目前咱们搭建了覆盖全国各省份以及全世界各大洲的边缘节点，缩短最初一公里，缩小不确定性，晋升服务的稳定性。2）数据安全：基于对称+非对称加密，客户端与服务器之前实现 0-RTT，实现秘钥替换和登录，同时也反对 RSA/AES/SM2/SM4 等各种加密算法。接入层除了承受来自客户端的申请，还负责进行音讯的单播和播送，因而接入层须要治理本节点的所有长连贯，包含每个聊天室房间的连贯以及每个连贯的标签属性。此外接入层会上报本人的负载信息给后端服务，不便调度层进行正当的调度。当流量洪峰来长期，因为须要进行音讯的播送，接入层往往是压力最大的，为了保障服务的稳定性，咱们做了很多优化策略。3）自适应的流控策略：单机流控：接入层服务会监控本机整体的网络带宽应用状况，并设置 2 个阈值 T1 和 T2，当带宽使用率超过 T1 时，触发流控，如果进一步超过了 T2，则不仅触发流控还会一直的调整流控的强度。最终的指标是使带宽使用率稳固在 T1 和 T2 之间。单连贯流控：除此之外，接入层服务还会记录每个长连贯的音讯散发速度，并进行细粒度的调整，防止单机粗粒度流控导致单个连贯散发过少或者过多，做到音讯散发的平滑，即缩小了带宽流量的稳定尖刺，也改善了端侧的体验。4）性能优化：ChatLink 高负载运行时，除了网络带宽，调用链路上的各个环节都可能成为性能的瓶颈。咱们通过缩小编解码的次数（包含序列化、压缩等）、多线程并发、缩小内存拷贝、音讯合并等多种形式，显著地晋升了服务性能。 5、聊天室的网络传输层咱们的IM聊天室零碎最后的架构是将接入层和后端服务层都部署在同一个机房的，大部分用户都是直连 BGP 机房的 ChatLink，对于偏远地区或者海内，则通过专线的形式部署代理节点实现减速。该计划存在显著的毛病就是服务能力下限受制于单机房的容量。此外，专线也是一笔不小的开销。在咱们接入 WE-CAN 大网后，接入层 ChatLink 能够做到客户端就近接入，进步服务质量的同时升高了老本。此外，多机房的架构也使得咱们的服务能力回升了一个台阶。为了适配 WE-CAN 大网，咱们设计了 WE-CAN Bridge 层，作为大网接入协定和聊天室协定的桥接层，负责协定转换、会话治理、转发接管。通过这种分层架构，接入层和后端业务层能够少批改或者不批改，缩小对已有零碎的革新老本，也升高了架构降级带来的危险。什么是WE-CAN？ WE-CAN（Communications Acceleration Network）是网易自研的新一代大规模分布式传输网络，WE-CAN的基本指标是建设一个能将任意数据从寰球任一点稳固、疾速、高效地发送到寰球任何其余角落的通用传输网络，且这个网络是架设在公共互联网之上的 —— 即无需借助任何非凡的硬件设施或架设专线，而是通过软件计划来达到目标。6、聊天室的调度层调度层是客户端接入聊天室零碎的前提。客户端登录聊天室之前须要先获取接入地址，调配服务咱们称之为 Dispatcher。Dispatcher 是中心化的，会承受来自 WE-CAN 和 ChatLink 的心跳信息，依据心跳状况来抉择最佳接入点。调度零碎设计次要思考的是以下两个关键点。1）调度精度：调度零碎会依据申请方的 IP 判断地区和运营商信息，比照各个边缘节点的所属区域、运营商以及节点自身的负载（如 CPU、网络带宽等）。此外还思考边缘节点到核心机房的链路状况（来自 WE-CAN），计算综合打分，并把最优的若干节点作为调度后果。2）调度性能：面对高并发场景，比方一个大型聊天室，流动初期往往随同着大量人员的同时进入，此时就须要调度零碎做出疾速的反馈。为此，咱们会将上述的调度规定以及原始数据进行本地缓存优化。此外，为了防止心跳信息滞后导致调配不合理引起节点过载，调配服务时还会动静调整负载因子，在保障调度性能的前提下，尽量做到调配后果的平滑。 ...

本文由QQ技术团队王辉、吴浩、陈俊文分享，编辑Tina整顿，本文收录时有内容订正和排版优化。1、引言在瞬息万变的互联网行业中，年过二十四的即时通讯IM利用 QQ 堪称超长命的产品，见证了中国互联网崛起的残缺历程。然而，现在这个元老级产品经验了一次从内到外彻底的重构。在这次重构中，QQ 抉择了 Electron 作为 UI 跨平台开发框架。只管 Electron 被 Slack、Visual Studio Code 和 Discord 等大型产品宽泛应用，但也引发了一些网友的担心，例如内存占用、安装包体积和启动速度等方面的问题。本文内容整顿自 QQ 技术团队的采访，咱们一起来看看QQ团队抉择Electron作为桌面版跨端框架背地的决策与思考。 技术交换： 挪动端IM开发入门文章：《新手入门一篇就够：从零开发挪动端IM》开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）（本文已同步公布于：http://www.52im.net/thread-4391-1-1.html）2、系列文章本文是系列文章中的第8篇，本系列总目录如下：《IM跨平台技术学习(一)：疾速理解新一代跨平台桌面技术——Electron》《IM跨平台技术学习(二)：Electron初体验(疾速开始、跨过程通信、打包、踩坑等)》《IM跨平台技术学习(三)：vivo的Electron技术栈选型、全方位实际总结》《IM跨平台技术学习(四)：蘑菇街基于Electron开发IM客户端的技术实际》《IM跨平台技术学习(五)：融云基于Electron的IM跨平台SDK革新实际总结》《IM跨平台技术学习(六)：网易云信基于Electron的IM音讯全文检索技术实际》《IM跨平台技术学习(七)：得物基于Electron开发客服IM桌面端的技术实际》《IM跨平台技术学习(八)：新QQ桌面版为何抉择Electron作为跨端框架》（* 本文） 3、老QQ桌面版的技术债3.1多端代码不对立QQ 的第一个版本公布于 1998 年，在 Windows 技术栈的根底上用纯原生的形式开发，在过后互联网带宽十分小的状况下，QQ 将安装包管制在了只有 200K 左右。2007 年后智能手机开始露出苗头，腾讯口头得比拟早，局部前端技术开发开始转型到了挪动端，在桌面端， QQ 随着业务和组织的倒退，针对三大操作系统陆续组建了三支不同的研发团队，各自负责本人的一套代码。▲ 初版QQ的注册向导页▲ 初版QQ的次要性能为即时聊天 三端不同代码，老产品历史包袱，加上挪动时代研发人员的转型，导致桌面 QQ 保护老本很高。QQ 技术团队介绍，拿之前的桌面 QQ 为例，Windows QQ 以前的 UI 框架用的是腾讯自研的 GF 框架，10 多年了，GF 这个框架文档还不全，新退出这个我的项目的团队人员，要基于这个根底框架去做一些事件，是效率很低的一件事件，缓缓的就没有人违心去用这个框架了。简而言之，就是技术债。PS：如果你对QQ的发展史感兴趣能够看看上面这些文章：《闲话即时通讯：腾讯的成长史实质就是一部QQ成长史》《技术往事：守业初期的腾讯——16年前的冬天，谁动了马化腾的代码》《技术往事：史上最全QQ图标变迁过程，追寻IM伟人的演进历史》《QQ的胜利，远没有你设想的那么顺利和轻松》《还原实在的腾讯：从最不被看好，到即时通讯巨头的草根创业史》 3.2多端性能不统一旧版的桌面端 QQ，Windows 的性能最丰盛，Mac OS 次之， Linux 性能十分简洁。比方“屏幕共享”这个性能，挪动端有，Windows 端有，然而 Mac OS 端是没有的。那用户就会遇到一个问题，像 Mac OS 端无奈与其它端 QQ 用户一起来应用这个性能。“多端不对立不利于用户对于 QQ 的对立认知。咱们这次的架构降级就是想尽量通过一套外围代码去拉平所有平台的体验，让它具备更好的可维护性和可扩展性，让桌面 QQ 可能更好地迭代产品交互和性能，降级用户体验，再次焕发成长的生命力。” ...

对于MobileIMSDKMobileIMSDK 是一套专门为挪动端开发的开源IM即时通讯框架，超轻量级、高度提炼，一套API优雅反对 UDP 、TCP 、WebSocket 三种协定，反对 iOS、Android、H5、规范Java、小程序、Uniapp，服务端基于Netty编写。工程开源地址是：1）Gitee码云地址：https://gitee.com/jackjiang/MobileIMSDK2）Github托管地址：https://github.com/JackJiang2011/MobileIMSDK 对于RainbowChat► 具体产品介绍：http://www.52im.net/thread-19-1-1.html► iOS端更新记录：http://www.52im.net/thread-2735-1-1.html► 全副运行截图：iOS端全副运行截图 （另：Android端运行截图 点此查看）► 在线体验下载：App Store装置地址 （另：Android端下载体验 点此查看） RainbowChat是一套基于开源IM聊天框架 MobileIMSDK 的产品级挪动端IM零碎。RainbowChat源于实在经营的产品，解决了大量的屏幕适配、细节优化、机器兼容问题（可自行下载体验：专业版下载安装）。RainbowChat可能是市面上提供im即时通讯聊天源码的，惟一一款同时反对TCP、UDP两种通信协议的IM产品（通信层基于开源IM聊天框架 MobileIMSDK 实现）。 v7.0 版更新内容此版更新内容（更多历史更新日志）：1）[新增] 新增了反对从相册中选取视频并发送；2）[bug] 解决了代码中设置聊天界面中音讯文字色彩无作用的问题；3）[bug] 解决了聊天音讯列表中查看短视频后返回时，最初一行音讯被输入框档住的问题；4）[bug] 解决了一处因后台任务未显式完结导致的潜在内存透露问题；5）[bug] 当处于群聊界面是，群主更新群名称时，不能间接刷新群聊界面以后的题目上群名称的最新显示；6）[优化] 登陆界面中，明码输入框减少了密文和明文切换显示性能；7）[优化] 解决了iOS16.4+零碎上因UIAlertView兼容性导致的某些性能中确认事件不能执行的问题；8）[优化] 解决了从其它界面返回到注册界面的动画跳转时，原界面导航栏变成彩色块的问题；9）[优化] 解决了聊天界面下方的性能面板关上状态下，再点“+” 号会切换到文本输出，而不是勾销性能面板显示的问题；10）[优化] 降级了图片抉择库以适配最新的iOS零碎；11）[优化] 解决了聊天界面中发送大文件后，会立刻弹出软键盘并进入文字输出状态的问题；12）[优化] 查看图片界面中，长按弹出菜单成果UI丑化；13）[优化] 从新优化了闪屏、登录、帮忙、遗记明码、注册、注册胜利、查找用户、邀请敌人共计8个界面的UI设计；14）[优化] 其它未提及的ui细节优化和美感晋升。 此版局部界面更新（更多截图点此查看）：  

本文由腾讯产品体验设计师volihuang分享，原题“千万级增长，实时社交产品Discord拆解”，本文收录时有内容订正和大量排版优化。1、引言对于大多数人而言，对即时通讯IM利用的认知依然停留在微信、QQ这类经典的即时通讯聊天场景。实际上，现在的即时通讯技术已渗透到各种业态中，包含本系列文章将要分享的目前大热的Discord实时社群软件（Discord次要用于游戏社交），钻研Discord软件（包含技术实现上和产品定义上）或者能够对你在其它业态中更好的利用即时通讯技术带来启发，也这是整顿分系列文章的初衷。本文为系列文章的首篇，文章内容不探讨Discord具体的技术实现，仅从其产品定义的角度上对Discord软件进行详尽和具体的介绍，心愿能帮忙你对Discord从产品状态上有较为残缺的认知，也不便你浏览本系列文章的后续篇章。  技术交换： 挪动端IM开发入门文章：《新手入门一篇就够：从零开发挪动端IM》开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）（本文已同步公布于：http://www.52im.net/thread-4300-1-1.html） 2、系列文章本文是系列文章中的第 1 篇：《实时社群技术专题(一)：反对百万人超级群聊，一文读懂社群产品Discord》（* 本文）《实时社群技术专题(二)：百万级成员实时社群技术实现（音讯零碎篇）》（稍后公布）《实时社群技术专题(三)：百万级成员实时社群技术实现（关系零碎篇）》（稍后公布） 3、Discord是什么3.1席卷游戏圈的社群Discord是一家游戏实时聊天利用与社区，Discord从游戏语音、IM工具服务起家，随后转向直播平台，进而开设游戏商店的社区平台，成为游戏玩家在游戏中沟通合作的首选工具。Discord于2015年5月公开发行。在 2018 年，它就曾经席卷游戏圈，成了最受游戏玩家亲睐的「语音聊天工具」。在“英雄联盟”美服，简直每局游戏开始前，都会有人发送 Discord 频道链接，邀请队友通过 Discord 沟通，而不是应用游戏内置的语音工具。从语音聊天工具，到游戏玩家社区，Discord 仿佛正在创始一种全新的互联网社会形态。它预示了一种比 reddit、Facebook 可能更现实的全新将来。 3.2从「工具」到「社区」Discord 绝不是最「简略易用」的一个，但 Discord 却在思考如何从最底层优化产品，给到用户更多「可能性」.在疫情的大环境下，从2020年2月到7月，Discord的用户数量减少了47%，学习小组开始应用Discord；老师用它上课；敌人们用它来玩，就像平时放学后或周末一样。3.3UI界面概览 4、Discord的倒退历程Discord相较于传统图文沟通模式的社群有着显著的长处：在Discord上社区建设者能够通过权限设置，轻松的进行用户细分，精准高效的传递信息；也能够进行社交媒体整合，为本人的其余社群进行引流。而Discord建设如此丰盛的性能次要分为三个阶段来实现： 4.1第一阶段：游戏语音工具外围增长点：极致的根底用户体验。在工具阶段，Discord一直打磨全面超过竞品的根底体验，从界面审美、多端反对、提早、降噪等等方面都处于市场领先地位。通过极致的用户体验与因而播种的口碑流传，获取了第一批深度的种子用户。而这些用户逐步围绕所玩的游戏造成了游戏社群。 4.2第二阶段：游戏社群外围增长点：平台设计+能力凋谢+内容经营+用户品质。在游戏社群阶段，Discord通过平台设计、能力凋谢、内容经营等形式减速了游戏社群的造成和壮大，游戏品类用户需要的溢出发明了更多的品类。平台设计：完全免费设计、PC/Web/挪动多端反对、免注册即可应用、无任何广告等，这些产品设计减速了用户的裂变；好友列表、退出服务器等积淀的关系链继而让用户持续留存。Discord在产品设计中始终依照做一个平台的思路来设计，冀望疾速取得大量用户以造成网络效应。能力凋谢：凋谢了较多的API能力，如反对游戏厂商接入语音sdk、反对同步Twitch直播状态、同步Steam游戏状态等等。这给用户和其余平台方提供弱小的额定价值。如音视频流可间接接入Discord，在服务器内就能够和好友一起观看Twitch/Youtube。如得悉好友的游戏状态能够疾速退出雷同游戏一起开黑等。这也是平台设计的思路，凋谢能力接入第三方以获取赋能。 4.3第三阶段：全品类社群/社区外围增长点：弱小的治理能力（机器人开放平台/服务器权限/服务器模板…）。Discord中服务器的治理能力十分丰盛，通过设置不同的频道组和频道、设置身份权限、引入机器人等等伎俩，数十万人的社群也可能进行得井井有条。 5、Discord的现状现阶段，Discord 预计有 3 亿用户，其中包含 1.5 亿月沉闷用户，平台上有 1900 万个服务器，涵盖游戏、投资、政治、动漫等畛域。2020 年，Discord 每周有 670 万服务器处于沉闷状态，基本上每周都有某个给定话题的对话探讨。2021 年，Discord 每周沉闷服务器数据增长到了 1900 万。来自挪动产业数据平台 Apptopia 的音讯显示，线上社区 App「Discord」的下载总量在近期已冲破 5 亿次，同时利用内购营收总额冲破 1 亿美元。Discord 平台上单个日沉闷用户（DAU）与平台的均匀互动时长，是游戏直播平台 Twitch 的两倍，同时还是 Facebook Gaming、TikTok、Reddit 以及 Snap 等头部社交平台的两倍以上。然而，即使在如此惊人的增长之后，Discord 仿佛并没有太多商业化的动作。2020 年，Discord 的每用户平均收入 (ARPU) 仅为 1.30 美元，在公共社交媒体公司中排名十分靠后。 6、Discord平台机制介绍6.1根本Discord以其多样化的平台机制设定，为使用者提供了多种多样收费的性能。它们是：1）以高音质、简直零提早、有限工夫与尽可能多的敌人交谈；2）只需单击两次，即可将游戏直播带给服务器中的任何人，而且不会存在任何提早；3） 应用独自的音量滑块一次观看多个流媒体；4）能够创立简直无限量的文本聊天室，甚至能够追溯到几年前的档案；5）与敌人分享小文件；6）将机器人融入其中，能够向所有人播送音乐；7）Discord 反对视频流和屏幕截图等性能。上面，咱们具体介绍Discord中的性能设置。 6.2服务器机制在 Discord 中有一种别于个别通信软体之群组的群体聊天，称作服务器（相似社团），服务器拥有者能够在服务器中发明属于本人的社群。例如：MINECRAFT在Discord的服务器，成员数已超过100w人，达到Discord目前设置的服务器下限。MINECRAFT界面：此外，在服务器搜寻界面搜寻MINECRAFT，可发现Discord上有6000+个MINECRAFT相干服务器，散布于社交、娱乐、同好、动画漫画、创作者等不同板块，绝大部分由玩家自发成立，在其中分享素材及想法。 6.3身份组机制在 Discord 中能够建设十分多不同的身份组，使用者能够齐全自订身分组的色彩、名称、权限、符号等等，身份组会间接影响使用者的名称色彩及用户列表的排序。 6.4频道机制在伺服器中能够建设名为频道的聊天管道，分为语音、文字，其中的语音频道能够用来直播游戏与聊天等，频道能够设定与身份组整合各种权限，让 Discord 社群零碎更加多样化。文字方面：Discord 应用markdown语法，目标是对富文本肯定水平的反对。语音方面：Discord 应用opus音频格式，目标是压缩语音来升高提早。“哈利波特：魔法沉睡”的频道介绍列表： ...

本文由云信IM技术团队分享，原题“千万级在线直播弹幕计划”，本文有订正和改变。1、引言疫情期间，线上演唱会是一种很常见的直播娱乐模式，因为线下社交间隔的限度，线上模式演唱会比以往更火爆，而对技术的要求也更高。本文基于网易云信针对TFBOYS某场线上演唱会的技术支持，为你分享千万级在线用户量的直播零碎中实时弹幕性能的技术实际，心愿能带给你启发。   技术交换： 挪动端IM开发入门文章：《新手入门一篇就够：从零开发挪动端IM》开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）（本文已同步公布于：http://www.52im.net/thread-4299-1-1.html）2、系列文章本文是系列文章中的第 9 篇：《直播零碎聊天技术(一)：百万在线的美拍直播弹幕零碎的实时推送技术实际之路》《直播零碎聊天技术(二)：阿里电商IM音讯平台，在群聊、直播场景下的技术实际》《直播零碎聊天技术(三)：微信直播聊天室单房间1500万在线的音讯架构演进之路》《直播零碎聊天技术(四)：百度直播的海量用户实时音讯零碎架构演进实际》《直播零碎聊天技术(五)：微信小游戏直播在Android端的跨过程渲染推流实际》《直播零碎聊天技术(六)：百万人在线的直播间实时聊天音讯散发技术实际》《直播零碎聊天技术(七)：直播间海量聊天音讯的架构设计难点实际》《直播零碎聊天技术(八)：vivo直播零碎中IM音讯模块的架构实际》《直播零碎聊天技术(九)：千万级实时直播弹幕的技术实际》（* 本文） 3、弹幕整体技术计划本次的弹幕计划以IM聊天室技术为根底，提供了登录直播间、发送弹幕、礼物音讯等能力。同时依照千万级在线播送的指标，为期设计了基于CDN的弹幕播送服务。直播间收发实时音讯（也就是弹幕、礼物）的次要流程如下：1）获取直播间接入地址；2）登录直播间；3）收发音讯（弹幕、礼物）。上面将围绕以上流程的三个阶段，在技术上别离论述如何实现千万级在线直播实时弹幕的能力。 4、弹幕技术计划之获取直播间接入地址为了提供稳固高可用的实时弹幕服务，须要通过GSLB（Global Server Load Balancing）服务给用户调配最佳的接入地址。GSLB服务须要从以下几个维度综合思考： 1）用户网络类型；2）机房网络容量；3）服务器负载；4）老本。 1）用户网络类型和机房网络容量：为了用户可能疾速、稳固的登录直播间收发音讯，个别要依据用户所在地理位置以及网络运营商类型综合思考给用户分类接入服务器。机房个别提供BGP网络、三线网络两种接入计划，调配服务依据用户IP地址剖析用户的地区、运营商类型并调配最佳接入地址。个别优先按运营商类型调配三线地址（例如电信用户调配电信接入地址），如果是小运营商或无奈辨认的IP地址则调配BGP地址，两种接入形式用户都能够取得稳固的网络环境。 2）服务器负载：单台服务器可能承载的TCP长链接无限，尤其是在高并发进入直播间的状况下，握手协定须要实现链路加密工作，对系统的CPU资源耗费比拟大，因而须要实现一套良好的平衡调配策略。 3）一套基于服务器负载平衡的调配策略：长链接接入服务器周期性上报以后服务器负载到负载平衡服务集群，负载信息存储在共享缓存中，接入调配服务依据负载信息动态分配接入地址。个别状况下用户申请直播间地址，地址调配服务会查问负载平衡服务（或者间接查问负载缓存），而后依据获取到的信息调配以后负载最低的服务器。在千万级别的在线直播流动场景下，开播时大量用户并发进入直播间，调配服务可达50万到100万TPS，这么高的TPS下如果还用“个别调配”计划，负载平衡（缓存）服务的TPS和集群之间的机房网络带宽十分高，单台服务器亦可能因为负载信息滞后导致超负荷调配。为解决机房内带宽和超负载调配的问题，咱们对调配计划进行了优化：1）长链接服务器上报负载的周期从1秒调整到5毫秒，负载平衡服务器能够更实时的同步负载信息；2）“地址调配”服务不再按申请查问负载信息，而是开启独自的同步线程周期性（同样是5毫秒）同步负载数据，从而无效升高负责信息同步的TPS和网络开销；3）“地址调配”服务不在按最低负载调配，而是将服务接入地址按负载排序，单个接入地址调配肯定次数后按程序调配下一个接入地址（防止低负载服务器霎时被打爆）。在理论计划落地中，须要联合负载、用户网络类型、机房线路容量等因素综合调配。 5、弹幕技术计划之登录直播间登录直播间次要有两项工作：1）握手；2）身份认证。 1）握手：SDK建设TCP长链接后，首先向服务器发送握手协定，次要提供SDK版本、协定版本、反对的加密算法等信息，服务器依据SDK提供的信息抉择适合的协定版本以及加密算法，建设平安的通信链路。咱们反对的非对称算法包含：RSA、SM2等算法。反对的对称加密算法包含：AES，SM4等（SM2、SM4为国密算法）。非对称加密算法对CPU资源耗费十分高，为了进步性能个别能够思考抉择适合的密钥长度，另外针对Java平台倡议思考应用JNI技术进步非对称加密计算性能。2）身份认证：引言中提到的该次直播流动是在线付费直播，因而身份认证蕴含了账号认证和业务认证两局部，即用户必须应用正确的账号密码登录App，且必须付费购买直播门票才有权限观看直播。为优化零碎性能，实时弹幕服务将“地址调配和鉴权”服务进行了非凡优化：鉴权核心提供用户进入直播间弹幕服务的身份鉴权策略配置。在该次直播流动中采纳了动静Token的鉴权机制，即依据用户账号、登录工夫、调配的接入地址以及鉴权核心按工夫区间生成的“随机数以及对应的Token算法”动静计算鉴权Token。用户关上直播App，首先实现账号鉴权。在进入直播间时通过业务核心实现直播付费身份认证和弹幕服务地址调配（同步获取到弹幕服务的动静鉴权token），最初依据接入地址登录弹幕服务，弹幕服务根据鉴权核心的策略校验Token正确性。动静Token鉴权采纳过程本地计算的形式。能够在不拜访用户服务的状况下实现身份鉴权，在进步登录认证的性能同时无效的升高了业务老本。 6、弹幕技术计划之收发音讯（弹幕、礼物）实时收发音讯是直播间的外围业务，次要分为弹幕和礼物两类：1）礼物因波及付费等因素个别通过客户方业务服务器发送；2）弹幕音讯则能够通过聊天室长链接发送。在千万级直播间场景下，因音讯量太高，因而须要从音讯量、音讯体大小、音讯比例等多个方面优化，因而咱们设计了一套基于优先级队列的弹幕服务。首先：为了节约音讯产生的带宽，在大型直播我的项目开始阶段，就须要对音讯格局进行优化，充沛精简音讯体大小。例如将礼物音讯展现相干的资源文件提前预加载到直播App中，礼物音讯转化为业务编号，可极大的缩小音讯大小；其次：针对上行音讯设计流控机制。为了能全局管制上行音讯体量，设计了逐级流控计划。上层级依据下层级可能撑持解决能力设计绝对较粗粒度的本地流控机制。在弹幕反垃圾业务阶段，因须要全局管制音讯量，因而采纳分布式全局流控计划；弹幕播送阶段则依据业务播送需要再一次进行音讯流控。上行音讯通过反垃圾监测后被投递到弹幕服务解决。基于优先级队列的弹幕服务首先按业务划分不同的音讯队列，例如：零碎播送、高优先级礼物、低优先级、弹幕，而后按队列调配音讯比例，最初依据单位工夫（1秒）内用户须要接管到的音讯量计算各个队列应该投递的音讯数量。在理论投递音讯的过程中，若前一个队列音讯量有余，可将残余的音讯数量叠加到下一个队列，以确保每一个周期都发送足够的音讯给用户。弹幕可通过长连贯或CDN播送给其余用户。为了给用户提供极致的弹幕体验，充分发挥边缘减速的劣势，在千万级在线直播场景下优先选择CDN计划（如下图所示）。基于CDN播送弹幕有两种计划：1）基于推流的计划：相似于直播视频推流技术，行将音讯伪装成视频流的模式推送到CDN，直播App以订阅数据流的形式同步弹幕信息；2）动态文件减速计划：即弹幕服务将不同队列中的音讯组装成一个动态文件，直播App周期性的到CDN服务器下载弹幕动态文件。相对来说：1）动态文件减速计划实现更简略但实时性不高（取决于弹幕同步的周期时长）；2）推流的计划音讯实时性更高，但实现绝对简单，且须要思考到不同终端的兼容性。理论我的项目中可依据场景和终端类型灵便抉择不同的计划。为了保障服务的可靠性，可思考交融CDN的计划，即同时将音讯推送到多家CDN厂商，并联合CDN厂商的容量比例以及网络提早状况综合调度（例如基于权重的轮巡调度策略）。 7、弹幕稳定性设计之单元化部署ChatLink和ChatServer采纳单元化部署的计划，有以下长处：1）单元内依赖的外围服务单元之间互相独立，程度扩大能力好，且单元内服务故障不影响其余单元，能够无效防止整个服务不可用的问题；2）跨机房部署，防止单个机房容量有余，或单机房不可用问题；3）弹幕计划采纳了单元无状态的设计理念，因而不须要思考单元之间同步数据的问题。单个直播间的“接入服务”和“弹幕服务”因须要全局管制未采纳单元化部署计划，然而在施行阶段采纳了跨机房部署的计划（包含依赖的存储资源、服务），能够防止单个机房故障导致服务不可用的问题。 8、弹幕稳定性设计之单点服务高可用针对“接入服务”和“弹幕服务”，除了采纳跨机房部署外，在服务设计上外围依赖的存储资源、服务，采纳主备模式。例如：心跳负载依赖的缓存服务，单个缓存实例自身高可用，但思考到极其状况（例如缓存集群内超过一半的服务器宕机导致服务不可用），因而采纳主备缓存集群计划，当主集群不可用后，业务被动切换到备用集群，可保障业务在5秒内恢复正常。 9、幕稳定性设计之系统监控与数据大盘为了实时理解零碎运行状态，在弹幕计划中实现了秒级数据大盘计划。监控大盘围绕用户和音讯次要展现以下信息：1）用户地区散布变动；2）上行音讯量；3）播送音讯量；4）机房进口带宽；5）CDN带宽；6）音讯流控比例；7）端侧CDN弹幕同步指标（胜利比例、提早情况7）端侧CDN弹幕同步指标（胜利比例、提早情况）。为了达成秒级监控的指标，数据收集采纳了“业务预聚合+数据中心合并”的实时计算计划。即业务服务间接在本地过程内聚合计算指标上报到数据中心，数据中心仅须要按工夫窗口合并监控指标数据即可输入到监控大盘。 10、弹幕稳定性设计之故障与应急预案演练为确保流动顺利完成，弹幕计划还进行了屡次故障与应急预案演练措施。具体蕴含两个方面。1）预设故障演练：即针对高可用设计方案的故障演练，按预设有打算的制作故障，次要验证高可用计划是否失效。2）随机故障演练：无打算的随机制作故障，次要用于查看应急预案、异样监控报警、数据大盘等应急监测机制是否失效。 11、相干材料[1] 海量实时音讯的视频直播零碎架构演进之路(视频+PPT)[2] 百万在线的美拍直播弹幕零碎的实时推送技术实际之路[3] 阿里电商IM音讯平台，在群聊、直播场景下的技术实际[4] 微信直播聊天室单房间1500万在线的音讯架构演进之路[5] 百度直播的海量用户实时音讯零碎架构演进实际[6] 百万人在线的直播间实时聊天音讯散发技术实际[7] 直播间海量聊天音讯的架构设计难点实际[8] vivo直播零碎中IM音讯模块的架构实际[9] 万人群聊音讯投递计划的思考和实际[10] IM中的万人群聊技术计划实际总结 （本文已同步公布于：http://www.52im.net/thread-4299-1-1.html）

为了更好地分类浏览 52im.net 总计1000多篇精编文章，我将在每周三推送新的一期技术文集，本次是第18 期。[- 1 -] IM零碎的MQ消息中间件选型：Kafka还是RabbitMQ？ [链接] http://www.52im.net/thread-1647-1-1.html [摘要] MQ消息中间件能够了解一个水池，水池的这头是音讯生产者，水池的那头是音讯消费者，生产者和音讯者无需间接对接，这将带来很多益处：业务解耦、架构分布式化等，生产者和消费者相互齐全通明。但市面上的MQ消息中间件产品很多，作为IM零碎中必不可少的一环，咱们该如何选型？那么请持续浏览本文。 [- 2 -] 腾讯资深架构师干货总结：一文读懂大型分布式系统设计的方方面面 [链接] http://www.52im.net/thread-1811-1-1.html [摘要] 本文适宜有过几年工作教训、正处于技术上升期的程序员浏览，内容少有虚夸，多为实际经验总结，心愿能为您的技术成长加油助力。 [- 3 -] 以微博类利用场景为例，总结海量社交零碎的架构设计步骤 [链接] http://www.52im.net/thread-1910-1-1.html [摘要] 本文让咱们联合典型的互联网利用架构设计准则，通过一个模仿的微博利用场景，和你一起看看在微博这种海量社交利用实际中到底如何分步进行架构设计的。 [- 4 -]疾速了解高性能HTTP服务端的负载平衡技术原理 [链接] http://www.52im.net/thread-1950-1-1.html [摘要] 本文将以简洁艰深的文字，为你解说支流的HTTP服务端实现负载平衡的常见计划，以及具体到计划中的负载平衡算法的实现原理。了解和把握这些计划、算法原理，有助于您今后的互联网项的技术选型和架构设计，因为没有哪一种计划和算法能解决所有问题，只有针对特定的场景应用适合的计划和算法才是最理智的抉择。 [- 5 -] 子弹短信光鲜的背地：网易云信首席架构师分享亿级IM平台的技术实际 [链接] http://www.52im.net/thread-1961-1-1.html [摘要] 本文内容来自对网易云信首席架构师周梁伟的采访，采访内容次要围绕网易云信这种海量用户IM云平台的关键技术难点以及对应的技术实际。 [- 6 -] 知乎技术分享：从单机到2000万QPS并发的Redis高性能缓存实际之路 [链接] http://www.52im.net/thread-1968-1-1.html [摘要] 知乎存储平台团队基于开源Redis 组件打造的知乎 Redis 平台，通过一直的研发迭代，目前曾经造成了一整套残缺自动化运维服务体系，提供很多弱小的性能。本文作者陈鹏是该零碎的负责人，本次文章深刻介绍了该零碎的方方面面，值得互联网后端程序员认真钻研。 [- 7 -] IM开发基础知识补课(五)：通俗易懂，正确理解并用好MQ音讯队列 [链接] http://www.52im.net/thread-1979-1-1.html [摘要] 对于即时通讯开发者来说，正确地了解MQ音讯队列，对于IM或音讯推送零碎的架构设计、计划选型等都大有裨益。 [- 8 -] 新手入门：零根底了解大型分布式架构的演进历史、技术原理、最佳实际 [链接] http://www.52im.net/thread-2007-1-1.html [摘要] 即时通讯网作为IM和推送技术钻研、学习和分享的社区，整顿了大量的跟IM和推广技术无关的根底技术材料（比方网络根底、通信实践、架构根底等），本文内容尽管看起来跟IM和推送技术没有间接的关联性，但因为设计IM和推送零碎的技术思路和原理跟典型大型互联网分布式架构都是一脉相承的，因此读懂本文内容对于IM和推送零碎的架构设计同样大有裨益。 ...

在联网游戏中，很多游戏会做聊天零碎，来实现玩家之间的互动。在游戏中最常见的聊天模式有世界聊天、组队聊天、好友聊天等。 世界聊天世界聊天是游戏中最常见的聊天模式。游戏个别会应用了聊天室的概念，来组织玩家的世界聊天。TDS 即时通讯零碎提供的 聊天室 性能不限度人数下限，能够让用户在每次进入大厅、或者游戏上线时主动退出聊天室。 尽管「聊天室」不限度成员数量，但从理论教训来看，如果人数过多，那么聊天室内音讯被放大的成果会非常明显，对于终端用户而言即体现为适量音讯一直刷屏，反而影响用户体验。咱们会倡议每个聊天室的人数管制在 5000 人左右。开发者能够思考从利用层面将大聊天室拆分成多个较小的聊天室。 组队聊天和好友聊天吃鸡游戏中的小队聊天、MMORPG 中的公会聊天、玩家之间的一对一私聊，也是游戏中非常常见的聊天模式。游戏能够应用 TDS 提供的 一般对话 来实现这些聊天。并且对于这类聊天，玩家能够有减少、删除成员的治理能力，用来实现队长踢出成员后同时移除对话、公会会长移除成员后同时移除对话等场景。 并且这种聊天形式也能够用于实现@ 成员揭示音讯、撤回和批改音讯、暂态音讯、音讯送达和已读的回执告诉、离线推送告诉（Push）等高级能力，让聊天的性能更加丰盛和好用。 官方消息和 GM 音讯在游戏中，游戏经营可能有时候须要发送一些全局的音讯，譬如服务器行将保护这种保护类音讯、世界 Boss 流动行将开始这种流动类音讯。 这时候能够应用 零碎音讯 来实现此能力，任何人都能够随时订阅零碎音讯，没有人数限度，倡议开发者让每个角色在创立胜利后就主动订阅上零碎音讯，这样就能让玩家承受到每一条重要的零碎告诉。 不仅只是文字聊天，也能够发表情包、图片、音视频、配备链接在很多游戏中，文字聊天是最根底的能力，然而只是文字聊天也会让聊天短少点乐趣。 开发者能够尝试引入表情包，能够反对官网表情包或玩家自定义表情包（倡议配合审核性能），如此来减少玩家之间的互动频率和参与度。目前也有不少游戏曾经反对了这类性能。 另外某些游戏中，玩家可能会想在聊天中贴出本人的战绩、配备链接、BD 配置等和游戏强相干的信息，这类性能可依据游戏的理论须要不便地增加到聊天零碎中。 敏感词过滤聊天中的敏感词过滤是必备的一个模块，开发者能够在后盾上传敏感词列表，也能够接入第三方或者自建的敏感词过滤零碎。 以上就是在游戏开发中常常应用到的几种聊天模式，如果想理解如何接入 TDS 即时通讯，能够拜访咱们的 即时通讯产品指南 和 即时通讯开发指南。 更多游戏开发中聊天性能的疑难，也欢送在评论区留言探讨。

本文由得物技术团队Uni分享，即时通讯网收录时有内容订正和大量排版优化。1、引言对于Java网络编程中的同步IO和异步IO的区别及原理的文章十分的多，具体来说次要还是在探讨Java BIO和Java NIO这两者，而对于Java AIO的文章就少之又少了（即应用也只是介绍了一下概念和代码示例）。在深刻理解AIO之前，我留神到以下几个景象：1）2011年Java 7公布，它减少了AIO（号称异步IO网络编程模型），但12年过来了，平时应用的开发框架和中间件却还是以NIO为主（例如网络框架Netty、Mina，Web容器Tomcat、Undertow），这是为什么？2）Java AIO又称为NIO 2.0，难道它也是基于NIO来实现的？3）Netty为什么会舍去了AIO的反对？（点此查看）；4）AIO看起来貌似只是解决了有无，理论是公布了个寂寞？Java AIO的这些不合常理的景象难免会令人心存疑惑。所以决定写这篇文章时，我不想只是简略的把AIO的概念再复述一遍，而是要透过景象，深入分析、思考和并了解Java AIO的实质。 技术交换： 挪动端IM开发入门文章：《新手入门一篇就够：从零开发挪动端IM》开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）（本文已同步公布于：http://www.52im.net/thread-4283-1-1.html） 2、咱们所了解的异步AIO的A是Asynchronous（即异步）的意思，在理解AIO的原理之前，咱们先理清一下“异步”到底是怎么的一个概念。说起异步编程，在平时的开发还是比拟常见的。例如以下的代码示例：@Asyncpublicvoidcreate() {    //TODO} publicvoidbuild() {    executor.execute(() -> build());}不论是用@Async注解，还是往线程池里提交工作，他们最终都是同一个后果，就是把要执行的工作，交给另外一个线程来执行。这个时候，咱们能够大抵的认为，所谓的“异步”，就是用多线程的形式去并行执行工作。 3、Java BIO和NIO到底是同步还是异步？Java BIO和NIO到底是同步还是异步，咱们先依照异步这个思路，做异步编程。 3.1BIO代码示例byte[] data = newbyte[1024];InputStream in = socket.getInputStream();in.read(data);// 接管到数据，异步解决executor.execute(() -> handle(data)); publicvoidhandle(byte[] data) {    // TODO}如上：BIO在read()时，尽管线程阻塞了，但在收到数据时，能够异步启动一个线程去解决。 3.2NIO代码示例selector.select();Set<SelectionKey> keys = selector.selectedKeys();Iterator<SelectionKey> iterator = keys.iterator();while(iterator.hasNext()) {    SelectionKey key = iterator.next();    if(key.isReadable()) {        SocketChannel channel = (SocketChannel) key.channel();        ByteBuffer byteBuffer = (ByteBuffer) key.attachment();        executor.execute(() -> {            try{                channel.read(byteBuffer);                handle(byteBuffer);            } catch(Exception e) {             }        });    }} publicstaticvoidhandle(ByteBuffer buffer) {    // TODO}同理：NIO尽管read()是非阻塞的，通过select()能够阻塞期待数据，在有数据可读的时候，异步启动一个线程，去读取数据和解决数据。 3.3产生的了解偏差此时咱们山盟海誓地说，Java的BIO和NIO是异步还是同步，取决你的情绪，你快乐给它个多线程，它就是异步的。但果真如此么？在翻阅了大量博客文章之后，基本一致的说明了——BIO和NIO是同步的。那问题点出在哪呢，是什么造成了咱们了解上的偏差呢？那就是参考系的问题，以前学物理时，公交车上的乘客是静止还是静止，须要有参考系前提，如果以高空为参考，他是静止的，以公交车为参考，他是静止的。Java IO也是一样，须要有个参考系，能力定义它是同步还是异步。既然咱们探讨的是对于Java IO是哪一种模式，那就是要针对IO读写操作这件事来了解，而其余的启动另外一个线程去解决数据，曾经是脱离IO读写的范畴了，不应该把他们扯进来。 3.4尝试定义异步所以以IO读写操作这事件作为参照，咱们先尝试的这样定义，就是：发动IO读写的线程（调用read和write的线程），和实际操作IO读写的线程，如果是同一个线程，就称之为同步，否则是异步。按上述定义：1）显然BIO只能是同步，调用in.read()以后线程阻塞，有数据返回的时候，接管到数据的还是原来的线程；2）而NIO也称之为同步，起因也是如此，调用channel.read()时，线程尽管不会阻塞，但读到数据的还是以后线程。依照这个思路，AIO应该是发动IO读写的线程，和理论收到数据的线程，可能不是同一个线程。是不是这样呢？咱们将在上一节间接上Java AIO的代码，咱们从 理论代码中一窥到底吧。 4、一个Java AIO的网络编程示例4.1AIO服务端程序代码publicclassAioServer {     publicstaticvoidmain(String[] args) throwsIOException {        System.out.println(Thread.currentThread().getName() + " AioServer start");        AsynchronousServerSocketChannel serverChannel = AsynchronousServerSocketChannel.open()                .bind(newInetSocketAddress("127.0.0.1", 8080));        serverChannel.accept(null, newCompletionHandler<AsynchronousSocketChannel, Void>() {             @Override            publicvoidcompleted(AsynchronousSocketChannel clientChannel, Void attachment) {                System.out.println(Thread.currentThread().getName() + " client is connected");                ByteBuffer buffer = ByteBuffer.allocate(1024);                clientChannel.read(buffer, buffer, newClientHandler());            }             @Override            publicvoidfailed(Throwable exc, Void attachment) {                System.out.println("accept fail");            }        });        System.in.read();    }} publicclassClientHandler implementsCompletionHandler<Integer, ByteBuffer> {    @Override    publicvoidcompleted(Integer result, ByteBuffer buffer) {        buffer.flip();        byte[] data = newbyte[buffer.remaining()];        buffer.get(data);        System.out.println(Thread.currentThread().getName() + " received:"+ newString(data, StandardCharsets.UTF_8));    }     @Override    publicvoidfailed(Throwable exc, ByteBuffer buffer) {     }} ...

为了更好地分类浏览 52im.net 总计1000多篇精编文章，我将在每周三推送新的一期技术文集，本次是第17 期。[- 1 -] 社交软件红包技术解密(一)：全面解密QQ红包技术计划——架构、技术实现等 [链接] http://www.52im.net/thread-2202-1-1.html [摘要] 本文将从架构开始，到手机 QQ 挪动端优化，再到个性化红包和 AR 新玩法，为大家全面解密 QQ 红包技术计划。 [- 2 -] 社交软件红包技术解密(二)：解密微信摇一摇红包从0到1的技术演进 [链接] http://www.52im.net/thread-2519-1-1.html [摘要] 今天下午跟大家分享的主题是：微信团队是如何从0到1实现“有把握”的微信春晚摇一摇红包零碎的。 [- 3 -] 社交软件红包技术解密(三)：微信摇一摇红包雨背地的技术细节 [链接] http://www.52im.net/thread-2533-1-1.html [摘要] 本文将由微信团队工程师张文瑞分享微信春节摇一摇红包技术背地的方方面面，心愿能给同行们带来启发。 [- 4 -]社交软件红包技术解密(四)：微信红包零碎是如何应答高并发的 [链接] http://www.52im.net/thread-2548-1-1.html [摘要] 本文将为读者介绍微信百亿级别红包背地的高并发设计实际，内容包含微信红包零碎的技术难点、解决高并发问题通常应用的计划，以及微信红包零碎的所采纳高并发解决方案。 [- 5 -] 社交软件红包技术解密(五)：微信红包零碎是如何实现高可用性的 [链接] http://www.52im.net/thread-2564-1-1.html [摘要] 本次分享介绍了微信红包后盾零碎的高可用实践经验，次要包含后盾的 set 化设计、异步化设计、订单异地存储设计、存储层容灾设计与平行扩缩容等。听众能够理解到微信红包后盾架构的设计细节，独特探讨高可用设计实际上遇到的问题与解决方案。 [- 6 -] 社交软件红包技术解密(六)：微信红包零碎的存储层架构演进实际 [链接] http://www.52im.net/thread-2568-1-1.html [摘要] 微信红包实质是小额资金在用户帐户流转，有发、抢、拆三大步骤。在这个过程中对事务有高要求，所以订单最终要基于传统的RDBMS，这方面是它的强项，最终订单的存储应用互联网行业最通用的MySQL数据库。反对事务、成熟稳固，咱们的团队在MySQL上有长期技术积攒。然而传统数据库的扩展性有局限，须要通过架构解决。 [- 7 -] 社交软件红包技术解密(七)：支付宝红包的海量高并发技术实际 [链接] http://www.52im.net/thread-2573-1-1.html [摘要] 本文将为读者分析支付宝红包零碎背地的技术细节。 [- 8 -] 社交软件红包技术解密(八)：全面解密微博红包技术计划 ...

► 相干链接：① MobileIMSDK-H5端的具体介绍② MobileIMSDK-H5端的开发手册new（* 精编PDF版） 一、技术筹备您是否已对Web端即时通讯技术有所理解？1）新手入门贴：史上最全Web端即时通讯技术原理详解2）Web端即时通讯技术盘点：短轮询、Comet、Websocket、SSE 您须要对WebSocket技术有所理解：1）老手疾速入门：WebSocket扼要教程2）WebSocket详解（一）：初步意识WebSocket技术3）WebSocket从入门到精通，半小时就够！4）从零了解WebSocket的通信原理、协定格局、安全性 WebSocket规范文档、API手册：1）WebSocket的API手册2）WebSocket的规范文档 二、开发工具筹备1）WebStorm：（JackJiang 应用的版本号如上图所示，倡议你也应用此版或较新版本）2）一站式下载地址：WebStorm官网下载地址点此进入。 三、工程文件用处阐明3.1文件概览纯原生JS实现，无任何重框架依赖： MobileIMSDK-H5端SDK自身只是JS文件源码的汇合，本工程中自带的前端Demo的目标只是为了不便随时测试MobileIMSDK-H5端的SDK代码而已，在此工程中的应用也仅仅只波及了一个主Demo页面而已。工程目录阐明：3.2具体阐明SDK 各模块/文件作用阐明：四、次要 API 接口4.1次要 API 接口概览如下图所示：所有 SDK 接口均由/mobileimsdk/mobileimsdk-client-sdk.js 提供。，接口设计跟MobileIMSDK 的APP版一样，均为高内聚和低侵入的回调形式传入SDK解决逻辑，无需（也不倡议）开发者间接批改sdk级代码。▲ 图上为浏览器端SDK的对外接口文件地位▲ 图上为浏览器SDK为开发者提供的回调接口▲ 图上浏览器端SDK的对外接口文件全图 4.2次要 API 接口用处阐明1）IMSDK.isLogined()： 用处：是否曾经实现过首次登陆。阐明 ：用户一旦从自已的利用中实现登陆IM服务器后，本办法就会始终返回true（直到退出登陆IM）。返回值：{boolean}，true示意已实现首次胜利登陆（即曾经胜利登陆过IM服务端了，前面掉线时不影响此标识），否则示意尚未连贯IM服务器。2）IMSDK.isOnline()： 用处：是否在线。阐明 ：示意网络连接是否失常。返回值：{boolean}，true示意网络连接失常，否则示意已掉线，本字段只在this._logined=true时有意义（如果都没有登陆到IM服务器，怎么存在在线或掉线的概念呢）。3）IMSDK.getLoginInfo()： 用处：返回登陆时提交的登陆信息（用户名、明码/token等）。阐明 ：格局形如：{loginUserId:'',loginToken:''}，此返回值的内容由调用登陆函数 loginImpl()时传入的内容决定。字段定义详见：PLoginInfo返回值：{boolean}，true示意网络连接失常，否则示意已掉线，本字段只在this._logined=true时有意义（如果都没有登陆到IM服务器，怎么存在在线或掉线的概念呢）。4）IMSDK.sendData(p, fnSucess, fnFail, fnComplete)： 用处：向某人发送一条音讯。参数p：{Protocal} 要发送的音讯协定包对象，Protocal详情请见“/module/mb_constants.js”下的createCommonData函数阐明。返回值：{int} 0示意胜利，否则示意错误码，错码详见“/module/mb_constants.js”下的MBErrorCode对象属性阐明。5）IMSDK.disconnectSocket()： 用处：客户端被动断开客户端socket连贯。阐明 ：当开发者登陆IM后，须要退出登陆时，调用本函数就对了，本函数相当于登陆函数 loginImpl()的逆操作。6）IMSDK.setDebugCoreEnable(enable)： 用处：是否开启MobileIMSDK-Uniapp端外围算法层的log输出，不便开发者调试。参数enable ：{boolean} true示意开启log输入，否则不输入，开发者不调用本函数的话零碎默认是false（即不输入log）。7）IMSDK.setDebugSDKEnable(enable)： 用处：是否开启MobileIMSDK-Uniapp端框架层的log输出，不便开发者调试。参数enable ：{boolean} true示意开启log输入，否则不输入，开发者不调用本函数的话零碎默认是false（即不输入log）。8）IMSDK.setDebugPingPongEnable(enable)： 用处：是否开启MobileIMSDK-Uniapp端框架层的底层网络WebSocket心跳包的log输入，不便开发者调试。参数enable ：{boolean} true示意开启log输入，否则不输入，开发者不调用本函数的话零碎默认是false（即不输入log）。留神：必须 setDebugEnable(true) 且 setDebugPingPongEnable(true) 时，心跳log才会真正输入，不便管制。返回值：true示意开启log输入，否则不输入，开发者不调用本函数的话零碎默认是false（即不输入log）。9）IMSDK.loginImpl(varloginInfo, wsUrl)： 用处：登陆/连贯MobileIMSDK服务器时调用的办法。阐明 ：登陆/连贯MobileIMSDK服务器由本函数发动参数varloginInfo：{PLoginInfo} 必填项，登陆要提交给Websocket服务器的认证信息，不可为空，对象字段定义见：PLoginInfo参数wsUrl：{string} 必填项：要连贯的Websocket服务器地址，不可为空，形如：wss://yousite.net:3000/websocket。10）IMSDK.callback_onIMLog(message, toConsole)： 用处：由开发者设置的回调办法：用于debug的log输入。举荐用法 ：开发者可在此回调中依照自已的用意打印MobileIMSDK微信小程序端框架中的log，不便调试时应用。参数1： {String}：必填项，字符串类型，示意log内容。参数2： {boolean}：选填项，true示意输入到console，否则默认形式(由开发者设置的回调决定)。11）IMSDK.callback_onIMData(p, options)： 用处：由开发者设置的回调办法：用于收到聊天音讯时在UI上展示进去（事件告诉于收到IM音讯时）。举荐用法：开发者可在此回调中解决收到的各种IM音讯。参数1： {Protocal}：详情请见“/module/mb_constants.js”下的Protocal类定义)。12）IMSDK.callback_onIMAfterLoginSucess()： 用处：由开发者设置的回调办法：客户端的登陆申请被服务端胜利认证实现后的回调（事件告诉于 登陆/认证 胜利后）。举荐用法 ：开发者可在此回调中进行登陆IM服务器胜利后的解决。13）IMSDK.callback_onIMAfterLoginFailed(isReconnect)： 用处：由开发者设置的回调办法：客户端的登陆申请被服务端认证失败后的回调（事件告诉于 登陆/认证 失败后）。阐明 ：补充阐明：登陆/认证失败的起因可能是用户名、明码等不正确等，但具体逻辑由服务端的 callBack_checkAuthToken回调函数去解决。举荐用法：开发者可在此回调中提醒用户登陆IM服务器失败。。参数1： {boolean}：true示意是掉线重连后的认证失败（在登陆其间可能用户的明码信息等产生了变更），否则示意首次登陆时的认证失败。14）IMSDK.callback_onIMReconnectSucess()： ...

一、对于RainbowChat-WebRainbowChat-Web是一套Web网页端IM零碎，是RainbowChat的姊妹零碎（RainbowChat是一套基于开源IM聊天框架 MobileIMSDK(Github地址) 的产品级挪动端IM零碎）。► 具体介绍：http://www.52im.net/thread-2483-1-1.html► 版本记录：http://www.52im.net/thread-2480-1-1.html► 运行截图：http://www.52im.net/thread-2470-1-1.html► 运行视频：http://www.52im.net/thread-2491-1-1.html 二、v5.0 版更新内容此版更新内容（更多历史更新日志）： 1）bug - 解决了当首页“音讯”无item时，从好友列表中删除某人时不主动清空聊天面板和右侧详情面板的问题；2）bug - 解决了处于群列表Tab时，退群或遣散群不会更新群列表中“以后群聊”数字的问题 ；3）bug - 解决了处于群列表Tab时，点击创立群聊后，不会在群聊列表中主动选中此创立的群的问题；4）[优化] - 降级外围通信层框架MobileIMSDK-Web至最新v5.1版；5）优化 - 优化了当发送名片音讯时，如名片者未设置头像，则在聊天音讯界面中显示默认头像（晋升体验）；6）优化 - 进一步加固了uid登陆时的sql注入危险；7）优化 - 解决与最新rabbitmq-client库不兼容从而断线重连不胜利，导致MQ中音讯沉积的问题：8）优化 - 解决MQ断线主动复原时消费者Chennal未被动清理，导致空channel越来越多的问题；9）优化 - 解决了被踢出群的状况下，仍能退群、邀请他人入群等问题；10）优化 - 解决了高版本Tomcat下文件名中蕴含了特殊符号的大文件无奈下载的问题。11）新增 - 聊天区上方实现了聊天对象信息的显示（可显示昵称、群名称等信息）；12）新增 - 新增了音讯送达状态图标的显示（包含发送中、发送胜利、发送失败3种状态）。 三、v5.0 版新增个性截图聊天区上方聊天对象信息的演示运行截图（更多运行截图）： 聊天区上方聊天对象信息的演示运行截图（更多运行截图）：音讯送达状态的演示运行截图（更多运行截图）： 四、次要界面截图概览 ▲ 主界面（更多截图、更多演示视频）▲ 主界面(聊天窗全屏时)（更多截图、更多演示视频）▲ 主界面(聊天窗敞开时)（更多截图、更多演示视频） 

本文由will分享，集体博客zhangyaoo.github.io，原题“基于Netty的IM零碎设计与实现”，有订正和从新排版。1、引言本文将要分享的是如何从零实现一套基于Netty框架的分布式高可用IM零碎，它将反对长连贯网关治理、单聊、群聊、聊天记录查问、离线音讯存储、音讯推送、心跳、分布式惟一ID、红包、音讯同步等性能，并且还反对集群部署。本文中针对这套架构和零碎设计，同时还会提供残缺的源码，比拟适宜有肯定Java开发能力和Netty常识的IM初学者。* 情谊提醒：如果你对IM即时通讯的根底技术实践理解的太少，倡议能够先读：《新手入门一篇就够：从零开发挪动端IM》。 技术交换： 挪动端IM开发入门文章：《新手入门一篇就够：从零开发挪动端IM》开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）（本文已同步公布于：http://www.52im.net/thread-4257-1-1.html）2、配套源码本文配套源码的开源托管地址是：1）主地址：https://github.com/zhangyaoo/fastim2）备地址：https://github.com/52im/fastim2023如果你拜访Github太慢，可间接从以下附件打包下载： fastim-master(52im.net).zip (1.12 MB , 下载次数: 5 , 售价: 1 金币)残缺源码的目录构造，如下图： 3、常识筹备对于 Netty 是什么，这里简略介绍下：Netty 是一个 Java 开源框架。Netty 提供异步的、事件驱动的网络应用程序框架和工具，用以疾速开发高性能、高可靠性的网络服务器和客户端程序。也就是说，Netty 是一个基于 NIO 的客户、服务器端编程框架，应用Netty 能够确保你疾速和简略的开发出一个网络应用，例如实现了某种协定的客户，服务端利用。Netty 相当简化和流线化了网络应用的编程开发过程，例如，TCP 和 UDP 的 Socket 服务开发。 无关Netty的入门文章：1）新手入门：目前为止最透彻的的Netty高性能原理和框架架构解析2）写给初学者：Java高性能NIO框架Netty的学习办法和进阶策略3）史上最艰深Netty框架入门长文：根本介绍、环境搭建、入手实战如果你连Java NIO都不晓得，上面的文章倡议优先读：1）少啰嗦！一分钟带你读懂Java的NIO和经典IO的区别2）史上最强Java NIO入门：放心从入门到放弃的，请读这篇！3）Java的BIO和NIO很难懂？用代码实际给你看，再不懂我转行！ Netty源码和API 在线查阅地址：1）Netty-4.1.x 残缺源码（在线浏览版）2）Netty-4.1.x API文档（在线版） 4、整体架构设计概览本次的IM零碎设计次要基于可扩展性高可用准则，把网关层、逻辑层、数据层进行了拆散，并且还要反对分布式部署。以下是整体零碎的架构设计概览图：上面将针对整体架构来逐个分享设计的次要思路等。 5、整体架构设计之客户端设计5.1客户端设计客户端的设计次要从以下几点登程：1）client每个设施会在本地存每一个会话，保留有最新一条音讯的程序 ID；2）为了防止client宕机，也就是退出利用，保留在内存的音讯ID失落，会存到本地的文件中；3）client须要在本地保护一个期待ack队列，并配合timer超时机制，来记录哪些音讯没有收到ack：N，以定时重发；4）客户端本地生成一个递增序列号发送给服务器，用作保障发送程序性。该序列号还用作ack队列收音讯时候的移除。 5.2客户端序列号设计1）计划一：设计思路：1）数据传输中的大小尽量小用int，不必bigint，节俭传输大小；2）只保障递增即可,在用户从新登录或者重连后能够进行日期重置，只保障单次；3）客户端发号器不须要像相似服务器端发号器那样集群部署，不须要思考集群同步问题。注：上述生成器能够用18年[(2^29-1)/3600/24/365]左右，一秒内最多产生4个音讯。长处：能够在断线重连和重装APP的状况下，18年之内是有序的。毛病：每秒只能发4个音讯，限度太大，对于群发场景不适合。改良：应用long进行传输，年限扩大很久并且有序。2）计划二：设计思路：1）每次从新建设链接后进行重置，将sequence_id（int示意）从0开始进行严格递增；2）客户端发送音讯会带上惟一的递增sequence_id，同一条音讯反复投递的sequence_id是一样的；3）后端存储每个用户的sequence_id，当sequence_id归0，用户的epoch年代加1存储入库，单聊场景下转发给接收者时候，接收者依照sequence_id和epoch来进行排序。长处：能够在断线重连和重装APP的状况下，接收者能够依照发送者发送时序来显示，并且对发送音讯的速率没限度。 6、整体架构设计之LSB设计6.1思路IM接入层的高可用、负载平衡、扩展性全副在这外面做。客户端通过LSB，来获取gate IP地址，通过IP直连。这样做的目标是：1）灵便的负载平衡策略 可依据起码连接数来调配IP；2）做灰度策略来调配IP；3）AppId业务隔离策略 不同业务连贯不同的gate，避免相互影响；4）单聊和群聊的im接入层通道离开。 6.2优化上述设计存在一个问题：就是当某个实例重启后，该实例的连贯断开后，客户端会发动重连，重连就大概率转移其余实例上，导致最近启动的实例连接数较少，最早启动的实例连接数较多。解决办法：1）客户端会发动重连，跟服务器申请重连的新的服务器IP，零碎提供适合的算法来平摊gate层的压力，避免雪崩效应；2）gate层定时上报本机的元数据信息以及连接数信息，提供给LSB核心，LSB依据起码连接数负载平衡实现，来计算一个节点供连贯。 7、整体架构设计之GATE层网关设计GATE层网关设计次要听从以下几点：1）任何一个gate网关断掉，用户端检测到当前从新连贯LSB服务获取另一个gate网关IP，拿到IP从新进行长连贯通信（对整体服务可靠性根本没有影响）；2）gate能够无状态的横向部署，来扩大接入层的接入能力；3）依据协定分类将入口申请打到不同的网关下来，HTTP网关接管HTTP申请，TCP网关接管tcp长连贯申请；4）长连贯网关，提供各种监控性能，比方网关执行线程数、队列工作数、ByteBuf应用堆内存数、堆外内存数、音讯上行和上行的数量以及工夫。 8、整体架构设计之LOGIC和路由SDK设计logic依照散布式微服务的拆分思维进行拆分，拆分为多个模块，集群部署。次要包含：1）音讯服务；2）红包服务；3）其余服务。音讯logic服务集成路由客户端的SDK，SDK职责次要是：1）负责和网关底层通信交互；2）负责网关服务寻址；3）负责存储uid和gate层机器ID关系（有状态：多级缓存防止和中间件屡次交互。无状态：在业务初期能够不必存）；4）配合网关负责路由信息一致性保障。针对上述第4）点：1）如果路由状态和channel通道不统一，比方有路由状态，没有channel通道（已敞开）那么，就会走离线音讯流出，并且革除路由信息；2）动静重启gate，会及时清理路由信息。SDK和网关底层通信设计：如上图所示：网关层到服务层，只须要单向传输发申请，网关层不须要关怀调用的后果。而客户端想要的ack或者notify申请是由SDK发送数据到网关层，SDK也不须要关怀调用的后果，最初网关层只转发数据，不做额定的逻辑解决。SDK和所有的网关进行长连贯，当发送信息给客户端时，依据路由寻址信息，即可通过长连贯推送信息。 9、通信协议设计9.1指标通信协议设计的次要指标是：1）高性能：协定设计紧凑，保障数据包小，并且序列化性能好；2）可扩大：针对后续业务倒退，能够自在的自定义协定，无需较大改变协定构造。 9.2设计IM协定采纳二进制定长包头和变长包体来实现客户端和服务端的通信，并且采纳谷歌protobuf序列化协定。设计如下：各个字段解释如下：1）headData：头部标识，协定头标识，用作粘包半包解决。4个字节；2）version：客户端版本。4个字节；3）cmd：业务命令，比方心跳、推送、单聊、群聊。1个字节；4）msgType：音讯告诉类型 request response notify。1个字节；5）logId：调试性日志，追溯一个申请的全门路。4个字节；6）sequenceId：序列号，能够用作异步解决。4个字节；7）dataLength：数据体的长度。4个字节；8）data：数据。PS：如果你对Protobuf不理解，倡议详读以下系列文章：1.《强列倡议将Protobuf作为你的即时通讯利用数据传输格局》2.《IM通信协定专题学习(一)：Protobuf从入门到精通，一篇就够！》3.《IM通信协定专题学习(二)：疾速了解Protobuf的背景、原理、应用、优缺点》4.《IM通信协定专题学习(三)：由浅入深，从根上了解Protobuf的编解码原理》5.《IM通信协定专题学习(四)：从Base64到Protobuf，详解Protobuf的数据编码原理》6.《IM通信协定专题学习(五)：Protobuf到底比JSON快几倍？全方位实测！》7.《IM通信协定专题学习(六)：手把手教你如何在Android上从零应用Protobuf》8.《IM通信协定专题学习(七)：手把手教你如何在NodeJS中从零应用Protobuf》9.《IM通信协定专题学习(八)：金蝶顺手记团队的Protobuf利用实际(原理篇)》10.《IM通信协定专题学习(九)：手把手教你如何在iOS上从零应用Protobuf》 9.3实际针对数据data，网关gate层不做反序列化，反序列化步骤在service做，防止反复序列化和反序列化导致的性能损失。网关层不做业务逻辑解决，只做音讯转发和推送，缩小网关层的复杂度。 10、平安设计为避免音讯传输过程中不被截获、篡改、伪造，采纳TLS传输层加密协议（可参考《微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解》）。私有化协定人造具备肯定的防窃取和防篡改的能力，绝对于应用JSON、XML、HTML等明文传输零碎，被第三方截获后在内容破解上绝对老本更高，因而安全性上会更好一些。音讯存储安全性：将针对账号密码的存储平安能够通过“高强度单向散列算法”和“加盐”机制来晋升加密明码可逆性；IM音讯采纳“端到端加密”形式来提供更加平安的音讯传输爱护。平安层协定设计：基于动静密钥，借鉴相似SSL，不须要用证书来治理（可参考《探讨组合加密算法在IM中的利用》）。 11、音讯投递设计11.1概述一个失常的音讯流转须要如下图所示的流程：如上图所示：1）客户端A发送申请包R；2）server将音讯存储到DB；3）存储胜利后返回确认ack；4）server push音讯给客户端B；5）客户端B收到音讯后返回确认ack；6）server收到ack后更新音讯的状态或者删除音讯。须要思考的是：一个强壮的IM零碎须要思考各种异常情况，比方丢音讯，反复音讯，音讯时序问题。 11.2音讯可靠性如何保障（不丢音讯）我的设计和实现思路是这样的：1）应用层ACK；2）客户端须要超时与重传；3）服务端须要超时与重传，具体做法就是减少ack队列和定时器Timer；4）业务侧兜底保障，客户端拉音讯通过一个本地的旧的序列号来拉取服务器的最新消息；5）为了保障音讯必达，在线客户端还减少一个定时器，定时向服务端拉取音讯，防止服务端向客户端发送拉取告诉的包失落导致客户端未及时拉取数据。 相干材料可参考：1.《从客户端的角度来谈谈挪动端IM的音讯可靠性和送达机制》2.《IM音讯送达保障机制实现(一)：保障在线实时音讯的牢靠投递》3.《IM音讯送达保障机制实现(二)：保障离线音讯的牢靠投递》4.《IM开发干货分享：如何优雅的实现大量离线音讯的牢靠投递》5.《了解IM音讯“可靠性”和“一致性”问题，以及解决方案探讨》6.《融云技术分享：全面揭秘亿级IM音讯的牢靠投递机制》 11.3音讯重复性如何保障（不反复）超时与重传机制将导致接管的client收到反复的音讯，具体做法就是一份音讯应用同一个音讯ID进行去重解决。相干材料可参考：1.《IM群聊音讯如此简单，如何保障不丢不重？》2.《齐全自已开发的IM该如何设计“失败重试”机制？》 11.4音讯程序性如何保障（不乱序）音讯乱序影响的因素：1）时钟不统一，分布式环境下每个机器的工夫可能是不统一的；2）多发送方和多接管方，这种状况下，无奈保先发的音讯被先收到；3）网络传输和多线程，网络传输不稳固的话可能导致包在数据传输过程中有的慢有的快。多线程也可能是会导致时序不统一影响的因素。以上：如果放弃相对的实现，那么只能是一个发送方，一个接管方，一个线程阻塞式通信来实现。那么性能会升高。1）如何保障时序：单聊：通过发送方的相对时序seq，来作为接管方的展示时序seq。实现形式：能够通过工夫戳或者本地序列号形式来实现毛病：本地工夫戳不精确或者本地序列号在意外状况下可能会清0，都会导致发送方的相对时序不精确群聊：因为发送方多点发送时序不统一，所以通过服务器的单点做序列化，也就是通过ID递增发号器服务来生成seq，接管方通过seq来进行展示时序。实现形式：通过服务端对立生成惟一趋势递增音讯ID来实现或者通过redis的递增incr来实现。毛病：redis的递增incr来实现，redis取号都是从主取的，会有性能瓶颈。ID递增发号器服务是集群部署，可能不同发号服务上的集群工夫戳不同，可能会导致后到的音讯seq还小。群聊时序的优化：依照下面的群聊解决，业务上依照情理只须要保障单个群的时序，不须要保障所有群的相对时序，所以解决思路就是同一个群的音讯落到同一个发号service下面，音讯seq通过service本地生成即可。 2）客户端如何保障程序：为什么要保障程序？因为音讯即便依照程序达到服务器端，也会可能呈现：不同音讯达到接收端后，可能会呈现“先产生的音讯后到”“后产生的音讯先到”等问题。所以客户端须要进行兜底的流量整形机制如何保障程序？能够在接管方收到音讯后进行断定，如果以后音讯序号大于前一条音讯的序号就将以后音讯追加在会话里。否则持续往前查找倒数第二条、第三条等音讯，始终查找到恰好小于以后推送音讯的那条音讯，而后插入在其后展现。相干材料可参考：《零根底IM开发入门(四)：什么是IM零碎的音讯时序一致性？》《一套亿级用户的IM架构技术干货(下篇)：可靠性、有序性、弱网优化等》《如何保障IM实时音讯的“时序性”与“一致性”？》《一个低成本确保IM音讯时序的办法探讨》 12、音讯告诉设计12.1概述整体音讯推送和拉取的时序图如下： 12.2音讯拉取形式的抉择本零碎是通过推拉联合来进行服务器端音讯的推送和客户端的拉取。咱们晓得单pull和单push有以下毛病。对于单pull：1）pull要思考到音讯的实时性，不晓得音讯何时送达；2）pull要思考到哪些好友和群收到了音讯，要循环每个群和好友拿到音讯列表，读扩散。对于单push：1）push实时性高，只有将音讯推送给接收者就ok，然而会集中耗费服务器资源；2）并且再群聊十分多、聊天频率十分高的状况下，会减少客户端和服务端的网络交互次数。对于推拉联合：1）推拉联合的形式可能摊派服务端的压力,能保障时效性，又能保障性能；2）具体做法就是有新音讯时候，推送哪个好友或者哪个群有新音讯，以及新音讯的数量或者最新消息ID，客户端按需依据本身数据进行拉取。 12.3推拉隔离设计为什么做隔离？如果客户端一边正在拉取数据，一边有新的增量音讯push过去。如何做隔离？本地设置一个全局的状态，当客户端拉取完离线音讯后设置状态为1（示意离线音讯拉取结束）。当客户端收到拉取实时音讯，会启用一个轮询监听这个状态，状态为1后，再去向服务器拉取音讯。如果是push音讯过去（不是被动拉取），那么会先将音讯存储到本地的音讯队列中，期待客户端上一次拉取数据结束，而后将数据进行合并即可。 相干材料可参考：《阿里IM技术分享(六)：闲鱼亿级IM音讯零碎的离线推送达到率优化》《阿里IM技术分享(七)：闲鱼IM的在线、离线聊天数据同步机制优化实际》 13、音讯ID生成设计以下是我设计的场景：1）单机顶峰并发量小于1W，预计将来5年单机顶峰并发量小于10W；2）有2个机房，预计将来5年机房数量小于4个 每个机房机器数小于150台；3）目前只有单聊和群聊两个业务线，后续能够扩大为零碎音讯、聊天室、客服等业务线，最多8个业务线。依据以上业务状况，来设计分布式ID：长处：1）不同机房不同机器不同业务线内生成的ID互不雷同；2）每个机器的每毫秒内生成的ID不同；3）预留两位留作扩大位。毛病：当并发度不高的时候，工夫跨毫秒的音讯，辨别不进去音讯的先后顺序。因为工夫跨毫秒的音讯生成的ID前面的最初一位都是0，后续如果依照音讯ID维度进行分库分表，会导致数据歪斜。 两种解决方案：1）计划一：去掉snowflake最初8位，而后对残余的位进行取模；2）计划二：不同毫秒的计数，每次不是归0，而是归为随机数，相比计划一，比较简单实用。 相干材料可参考：《微信的海量IM聊天音讯序列号生成实际（算法原理篇）》《微信的海量IM聊天音讯序列号生成实际（容灾计划篇）》《解密融云IM产品的聊天音讯ID生成策略》《深度解密美团的分布式ID生成算法》《开源分布式ID生成器UidGenerator的技术实现》《深度解密滴滴的高性能ID生成器(Tinyid)》 14、音讯未读数设计14.1根本实现思路大抵如下：1）每发一个音讯，音讯接收者的会话未读数+1，并且接收者所有未读数+1；2）音讯接收者返回音讯接管确认ack后，音讯未读数会-1；3）音讯接收者的未读数+1，服务端就会推算有多少条未读数的告诉。 分布式锁保障总未读数和会话未读数统一：1）起因：当总未读数减少，这个时候客户端来了申请将未知数置0，而后再减少会话未读数，那么会导致不统一；2）保障：为了保障总未读数和会话未读数原子性，须要用分布式锁来保障。 14.2群聊音讯未读数的难点和优化思路对于群聊来说，音讯未读数的技术难点次要是：一个群聊每秒几百的并发聊天，比方音讯未读数，相当于每秒W级别的写入redis，即使redis做了集群数据分片+主从，然而写入还是单节点，会有写入瓶颈。我的优化思路是：按群ID分组或者用户ID分组，批量写入，写入的两种形式：定时flush和满多少音讯进行flush。 15、网关设计15.1概述本套IM零碎在设计时，将网关分为了接入层网关和应用层网关两种。接入层网关和应用层网关区别次要是：1）接入层网关须要有接管告诉包或者上行接收数据的端口，并且须要另外开启线程池。应用层网关不须要开始口，并且不须要开启线程池；2）接入层网关须要放弃长连贯，接入层网关须要本地缓存channel映射关系。应用层网关无状态不须要保留。 15.2接入层网关设计我的设计指标是：1）网关的线程池实现1+8+4+1，缩小线程切换；2）集中实现长连贯治理和推送能力；3）与业务服务器解耦，集群部署缩容扩容以及重启降级不相互影响；4）长连贯的监控与报警能力；5）客户端重连指令一键实现。次要技术要点：1）反对自定义协定以及序列化；2）反对websocket协定；3）通道连贯自定义保活以及心跳检测；4）本地缓存channel；5）责任链；6）服务调用齐全异步；7）泛化调用；8）转发告诉包或者Push包；9）容错网关down机处理。设计方案（一个Notify包的数据经网关的线程模型图）： 15.3应用层API网关设计我的设计指标是：1）基于版本的主动发现以及灰度/扩容 ，不须要关注IP；2）网关的线程池实现1+8+1，缩小线程切换；3）反对协定转换实现多个协定转换，基于SPI来实现；4）与业务服务器解耦，集群部署缩容扩容以及重启降级不相互影响；5）接口错误信息统计和RT工夫的监控和报警能力；6）UI界面实现路由算法，服务接口版本治理，灰度策略管理以及接口和服务信息展现能力；7）基于OpenAPI提供接口级别的主动生成文档的性能。 ...

为了更好地分类浏览 52im.net 总计1000多篇精编文章，我将在每周三推送新的一期技术文集，本次是第16 期。[- 1 -] 浅谈IM零碎的架构设计 [链接] http://www.52im.net/thread-307-1-1.html [摘要] 上面把我近年来从技术上我对IM零碎（即时消息的传输，不包含语音，视频，文件的传输）的了解和设计分享进去，肤浅之见，望大家别见笑，欢送给出批评意见。 [- 2 -] 简述挪动端IM开发的那些坑：架构设计、通信协议和客户端 [链接] http://www.52im.net/thread-289-1-1.html [摘要] 有过挪动端开发经验的开发者都深有体会：挪动端IM的开发，与传统PC端IM有很大的不同，尤其无线网络的不可靠性、挪动端硬件设施资源的有限性等问题，导致一个残缺的挪动端IM架构设计和实现都充斥着大量的挑战。本文将简述挪动端IM最重要的架构设计和通信协议抉择方面的坑点，心愿为IM开发者同行带来些许启发。 [- 3 -] 一套海量在线用户的挪动端IM架构设计实际分享(含具体图文） [链接] http://www.52im.net/thread-812-1-1.html [摘要] 本文分享了一套残缺的海量在线用户的挪动端IM架构设计，来自于作者的实在我的项目实际总结，蕴含了具体的算法原理图、数据结构定义、表构造定义等等。 [- 4 -] 一套原创分布式即时通讯(IM)零碎实践架构计划 [链接] http://www.52im.net/thread-151-1-1.html [摘要] 无论是IM音讯通信零碎还是客户音讯零碎，其本质都是一套音讯发送与投递零碎，或者说是一套网络通信零碎，其本质两个词：存储与转发。举荐：如有趣味，本文作者的另一篇《一套高可用、易伸缩、高并发的IM群聊架构方案设计实际》，适宜进行IM群聊架构设计的参考。 [- 5 -] 从零到卓越：京东客服即时通讯零碎的技术架构演进历程 [链接] http://www.52im.net/thread-152-1-1.html [摘要] 京东的客服即时通讯零碎名为咚咚是。咚咚之于京东相当于旺旺之于淘宝，它们都是服务于买家和卖家的沟通。自从京东开始为第三方卖家提供入驻平台服务后，咚咚也就随之诞生了。 [- 6-] 蘑菇街即时通讯/IM服务器开发之架构抉择 [链接] http://www.52im.net/thread-31-1-1.html [摘要] 因为IM服务器外面的内容比拟多，这个能够是一个系列的内容，所以这里只介绍服务器的架构以及为什么抉择这样的架构。 [- 7 -] 腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT [链接] http://www.52im.net/thread-158-1-1.html [摘要] 家喻户晓海量互联网服务能力是世界公认的技术难题。通过十多年的倒退，腾讯在海量互联网服务方面已有不少技术积攒。PPT中以QQ IM后盾服务为例，重现了QQ在线用户从百万级到亿级的整个过程中遇到的技术挑战，并与与会者分享了泛滥在海量互联网后盾服务研发经营方面鲜为人知的机密。 [- 8-] 微信后盾基于工夫序的海量数据冷热分级架构设计实际 [链接] http://www.52im.net/thread-895-1-1.html [摘要] 时隔3年，微信团队再次分享了本文所述架构的最新降级版本及其革新过程，有趣味能够返回浏览《微信后盾基于工夫序的新一代海量数据存储架构的设计实际》。 [- 9 -] 微信技术总监谈架构：微信之道——大道至简(演讲全文) ...

明天，环信迎来了 10周年生日庆典～ 环信从13年开始守业，从车库咖啡开发app开始，到14年5月公布即时通讯云，15年搬到数码大厦开始IM PaaS和客服SaaS双畛域倒退。守业十年，咱们创始了即时通讯云畛域，继续服务宽广开发者，一路走来咱们引领了诸多行业翻新。我起环信这个名字，来源于环聊和微信各取一字，也反映团队的环球通信幻想。指标是远大的，路线是起伏的，咱们痛并高兴着。从初期继续的熬夜，到无数个上线的夜晚，和那些数不清的烽火连天。数百人的致力，激情与翻新，晚期数千客户的信赖，开发者帮忙开发者，大家携手创始了一个全新的即时通讯云行业，让环信成为了开发者云服务的领导品牌。十年磨一剑，而今再登程。展望未来十年，环信将齐全聚焦在IM 和通信云畛域，指标是早日实现 “Message infrastructure for the internet” —— 互联网的音讯基础设施 ----环信创始人 马晓宇数字10在十进制和计算机世界的二进制里都示意进一位，对于企业的生命周期而言，10年代表着一个新的里程碑，是一个新的开始，将踏入下一个新的台阶。明天，环信10周年庆典正式揭幕。为了回馈一路走来，客户和开发者们的反对与陪伴，咱们筹备了系列流动和礼品，IMGeek 社区周年趴系列流动：「我的程序人生征文」「寄语有奖」「有奖答题」；产品促销流动：「环信10周年大回馈」「10周年专属礼品」欢送大家参加 ！～10周年庆典活动现已上线，快来看看这趟旅途中会有哪些精彩亮点吧~ 咱们这10年 用心服务 链接无界十年间环信从一个小小的守业团队，不停追赶大大的幻想：立志于为开发者提供最稳固、最优质、最便捷、最全面的挪动即时通讯能力。明天，咱们曾经成长为一家当先的，服务寰球客户的企业级根底音讯服务提供商。过来十年，咱们见证了有数基于环信 IM，令人惊叹的翻新和改革：从社交娱乐到电子商务，从教育、医疗到保险、金融，既有高大上又有小而美。环信开发者应用 IM 扭转了人们沟通、学习、工作、娱乐和生存的形式，为寰球数亿人提供了更好的体验和服务。将来十年，咱们将持续保持以客户为核心，以技术为驱动，以翻新为能源，以卓越为指标。咱们将持续欠缺和优化咱们的产品和服务，让寰球开发者可能更加稳固、平安、便捷地应用环信 IM。将持续拓展和深入咱们的单干关系，让大家可能更加严密、敌对、互利地与环信共赢。咱们将持续摸索和挑战咱们的潜能和极限，让大家可能更加惊喜、称心、骄傲地抉择环信。----环信联席CEO 赵贵斌IMGeek 社区周年趴！神秘大礼号召你！为了回馈一路走来，社区开发者们的反对与陪伴，这个6月咱们筹备了一系列流动和礼品，「我的程序人生征文」「寄语有奖」「环信开发者技术等级考试」「10周年专属徽章」，欢送大家参加～ 10周年白皮书巨献合集10周年之际，环信公布了即时通讯畛域白皮书巨献合集，此合集提供了丰盛的即时通讯畛域技术剖析和思考。涵盖了即时通讯畛域的诸多热点话题，展示了环信在该畛域一直摸索和翻新的精力和成绩。对于即时通讯畛域的从业人员、学者和爱好者来说，无疑是一份贵重的参考资料和技术指南。 白皮书下载链接：https://www.easemob.com/event/10th/ 10周年钜惠福利·人气爆款 十力代表在这个非凡的日子，咱们推出十周年生日大礼，十年守护，四重豪礼感恩用户的陪伴和容纳，与咱们独特成长～环信十周大回馈 返回10周年主会场，开启你的探索之旅吧！

本文内容由百度技术团队分享，原题“基于公共信箱的全量音讯实现”，为了帮忙了解，有较多订正、内容重组和从新排版。 1、引言百度的IM音讯中台为百度APP以及厂内百度系产品提供即时通讯的能力，提供包含私聊、群聊、聊天室、直播弹幕等用户沟通场景，并帮忙业务通过音讯推送触达用户。现在，百度APP新增了一种须要以“低用户打搅”的模式触达全量用户的场景需要，而现有的IM音讯中台次要是基于用户“公有信箱”告诉拆分的机制（艰深了说也就是IM里的“扩散写”），所以如果不进行革新，是很难低成本、高时效的满足该场景诉求。 基于上述问题，本文介绍了百度现有IM音讯中台零碎的次要组成，并比照多种实现计划的优劣，以“私有信箱”告诉读扩散的技术计划对现有IM音讯中台零碎进行革新，从而达成了低成本、高时效地实现全量用户告诉推送需要。 技术交换： 挪动端IM开发入门文章：《新手入门一篇就够：从零开发挪动端IM》开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）（本文已同步公布于：http://www.52im.net/thread-4235-1-1.html） 2、全量用户音讯推送需要背景百度APP新增了须要通过IM实时告诉触达全量用户的诉求，比方2022年12月7日解除疫情管控完结后，将通过筛选的官网政策解读、专题汇总、常识科普、实用工具类介绍等信息，通过官网号“x度小助手”下发触达到百度APP用户，从而来无效体现人文关心，进步用户粘性。在以IM音讯服务进行全量用户音讯触达时，须要满足以下诉求： 具体就是：1）在触达范畴上：心愿尽量扩充用户触达范畴，包含百度APP月活用户、以及非月活用户然而近期新注册或登录的用户；2）在时效上：一次全量触达，心愿短时间内实现（比方小时级、甚至分钟级），抢占时效性；3）在用户打搅方面：音讯触达不能给用户带来较大的打搅，每次音讯下发，只触达一次，不能反复打搅用户（然而须要保留回访入口，满足用户二次查看的诉求）。 3、现有IM音讯中台的技术痛点咱们现有的IM（即时通讯）服务中，每个IM用户对应一个用户信箱。基于现有的IM技术实现计划，如果想实现全量用户的音讯触达，须要把音讯推送到每个用户的信箱（也就是IM中的扩散写）。这样的话，要实现6亿以上的音讯写入（假设每条占用存储4KB，每秒写入2W条音讯），在音讯写入时效性以及存储资源耗费上，都是很难承受的。且现有的基于用户公有信箱的计划，在同时反对多条全量用户告诉音讯的场景下，扩展性也较差。基于上述需要背景和技术痛点，咱们本次的革新目标，就是要找到一种技术计划，从而在特定业务场景下通过革新后的音讯服务，低成本、高时效的给全量用户推送内容统一的音讯告诉。 4、现有IM音讯中台的次要技术实现在探讨革新计划前，咱们有必要介绍一下目前IM音讯零碎的现状，包含音讯零碎的组成、告诉拉取模式、用户信箱等。4.1 音讯零碎组成从普通用户的直观体验上看，一个IM零碎能够包含如下元素：1）用户主体；2）用户账号；3）账号关系；4）聊天会话；5）聊天音讯。用自然语言串一下以上元素就是：1）“用户主体”具备“用户账号”；2）“用户主体”具备头像、昵称等用户属性；3）“用户主体”通过“用户账号”登录IM零碎，进行聊天；4）“用户账号”之间的关注、屏蔽、免打搅等形成“用户关系”；5）通过用户之间的互动环节能够产生“聊天音讯”；6）聊天记录形成了一个“聊天会话”。上面这张图可能更直观一些：从集成音讯服务的业务方角度看：1）一个IM零碎能够包含音讯客户端（音讯客户端UI组件、音讯SDK）和音讯服务端；2）IM音讯能够作为一种服务，嵌入到各业务零碎中，为业务零碎提供“实时交互”能力；3）业务通过集成IM服务，晋升其用户体验；4）业务APP集成IM SDK，通过IM SDK与IM Server交互，实现用户上行通信能力；5）业务APP Server通过与IM Server交互，实现告诉上行触达用户。下图为一个集成了IM SDK的业务架构图：从应用场景来看，音讯包含：1）“私信音讯”（包含用户上下行音讯）；2）“告诉音讯”（业务方给用户推送的上行音讯）；3）“群聊”、“聊天室”；4）“直播间弹幕”等。4.2 音讯的告诉拉取模式百度的IM音讯零碎，采纳告诉拉取（notify-pull）模式来感知新音讯、拉取新音讯。IM SDK登录时，与IM 服务端建设长连贯（LCS, Long Connect Service），用户有新的音讯时，通过长连贯下发notify，实时告诉用户的IM SDK。实时notify不写用户信箱，因为noitfy不是音讯（能够了解为揭示在线用户有新音讯的信号），IM SDK依据这个信号，来服务端拉取音讯。业务方server或者其余用户给该用户发送音讯后，通过IM业务解决模块，把音讯写入接收者信箱，IM Server会依据用户的登录和路由信息，给音讯接收者（私信场景下也包含“音讯发送者”，用于音讯的多端同步）发送新音讯notify，接管到notify的IM设施，通过IM SDK来IM Server端拉取（pull）音讯。4.3 用户信箱介绍为了暂存尚未拉取到IM SDK本地的离线音讯，须要对音讯进行服务端存储，而音讯的离线存储是通过音讯信箱服务实现的。目前百度的IM用户音讯信箱次要包含：1）用户公有信箱；2）群公共信箱（非下文提到的用户公共信箱）；3）直播间弹幕mcast等。用户信箱通过“音讯所属利用”+“IM标识用户的惟一ID”来标识。就一条音讯而言：音讯参与者有“音讯发送者”和“音讯接收者”，音讯收发单方的信箱都是互相独立的（假如发送方删除了本人信箱的某一条音讯，不会影响音讯接受者信箱的音讯）。对于有查看历史音讯诉求的一方来说：音讯须要入该方的信箱，比方用户之间的私信（也就是一对一单聊）音讯须要入发送者和接收者的信箱。而对于全量用户音讯告诉的场景：音讯不须要存储发送者信箱，而只须要存接收者的信箱。而用户的信箱排序，是基于信箱Timeline（详见《古代IM零碎中聊天音讯的同步和存储计划探讨》）。即音讯在信箱外部基于工夫线存储，每条音讯对应一个unix 微秒工夫戳（如第一条音讯1679757323320865），用户进行信箱拉取时，基于工夫范畴正序或者逆序拉取。如下为信箱Timeline的示例：用户信箱中的每一条音讯记录都蕴含四个次要局部：1）“音讯ID”；2）“音讯用户标识”；3）“音讯通用属性”；4）“音讯业务属性”。上面具体介绍以上四个局部：1）音讯ID：为unix微秒工夫戳，不须要全局惟一，只须要特定用户信箱范畴内惟一即可；2）音讯用户标识：包含from_uid、to_uid、contacter；3）音讯通用属性：包含create_time、expire、is_read；4）音讯业务属性：包含category、type、priority、business_type、APP_id、msgkey、content等。如下为一条音讯记录示例： 5、全量用户音讯推送技术计划选型5.1 需要剖析目前百度的IM音讯推送机制中，次要反对：1）单播：音讯推送形式，每次给一个用户推送一条音讯;2）批量单播：每次给小范畴用户推送音讯，比方30个;3）播送：基于关注关系的推送，如给全量粉丝推送。上述三种音讯推送机制推送的音讯，均须要存储服务端的用户公有信箱。为了实现百度APP 6亿以上全量月活用户的音讯推送，目前有三种可选的计划，接下来咱们逐个剖析。5.2 计划1：全流程从告诉入口推送该种形式下：须要获取全量的月活用户列表，通过IM Server推送入口，给每一个用户推送疫情相干告诉。该告诉写入到用户信箱时：1）若用户在线，在实时拉取该告诉；2）若用户离线，再下次登录IM服务时，拉取离线告诉。该种计划下：推送行为会笼罩IM的全流程，推送的告诉会进入每个月活用户的公有信箱，服务压力大。其中增量用户不会收到告诉推送（这里增量用户指的是不在月活用户列表的用户）。5.3 计划2：跳过告诉入口间接写信箱该种形式跳过IM音讯推送流程中的中间环节，间接把告诉音讯写入用户信箱。因为跳过了两头流程间接写入信箱，告诉写入速度次要取决于信箱底层存储的压力接受状况。该种计划下，同计划1一样，无奈给用户发送实时告诉，依赖用户IM SDK的被动音讯拉取（断链后从新登录/新音讯揭示拉取），无奈给增量用户发送告诉。该计划因为跳过中间环节间接写信箱，危险较大，无奈间接提供给业务方应用，不倡议如此操作。5.4 计划3：私有信箱实现机制该种私有信箱机制的逻辑是把告诉音讯写入“公共信箱”。在用户音讯拉取时，合并“用户私信信箱”+“公共信箱”的音讯。5.5 三种计划比拟计划1和2都是写扩散形式，基于现有“用户公有信箱”的机制，把告诉音讯写入每个接管告诉的用户公有信箱。计划2与计划1的差异次要是跳过了音讯两头流程，能够防止因为中间环节负载瓶颈导致整体音讯写入速度过低。计划3是读扩散形式，音讯不必再写入接管告诉的用户公有信箱，而只须要在公共信箱存储一份。在用户拉取音讯时，实时拉取公共信箱的音讯。计划③中能够采纳内存缓存计划，解决对公共信箱的读压力。实质上来说：计划3与计划前两种相比，是用读老本（CPU）换写老本（存储）。 6、基于私有信箱技术计划的全量用户音讯推送实现6.1 概述基于上述计划3的思路，咱们进行基于私有信箱的全量音讯设计与实现。该种计划中蕴含两个次要流程：1）全量音讯的治理；2）用户公有+私有信箱的拉取。6.2 全量音讯的治理全量音讯治理次要分为：1）经营O端操作平台：复用经营音讯平台；2）全量音讯解决服务：复用IM服务的连贯层、逻辑解决层、信箱代理、信箱解决。经营O端平台为经营同学提供可视化界面，能够对全量音讯进行编辑、预公布、公布、批改、进行、撤回等操作。具体就是：1）接入层：对接经营O端，进行参数校验、转发IM后端逻辑解决模块；2）逻辑解决层：进行全量音讯的创立、批改、进行、删除、撤回等逻辑操作；3）信箱代理层：复用IM服务的信箱CRUD操作；信箱存储层公共信箱的底层存储。全量音讯治理流程：6.3 用户信箱拉取用户通过IM SDK，以长连贯的形式，在逻辑解决层进行音讯拉拉取。在用户拉取信箱音讯时，须要对“用户集体信箱”和“私有信箱”进行合并。于是每次用户信箱拉取，都须要进行信箱的合并拉取。6.3.1）公共信箱内存缓存机制：百度APP的IM用户，在IM SDK登录时须要拉取信箱中的音讯。每次音讯拉取时，须要查看公共信箱中是否有音讯。因而，公共信箱须要能抗住日常和峰值流量（拉取峰值为4.7Wqps）。为了避免流量击穿，流量打到底层的长久化公共信箱MYSQL存储，咱们设计了基于内存的公共信箱缓存机制。同时公共信箱内容变动时，也要实时（或者在能容忍的范畴内做到准实时）变更内存缓存信箱中的音讯，咱们采纳Bthread定期轮询长久化公共信箱，更新内存公共信箱，轮询距离可配置（比方设置1秒）。6.3.2）分级公布机制：同时，在逻辑层实现白名单机制，反对全量音讯在“预公布”状态下，仅对白名单用户可见，从而达到分级验证的成果。白名单的用户列表通过逻辑解决成的配置加载，也反对通过CURL申请动静批改白名单的配置。 7、基于私有信箱技术计划的技术挑战私有信箱的技术计划，须要解决如下问题： 8、基于私有信箱技术计划的优缺点总结8.1 长处以公共信箱的形式，实现全量用户音讯散发，具备：“散发速度快”、“资源成本低”的特点。8.2 毛病但公共信箱的形式也存在肯定的局限性。8.2.1）不适用于个性化要求高的场景：因为音讯在公共信箱只存储一份，下发音讯内容固定，无奈很大水平下，下发个性化音讯（当然也不是肯定无奈下发个性化的音讯，能够通过在公共信箱存储音讯模板，依据拉取音讯的用户ID获取个性化信息，在音讯拉取时，长期拼装音讯，这样就增大了音讯拉取时的代价）。8.2.2）不适用于实时音讯揭示场景：1）从业务场景上看：全量音讯优先级低，不须要在全量失效的霎时让用户感知。2）从实现上看：全量音讯实时音讯揭示老本高。因为实时音讯揭示Notify，须要以相似单播的模式实时告诉用户。和单播的区别是，Notify不必触达离线用户，也就是不必写用户信箱，只需实时触达在线用户。3）从零碎压力看：全量在线用户均收到实时新音讯揭示，会带来信箱拉取申请的刹时流量（手机百度IM SDK长连贯峰值在线1550W，假设新音讯揭示在霎时下发，同时在线用户信箱拉取申请，会把db打挂的）。 9、基于私有信箱技术计划的落地施行成果全量音讯目前曾经在百度APP失去利用，包含：重大告诉的下发；百度APP性能更新介绍告诉；音讯的撤回，后续还将推广到其余的矩阵APP的全量告诉推送场景。举个具体的例子：22年Q4发表疫情解封时，利用全量音讯推送，低成本、高时效的实现3条“疫情解封专项”全量音讯下发。 在这个例子中，三次全量音讯下发，达到数据在2亿+（该值小于月活的6亿+），次要因为几个起因：1）本次全量音讯有效期仅3天左右，全量音讯有效期内登录IM SDK的用户才有机会拉到全量音讯；2）本次下发应用了新的音讯展现模板，所以限度了拉取全量音讯的百度APP版本，只有高版本百度APP能够拉到；3）本次全量音讯，限度了仅有百度APP登录用户拉取。 10、将来瞻望本文介绍了现有IM音讯中台零碎，并通过私有信箱技术计划的革新，达成了低成本、高散发速度实现全量用户音讯下发的设计、实现与利用。在全量用户音讯利用方面，除了业务上的应用，后续也能够用于播送音讯、批量单播音讯的撤回。比方因为误操作发送了播送音讯，用户曾经把播送音讯拉到了端，并长久化到端，这是能够“以全量音讯的形式，下发删除指令”，删除曾经缓存到端的垃圾音讯。咱们心愿，通过音讯零碎继续一直优化，为更多的业务提供低成本、高稳定性的即时通讯能力。 11、相干材料[1] 古代IM零碎中聊天音讯的同步和存储计划探讨[2] 百度APP挪动端网络深度优化实际分享(一)：DNS优化篇[3] 百度APP挪动端网络深度优化实际分享(二)：网络连接优化篇[4] 百度APP挪动端网络深度优化实际分享(三)：挪动端弱网优化篇[5] 百度直播的海量用户实时音讯零碎架构演进实际[6] 深刻理解百度开源的分布式RPC框架brpc的方方面面[7] 百度网盘千万节点的P2P架构设计(PPT)[8] 零根底IM开发入门(一)：什么是IM零碎？[9] 一套海量在线用户的挪动端IM架构设计实际分享(含具体图文)[10] 一套原创分布式即时通讯(IM)零碎实践架构计划[11] 一套亿级用户的IM架构技术干货(上篇)：整体架构、服务拆分等[12] 基于实际：一套百万音讯量小规模IM零碎技术要点总结[13] 一套十万级TPS的IM综合音讯零碎的架构实际与思考[14] 从老手到专家：如何设计一套亿级音讯量的分布式IM零碎[15] 闲鱼亿级IM音讯零碎的架构演进之路[16] 深度解密钉钉即时消息服务DTIM的技术设计[17] 一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实际[18] 企业微信的IM架构设计揭秘：音讯模型、万人群、已读回执、音讯撤回等（本文已同步公布于：http://www.52im.net/thread-4235-1-1.html）

► 相干链接：① MobileIMSDK-Uniapp端的具体介绍② MobileIMSDK-Uniapp端的开发手册new（* 精编PDF版） 一、理论知识筹备您须要对Uniapp和Vue开发有所理解：1）Uniapp 官网入门教程2）可能是最好的 uniapp 入门教程3）Uniapp 官网 Vue 疾速入门教程您须要对WebSocket技术有所理解：1）老手疾速入门：WebSocket 扼要教程2）WebSocket 详解（一）：初步意识 WebSocket 技术3）WebSocket 从入门到精通，半小时就够！4）从零了解 WebSocket 的通信原理、协定格局、安全性规范 WebSocket协定文档、API手册：1）WebSocket 的 API 手册2）WebSocket 的规范文档 Uniapp 的 WebSocket 文档和手册：1）uniapp 官网文档 二、开发工具筹备1）HBuilderX：（JackJiang 应用的版本号如下图所示，为了不便间接援用工程，倡议你也应用此版或较新版本）2）一站式下载地址：HBuilderX官网下载地址点此进入。3）HBuilderX成果预览： 三、SDK 文件用处阐明3.1文件概览纯 Uniapp 规范 JS API 实现，无任何第 3 方库依赖，更无本地原生代码混编：MobileIMSDK-Uniapp 端 SDK 自身只是 JS 文件源码的汇合，自带的 Demo 代码只是为了不便随时测试 SDK 代码，目标次要是用于演示 SDK 的 API 调用，Demo 代码不属于 SDK 框架的一部分。大抵的目录阐明： 3.2具体阐明SDK 各模块/文件作用阐明： 四、次要 API 接口4.1次要 API 接口概览所有 SDK 接口均由/mobileimsdk/mobileimsdk-client-sdk.js 提供。以下是次要 API 接口概览图。 如下图所示：接口设计跟 MobileIMSDK  的APP版一样，均为高内聚和低侵入式的回调形式传入业务层解决逻辑，无需（也不倡议）开发者间接批改 sdk 级代码。 4.2次要 API 接口概览1）IMSDK.isLogined()：用处：是否曾经实现过首次登陆。阐明 ：用户一旦从自已的利用中实现登陆IM服务器后，本办法就会始终返回true（直到退出登陆IM）。返回值：{boolean}，true示意已实现首次胜利登陆（即曾经胜利登陆过IM服务端了，前面掉线时不影响此标识），否则示意尚未连贯IM服务器。2）IMSDK.isOnline()：用处：是否在线。阐明 ：示意网络连接是否失常。返回值：{boolean}，true示意网络连接失常，否则示意已掉线，本字段只在this._logined=true时有意义（如果都没有登陆到IM服务器，怎么存在在线或掉线的概念呢）。 ...

为了更好地分类浏览 52im.net 总计1000多篇精编文章，我将在每周三推送新的一期技术文集，本次是第15 期。[- 1 -] IM跨平台技术学习(一)：疾速理解新一代跨平台桌面技术——Electron [链接] http://www.52im.net/thread-2616-1-1.html [摘要] 本文将从入门者的角度，为你疾速解说Electron到底是个什么技术，包含案例介绍、技术劣势、技术体验、实现原理等。 [- 2 -] IM跨平台技术学习(二)：Electron初体验(疾速开始、跨过程通信、打包、踩坑等) [链接] http://www.52im.net/thread-4039-1-1.html [摘要] 本篇将带你简略上手Electron框架开发跨平台桌面端，内容包含一个疾速开始例子、跨过程通信原理、打包和散发、以及一些典型的技术踩坑等。心愿能带给你启发。 [- 3 -] IM跨平台技术学习(三)：vivo的Electron技术栈选型、全方位实际总结 [链接] http://www.52im.net/thread-4044-1-1.html [摘要] 本篇将基于vivo技术团队的技术实际，具体论述了vivo在应用Electron进行跨端桌面开发时的技术栈选型考量，同时分享了在打包构建、版本更新、性能优化、品质保障、安全性等方面的实际计划和踩坑总结。 [- 4 -] IM跨平台技术学习(四)：蘑菇街基于Electron开发IM客户端的技术实际 [链接] http://www.52im.net/thread-4051-1-1.html [摘要] 本篇将回到IM即时通讯技术自身，依据蘑菇街的理论技术实际，总结和分享基于Electron开发跨平台IM客户端的过程中，须要思考的典型技术问题以及咱们的解决方案。 [- 5 -] IM跨平台技术学习(五)：融云基于Electron的IM跨平台SDK革新实际总结 [链接] http://www.52im.net/thread-332-1-1.html [摘要] 本文分享的是融云基于Electron的IM跨平台PC端SDK革新过程中所总结的一些实践经验，心愿对你有用。 [- 6 -] IM跨平台技术学习(六)：网易云信基于Electron的IM音讯全文检索技术实际 [链接] http://www.52im.net/thread-4065-1-1.html [摘要] 本文将要分享的是，网易云信基于Electron的PC端是如何实现IM客户端全文检索能力的。 [- 7 -] IM跨平台技术学习(七)：得物基于Electron开发客服IM桌面端的技术实际 [链接] http://www.52im.net/thread-4159-1-1.html [摘要] 本文要分享的是得物技术团队基于Electron开发客服IM桌面端的技术实际过程，内容包含桌面技术选型、Electron的根底概念、具体的施行技术计划、遇到的辣手问题等。 [- 8-] 社交软件红包技术解密(一)：全面解密QQ红包技术计划——架构、技术实现等 [链接] http://www.52im.net/thread-2202-1-1.html [摘要] 本文将从架构开始，到手机 QQ 挪动端优化，再到个性化红包和 AR 新玩法，为大家全面解密 QQ 红包技术计划。 ...

一、根本介绍MobileIMSDK-Uniapp端是一套基于Uniapp跨端框架的即时通讯库：1）超轻量级、无任何第3方库依赖（开箱即用）；2）纯JS编写、ES6语法、高度提炼，简略易用；3）基于Uniapp规范WebSocket API，简洁优雅；4）实践上可运行于任何反对Uniapp跨端框架的平台上；5）能与 MobileIMSDK（Github托管链接） 的各种客户端完满互通；6）可利用于基于Uniapp的跨平台App或Web的音讯推送、客服聊天、企业OA、IM等场景。 具体开发材料：① MobileIMSDK-Uniapp端具体介绍 ② MobileIMSDK-Uniapp端开发手册 ③ MobileIMSDK-开源框架的详细资料 （Github托管链接） 二、与MobileIMSDK的关系MobileIMSDK-Uniapp端 是基于Uniapp规范 WebSocket API的 MobileIMSDK配套客户端库。以下是MobileIMSDK的最新通信架构图： MobileIMSDK是一套专为挪动端开发的原创开源IM通信层框架：1）历经8年、久经考验；2）超轻量级、高度提炼，lib包50KB以内；3）精心封装，一套API同时反对UDP、TCP、WebSocket三种协定（可能是全网惟一开源的）；4）客户端反对iOS、Android、规范Java、H5(暂未开源)、微信小程序(暂未开源)、Uniapp(暂未开源)；5）服务端基于Netty，性能卓越、易于扩大；6）可与姊妹工程 MobileIMSDK-Web 无缝互通实现网页端聊天或推送等；7）可利用于跨设施、跨网络的聊天APP、企业OA、音讯推送等各种场景。PS： MobileIMSDK始终在继续开发和降级中，本Uniapp客户端是MobileIMSDK工程的最新成绩。 三、设计指标间接应用Uniapp的WebSocket API开撸，有以下问题和劣势：1）性能无限： 没有心跳保活、断线重连、音讯送达保障（重传和去重）等即时通讯要害算法和逻辑；2）API简陋： 在如此无限的API接口下，能逻辑清晰且强壮地实现并组合心跳保活、断线重连、音讯送达保障等算法，须要相当高的技术掌控力；3）逻辑耦合： 教训欠缺的开发人员，会将WebSocket通信与前端UI界面代码混在一起，使得UI界面的编写、保护、改版都十分艰难。针对以上问题： MobileIMSDK-Uniapp端库将让开发者专一于UI应用层的开发，网络通信层的业余代码交由SDK开发人员，从而解偶UI前端和通信层的逻辑耦合性，大大降低技术复杂度和利用门槛。MobileIMSDK-Uniapp端库的设计指标是为您的开发带来以下便当：1）界面与通信解偶： UI界面与网络通信代码解耦，UI界面的重构、保护、改版都非常容易和优雅；2）轻量级和兼容性： 受害于保持应用Uniapp的规范WebSocket API，简洁轻量，无需任何额定库依赖；3）外围内聚和收敛： 得益于长期的提炼和教训积攒，SDK核心层高度封装，开发者无需了解简单算法即可简略上手。4）纯JS轻量级实现： 纯JS编写、ES6语法，无重量级框架和库依赖（更无Native代码），可干净利落地对接各种既有零碎；5）跨平台运行能力： 受害于Uniapp框架的跨端个性，实践上本SDK可运行于任何反对Uniapp的平台上。 四、技术亮点1）轻量易使用： 超轻量级——纯JS编写且无任何第3方库依赖，高度提炼——简略易用；2）代码现代感： 尽可能优先应用ES6语法，摒弃新式JS语法的年代感；3）跨端反对好： 基于Uniapp的规范WebSocket API（无Native代码依赖），实践上可很好地运行于任何反对Uniapp的平台上；4）断网恢复能力： 领有网络情况自动检测、断网主动治愈的能力；5）送达保障机制： 欠缺的QoS音讯送达保障机制（主动重传、音讯去重、状态反馈等），不漏过每一条音讯；6）通信协议封装： 实现了一个对下层通明的即时通讯通信协议模型；7）身份认证机制： 实现了简略正当的身份认证机制；8）欠缺的log信息： 在开发调试阶段，确保每一个算法关键步骤都有日志输入，让您的运行调试更为便当；9）界面代码解耦： 实现了UI界面代码与SDK网络通信代码解偶，避免界面代码跟IM外围代码混在一起，不利于继续降级、重用和保护；10）多端协定兼容： 实现了与MobileIMSDK各种客户端齐全兼容的协定模型。 五、文件组成SDK代码文件概览：SDK代码文件用处阐明： 六、Demo运行成果和阐明 七、跨平台运行成果演示1）Demo在内置浏览器中的运行成果：2）Demo在电脑浏览器中的运行成果（以Chrome为例）：3）Demo在Android真机上的运行成果：4）Demo在iOS模拟器上的运行成果：5）Demo在iOS真机上的运行成果：6）Demo在微信小程序上的运行成果：7）Demo在支付宝小程序上的运行成果：（其它更多平台的运行成果就不一一列举了，因为都要装置各自的开发工具，硬盘空间吃紧 。。。） 八、详细资料① MobileIMSDK-Uniapp端的具体介绍：点此查看 ② MobileIMSDK-Uniapp端的开发手册（网页版）：点此查看 ③ MobileIMSDK-Uniapp端的开发手册（精编PDF版）：点此查看 （* 举荐）④ MobileIMSDK-开源框架的具体介绍：https://gitee.com/jackjiang/MobileIMSDK （Github托管链接）

本文由阿里技术团队詹背阴（骁飏）分享，原题“一文读懂字符编码”，有订正和改变。一、引言说起计算机字符编码，让我想起了科幻巨作《三体-光明深林》人类遇到外星文化魔戒的画面（以下内容摘自大刘的原文）。 人类第一次近距离看到四维物体魔戒，卓文用中频电波发送了一个问候语。这是一幅简略的点阵图，图中由六行不同数量的点组成了一个质数数列:1，3，5，7，11，13。他们没有指望失去应答，但应答立即呈现了.....太空艇收到了来自“魔戒”的一系列点阵图，第一幅是很参差的一个8×8点阵，共六十四个点；第二幅图中点阵的一角少了一个点，剩下六十三个；第三幅图中又少一点，剩六十二个……“这是倒计数，也相当于一个进度条，可能示意‘它’曾经收到了罗塞塔，正在译解，让咱们等侍。”韦斯特说。“可为什么是六十四点呢?”“应用二进制时一个不大不小的数呗,与十进制的一百差不多。”卓文和关一帆都很庆幸能带韦斯特来，在与未知的智慧体建设交换方面、心理学家的确很有能力。在倒计数达到五十七时，令人激动的事件呈现了：下一个计数没有用点阵示意，“魔戒”发来的图片上赫然显示出人类的阿拉伯数字56！.....在人类摸索外星文化、迈向星辰大海的宇宙征程里，也离不开这种最最根底的编码问题。前一阵跟共事碰到了字符乱码的问题，理解后发现这个问题存在两年了，咱们程序员每天都在跟编码打交道，但大家对字符编码都是只知其一;不知其二：“天天吃猪肉却很少见过猪跑”，明天我就把它彻底讲透！ 举荐浏览：如果本文太“硬”，就看看这两篇吧：《史上最艰深，彻底搞懂字符乱码问题的实质》、《字符编码那点事：疾速了解ASCII、Unicode、GBK和UTF-8》。技术交换： 挪动端IM开发入门文章：《新手入门一篇就够：从零开发挪动端IM》开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）（本文已同步公布于：http://www.52im.net/thread-4210-1-1.html） 二、什么是字符编码？咱们晓得计算机的世界只有0和1，如果没有字符编码，咱们看到的就是一串"110010100101100111001...."，咱们的沟通就如同是在对牛弹琴，我看不懂它，它看不懂我。字符编码就好比人类和机器之间的翻译程序，把咱们熟知的字符文字翻译成机器能读懂的二进制，同时把二进制翻译成咱们能看懂的字符。以下是百科对字符编码的解释:字符编码（Character encoding）也称字集码，是把字符集中的字符，编码为指定汇合中的某一对象（例如：比特模式、自然数序列、8位组或者电脉冲），以便文本在计算机中存储或者通信网络的传递。常见的例子是将拉丁字母表编码成摩斯电码和ASCII，比方ASCII编码是将字母、数字和其它符号进行编号，并用7比特的二进制来示意这个整数。字符集（Character set）是多个字符的汇合，字符集品种较多，每个字符集蕴含的字符个数不同，常见字符集名称：ASCII字符集、GB2312字符集、BIG5字符集、 GB18030字符集、Unicode字符集等。计算机要精确的解决各种字符集文字，就须要进行字符编码，以便计算机可能辨认和存储各种文字。 三、为什么计算机须要编码？3.1、概述编码（Encode）是信息从一种模式转换为另一种模式的过程，比方用预先规定的办法将字符（文字、数字、符号等）、图像、声音或其它对象转换成规定的电脉冲信号或二进制数字。咱们当初看到的一幅幅图画，听到的一首首音乐，甚至咱们写的一行行代码，敲下的一个个字符，所看到的所听到的都是那么的实在，但其实在背地都是一串“01”的数字。你昨天在手机上看到的那个心动女孩，真实世界中并不存在，只是计算机用“01”数字帮你生成的“骷髅”而已（宅男梦碎。。。）。 3.2、二进制其实不存在你可能认为计算机中的数据就是“01”二进制，然而实际上计算机中并没有二进制，即使咱们晓得所有的内容都是存储在硬盘中，然而你把它拆开可找不到外面有任何“0101”的数字，外面也只有盘片、磁道。就算咱们放大了去看盘片，也只有凹凸不平的盘面，凸起的中央是被磁化过的，凹进去的中央是没有被磁化的；只是咱们给凸起的中央取了个名字叫数字“1”，凹进的中央取名叫数字“0”。同样内存里你也找不到二进制数字：内存放大了看就是一堆电容组，内存单元存储的是“0”还是“1”取决于电容是否有电荷，有电荷咱们认为他是“1”，无电荷认为他是“0”。然而电容是会放电的，工夫一长，代表“1”的电容会放电，代表“0”的电容会吸电，这也是咱们内存不能断电的起因，须要定期对电容进行充电，保障“1”的电容电量有电。再说显示器：这个大家感触是最间接的，你透过显示器看到的美女画皮、日月山川，其实就是一个个不同色彩的发光二极管收回强弱不一的光点，显示器就是一群发光二极管组成的矩阵，其中每一个二极管能够被称为一个像素，“1”示意亮，“0”示意灭，而咱们平时能看到五彩的色彩，是把三种色彩(红绿蓝三原色)的发光二极管做到了一起。那对于一个ASCII编码“65”最初又怎么显示成“A”的呢？这就是显卡的功绩，显卡中存储了每一个字符的图形数据（也称字形码），将二维矩阵的图形数据传给显示器成像（如下图所示）。因而：所谓的0和1都是电流脉冲信号，二进制其实是咱们形象进去的数学逻辑概念。那咱们为什么要用二进制示意？因为：二进制只有两种状态，应用有两个稳固状态的物理器件就能够示意二进制中的每一位，例如用高低电平或电荷的正负性、灯的亮和灭都能够很不便地用“0”和“1”来示意，这为计算机实现逻辑运算和逻辑判断提供了便当条件。 四、计算机编码转换过程4.1、概述正因为计算机只能示意“01”的逻辑概念，无奈间接示意图片以及文字，所以咱们须要肯定的转换过程。这其实就是咱们依照肯定的规定保护了字符-数字的映射关系，比方咱们把“A”形象成计算机中的“1”，当咱们看到1的时候就认为这是“A”，实质上就是一张映射表，实践上你能够随便给每个字符调配一个举世无双的编号（character code，字符编码）。比方下表这样：接下来咱们来看下一个文字从“输出-转码存储-输入（显示/打印）”的简略流程。首先：咱们晓得计算机是美国人创造的，规定是美国人定的，键盘上的按键也都是英文字母，所以编号不是你想怎么调配就怎么调配。对于英文字母的输出，键盘和ASCII码之间是间接对应的，键盘按键“A”对应的编号“65”，存储到磁盘上也是“65”的二进制直译“01000001”，这很好了解。然而：对于汉字输入就不是这么回事了，键盘上可没有汉字对应的输出按键，咱们不可能间接敲出汉字字符。于是就有了输入码、机内码、字形码的转换关系，输入码帮忙咱们把英文键盘按键转换成汉字字符，机内码帮忙咱们把汉字字符转换成二进制序列，字形码帮忙咱们把二进制序列输入到显示器成像。 4.2、输入码咱们模仿下汉字的输出过程。首先：关上txt文本敲下“nihao”的拼音字母，而后输出栏会弹出多个符合条件的汉字词组，最初咱们会抉择相应的编号，就能实现汉字的输出。那这过程又是如何实现的呢？计算机领域有一句如同摩西十诫般的神圣哲言：“计算机科学畛域的任何问题都能够通过减少一个间接的中间层来解决”。这里咱们再加一层按键字母组合和汉字的映射表，好比英汉字典，这层咱们称为输入码，输入码到内码的过程就是一次查表转换操作，比方“nihao”这几个ASCII字符，大家能够轻易批改映射表以及候选编号，我能够把他映射成“你好骁飏”（如下图所示）。 4.3、机内码机内码也称内码，是字符编码最外围的局部。机内码是字符集在计算机中理论存储、替换、通信应用的二进制编码，通过内码咱们能够达到高效率的存储、传输文本的目标。咱们的外码（输入码）实现了键盘按键和字符的映射转换，然而机内码是让字符真正变成了机器能读懂的二进制语言。 4.4、字形码计算机中的字符都是以内码的二进制模式示意，咱们怎么把数字对应的字符在显示器上显示进去呢，比方数字“1”代表汉字“你”，怎么把“1”显示成“你”？这就须要依赖字形码，字形码实质上是一个nn 的像素点阵，把某些地位的像素设置为红色（用 1 示意），其它地位像素设置为彩色（用 0 示意），每一个字符的字形都是事后寄存在计算机内，而这样的字形信息库咱们称为字库。比方中文“你”的点阵图，这样一个 1616 的像素矩阵，须要 16 * 16 / 8 = 32 字节的空间来示意，左边的字模信息称为字形码。不同的字库（如宋体、黑体）对同一个字符的字形编码是不同的。所以字符编码到显示的字形码，其实又是另一张查找表，也就是字符编码-字形码的映射关系表。其实咱们也能够认为字符编码是字形码的一种压缩形式，一个占32字节的像素点阵压缩成了2字节的机内码。 五、字符编码的历史5.1、电报编码从狭义上来说，编码的历史很悠久，始终能够追溯到结绳记事的远古期间，但跟古代字符编码比拟靠近的还是摩尔斯电码的创造，自此开启了信息通信时代的大门。摩尔斯电码是由美国人摩尔斯在1837年创造的，比起ASCII还要早100多年，在晚期的无线电上作用十分大，它是每个无线电通信者需必知的，它的是由点dot “.” 和划dash “-” 这两种符号所组成的，电报中表白为短滴和长嗒，跟二进制一样也是二元码。一个二元必定不够示意咱们的字母，那么就用多个二元来示意，比方嘀嗒“.-”代表字母“A”，嗒嘀嘀嘀“-...”代表字母“B”。摩尔斯电码表： 5.2、编码纪元计算机一开始创造进去时是用来解决数学计算问题的，起初人们发现，计算机还能够做更多的事，例如文本处理等。那个时候的机器都很大，机器之间都是隔离的，没思考过机器的通信问题，各大厂商也各干各个的，搞本人的硬件搞本人的软件，想怎么编码就怎么编码。起初机器间须要互相通信的时候，发现在不同计算机上显示进去的字符不一样，在IBM上“00010100”数字代表“A”，跑到微软零碎上显示成了“B”，大家就傻眼了。于是美国的标准化组织就跑进去制订了ASCII编码（American Standard Code for Information Interchange），对立了游戏规则，规定了罕用符号用哪些二进制数来示意。 5.3、百花齐放对立ASCII 码规范对于英语国家很开心，然而ASCII编码只思考了英文字母，起初计算机传到欧洲地区，法国人须要加个字母符号（如：é），德国人又须要加几个字母（Ä ä、Ö ö、ü ü、ß），幸好ASCII只用了前127个编号，于是欧洲人就将ASCII没用完的编码（128-255）为本人特有的符号编码，也能很好的一起游玩。然而等传到咱们中国后，做为博大精深的汉语言就彻底蒙圈了，咱们有几万个汉字，255个编号齐全不够用啊，所以有了起初的多字节编码… 因而，各个国家都推出了外国语言的编码表，也就有了起初的 ISO 8859 系列、GB系列（GB2312、GBK、GB18030、GB13000）、Big5、EUC-KR、JIS … ，不过为了能在计算机系统中通用，这些扩大的编码均间接或间接兼容 ASCII 码。而微软/IBM这些国际化产商为了把本人的产品卖到全世界，就须要反对各个国家的语言，要在不同的中央采纳当地的编码方式，于是他们就把全世界的编码方式都集中到一起并编上号，并且起了个名字叫代码页（Codepage，又称内码表），所以咱们有时候也会看到xx代码页来指代某种字符编码，比方在微软零碎里 中文GBK编码对应的是936代码页，繁体中文 Big5编码对应的是950代码页。这些既兼容ASCII又相互之间不兼容的字符编码，起初又统称为ANSI编码。看到上面这张图预计大家就很相熟了，window上面咱们基本上都用ANSI编码保留。ANSI的字面意思并非指字符编码，而是美国的一个非营利组织，是美国国家标准学会（American National Standards Institute）的缩写，ANSI这个组织为字符编码做了很多规范制订工作，起初大家习惯把这类凌乱的多字节编码叫ANSI编码或者规范代码页。ANSI编码只是一个范称，个别代表零碎默认的编码方式，而且并不是确定的某一种编码方式——比方在Window操作系统里，中国区ANSI编码指的是GB编码，在香港地区ANSI编码指的是Big5编码，在韩国ANSI编码指的是EUC-KR编码。 5.4、天下一统因为各个国家各搞各的字符编码，如果有些人想装逼中文里飚两句韩文怎么办呢？不好意思，你的逼级太高，没法反对，你抉择了GB2312就只能打出中文字符。同时各大国内厂商在兼容各种字符编码问题上也深受折磨，于是忍气吞声之下，决定开发一套能包容全世界所有字符的编码，就有了前面赫赫有名的Unicode。Unicode也叫万国码，包含字符集、编码方案等。Unicode是为了解决传统的字符编码方案的局限而产生的，它为每种语言中的每个字符设定了对立并且惟一的二进制编码，在这种语言环境下，不会再有语言的编码抵触，在同屏下也能够显示任何国家语言的内容，这就是Unicode的最大益处。在Unicode编码方案里常见的有四种编码实现计划UTF-7、 UTF-8、UTF-16、UTF-32，最为出名的就是 UTF-8。Unicode设计之初是采纳双字节定长编码的UTF-16，然而发现历史包袱太重推不动，最初出了个变长的UTF-8才被宽泛承受。 六、字符编码模型6.1、传统编码模型在传统字符编码模型中，基本上都是将字符集里的字符用十进制进行逐个的编号，而后把十进制编号间接转成对应的二进制码，能够说该字符编号就是字符的编码。计算机在解决字符与数字的转换关系上其实就是查找映射表的过程。像ASCII编码就是给每个英文字符编一个举世无双的数字，整个编码处理过程绝对还是比较简单的，计算机外部间接就映射成了二进制，十进制的编号只是不便咱们看的。 6.2、古代编码模型Unicode编码模型采纳了一个全新的编码思路，将编码模型划分为4 个档次（也有说5个档次的），不过第五层是传输层的编码适配，放在编码模型里严格来说不是很失当。这 4 个档次别离是：1）第一层，形象字符集 ACR（Abstract Character Repertoire）：定义形象字符汇合，明确各个形象字符；2）第二层，编号字符集 CCS（Coded Character Set）：将形象字符集进行数字编号；3）第三层，字符编码方式 CEF（Character Encoding Form）：将字符编号编码为逻辑上的码元序列；4）第四层，字符编码方案 CES（Character Encoding Scheme）：将逻辑上的码元序列编码为物理字节序列。上面将别离来具体讲讲各层。 ...

为了更好地分类浏览52im.net 总计1000多篇精编文章，我将在每周三推送新的一期技术文集，本次是第14 期。 [- 1 -] 老手疾速入门：WebSocket扼要教程 [链接] http://www.52im.net/thread-831-1-1.html [摘要] 艰深的讲，WebSocket 是一种新的网络通信协定，当初浏览器端很多高级性能都须要用到它。本文将以通俗易懂的形式介绍 WebSocket 协定的应用办法，适宜初学者疾速入门之用。 [- 2 -] WebSocket从入门到精通，半小时就够！ [链接] http://www.52im.net/thread-3134-1-1.html [摘要] 本文也是一篇对于WebSocket从入门到精通的文章，内容由浅入深，比拟适宜想要在短时间内较深刻的理解WebSocket协定的开发者学习。 [- 3 -] WebSocket详解（一）：初步意识WebSocket技术 [链接] http://www.52im.net/thread-331-1-1.html [摘要] HTML5标准在传统的web交互根底上为咱们带来了泛滥的新个性，随着web技术被宽泛用于web APP的开发，这些新个性得以推广和应用，而websocket作为一种新的web通信技术具备微小意义。本文将带您意识WebSocket。 [- 4 -] WebSocket详解（二）：技术原理、代码演示和利用案例 [链接] http://www.52im.net/thread-326-1-1.html [摘要] 本文将简要介绍 WebSocket 的由来、原理机制以及服务端/客户端实现，并以理论客户案例领导并解说了如何应用 WebSocket 解决实时响应及服务端音讯推送方面的问题。 [- 5 -] WebSocket详解（三）：深刻WebSocket通信协议细节 [链接] http://www.52im.net/thread-332-1-1.html [摘要] ebSocket 是HTML5一种新的web通信技术，它真正实现了浏览器与服务器的全双工实时通信(full-duplex)。本文将详解介绍WebSocket的通信协议细节。 [- 6 -] WebSocket详解（四）：刨根问底HTTP与WebSocket的关系(上篇) [链接] http://www.52im.net/thread-1258-1-1.html [摘要] 因本文有点长，所以分成了高低两篇，本文将首先以通俗易懂的语言着重介绍HTTP协定，下篇中再开展WebSocket协定相干的文字。 [- 7 -] WebSocket详解（五）：刨根问底HTTP与WebSocket的关系(下篇) [链接] http://www.52im.net/thread-1266-1-1.html [摘要] 本文的上篇《WebSocket详解（四）：刨根问底HTTP与WebSocket的关系(上篇)》介绍了HTTP1.1协定的根本内容，这篇文章将持续剖析WebSocket协定，而后对这两个进行简略的比拟。 [- 8-] WebSocket详解（六）：刨根问底WebSocket与Socket的关系 ...

为了更好地分类浏览52im.net 总计1000多篇精编文章，我将在每周三推送新的一期技术文集，本次是第13 期。[- 1 -] 新手入门贴：史上最全Web端即时通讯技术原理详解 [链接] http://www.52im.net/thread-338-1-1.html [摘要] 本文的目标就是要具体探讨这些技术并剖析其原理和过程。 [- 2 -] Web端即时通讯技术盘点：短轮询、Comet、Websocket、SSE [链接] http://www.52im.net/thread-336-1-1.html [摘要] 本文将简要介绍这4种技术的原理，并指出各自的异同点、优缺点等。 [- 3 -] SSE技术详解：一种全新的HTML5服务器推送事件技术 [链接] http://www.52im.net/thread-335-1-1.html [摘要] 本文对服务器推送技术（SSE）进行了具体的介绍，蕴含浏览器端和服务器端的相应实现细节，为在实践中应用该技术提供了指南。 [- 4 -]Comet技术详解：基于HTTP长连贯的Web端实时通信技术 [链接] http://www.52im.net/thread-334-1-1.html [摘要] 一般来说，Web端即时通讯技术因受限于浏览器的设计限度，始终以来实现起来并不容易，支流的Web端即时通讯计划大抵有4种：传统Ajax短轮询、Comet技术、WebSocket技术、SSE（Server-sent Events）。本文将专门解说Comet技术。 [- 5 -] socket.io实现音讯推送的一点实际及思路 [链接] http://www.52im.net/thread-188-1-1.html [摘要] 对于一般站点来说， 申请-响应模式能够满足绝大多数的性能需要，但总有某些性能咱们心愿可能为用户提供实时音讯的体验。 [- 6 - ] LinkedIn的Web端即时通讯实际：实现单机几十万条长连贯 [链接] http://www.52im.net/thread-659-1-1.html [摘要] 在这篇文章中会形容在咱们收到了音讯、分型指标和读回复之后，如何立即把它们发往客户端。内容会蕴含咱们是如何应用Play框架和Akka Actor Model来治理长连贯、由服务器被动发送事件的。咱们也会分享一些在生产环境中咱们是如何在服务器上做负载测试，来治理数十万条并发长连贯的，还有一些心得。最初，咱们会分享在整个过程中咱们用到的各种优化办法。 [- 7 -] Web端即时通讯技术的倒退与WebSocket、Socket.io的技术实际 [链接] http://www.52im.net/thread-690-1-1.html [摘要] 为什么说Web即时通讯技术这么重要？咱们生存在一个实时（real-time）的世界中，因而Web的最终最天然的状态也该当是实时的。用户须要实时的沟通、数据和搜寻。咱们对互联网信息实时性的要求也越来越高，如果信息或音讯延时几分钟后才更新，几乎让人无法忍受。当初很多大公司（如Google、Facebook和Twitter）都在关注实时Web，并提供了实时性服务。实时Web是当初也将是将来最热门的话题之一。 [- 8 -] 开源框架Pomelo实际：搭建Web端高性能分布式IM聊天服务器 [链接] http://www.52im.net/thread-849-1-1.html [摘要] Pomelo是来自网易公司的基于 Node.js 的高性能、分布式游戏服务器框架。它包含根底的开发框架和相干的扩大组件（库和工具包），能够帮忙你省去游戏开发干燥中的重复劳动和底层逻辑的开发。 ...

本文由黄工首先发表于strongerHuang公众号，原题“网络硬件的发展史”，本文有订正。1、引言本文是《网络编程懒人入门》系列文章的第15篇，本篇将持续以通俗易懂的文字，帮你无脑了解各种根底网络硬件设施的性能原理。 本文不列举简单、全面的计算机网络实践，目标是让阅读者脱离以往计算机实践专著的干燥内容，在寓教于乐的语言文字中轻松疾速的把握这些常识，适宜入门者，计网大佬和网络编程老油条们请略过。 学习交换： 挪动端IM开发入门文章：《新手入门一篇就够：从零开发挪动端IM》开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）（本文已同步公布于：http://www.52im.net/thread-4188-1-1.html） 2、如何连贯集体计算机（PC）？在创造网络之前，集体计算机之间是独立工作的，没有网卡、网线或协定栈，次要应用磁盘、CD 和其余货色来传输数据。 起初，网线呈现了。最小的网络单元由网线、网卡和协定栈组成：1）网线起着物理介质的作用，以传输比特流 / 电信号；2）网卡将转换数据（例如：它将计算机存储的数据转换为网线的比特流 / 电信号）；3）协定栈作为一种通信语言，能够在通信过程中实现数据分析、地址寻址和流控制。 3、网线不够长怎么办？如果终端之间的间隔太远，一旦超过网线物理传输间隔的下限，数据就会开始失落。中继器是物理层的设施，能够中继和放大信息以实现设施的远距离传输。 4、中继器端口有余怎么办？中继器通常只有两个接口，这意味着如果网络中有三个以上的终端主机，则无奈实现多个主机之间的间接数据通信。集线器是一种多接口中继器，也是一个物理层设施。它能够中继和放大信息，从任何接口接管的数据都将被发送到所有其余接口。 5、如何有选择性的发送数据？有人把网桥比喻成一个 “聪慧” 的中继器。因为中继器只是对所接管的信号进行放大，而后间接发送到另一个端口连贯的电缆上，次要用于扩大网络的物理连贯范畴。而网桥除了能够扩大网络的物理连贯范畴外，还能够对 MAC 地址进行分区，隔离不同物理网段之间的碰撞（也就是隔离 “抵触域”）。 6、速度不够快怎么办？交换机能够记录该终端主机的 MAC 地址，并生成一个 MAC 表。MAC 表相当于一个 “map”，交换机依据 MAC 表在主机之间转发数据流。交换机基于网桥进行扩大和降级。与网桥相比，交换机具备以下长处：1）接口数量更密集（每个主机位于一个独立的抵触域中，带宽利用率大大提高）；2）应用专用的 ASIC 硬件芯片进行高速转发；3）VLAN 隔离（不仅能够隔离抵触域，还能够通过 VLAN 隔离播送域）。交换机是一种局域网设施，通常用于局域网，不能实现近程广域网通信。 7、间隔还不够怎么办？世界上第一台路由器是由斯坦福大学的 Leonard Bossack 和 Santi Lerner 这对老师夫妇为斯坦福大学校园网络 (SUNet) 和思科公司创造的。▲ 思科公司创始人Leonard Bossack 和 Santi Lerner 夫妇路由器是一种基于 IP 寻址的网络层设施，利用路由表来实现数据转发。路由器次要用于连贯不同的局域网以实现播送域隔离，也能够用于近程通信，如广域网连贯。 诸如 IP 协定之类的逻辑寻址机制是实现不同类型局域网连贯的要害。不同局域网的主机只有具备逻辑地址（IP 地址）和正当的逻辑地址布局（网段布局)，它们就能够通信。路由器的诞生是互联网爆炸的次要起因，跨媒介、跨地区的网络集成已成为事实。 8、接线太麻烦怎么办？无线 AP能够被视为具备无线性能的交换机 / 路由器。随着无线城市和挪动办公的发展趋势，无线产品在网络中所占的比例正在减少。依据部署形式的不同，能够分为胖 AP 和瘦 AP 解决方案。1）在胖 AP 计划中，无线 AP 具备独立的操作系统，该操作系统能够独立调试无线热点的所有配置，相似于家用 Tp-link 产品。2）在瘦 AP 计划中，无线 AP 仅具备无线信号传输性能，所有命令调试都集中在后盾的 AC / 无线控制器上。小型无线网络（家庭、小型企业）能够应用胖 AP 解决，而大型无线网络（无线城市、无线园区网络）则须要应用瘦 AP（AC + AP）解决。 ...

为了更好地分类浏览52im.net 总计1000多篇精编文章，我将在每周三推送新的一期技术文集，本次是第12 期。[- 1 -] 利用保活终极总结(一)：Android6.0以下的双过程守护保活实际 [链接] http://www.52im.net/thread-1135-1-1.html [摘要] 因为Android机型太多太杂，以及各厂商定制ROOM的差别，Android利用保活没有一劳永逸和万能的办法，本文探讨的是Android利用在Android 6.0以下零碎中的典型利用场景下的保活实际（Android 6.0及以上零碎的防杀和复活办法，详见本系列文章的下两篇《利用保活终极总结(二)：Android6.0及以上的保活实际(过程防杀篇)》、《Android利用保活终极总结(三)：Android6.0及以上的保活实际(被杀复活篇)》），内容仅供参考，心愿给您带来启发。 [- 2 -] 利用保活终极总结(二)：Android6.0及以上的保活实际(过程防杀篇) [链接] http://www.52im.net/thread-1138-1-1.html [摘要] 本文便是对最近一周的Android过程防杀、过程被杀复活的摸索、学习、测试的内容总结，以备未来不时之需。因保活防杀和被杀复活波及内容较多，我将它分成了两篇：即过程防杀篇（本文）和过程被杀复活篇（下篇），本篇将探讨如何实现过程防杀。 [- 3 -] 利用保活终极总结(三)：Android6.0及以上的保活实际(被杀复活篇) [链接] http://www.52im.net/thread-1140-1-1.html [摘要] 本文将重点探讨过程被杀后复活的可能性及实际。 [- 4 -] Android过程保活详解：一篇文章解决你的所有疑难 [链接] http://www.52im.net/thread-438-1-1.html [摘要] 什么样的利用须要过程保活？通常状况下，即时通讯类的利用（包含IM聊天利用、音讯推送服务等）为了保障音讯的全时、实时送达能力，必须要实现过程或Service的保活。而就这一看似不起眼的问题，理论解决起来，因为泛滥Android手机和Android零碎版本的差别，让问题的解决充斥了不确定性。 [- 5 -] Android端音讯推送总结：实现原理、心跳保活、遇到的问题等 [链接]http://www.52im.net/thread-341-1-1.html [摘要] 最近钻研Android推送的实现, 钻研了两天一夜, 有了一点播种, 写下来既为了分享, 也为了吐槽. 须要阐明的是有些货色偏底层硬件和通信行业, 我对这些无所不通, 只能说说本人的了解. [- 6-] 为何基于TCP协定的挪动端IM依然须要心跳保活机制？ [链接] http://www.52im.net/thread-281-1-1.html [摘要] 很多人认为，TCP协定本身先天就有KeepAlive机制，为何基于它的通信链接，依然须要在应用层实现额定的心跳保活？本文将从挪动端IM实际的角度通知你，即便应用的是TCP协定，应用层的心跳保活仍旧必不可少。 [- 7 -] 一文读懂即时通讯利用中的网络心跳包机制：作用、原理、实现思路等 [链接] http://www.52im.net/thread-2697-1-1.html [摘要] 要想真正了解即时通讯利用底层的开发，心跳机制必须把握，而这也是本文写作的目标，心愿能带给你启发。 [- 8-] 微信团队原创分享：Android版微信后盾保活实战分享(过程保活篇) [链接] http://www.52im.net/thread-210-1-1.html ...

一、理论知识筹备您须要对微信小程序开发有所理解： 1）真正零根底入门学习笔记系列2）从零开始的微信小程序入门教程3）最全教程：微信小程序开发入门详解您须要对WebSocket技术有所理解： 1）老手疾速入门：WebSocket扼要教程2）WebSocket详解（一）：初步意识WebSocket技术3）WebSocket从入门到精通，半小时就够！4）从零了解WebSocket的通信原理、协定格局、安全性规范WebSocket协定文档、API手册： 1）WebSocket的API手册2）WebSocket的RFC规范文档微信小程序中的WebSocket API手册： 1）微信官网WebSocket文档链接小提示：微信小程序中的WebSocket API跟规范HTML5中的WebSocket接口及用法略有不同，但次要API都能一一对应，相差不大。 二、开发工具筹备1）微信小程序开发工具：（JackJiang应用的版本号如上图所示，为了不便间接援用工程，倡议你也应用此版或较新版本）2）一站式下载地址：微信官网下载地址点此进入。3）微信小程序开发工具成果预览： 三、SDK文件用处阐明3.1 文件概览纯微信规范JS API实现，无任何第3方库依赖：MobileIMSDK-微信小程序端SDK自身只是JS文件源码的汇合，自带的Demo代码只是为了不便随时测试SDK代码，目标次要是用于演示SDK的API调用，Demo代码不属于SDK框架的一部分。大抵的目录阐明： 3.2 具体阐明SDK各模块/文件作用阐明： 四、次要API接口4.1 次要API接口概览所有SDK接口均由 /mobileimsdk/mobileimsdk-client-sdk.js 提供。以下是次要API接口概览图：如下图所示：接口设计跟MobileIMSDK的APP版一样，均为高内聚和低侵入式的回调形式传入业务层解决逻辑，无需（也不倡议）开发者间接批改SDK级代码。 4.2 次要API接口用处阐明1）IMSDK.isLogined()： 用处：是否曾经实现过首次登陆。阐明 ：用户一旦从自已的利用中实现登陆IM服务器后，本办法就会始终返回true（直到退出登陆IM）。返回值：{boolean}，true示意已实现首次胜利登陆（即曾经胜利登陆过IM服务端了，前面掉线时不影响此标识），否则示意尚未连贯IM服务器。2）IMSDK.isOnline()： 用处：是否在线。阐明：示意网络连接是否失常。返回值：{boolean}，true示意网络连接失常，否则示意已掉线，本字段只在this._logined=true时有意义（如果都没有登陆到IM服务器，怎么存在在线或掉线的概念呢）。3）IMSDK.getLoginInfo()： 用处 ：返回登陆时提交的登陆信息（用户名、明码/token等）。阐明 ：格局形如：{loginUserId:'',loginToken:''}，此返回值的内容由调用登陆函数 loginImpl()时传入的内容决定。字段定义详见：PLoginInfo。返回值：{boolean}，true示意网络连接失常，否则示意已掉线，本字段只在this._logined=true时有意义（如果都没有登陆到IM服务器，怎么存在在线或掉线的概念呢）。4）IMSDK.sendData(p, fnSucess, fnFail, fnComplete)： 用处：向某人发送一条音讯。参数p：{Protocal} 要发送的音讯协定包对象，Protocal详情请见“/module/mb_constants.js”下的createCommonData函数阐明。参数fnSuccess ：{function} 接口调用胜利的回调函数，非必填项参数fnFail ：{function} 接口调用失败的回调函数，非必填项参数fnComplete ：{function} 接口调用完结的回调函数（调用胜利、失败都会执行），非必填项返回值：{int} 0示意胜利，否则示意错误码，错码详见“/module/mb_constants.js”下的MBErrorCode对象属性阐明。5）IMSDK.disconnectSocket()： 用处：客户端被动断开客户端socket连贯。阐明：当开发者登陆IM后，须要退出登陆时，调用本函数就对了，本函数相当于登陆函数 loginImpl()的逆操作。6）IMSDK.setDebugCoreEnable(enable)： 用处：是否开启MobileIMSDK-微信小程序端外围算法层的log输出，不便开发者调试。参数enable：{boolean} true示意开启log输入，否则不输入，开发者不调用本函数的话零碎默认是false（即不输入log）。7）IMSDK.setDebugSDKEnable(enable)： 用处：是否开启MobileIMSDK-微信小程序端框架层的log输出，不便开发者调试。参数enable：{boolean} true示意开启log输入，否则不输入，开发者不调用本函数的话零碎默认是false（即不输入log）。8）IMSDK.setDebugPingPongEnable(enable)： 用处：是否开启MobileIMSDK-微信小程序端框架层的底层网络WebSocket心跳包的log输入，不便开发者调试。参数enable：{boolean} true示意开启log输入，否则不输入，开发者不调用本函数的话零碎默认是false（即不输入log）。留神：必须 setDebugEnable(true) 且 setDebugPingPongEnable(true) 时，心跳log才会真正输入，不便管制。返回值：true示意开启log输入，否则不输入，开发者不调用本函数的话零碎默认是false（即不输入log）。9）IMSDK.loginImpl(varloginInfo, wsUrl)： 用处：登陆/连贯MobileIMSDK服务器时调用的办法。阐明：登陆/连贯MobileIMSDK服务器由本函数发动参数varloginInfo：{PLoginInfo} 必填项，登陆要提交给Websocket服务器的认证信息，不可为空，对象字段定义见：PLoginInfo参数wsUrl：{string} 必填项：要连贯的Websocket服务器地址，不可为空，形如：wss://yousite.net:3000/websocket。10）IMSDK.callback_onIMLog(message, toConsole)： 用处：由开发者设置的回调办法：用于debug的log输入。举荐用法：开发者可在此回调中依照自已的用意打印MobileIMSDK微信小程序端框架中的log，不便调试时应用。参数1： {String}：必填项，字符串类型，示意log内容。参数2： {boolean}：选填项，true示意输入到console，否则默认形式(由开发者设置的回调决定)。11）IMSDK.callback_onIMData(p, options)： 用处 ：由开发者设置的回调办法：用于收到聊天音讯时在UI上展示进去（事件告诉于收到IM音讯时）。举荐用法：开发者可在此回调中解决收到的各种IM音讯。参数1： {Protocal}：详情请见“/module/mb_constants.js”下的Protocal类定义)。12）IMSDK.callback_onIMAfterLoginSucess()： 用处：由开发者设置的回调办法：客户端的登陆申请被服务端胜利认证实现后的回调（事件告诉于 登陆/认证 胜利后）。举荐用法：开发者可在此回调中进行登陆IM服务器胜利后的解决。13）IMSDK.callback_onIMAfterLoginFailed(isReconnect)： 用处：由开发者设置的回调办法：客户端的登陆申请被服务端认证失败后的回调（事件告诉于 登陆/认证 失败后）。阐明：补充阐明：登陆/认证失败的起因可能是用户名、明码等不正确等，但具体逻辑由服务端的 callBack_checkAuthToken回调函数去解决。举荐用法：开发者可在此回调中提醒用户登陆IM服务器失败。。参数1： {boolean}：true示意是掉线重连后的认证失败（在登陆其间可能用户的明码信息等产生了变更），否则示意首次登陆时的认证失败。14）IMSDK.callback_onIMReconnectSucess()： 用处：由开发者设置的回调办法：掉线重连胜利后的回调（事件告诉于掉线重连胜利后）。举荐用法：开发者可在此回调中解决掉线重连胜利后的界面状态更新等，比方设置将界面上的“离线”文字更新成“在线”。15）IMSDK.callback_onIMDisconnected()： 用处：由开发者设置的回调办法：网络连接已断开时的回调（事件告诉于与服务器的网络断开后）。举荐用法：开发者可在此回调中解决掉线时的界面状态更新等，比方设置将界面上的“在线”文字更新成“离线”。16）IMSDK.callback_onIMPing()： 用处 ：由开发者设置的回调办法：本地收回心跳包后的回调告诉（本回调并非MobileIMSDK-微信小程序端外围逻辑，开发者能够不须要实现！）。举荐用法：开发者可在此回调中解决底层网络的流动状况。17）IMSDK.callback_onIMPong()： ...

一、根本介绍MobileIMSDK - 微信小程序端是一套基于微信原生 WebSocket 的即时通讯库： 1）超轻量级、无任何第 3 方库依赖（开箱即用）；2）纯 JS 编写、ES6 语法、高度提炼，简略易用；3）基于微信原生 WebSocket API，简洁优雅；4）反对运行于任何反对微信小程序的手机端；5）能与 MobileIMSDK 的各种客户端完满互通；6）可利用于微信小程序中的音讯推送、客服聊天、企业 OA、IM 等场景。 二、与 MobileIMSDK 的关系MobileIMSDK - 微信小程序端是基于微信原生 WebSocket 协定的 MobileIMSDK 配套客户端库。 MobileIMSDK 是一套专为挪动端开发的开源原创 IM 通信层框架： 历经 8 年、久经考验；超轻量级、高度提炼，lib 包 50KB 以内；精心封装，一套 API 同时反对 UDP、TCP、WebSocket 三种协定（可能是全网惟一开源的）；客户端反对 iOS、Android、规范 Java、H5、小程序、Uniapp(开发中..)；服务端基于 Netty，性能卓越、易于扩大；可与姊妹工程 MobileIMSDK-Web 无缝互通实现网页端聊天或推送等；可利用于跨设施、跨网络的聊天 APP、企业 OA、音讯推送等各种场景。以下是 MobileIMSDK 的最新通信架构图： MobileIMSDK 的客户端库始终在继续开发和降级中，目前 基于 Uniapp 的 MobileIMSDK 客户端正在开发中 。 三、设计指标间接应用原生的微信小程序 WebSocket 有以下问题和劣势： 1）性能无限：没有心跳保活、断线重连、音讯送达保障（重传和去重）等即时通讯要害算法和逻辑；2）API 简陋：在如此无限的原生 API 下，能逻辑清晰地实现并组合心跳保活、断线重连、音讯送达保障等算法，须要相当高的技术掌控力；3）逻辑耦合：教训欠缺的开发人员，会将 WebSocket 通信与前端 UI 界面代码混在一起，使得 UI 界面的重构、保护、改版都十分艰难。针对以上问题，而 MobileIMSDK - 微信小程序端库将让开发者专一于 UI 应用层的开发，网络通信层的业余代码交由 SDK 开发人员，从而解偶 UI 前端和通信层的逻辑耦合性，大大降低技术复杂性。 ...

本文由得物技术团队Uni分享，即时通讯网收录时有内容订正和排版优化。一、引言本文要分享的是得物技术团队基于Electron开发客服IM桌面端的技术实际过程，内容包含桌面技术选型、Electron的根底概念、具体的施行技术计划、遇到的辣手问题等。 Electron社区尽管很沉闷，然而不一样的场景遇到的技术问题，简直找不到对应的解决方案，咱们很多都是在摸索过程中一直的去欠缺，心愿本文能带给你一些启发。 学习交换： 挪动端IM开发入门文章：《新手入门一篇就够：从零开发挪动端IM》开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）（本文已同步公布于：http://www.52im.net/thread-4159-1-1.html） 二、系列文章本文是系列文章中的第7篇，本系列总目录如下：《IM跨平台技术学习(一)：疾速理解新一代跨平台桌面技术——Electron》《IM跨平台技术学习(二)：Electron初体验(疾速开始、跨过程通信、打包、踩坑等)》《IM跨平台技术学习(三)：vivo的Electron技术栈选型、全方位实际总结》《IM跨平台技术学习(四)：蘑菇街基于Electron开发IM客户端的技术实际》《IM跨平台技术学习(五)：融云基于Electron的IM跨平台SDK革新实际总结》《IM跨平台技术学习(六)：网易云信基于Electron的IM音讯全文检索技术实际》《IM跨平台技术学习(七)：得物基于Electron开发客服IM桌面端的技术实际》（* 本文） 三、业务背景随着公司业务的疾速倒退，商家客服也纳入了咱们的服务范畴，商家客服工作台的定位是通过工具和数据服务商家，一站式解决用户购买征询诉求。通过工具和经营策略帮助商家晋升服务品质，让品牌商家有能源经营好潜在的客户，从而达到晋升用户服务的指标。已有web端聊天零碎的前提下，商家客服为什么要迁徙桌面利用？首先咱们收到局部商家客服反馈：用户是上帝，咱们是很器重用户的反馈的，所以首先咱们想的是如何在web端解决这些问题，上面咱们逐个剖析下以上问题咱们能不能在网页端解决呢？1）针对客服A同学问题：大多数客服职场的台式机是不会装置音频设备，如果人家没音频，没外音，咱们能强制他买个播放器吗，那必定是不能.，如果是自营客服还有点解决计划，真须要，公司能够对立洽购，然而ToC的显然不能强制做什么事件，所以此问题无解.2）针对客服B同学问题：这句话怎么了解呢？是这样的，在一屏既有web浏览器，又有其余利用如飞书之类的PC利用叠着放，web notification告诉因为是浏览器级别的，揭示不到最上层，浏览器的揭示的确有点弱（看不到揭示会影响到客服的首响，首响会影响客服的绩效，咱公司对于用户的服务效率是比拟严格的），所以此问题无解。3）针对客服C同学问题：em。。。好的，您说的对，web网页给商家客服的感觉就是咱们平台有点赶不上局势。 基于下面的一些场景，想必大家曾经对为何做桌面利用有个初步的理解。上面以一张图来看下Web利用跟桌面利用的区别。四、技术选型为什么会抉择Electron而不是其余利用开发框架？ 4.1、Electron架构简介Electron的形成次要是下面的3个大模块，每个模块各司其职，让Electron有了桌面利用的能力。 一一了解Electron的3个大模块： 1）Chromium：能够为Electron提供UI渲染能力，再加上Chromium自身就是跨平台的，所以也不必思考代码的兼容性（只有有Chromium，就能用JavaScript，HTML，CSS这些前端开发工程师所熟知的三剑客来开发页面）；2）Node.js：Chromium并不具备原生GUI操作的能力，所以Node.js正好补足了这个能力（可能调用操作系统的底层 API，比方path、fs、crypto 这些模块，甚至能集成C++）；3）Native APIs：Native API让Electron有了跨平台和桌面端的原生能力（比如说它有对立的原生界面，窗口、托盘这些）。4.2、Electron与其余框架的区别如上图所示：1）Native(C++/C#/Objective-C)不论从原生体验、包的体积、性能方面来说都是最佳的抉择，然而开发门槛高、迭代速度慢；2）QT是基于C++的跨平台开发框架，跨平台利用非常宽泛(Mac、Windows、ios、Android、Linux、嵌入式)，家喻户晓的WPS就是用QT开发的。性能很好，甚至于能够媲美原生的体验，然而整体门槛还是比拟高的；3）Web技术的代表Electron 和 NW.js ，相比之前抉择Electron，Electron有十分沉闷的社区（有102k star），有Atom、vscode这样的大型利用都是基于Electron开发的，性能相比于natvie是必定要差一些，但综合来看，Electron是作为开发桌面利用的目前首选；4）值得一提的是Flutter desktop，从渲染原理看flutter是skia自绘性能优于Electron，但问题还是稳定性和生态。Electron因为是nodejs+chromium，前端的生态能够间接用，所以Flutter desktop就不纳入思考范畴的，但值得关注。除了以上这些，最次要的一点：Electron能疾速交付，业务层复用web零碎的代码，只须要关注主过程就好了，并且也能满足业务须要的零碎级别的一些性能。五、技术实现5.1、我的项目架构 首先介绍下Electron框架外面两个重要的概念主过程和渲染过程。 1）主过程：次要负责创立和治理BrowserWindow实例以及应用程序事件。它能够执行注册全局快捷方式，创立零碎菜单和对话框，响应自动更新事件等操作（主过程以及所有Node.js模块中都提供了一部分Electron API）；2）渲染过程：渲染过程负责运行应用程序的用户界面，渲染过程中提供了所有DOM API、Node.js API和Electron API的子集。 如下面截图：关上Electron我的项目之后会有多个过程，一个我的项目有且只有一个主过程，创立窗口等无关零碎事件写在主过程中进行，然而渲染过程可能有多个。 那为什么会有多个渲染过程呢？ Electron利用是Chromium内核，所以多过程的架构也来源于Chromium，Chromium会独自运行每个标签，任何一个标签页解体了都不会影响到其余标签。因而，每个过程在本人的空间中运行，由操作系统调度。如果某个过程触发了有限循环，也不会导致整个利用down掉。 在上文说到两个字“迁徙”：是的，咱们在开发桌面利用之前有十分成熟的web端商家客服聊天零碎了，所以咱们在开发桌面利用的时候大多数时候是关怀主过程的，渲染过程并不太须要关怀。 5.2、主过程功能模块5.2.1通信模块次要是调用Electron框架自身的API以及通用办法的封装： 5.2.1.1）主过程到渲染过程的通信： 5.2.1.2）渲染过程到主过程的通信：有两种计划。计划一：是在主过程开启了nodeIntegration: true之后在渲染过程外面能够应用window.require('Electron')来引入写通信相干代码：计划二：是须要在主过程编写preload.js（在初始化窗口的时候引入）：5.2.1.3）通信的同步和异步问题：异步：渲染过程->发送->主过程同步：渲染过程->发送->主过程5.2.2菜单模块次要是调用Electron框架自身的API，满足疾速扩大菜单性能以及自定义菜单性能： 然而商家客服我的项目没用到原生菜单，而是用了自定义的菜单。没有应用原生菜单的次要起因是： 1）原生菜单款式较死板，不能调整；2）自定义编写菜单能有各种本人想要的性能，可管制其展现。5.2.3 托盘模块托盘属于零碎级的操作，所以是在主过程中设置的。在开始之前须要留神的中央，设置托盘必须在程序ready之后。 实现较简略，代码如下： 5.2.4 异样解决模块次要调用Electron框架自身API，联合Node.js API，检测零碎异样后主动刷新并上报，渲染过程的异样曾经应用sls&arms解决，主过程的异样次要是通过Electron的crashReporter API来记录日志。 下面提交参数有两个须要留神的点： 1）submitURL 是以post形式上传；2）extra 一个你能够定义的对象，附带在解体报告上一起发送（只有字符串属性能够被正确发送，不反对嵌套对象）。5.3、渲染过程功能模块渲染过程的代码大部分跟商家客服IM web端统一，很多只是迁徙即可。 5.3.1登录革新登录信息本地化，在登录胜利的时候，把账号信息缓存，下次关上利用的时候客服无需再从新输出，间接从缓存获取即可。 逻辑如下图所示： 5.3.2动态资源传统Web利用，将我的项目代码部署服务器，我的项目运行时，拜访的是服务器动态资源，当初版本公布流程，走的是cdn资源，总而言之都是通过网络获取。Electron提供将动态资源打包到安装程序，在装置时，将我的项目文件同步装置到用户电脑，使其具备拜访本地文件，缩小了申请占用资源。肯定水平上也能改善因网速问题导致的动态资源不能实时获取，页面白屏问题。5.3.3 数据存储Electron利用外面的数据存储是通过Electron-store第三方库来实现的。实现比较简单，如下：5.3.4 渲染过程打包这块为什么要单拎进去讲渲染过程打包呢，是因为web我的项目迁徙变成利用渲染过程的时候不能像web利用一样间接打包，须要调整申请API代码，API前缀须要辨别本地调试和应用环境。代码如下：应用Electron, 将我的项目打包成离线利用。应用file协定，在本地读取动态资源。然而ajax申请如果用相对路径，打包之后，会间接找到根目录。如下截图。所以打包的时候须要给ajax提供残缺的url门路。六、技术挑战6.1、概述咱们在从0到1搭建商家客服IM桌面端的过程中，遇到了很多的问题。 起因是Electron社区尽管很沉闷，然而不一样场景遇到的问题，简直找不到对应的解决方案，所以很多都是在摸索过程中一直的去欠缺。 这里次要围绕公布构建流程和安全性来讲下，咱们是怎么解决的。 6.2、安全性问题Electron客户端的平安问题也是十分重要的，那都遇到了哪些平安问题以及咱们又是如何解决的呢？ 具体如下： 1）渲染过程XSS：Electron实现的桌面端软件渲染层的原理理论是通过chrome内核渲染的，同样存在XSS注入的危险（举个例子：在html页面中能够执行命令： ，就能够关上以后操作系统的计算器。接入了公司对立的XSS治理计划，该问题即失去解决）；2）用户认证信息透露问题：商家客服桌面端登录调用商家的受权接口，APP网关有校验，能够确保登陆没有问题；3）本地缓存明文读取问题：本地数据透露（例如：indexDB、localStorage、sessionStorage等），咱们次要用加密和解密算法对本地缓存信息进行解决。没有相对的平安，咱们能做的就是尽可能的进步平安门槛，过程中咱们也踊跃同公司的安全部门进行沟通，让他们排查桌面端公布之后的安全漏洞，最终验证都是满足平安规范，合乎公布的条件。 6.3、公布构建流程利用公布波及到渲染过程和主过程，渲染过程次要是负责给主过程提供渲染包，主过程应用Electron-builder库来打包部署所公布的包。后面曾经说过：Electron的益处是能够无缝集成web端的业务逻辑代码，这里上图右边红色的是web端构建出的产物，咱们会把这部分构建产物同步到主过程的app/render目录下（即渲染过程目录），这样在打包利用包的时候，就能集成渲染过程的业务逻辑，而不须要保护两份web端的代码。 此计划还存在不少的缺点：因为生产构建环境须要window环境，所以临时不反对在近程打包，目前都是在本地window机器上打出残缺的包之后再上传到CDN，商家客服通过加载CDN的更新包来替换本地安装文件，实现软件的本地装置。 6.4、利用更新问题利用开发离不开“更新”这个话题，比方飞书利用会时不时弹出一个更新窗口，让你抉择是否更新。咱们的商家客服IM在推广桌面利用之后，也存在更新这个问题。 在业务疾速倒退的同时，如何将业务需要更好的同步给商家应用，这是商家客服桌面利用面临的最大的挑战。 6.4.1全量更新：手动下载安装这是最根底的更新模式，次要思路是在关上app（其余时候也行，咱们业务次要是关上app的时候）的时候拜访近程的json文件，文件内容蕴含版本号，更新内容等等最新版本的信息，拿到近程版本号会跟本地利用版本号做比拟，如果版本号不统一，就询问用户是否更新，须要更新的话会下载到本地，用户手动点击装置即可。 这个更新形式不举荐应用，如果你的利用一年更新一次，ok，是能够这么做的。6.4.2增量更新在网速快的状况下，全量更新跟增量更新简直是没有区别的。然而网速慢的状况下它俩之间的差距会被放大，用户体验不是很好。 咱们不能想当然的认为所有用户网速都很好，这是不事实的，所以不论是PC利用还是挪动端利用，大多数状况下是须要做增量更新。 上面表格是网速不一样状况下的下载耗时比照：6.4.3增量更新计划1：electron-updater当初就开始介绍咱们在商家客服IM利用（windows利用）中是怎么实现增量更新性能的。 更新在大的分类上辨别全量以及增量更新，在每个小分类外面也辨别强更新、弱更新（业务上的辨别，底层实现没区别）。 ...

为了更好地分类浏览52im.net 总计1000多篇精编文章，我将在每周三推送新的一期技术文集，本次是第11 期。[- 1 -] 如何抉择即时通讯利用的数据传输格局 [链接] http://www.52im.net/thread-276-1-1.html [摘要] 本文内容中对即时通讯传输格局的抉择，是原作者的一家之言，可能存在很大争议，但如能为你的即时通讯利用开发的技术选型带来些许启发，我置信这才合乎作者的本意。 [- 2 -] 强列倡议将Protobuf作为你的即时通讯利用数据传输格局 [链接] http://www.52im.net/thread-277-1-1.html [摘要] 即时通讯利用（包含IM聊天利用、实时音讯推送利用等）在抉择数据传输格局的时候，置信没有真正实际过的人，都会犹豫该怎么抉择。在即时通讯开发者同行的眼里，怎么抉择其实是个极富争议话题。不过本文作者强烈建议将Protobuf作为您的即时通讯利用的首选通信协定格局，理由请见本文内容。 [- 3 -] 挪动端IM开发须要面对的技术问题（含通信协议抉择） [链接] http://www.52im.net/thread-133-1-1.html [摘要] 这两年多始终从事网易云信 iOS 端 IM SDK的开发，期间一直有兄弟部门的共事和合作伙伴过去问各种技术细节，罗唆对立介绍下一个IM APP的方方面面，包含技术选型（包含通信形式，网络连接形式，协定抉择）和常见问题。 [- 4 -]简述挪动端IM开发的那些坑：架构设计、通信协议和客户端 [链接] http://www.52im.net/thread-289-1-1.html [摘要] 有过挪动端开发经验的开发者都深有体会：挪动端IM的开发，与传统PC端IM有很大的不同，尤其无线网络的不可靠性、挪动端硬件设施资源的有限性等问题，导致一个残缺的挪动端IM架构设计和实现都充斥着大量的挑战。本文将简述挪动端IM最重要的架构设计和通信协议抉择方面的坑点，心愿为IM开发者同行带来些许启发。 [- 5 -] 实践联系实际：一套典型的IM通信协议设计详解 [链接]http://www.52im.net/thread-283-1-1.html [摘要] 本文将以实践联系实际的形式，具体解说一套典型IM的通信协议设计的方方面面。 [- 6-] 58到家实时音讯零碎的协定设计等技术实际分享 [链接] http://www.52im.net/thread-298-1-1.html [摘要] 本文内容整顿自58到家平台部负责人任桃术的演讲内容。次要内容包含三局部：音讯平台产生的背景、它的整体架构和零碎重点以及遇到并解决了哪些问题。 [- 7 -] APP与后盾通信数据格式的演进：从文本协定到二进制协定 [链接] http://www.52im.net/thread-1536-1-1.html [摘要] 本文作者分享的是一个一般App与后盾的通信数据格式演变，总结了其公司某App的接入层从文本协定到二进制jce协定迭代过程中的技术计划，包含协定标准、安全性等方面的内容。 [- 8-] IM通信协定专题学习(一)：Protobuf从入门到精通，一篇就够！ [链接] http://www.52im.net/thread-4080-1-1.html [摘要] 本文作为《IM通信协定专题学习》系列文章的首篇，将从初学者的角度，用艰深简洁的文字，从零开始为你介绍Protobuf的方方面面，特地适宜新手入门。 [- 9 -] IM通信协定专题学习(二)：疾速了解Protobuf的背景、原理、应用、优缺点 ...

一、本文内容概述WiFi对于当初的家庭来说，属于司空见惯的上网形式，但很多状况下，家里房间多、空间大、杂物乱的状况下，WiFi的信号就受影响。为什么WiFi信号会受影响？什么状况下该应用何种形式组网？如何改善WiFi信号差的问题？等等，本文将通俗易懂地为你找到这些问题的答案。 学习交换： 挪动端IM开发入门文章：《新手入门一篇就够：从零开发挪动端IM》开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）（本文已同步公布于：http://www.52im.net/thread-2402-1-1.html） 二、WiFi穿墙之迷自从WiFi成为人类生存根本需要以来，蜉蝣君常常被问到一个问题：“我的路由器有这么多根天线，看起来牛逼闪闪，号称大功率穿墙王，咋才走了几步就没信号了呢？”更有甚者，如上图这位MM，更是问出了如此让人瞠目结舌的问题：“号称450米的路由器，咋才过了不到10米，穿了两堵墙就没信号了？”纳尼？450米的路由器？！什么鬼？！把MM发来的盒子图片放大一看，下面赫然写着450M！！！能把“M”设想成“米”，这相象力相丰盛了吧！▲ 450M无线路由器其实这里的450M并不是450米的意思，而是指Mbps，又称兆比特每秒，说的是这款路由器的最大下载速率能够达到450Mbps，跟笼罩的间隔和穿墙能力一毛钱关系都没有。上面咱们就来聊聊WiFi的信号问题，包含笼罩间隔和穿墙能力。心愿看完之后，能让你对WiFi有一个全新的意识。 三、WiFi的协定和频谱3.1简介首先来说WiFi的协定及频谱的问题。自从WiFi规范被IEEE（电气和电子工程师协会）提出以来，通过了20年的蓬勃发展，一步一个脚印，出了一个又一个协定版本，如下图所示。▲ WiFi各协定版本从上表能够看出，WiFi有两个工作频段：2.4G和5G。这两个频段都是非受权频段（或者叫免受权频段）——只有符合国家法规，不经受权就可应用。也就是说，在家里装个无线路由器，收发WiFi信号，是不须要任何人批准的（而应用除此之外的“受权频段”，是须要国家正式受权的）。▲ 频谱之问 3.2什么是2.4G频段？2.4G频谱的范畴是2.4GHz～2.4835GHz，共有83.5M带宽，划分为13个信道，每个信道宽20M。可是，20M乘以13等于260M啊，这13个信道共须要260M带宽，而2.4G频谱只有83.5M，这怎么放得下？答案就跟上公交车一样：“挤一挤，往后挪一挪，连忙再上一个！”人多车小，为了独特的出行需要，个人空间就别想了，被踩到脚更是不免。从下图能够看出，2.4G频谱的这13个信道严密地交叠在一起，烦扰是不可避免的。▲ 2.4G频谱及信道留神：第14信道在国内是不容许应用的。信道交叠到什么水平呢？由下图能够比拟直观地看出，在这些信道外面，只有1，6，11，或者2，7，12，或者3，8，13这三组是齐全没有交叠的。就好比一条很窄的路，下面同行的车却很多，势必造成通行速度的降落。▲ 2.4G不交叠的信道散布到了802.11n，用户能够应用40M的信道，但2.4GHz频段仍然只有83.5M的总带宽，就只能包容两个信道了。因而只有在夜深人静网络闲暇的时候，单个用户才有可能应用40M信道，加之来自隔壁老王家的烦扰，802.11n的高速率很大水平上难以达到。▲ 2.4G 40M带宽信道 3.3什么是5G频段？既然2.4G频段如此拥挤不堪，IEEE那些制订WiFi规范的专家们，就打起了另一个免受权频段的主见——那就是5G频段。（再次留神，这里的5G和咱们当初常说的5G通信规范是齐全两回事。）802.11n虽说是能够工作在5GHz上的，但这个协定版本十分老旧。所以，5GHz的劣势由更年老的802.11ac来体现。5G频谱的范畴是4.910GHz～5.875GHz，有900多M的带宽，是2.4G的10倍还多！正是因为这段频谱很宽，外部还会划分成几个子频段，有的还没调配，有的作为其余用处。连4G LTE，都想用它（也就是LTE-U，LTE-Unlicensed）。对于这段频谱，不同国家之间的应用状况差异很大，中国能够应用的局部如下图所示。▲ 中国可用的5G频谱下图是中国的5GHz可用信道的散布状况。▲ 中国5G信道分布图反对802.11ac的路由器和手机能够在把这些可用的信道自由组合，应用20M、40M、80M甚至160M带宽的信道。信道多，带宽大，烦扰小，峰值下载速度无效晋升。 四、WiFi的速率估算WiFi工作在2.4G和5G别离能达到多大的峰值下载速率？2.4G频段咱们采纳802.11n来估算，这个版本也是反对2.4G的最新的协定版本。5G频段咱们采纳最新的802.11ac来估算，这个协定版本只反对5G。802.11n引入了几个特点：1）反对MIMO，也就是能够应用最多4个天线来收发送数据，下载速率成倍晋升。因而看到当初市场有上多个天线的路由器，至多反对802.11n无疑。2）在反对规范的20M带宽信道的根底之上，新增了双倍带宽，也就是40M。单用户实践峰值下载速率又失去了成倍晋升！因而，要估算802.11n最大下载速率，很简略，数天线的个数！一个天线加上40M信道最大能达到150Mbps的速率，两个天线天然就是300Mbps，以此类推，4个天线可达600Mbps！而802.11ac又在上面几点上进行了加强：1）MIMO加强：最多能够应用8个天线来收发送数据，速率倍增！2）信道扩宽：反对80MHz带宽信道，最大可反对160M带宽信道，速率倍倍增！3）高阶调制：反对256QAM，速率再增30%！在这3点的加成之下，802.11ac单天线可达433Mbps，两天线867Mbps，三天线1.3Gbps，4天线1.7Gbps，8天线3.4Gbps！以上只是实践上的推算，实际上反对802.11ac的路由器，天线个数都在4根以内。 五、双频路由器的诞生“双频路由器”的横空出世又是为何？既然5G加802.11ac这么好，那是不是当前的路由器和手机就都能够不反对2.4GHz了呢？单靠5Ghz和802.11ac是否打下一片全新的天地呢？答案是不行。不言而喻的一个起因是因为兼容性。几年前大量的手机、电脑、电视只反对2.4GHz，为了让这些老设施不至于没法上网，对于2.4GHz的反对的必须的。另一个起因是笼罩。2.4G的频率低波长大，信号损耗小，穿透能力强，在笼罩上和5G相比具备肯定劣势。这个问题咱们前面再详谈。▲ 2.4G的穿透能力强于5G尺有所短，寸有所长。既然如此，何不2.4G和5G双频合璧？平地一声雷，双频路由器横空出世。▲ 双频路由器因为2.4G和5G的信号指标差异较大，个别状况下2.4G和5G的天线是独立的，如上图一样错开散布，让雷同频段的天线之间相隔地尽可能远，保障性能最优。要估算双频路由器反对的最大下载速率，办法仍旧是数天线，不同之处是2.4G和5G的速率要离开计算，而后再加起来就能够了。其实，高速率这样的外围卖点，路由器厂家必定是要赫然印在包装盒上并大肆宣传的，商家早都替咱们算好了。▲ 1200M≈300M+867M ▲ 双频路由器的速率频段和速率铺垫结束，终于到和穿墙无关的局部了,也就是WiFi的信号强度和损耗。 六、为啥WiFi信号的总是这么差？首先咱们来看看WiFi信号在流传中遇到障碍物之后的反馈：1）折射：WiFi信号通过玻璃或水的时候，信号门路产生偏折，咱们和路由器都在空气中，因而折射的影响能够疏忽；2）反射：WiFi信号通过润滑的物体外表时，信号会产生反射，和光的反射相似；3）绕射：WiFi信号通过水泥墙体，因难以穿梭，局部信号会向旁边散开，等遇到一个能够穿过的区域再持续向原本的方向持续直线传播；4）漫射：WiFi信号遇到水泥墙，因为直线线路碰壁，局部信号会散开，沿着墙壁上下左右持续延长进来；5）穿透：WiFi信号的能量一部分被障碍物排汇，残余能量的透过障碍物持续流传。▲ 室内WiFi信号流传模型个别状况下，在室内环境下，咱们手机接管到的WiFi信号次要是反射、绕射、漫射和穿透这四种效应的叠加。后三种效应都和信号的频率关系很大，频率越高绕射和穿透的能力越差。不论是2.4G还是5G频段，在无线通信里都属于较高的频段了，虽说2.4G绕射和穿透能力要比5G强一些，但也高不到哪里去。咱们来看看2.4G信号穿墙之后的损耗（经验值）：▲ 2.4G频段穿透损耗在射频世界里，个别用dB这个单位来示意信号变动的状况。怎么了解呢？很简略：1）升高3dB，是指信号强度升高到原先的1/2（二分之一）；2）升高10dB，是指信号强度升高到原先的1/10（十分之一）；3）升高30dB，是指信号强度升高到原先的1/1000（千分之一）。联合上表能够得出上面的论断：1）木头，玻璃这些障碍物，对于WiFi信号的阻挡作用不强，只会带来一半左右的信号衰减；2）砖墙，水泥墙这些障碍物，堪称WiFi信号杀手，穿透的信号动辄衰减为原先的千分之一；3）电梯这类金属障碍物，几乎就是WiFi信号的噩梦，轻轻松松衰减到原先的万分之一！▲ WiFi信号差真是让人失望啊，这可咋办呢？有没有所谓“大功率路由器？”机智的你必定很快就想到了，想要信号好穿墙能力强，增大发射功率啊！没有什么不是增大功率不能解决的，如果有，那就再增大一倍！然而在WiFi这里，增大发射功率还真不行。因为无线路由器的发射功率是有国家规定的——最大100mW，也就是0.1W。我国对无线设施发射功率一贯要求严格，不合乎这个要求的产品是不能上市的。所以，想通过加强发射功率来晋升WiFi信号这条路是走不通的。“高增益天线”是否可行？既然发射功率有限度，那如果路由器用的高增益天线到话，不是能量发射会更集中，从而笼罩地更远吗？实践上来说是这样。但增益高能量集中的代价就是波束变窄，WiFi信号的笼罩会不平均，有的方向信号强，有的方向信号弱。如果有多集体在不同地位同时应用的话，对笼罩的评估会褒贬不一。▲ 天线增益及辐射方向图而且，个别的路由器天线增益也就9dBi，面对动辄就几十dB的穿透损耗来说也是无济于事。 七、我该怎么晋升WiFi信号？这也不行那些不行，那该到底咋样能力晋升WiFi信号呢？ 7.1场景1：“我就一台路由器，既想让WiFi信号变好，又一分钱都不想花，该怎么办？”【办法一：路由器摆放地位优化】既然所谓的“穿墙王”，“单台穿三墙”这种神器通通不存在，单台路由器不可避免的无奈齐全笼罩任意角落。如果想要最低老本地解决问题，请记住上面这几条法令：1）流传间隔越短信号越好，所以尽量把路由器放在房子的地方！2）木门，玻璃门等对信号的衰减小，尽量让路由器多走门，少穿墙！3）弱电箱的地位个别都在门口，周围面板也会屏蔽无线信号，所以尽量不要把无线路由器放在弱电箱里！4）把路由器摆在高一些，宽阔一下的中央，避开冰箱、洗衣机、各种家具等障碍物！上面是作业：请看这张图，地位一和地位二哪个好？▲ 路由器摆放地位差别对信号的影响再请看这张图，地位一和地位二哪个好？▲ 路由器摆放高度对信号的影响置信这两道题的答案是显而易见的。【办法二：调整正当的天线角度】个别的家用路由器都应用全向天线，全向天线的无线信号散布相似被程度压扁的轮胎。所以，无线信号在与天线垂直的方向上笼罩成果最好。如下图所示：▲ 全向天线辐射方向图所以，还乖乖把无线路由器的天线调整到与高空垂直，直戳戳地对着房顶就好，别掰成各种乌七八糟的角度了，直戳戳地对着你的方向恰好信号最弱！▲ 路由器的天线角度调节倡议【办法三：防止环境烦扰】1）尽量应用双频路由器，能应用5G频段尽量应用5G！如前文所示，2.4G频段是十分拥挤的，天然受到的烦扰也更多。而5G频段相对来说就要洁净地多。尽管有时候看起来5G的信号比2.4G少上一两格，但说不定速度更快！2）把路由器尽量放得离微波炉、蓝牙设施、无线鼠标键盘等设施远一些！这些玩意都在2.4G上工作，造成烦扰指数减少！3）更改路由器的信道配置！后面曾经说过，2.4G频段上只有3个独立不交叠的信道，一般来说就是1，6和11。试着改改看，哪个信道好就用哪个。▲ 批改2.4G信道设置 7.2场景2：“为了上网痛快，我还是违心点花钱的，怎么办？”这就必须要回升到家庭组网计划了！【计划一：应用无线扩展器扩大放大无线信号】这是目前中小户型WiFi信号扩大的支流计划。哪里信号比拟弱，就在这个地位就近的电源插座上插一个扩展器，不须要连贯网线。这个性能就叫做信号中继，顾名思义，就是指信号放大器接管主路由器的信号，放大之后再发射进去，因而家里的信号还是同一个，手机、Pad会连贯品质较好的信号。▲ 无线扩展器实用环境：任意环境都实用。【计划二：应用无线路由器桥接扩充信号】这个计划应用路由器的无线桥接性能，把多台无线路由器通过无线形式连起来，路由器之间也不须要网线连贯。通过无线桥接后，WiFi信合实现了接力，起到放大作用。当然，副路由器一般来说四个网络口，能够用来接有线电脑，这也是这个计划的劣势之一。▲ 两个路由器桥接那么计划二和计划一还有什么不同呢？那就是桥接的这两个路由器实际上还是独立工作的，能够设置不同的WiFi名称和明码。实用环境：手头已有多台无线路由器、想要在副路由器接有线设施。【计划三：应用网线把两台（或者多台）路由器连接起来】应用网线将多个路由器连接起来，其中连贯宽带的路由器作为主路由器，其余的作为副路由器。主副路由器之间通过各自的LAN口连接起来，此时副路由器相当于无线交换机。通过配置，能够实现整个网络只有一个无线信号，实现主动漫游。▲ 有线连贯多个路由器这个计划要求各个路由器之间通过网线连接起来，最大的劣势就是稳定性好，路由器之间没有无线损耗，各个路由器的速率都很高，但也有一个显著的限度条件，就是所有路由器之间必须通过网线连贯。实用环境：曾经布好网线的环境。【计划四：应用HyFi套装（子母路由器）组建全笼罩无线网络】HyFi（全称：Hybrid Wi-Fi）也叫电力猫，是指同一产品同时采纳“有线”和“无线”两种技术，以房间内无处不在的“电线”为主干，“无线”作为接入，使产品兼具备线的稳固可靠性和无线的挪动便捷性。TP-Link的HyFi套装是由HyFi路由器和HyFi扩展器两局部组成，两者是通过家里的电线传输数据的。配置好路由器后会将无线设置主动推送到扩展器，这样就组成了只有一个信号的无线网络。▲ HyFi套装通过电线传输信号HyFi无线解决方案是具备方便快捷的特点，通过电线传输无需布线，传输速度快、稳定性好。并且无线配置简略，只须要配置好路由器，扩展器的信号就会随之同步扭转。因而这个计划扩展性很好，能够依据理论须要配置多个扩展器，外观也十分的大气，好看、简洁。华为的这个计划也叫子母路由器，和HyFi这个名称相比来说更接地气，实质都是路由器和电力猫的联合，可通过家里的已布好的电线传送信号。相比拟前几种，这个计划计划老本绝对较大，须要替换之前的路由器。实用环境：任意家庭环境。【计划五：应用AP/AC扩大无线信号】如果你偏爱整洁的环境，不想看到插座上的线缆，更不想看到突兀的路由器天线，还要所有房间都笼罩良好，那么就应用AC加无线AP的形式组网吧，相对如你所愿。AP：无线拜访接入点（Access Point），说白了就是一个WiFi信号收发器，相当于去掉了路由和治理性能的无线路由器；AC：无线控制器（Access Controller），就是用来集中化治理多个无线AP的，负责下发配置、批改相干配置参数、射频智能治理、接入安全控制等。▲ AC/AP管理网络计划要求所有的AP（接入点）和AC（接入控制器）通过有线形式连接起来，由AC对立配置所有的无线AP，整个无线网络有对立的信号，能够实现无线漫游。该计划选用的AP是能够嵌入到墙外面的网线面板，由AC通过网线来供电，不须要外接电源，美观大方，不占空间。这所有的代价就是贵。实用环境：大户型，对笼罩要求高，心愿整洁，所有网络设备都隐形。【小结】至此，以上几种常见计划介绍结束，咱们对各个计划进行比照：▲ 各种组网计划比照好了，絮叨了这么多，对于WiFi穿墙的“道”和“术”都曾经介绍结束，心愿各位在任意角落都可能信号满满。▲ 技术男的难处 八、本系列文章目录《IM开发者的零根底通信技术入门(一)：通信替换技术的百年发展史(上)》《IM开发者的零根底通信技术入门(二)：通信替换技术的百年发展史(下)》《IM开发者的零根底通信技术入门(三)：国人通信形式的百年变迁》《IM开发者的零根底通信技术入门(四)：手机的演进，史上最全挪动终端发展史》《IM开发者的零根底通信技术入门(五)：1G到5G，30年挪动通信技术演进史》《IM开发者的零根底通信技术入门(六)：挪动终端的接头人——“基站”技术》《IM开发者的零根底通信技术入门(七)：挪动终端的千里马——“电磁波”》《IM开发者的零根底通信技术入门(八)：零根底，史上最强“天线”原理扫盲》《IM开发者的零根底通信技术入门(九)：无线通信网络的中枢——“核心网”》《IM开发者的零根底通信技术入门(十)：零根底，史上最强5G技术扫盲》《IM开发者的零根底通信技术入门(十一)：为什么WiFi信号差？一文即懂！》（* 本文）《IM开发者的零根底通信技术入门(十二)：上网卡顿？网络掉线？一文即懂！》《IM开发者的零根底通信技术入门(十三)：手机信号差？一文即懂！》《IM开发者的零根底通信技术入门(十四)：高铁上无线上网有多难？一文即懂！》《IM开发者的零根底通信技术入门(十五)：了解定位技术，一篇就够》  （本文已同步公布于：http://www.52im.net/thread-2402-1-1.html）

为了更好地分类浏览52im.net 总计1000多篇精编文章，我将在每周三推送新的一期技术文集，本次是第10 期。[-1-] 简述传输层协定TCP和UDP的区别 [链接] http://www.52im.net/thread-580-1-1.html [摘要] 本文将从应用层的角度，简要的比照TCP和UDP协定的区别，或者能给你些许启发。 [-2-] 为什么QQ用的是UDP协定而不是TCP协定？ [链接] http://www.52im.net/thread-279-1-1.html [摘要] QQ既有UDP也有TCP！不论UDP还是TCP，最终登陆胜利之后，QQ都会有一个TCP连贯来放弃在线状态。这个TCP连贯的近程端口个别是80，采纳UDP形式登陆的时候，端口是8000。 [-3-]挪动端即时通讯协定抉择：UDP还是TCP？ [链接] http://www.52im.net/thread-33-1-1.html [摘要]对于有抉择艰难证的人来说，基于以上因素，加上UDP和TCP协定的实质差别，这样的抉择的确很纠结。本文将从作者的实际总结，给出自已的观点，如有异议还请感性回复，不为找喷，仅供参考。 [-4-]疾速了解TCP和UDP的差别 [链接] http://www.52im.net/thread-1160-1-1.html [摘要] 本文连续《网络编程懒人入门》系列文章的格调，通过疾速比照剖析 TCP 和 UDP 的区别，来帮忙即时通讯初学者疾速理解这些根底的知识点，从而在IM、音讯推送等网络通信利用场景中能精确地抉择适合的传输层协定。 [-5-] 疾速了解为什么说UDP有时比TCP更有劣势 [链接] http://www.52im.net/thread-1277-1-1.html [摘要] 随着网络技术飞速发展，网速已不再是传输的瓶颈，UDP协定以其简略、传输快的劣势，在越来越多场景下取代了TCP，如网页浏览、流媒体、实时游戏、物联网。本文作为《网络编程懒人入门》系列文章的第5篇，将为您疾速梳理UDP协定在某些场景下比照TCP协定所具备的劣势。 [-6-] UDP的连接性和负载平衡 [链接] http://www.52im.net/thread-1018-1-1.html [摘要]本文将从实际登程，探讨UDP在理论利用中的连接性和负载平衡问题。 [-7-] 深刻地了解UDP协定并用好它 [链接] http://www.52im.net/thread-1024-1-1.html [摘要] 本文接系列文章的上篇《鲜为人知的网络编程(五)：UDP的连接性和负载平衡》，将从实际登程，探讨如何深刻地了解UDP协定并在实践中用好它。 [-8-] 如何让不牢靠的UDP变的牢靠？ [链接] http://www.52im.net/thread-1293-1-1.html [摘要] 波及到实时传输咱们都会先思考 RUDP，RUDP 利用在咱们APP外围传输体系的各个方面，但不同的零碎场景咱们设计了不同的 RUDP 形式，所以基于那些强烈的探讨和咱们应用的教训，我决定扒一扒 RUDP，来给大家分享如何让UDP变的牢靠的实践经验。 [-9-] 从底层动手，深度剖析TCP连贯耗时的机密 [链接] http://www.52im.net/thread-3265-1-1.html [摘要] 通过日常工作的思考之后，我更想弄明确的是，TCP的开销到底有多大，是否进行量化。一条TCP连贯的建设须要耗时提早多少，是多少毫秒，还是多少微秒？能不能有一个哪怕是粗略的量化预计？当然影响TCP耗时的因素有很多，比方网络丢包等等。我明天只分享我在工作实际中遇到的比拟高发的各种状况。 [-10-]彻底搞懂TCP协定层的KeepAlive保活机制 [链接] http://www.52im.net/thread-3506-1-1.html [摘要] 限于篇幅，该篇并没有深入探讨TCP协定自身的KeepAlive机制，所以这次借本文想把TCP协定的KeepAlive保活机制给具体的整理出来，以便大家能深刻其中一窥到底。 [-11-] 拔掉网线再插上，TCP连贯还在吗？一文即懂 [链接] http://www.52im.net/thread-3846-1-1.html ...

本文由得物技术王卫强分享，为了更好的浏览体验，有较多的内容订正和排版优化。一、引言客服IM的外围业务其实就是在线沟通，客服IM的益处是使得客服与用户通过实时沟通的形式能够在最短的工夫内帮忙用户解决问题。为了疾速撑持公司业务倒退需要，咱们客服IM在倒退初期是基于第三方的云IM SDK进行二次开发而来。尽管晋升了我的项目停顿，但同时也埋下了问题定位艰难、非凡性能实现老本低等隐患。随着公司业务的高速倒退，客服对IM聊天的性能和体验都有了更高的要求，在第三方云IM SDK音讯通信上逐步遇到了技术瓶颈。为解决租用第三方云IM SDK接入带来的潜在隐患、晋升IM的稳定性和高扩展性，自研一套可控、稳固、灵便的IM零碎已是火烧眉毛了。本篇文章将基于工程实际，分享咱们从0到1自研一套客服IM零碎时在各种关键技术点上的设计思路和实际办法。注：为了简化内容，本文分享的技术栈次要是以Web客服端为主。相干文章：1）从零到卓越：京东客服即时通讯零碎的技术架构演进历程；2）瓜子IM智能客服零碎的数据架构设计（整顿自现场演讲，有配套PPT）。学习交换： 挪动端IM开发入门文章：《新手入门一篇就够：从零开发挪动端IM》开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）（本文已同步公布于：http://www.52im.net/thread-4153-1-1.html）二、业务场景客服与用户在聊天的过程中，直观上就是客服在输出文案，而后通过网络发送给用户。然而IM聊天SDK该如何设计能力使客服在发送音讯过程中感知不到卡顿？这一点是十分要害的，要防止卡顿就要设计正当的发送策略以及防止大量JS脚本执行。举个客服与用户聊天的例子：1）客服发送了“客服小冰为您服务”这个文案，通过业务侧调用SDK的接口，传入到SDK；2）再将该数据存储到数据池中，序列化后把这个数据对象data传递给socket接口，通过网络通道发送到网关；3）网关侧接管到音讯后，再反序列化，传递到数据池中进行解决，组装成业务可辨认的model，推送到业务侧应用。针对第1）点，SDK会先创立音讯体，即把这个字符串封装成一个自定义的构造体model。其聊天流程如下图所示：从上图中能够清晰的看出一条音讯发送和接管的残缺流程链路。如果IM的SDK设计不合理，发送音讯和接管音讯流程呈现了卡顿，将间接影响用户的体验。 三、自研框架架构图概览下图是咱们的自研IM零碎架构原理图：咱们整体的技术改造次要是两个方面：1）对音讯链路的形象革新：次要是音讯数据存储和音讯排序的重构；2）业务接入侧的形象革新：次要是将业务逻辑和SDK源码进行解耦，做到代码分层更加的清晰。上面咱们将针对次要的技术点进行具体地总结和分享。 四、音讯链路公布/订阅实现在IM SDK自研开发过程中，如何解耦框架代码和业务代码，做到灵便的音讯监听，后期调研之后应用了RxJS。这里简略介绍几个RxJS的外围概念：1）Observable（可察看对象）：示意一个可调用的将来值或事件的汇合；2）Observer（观察者）：监听由Observable提供的值；3）Subscription （订阅）：示意 Observable 的执行。注：Subscription 有一个重要的办法，即 unsubscribe，它不须要任何参数，只是用来清理由 Subscription 占用的资源次要用于勾销 Observable 的执行。 SDK底层在接管到数据后须要同步到业务侧，之前的做法是通过监听形式实现，这种形式不具备勾销订阅的能力，保护老本绝对较高。而应用RxJS能够清晰的梳理出数据流向，通过公布订阅的形式实现数据的通信。RxJS在公布订阅的实现流程如下：从上图能够看到音讯解决的整个流向十分清晰，框架底层接管音讯，订阅者生产音讯。 五、音讯框架的分层构造概览在咱们整个自研的IM音讯通信框架中，次要构造分成三层：1）网络层；2）数据链路层；3）应用层。具体如下图所示：接下来我将具体分享各层的设计和实现思路。 六、音讯框架的分层实现：网络层网络层作为音讯发送的最底层，负责TCP的连贯、音讯发送和接管。网络协议咱们抉择的是TCP协定。咱们为什么没有抉择UDP呢？因为UDP是无连贯的、不够平安、无奈提供牢靠传输的服务，通过TCP连贯传送的数据能够无差别、不失落、不反复且按序达到。PS：尺有所短、寸有所长，TCP和UDP的优劣应该主观对待，感兴趣能够深刻学习上面的文章：《疾速了解TCP和UDP的差别》《一泡尿的工夫，疾速搞懂TCP和UDP的区别》《疾速了解为什么说UDP有时比TCP更有劣势》《深刻地了解UDP协定并用好它》《如何让不牢靠的UDP变的牢靠？》咱们整个IM SDK的通信形式采纳的是 WebSocket + JSON、grpc + protobuf。（如果你对WebSocket和Protobuf不相熟，能够具体学习《WebSocket从入门到精通，半小时就够！》、《Protobuf从入门到精通，一篇就够！》）首先咱们要做的就是建设Websocket连贯：代码层面咱们会先创立一个Connection的抽象类，次要解决网络连接相干配置、超时后从新连贯的弥补实现，和一些继承类须要实现的形象办法。如上述代码所示：外围在解决超时重连，传统的重试策略是每隔一段时间重试一次，因为是固定的工夫距离重试，重试时又会有大量的申请在同一时刻涌入，会一直地造成限流。（这里应用了指数退却的形式，指数退却是一种通过反馈，成倍地升高某个过程的速率，以逐步找到适合速率的算法，可依据时隙和重试尝试次数来决定提早重试。）其实现算法大抵如下：Websocket连贯咱们是通过继承Connect类实现的：至此：网络层连贯就已实现了，绝对比较简单，都是一些socket api的封装，外围的点在用指数退却算法实现音讯发送失败重连贯。 七、音讯框架的分层实现：数据链路层数据链路层是IM SDK的核心层，次要波及到用户信息、聊天音讯、数据池等等，咱们来一步步对每个模块进行剖析。首先梳理一下客服在登录到用户进线发送音讯和接管音讯的全过程。过程有如下几个阶段： 7.1、协定类型音讯协定类型十分重要，是音讯发送的基石。初始化协定数据体，能够用于后续各种音讯、事件的发送。在IM自研的SDK通信协议类型次要有如下几种：  具体解释一下：1）Hi：发送客户端根底信息，通知server以后client的版本、设施类型、语言等信息；2）Login: 登录，token验证，获取或创立以后用户topic信息；3）Sub: 订阅topic或更新topic数据；4）Leave: 勾销订阅，解绑之前的订阅关系；5）Pub: 发送数据音讯给指定topic的订阅者；6）Get: 获取topic的metadata信息，例如：获取订阅者列表、历史数据等；7）Set: 更新topic的metadata信息，例如：删除音讯或删除topic；8）Del: 用于删除操作，包含删除音讯、删除订阅关系、删除topic等；9）Note: client发送告诉给topic的订阅者，例如音讯已收到，音讯已读，以后正在输出等；10）Action: 触发的事件，例如：切换客服状态、获取机器人问题等；11）Datares: ack机制，通知网关已收到该音讯。 7.2、创立连贯对网络层音讯链接实例化，实现音讯的失常发送和接管。其实现如下： 7.3、音讯定义客服要发送一条音讯，必定有对应的音讯构造体model，即须要对音讯体进行设计，这里会设计一下message类，每次创立新的音讯体都会new一个实例，通过对实例的操作能够更新音讯状态等。如下所示：针对单个音讯，咱们也要定义好消息状态，用于聊天过程中音讯状态的更新。如下： 7.4、数据池音讯类创立好之后，就须要有音讯数据池来存储。音讯池构造定义如下：这里还波及到音讯体的一些基本操作办法对数据池中的数据进行操作，就不做过多的论述。 7.5、用户维度下面都是在剖析公共模块，然而客服和用户是一对多的关系存在，还须要设计一个用户维度模块，后续在业务侧的操作根本都是以用户维度来操作，须要从单个用户维度设计对应的订阅关系、音讯发送、删除等等。其实现大抵如下： 7.5.1发送音讯链路剖析针对客服发送音讯，咱们首先要站在客服角度思考音讯是否已收回去，优先展现的聊天页面，而不是等网关给了回复后在展现到聊天页面。依据已往教训来看，只有回车音讯就要立刻展现到聊天页面，否则客服会认为呈现了卡顿，体验成果不佳，鉴于这种场景的需要，在设计发送音讯链路的时候就要充分考虑到这一点。所以设计流程如下：如上图所示：先在SDK内进行解决对应的音讯，解决实现后返回到业务侧实现渲染后再进行音讯发送到网关，失常状况下都在一帧之内，客服是感知不到有提早的。这里要关注音讯体序列化、反序列化的机会，防止无谓的性能节约。上述图中有个虚构seq：次要是为了在未收到IM网关响应之前进行排序用的，比方图片、视频、断网发送音讯、音讯发送失败，或收到IM网关回复短少seq（场景：敏感词）等状况都须要通过虚构seq进行精确排序。 7.5.2接管音讯链路剖析接管音讯过程绝对比较简单，收到音讯进行反序列化后更新相干数据，而后在数据池中实现去重（重试机制）、排序后更新到业务侧渲染即可（如下图所示）。 7.5.3音讯的牢靠传递IM音讯的牢靠投递次要是指：音讯在发送接管过程中，可能做到不丢音讯、音讯不反复、音讯程序不错乱。咱们先来剖析以下2种状况。第一种状况：如果客服A在把音讯发送到IM网关的过程中：1）因为网络不通等起因失败了；2）或者IM网关接管到音讯进行存储时失败了；3）或者IM网关始终没有返回后果，导致超时。以上这些状况客服A都会被提醒音讯发送失败。第二种状况：音讯在IM网关存储完后，客服A被告知音讯发送胜利了，而后IM网关把音讯推送给用户A的在线设施：1）在推送的筹备阶段或者把音讯写入到内存后，如果服务端呈现掉电，也会导致音讯不能胜利推送给用户A；2）如果用户A的设施在接管到音讯，在后续处理过程中呈现问题，也会导致音讯失落。针对第2）点，具体场景比方：用户A的设施在把音讯写入本地DB时，出现异常导致落库失败，这种状况下，因为网络层面实际上曾经胜利传输，但用户A却看不到音讯。咱们客服IM对于音讯失落的解决计划次要是参考TCP协定的ACK机制，实现了一套基于业务层的ACK协定。增加ACK之前音讯发送的时序图如下：7.5.3.1）ACK 机制：在TCP协定中，默认提供了ACK机制，通过一个协定自带的规范的ACK数据包，来对通信方接管的数据进行确认，告知通信发送方已确认胜利接管了数据。ACK机制也是相似，须要解决的是：IM网关推送后如何确认音讯是否胜利送达接管方并明确被接管方所接管。具体实现的时序图如下：客服或用户在发送音讯的过程中都会携带一个msgid（32位的uuid，相似TCP的sequenceId），IM网关在接管到音讯后，会依据msgid到数据库中查问是否存在该条音讯，如果存在就不落库，如果不存在就落库。而后再推送到接管方，接管方在收到音讯后会回复ACK，ACK包中会携带上以后最新的seqid，IM网关收到ACK回复后会对最大的seqid进行更新。这里为什么要更新最大seqid呢？这么设计必定有肯定情理的，IM网关在收到发送方发送的音讯后除了到数据库中检测该音讯是否存在外，还会比照以后接管到音讯的seq和最大seqid两者之间的差值，会把 [seq, seqid) 之间的数据全副推到接管方，失常状况下都是 [n, n-1)，如果IM网关没有收到接管方ACK，n-1就不会更新，推送的音讯个数就大于1了。如果seq和seqid相等那就是发送方反复推送的音讯，这个时候就不会向接管方推送。这里就波及到了音讯重试，持续向下剖析吧。 PS：无关IM音讯ID或序列号生成的专题文章能够浏览：《IM音讯ID技术专题(一)：微信的海量IM聊天音讯序列号生成实际（算法原理篇）》《IM音讯ID技术专题(三)：解密融云IM产品的聊天音讯ID生成策略》《IM音讯ID技术专题(四)：深度解密美团的分布式ID生成算法》《IM音讯ID技术专题(五)：开源分布式ID生成器UidGenerator的技术实现》《IM音讯ID技术专题(六)：深度解密滴滴的高性能ID生成器(Tinyid)》 7.5.3.2）ACK机制中的音讯重试：音讯推给A的过程中失落了怎么办，比方:1）A网络理论曾经不可达，但IM网关还没有感知到（ping呈现问题）；2）音讯在两头网络途中被某些中间设备丢掉了。解决这个问题也是参考了TCP协定的重传机制。咱们会在客服端、IM网关、用户端都保护一个超时计时器，肯定工夫内如果没有收到对方回的ACK包，会从新取出该音讯进行重推。在重试肯定次数后，如果还是没有收到ACK，视为放弃。前端代码构造和成果如下： 上述图片中的数据只是模仿音讯重试，实在场景中执行频次必定要比这个工夫更久一些。7.5.3.3）音讯反复推送的问题：如果在肯定工夫内没有收到ACK包，就会触发重试机制。收不到ACK的状况有两种，除了推送的音讯真正失落导致A不回ACK外，还可能是A回的ACK包自身丢了。解决方案是：发送方在发送音讯时携带一个msgid，msgid是全局惟一的，针对同一条重推的音讯msgid不变，接管方依据这个惟一的msgid进行去重，这样通过去重后，对于A来说，在聊天界面是不会看到反复的音讯，不影响应用体验。7.5.3.4）保障音讯不会乱序：音讯的一致性是十分重要的，在聊天过程中音讯程序不能错乱。咱们是这样思考的：1）以发送方的本地工夫戳为序号，然而这样有比拟大的问题，发送方的工夫戳是能够被改变的，这种形式不可取；2）IM网关服务是集群部署，会通过topic和seqid做为惟一索引，在接管到音讯落库之前会生成seqid，客服端和用户端接管到发送音讯的回执时须要依据返回的seqid(IM网关自增)进行音讯排序，这种形式可取。通过以上的剖析：客服IM音讯的可靠性就是通过ACK机制、重试机制、去重机制、排序机制来确保每一条音讯的残缺触达和精确排序。 八、音讯框架的分层实现：应用层业务侧应用的时候间接实例化SDK即可，在音讯链路公布订阅中曾经提到了RxJS，此时在业务侧订阅应用即可。须要留神的是在实例化SDK的时候传递了一个filterMsgItem办法，次要是为非凡业务场景提供应用的。就拿咱们客服业务来说：有些特定音讯是不须要展现到聊天页面的（比方：用户发送音讯被篡改等）。当然咱们在业务侧从新对数据过滤或者渲染的时候也是能够做过滤的，这样操作是没什么问题，然而没有必要，如果不从源头过滤数据，后续参加二分、倒序查找的源数据也会减少。会有一些不必要的节约。当然也能够不增加这个参数，SDK都是全兼容的。至此咱们就实现了整个SDK的实现以及在业务侧的应用，音讯发送和接管也都失常。成果如下： 九、本文小结自研IM SDK还是蛮有挑战的一件事件，从单纯的基于第三方SDK二次开发到自研SDK并与咱们的理论业务场景绝对完满的联合。在SDK的整体设计以及和业务侧如何更完满的联合并不是欲速不达的，都是在理论业务场景中一直积攒教训，一直尝试才找到绝对完满的解决方案。这里列举一个简略的案例吧。例如音讯发送，须要思考到断网场景下：1）该如何进行音讯显示、排序、从新发送？2）发送失败的场景下从新发送再次失败后又该如何显示、排序？3）弱网场景下发送音讯触发重试机制该如何以最优的形式去重、排序？4）发送音讯触发敏感词该如何解决？5）断网重连后对于发送失败和触发敏感词的音讯又该如何解决？6）如果在波及到文件又该如何解决？……在自研过程中除了关注业务场景外，还调研了行业内比拟好的一些Web利用在某些非凡场景的解决形式。很多优良的计划也都只能是借鉴一些核心思想，还是要以业务为外围，真正通过技术手段解决业务痛点才是最重要的。自研SDK收益还是十分大的，也积攒了很多IM方面的教训，实现自研IM SDK也只是一个开始，后续咱们将会在耗时工作、数据安全等方面继续深耕细作。 十、参考资料[1] 从零到卓越：京东客服即时通讯零碎的技术架构演进历程[2] 瓜子IM智能客服零碎的数据架构设计（整顿自现场演讲，有配套PPT）[3] 从游击队到正规军(一)：马蜂窝旅游网的IM零碎架构演进之路[4] 一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实际[5] 浅谈IM零碎的架构设计[6] 简述挪动端IM开发的那些坑：架构设计、通信协议和客户端[7] 一套海量在线用户的挪动端IM架构设计实际分享(含具体图文)[8] 一套原创分布式即时通讯(IM)零碎实践架构计划[9] 一套亿级用户的IM架构技术干货(上篇)：整体架构、服务拆分等[10] 从老手到专家：如何设计一套亿级音讯量的分布式IM零碎[11] 企业微信的IM架构设计揭秘：音讯模型、万人群、已读回执、音讯撤回等[12] 阿里IM技术分享(三)：闲鱼亿级IM音讯零碎的架构演进之路[13] 基于实际：一套百万音讯量小规模IM零碎技术要点总结[14] 跟着源码学IM(十)：基于Netty，搭建高性能IM集群（含技术思路+源码）[15] 一套十万级TPS的IM综合音讯零碎的架构实际与思考[16] 直播零碎聊天技术(八)：vivo直播零碎中IM音讯模块的架构实际[17] 融云技术分享：全面揭秘亿级IM音讯的牢靠投递机制（本文已同步公布于：http://www.52im.net/thread-4153-1-1.html）

本文由sweetying分享，为了更好的浏览体验，有较多的内容订正和排版优化。1、前言最近我负责的 LiveChat 客服聊天零碎到了自研阶段，工作相似于做一个腾讯云IM这样的通信层SDK。在和后盾进行技术选型探讨后，确定了数据传输层协定格局应用 Protobuf。 本文基于我对Protobuf在Android端的理论应用心得，手把手教你如何在Android端IM产品中应用Protobuf，心愿对你有帮忙。 学习交换： 挪动端IM开发入门文章：《新手入门一篇就够：从零开发挪动端IM》开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）（本文已同步公布于：http://www.52im.net/thread-4135-1-1.html） 2、系列文章本文是系列文章中的第 6 篇，总目录如下：《IM通信协定专题学习(一)：Protobuf从入门到精通，一篇就够！》《IM通信协定专题学习(二)：疾速了解Protobuf的背景、原理、应用、优缺点》《IM通信协定专题学习(三)：由浅入深，从根上了解Protobuf的编解码原理》《IM通信协定专题学习(四)：从Base64到Protobuf，详解Protobuf的数据编码原理》《IM通信协定专题学习(五)：Protobuf到底比JSON快几倍？全方位实测！》《IM通信协定专题学习(六)：手把手教你如何在Android上从零应用Protobuf》（* 本文）《IM通信协定专题学习(七)：手把手教你如何在NodeJS中从零应用Protobuf》《IM通信协定专题学习(八)：金蝶顺手记团队的Protobuf利用实际(原理篇)》《IM通信协定专题学习(九)：手把手教你如何在iOS上从零应用Protobuf》 3、Protobuf 介绍Protobuf的全称是Protocol Buffers，它是 Google 推出的一种与平台无关、语言无关、可扩大的轻便高效的序列化数据存储格局，相似于咱们罕用的 xml 和 json。一个疑难：既然有了 XML 和 JSON，Google 为啥还要推出 Protobuf 呢？存在即是正当，Protobuf 的劣势用两个字总结就是：小、快。雷同的数据内容，用 Protobuf 序列化后的大小是 JSON 的十分之一，是 XML 格局的二十分之一，而且性能是他们的 5～100 倍。 通常状况下，咱们应用 XML 或者 JSON 进行数据通信是没什么问题的，然而在性能优化的场景下，如果有方法压缩数据量、进步传输效率，显然会给用户带来更快更晦涩的体验。因而我在做 LiveChat 自研技术选型时，Protobuf 成为了咱们进行数据传输协定格局的第一抉择。 4、Protobuf 环境配置4.1概述介绍两种装置 Protobuf 的形式：1）Github 下载 Protobuf 并装置；2）brew 装置。 4.2Github 下载 Protobuf 并装置Protobuf 版本尽量放弃前后台统一，这里是后盾和我约定的一个版本（点此下载）。1）依据本人的零碎抉择相应的 zip 包：以我下载的为例，解压后构造如下：能够看到 bin 目录下有个 protoc 的可执行文件。咱们给它配置一下环境变量就能够应用了（以我的为例）：# protobuf 环境变量exportPROTOBUF_HOME=/Users/zhouying/Downloads/protoc-3.19.2-osx-x86_64exportPATH=${PATH}:${PROTOBUF_HOME}/bin配置好后，应用 protoc --version 命令验证：能够看到打印出了版本，证实咱们装置胜利了。 4.3brew 装置间接应用以下命令就能够一键装置或卸载：//一键装置 protobufbrew installprotobuf //一键卸载 protobufbrew uninstall protobufPS：这种形式只实用于 Mac 零碎，而且装置的 protobuf 为最新版本，因而如果想要应用指定的版本，倡议应用上大节里的Github下载安装这种形式。 ...

为了更好地分类浏览52im.net 总计1000多篇精编文章，我将在每周三推送新的一期技术文集，本次是第9 期。[-1-] 少啰嗦！一分钟带你读懂Java的NIO和经典IO的区别 [链接] http://www.52im.net/thread-26... [摘要] 在本文中，将尝试用简明扼要的文字，说明Java NIO和经典IO之间的差别、典型用例，以及这些差别如何影响咱们的网络编程或数据传输代码的设计和实现的。 [-2-] 史上最强Java NIO入门：放心从入门到放弃的，请读这篇！ [链接] http://www.52im.net/thread-26... [摘要] 本文作者厚积薄发，以远比个别的技术博客或技术作者更深厚的Java技术储备，为你由浅入深，从零解说到底什么是Java NIO。本文即便没有多少 Java 编程教训的读者也能很容易地开始学习 NIO。 [-3-]Java的BIO和NIO很难懂？用代码实际给你看，再不懂我转行！ [链接] http://www.52im.net/thread-28... [摘要]本文不会提到很多Java NIO和Java BIO的实践概念（需要的话请参见本文的“相干文章”一节），而是站在编码实际的角度，通过代码实例，总结了我本人对于Java NIO的见解。有了代码实际的过程后再从新回头看实践概念，会有一个不一样的了解视角，心愿能助你吃透它们！ [-4-]Java新一代网络编程模型AIO原理及Linux零碎AIO介绍 [链接] http://www.52im.net/thread-30... [摘要] 从JDK 7版本开始，Java新退出的文件和网络io个性称为nio2(new io 2, 因为jdk1.4中曾经有过一个nio了)，蕴含了泛滥性能和性能上的改良，其中最重要的局部，就是对异步io的反对，称为Java AIO(asynchronous IO)。因为AIO的施行需充沛调用OS参加，IO须要操作系统反对、并发也同样须要操作系统的反对，所以性能方面不同操作系统差别会比拟显著。所以本文也附带介绍了Linux 2.6及当前版本新增的AIO个性（因为这跟Java AIO是对应关系）。 [-5-] 新手入门：目前为止最透彻的的Netty高性能原理和框架架构解析 [链接] http://www.52im.net/thread-20... [摘要] Netty 是一个广受欢迎的异步事件驱动的Java开源网络应用程序框架，用于疾速开发可保护的高性能协定服务器和客户端。本文基于 Netty 4.1 开展介绍相干实践模型，应用场景，根本组件、整体架构，知其然且知其所以然，心愿给大家在理论开发实际、学习开源我的项目方面提供参考。 [-6-] 写给初学者：Java高性能NIO框架Netty的学习办法和进阶策略 [链接] http://www.52im.net/thread-21... [摘要]Netty 入门绝对简略，然而要在理论我的项目中用好它，出了问题可能疾速定位和解决，却并非易事。只有在入门阶段扎实的学好 Netty，前面应用才可能得心应手。 [-7-] Netty 4.x学习（一）：ByteBuf详解 [链接] http://www.52im.net/thread-99... [摘要]ByteBuf提供了一些较为丰盛的实现类，逻辑上次要分为两种：HeapByteBuf和DirectByteBuf，实现机制则分为两种：PooledByteBuf和UnpooledByteBuf，除了这些之外，Netty还实现了一些衍生ByteBuf（DerivedByteBuf），如：ReadOnlyByteBuf、DuplicatedByteBuf以及SlicedByteBuf。 [-8-] Netty 4.x学习（二）：Channel和Pipeline详解 [链接] http://www.52im.net/thread-10... [摘要]Channel概念与java.nio.channel概念统一，用以连贯IO设施（socket、文件等）的纽带。Netty 4.x之后的Channel变动较大，官网的唬人的说法是无奈通过简略的关键字替换进行迁徙。用得较多应该是：ChannelHandler接口从新设计，换了个较为清晰的名字；write不会被动flush。因为笔者3.x、4.x都没用过，所以也无奈深刻了解版本的变动了。 ...

1、引言对于IM聊天利用来说，为了晋升安全性，对聊天音讯加密是惯例操作。众所周之，Netty是高性能的Java NIO网络通信框架，因此用Netty来写IM是再失常不过了。网上对于为Netty生成、以及应用SSL/TLS证书的文章有很多，但因为各种起因，生成的证书要么是Netty中无奈读取和应用，要么是代码不全或不具体导致基本配不通SSL/TLS加密。正好这段时间专门为 MobileIMSDK 生成了一套测试证书，棘手把这个过程记录了下来，分享给大家。本文要分享的是如何应用OpenSSL生成在基于Netty的IM中真正可用的SSL/TLS证书，内容包含：证书的创立、创立过程中的留神点，以及在Server端、Android端、iOS端、Java桌面端、H5端应用证书的代码范例。注：对于那些付费购买了第3方权威CA机构签发的证书，他们都有相应的应用文档，这就没什么好说的。本文里的证书指的是不须要花钱的自签名证书。学习交换： 挪动端IM开发入门文章：《新手入门一篇就够：从零开发挪动端IM》开源IM框架源码：https://github.com/JackJiang2...（备用地址点此）（本文已同步公布于：http://www.52im.net/thread-41...）2、常识筹备► 如果你对IM零碎毫无概念，倡议先浏览《零根底IM开发入门(一)：什么是IM零碎？》系列文章，通俗易懂，适宜小白。► 如果你想零碎学习IM开发相干的理论知识，比方网格编程、IM架构设计等，倡议先浏览《新手入门一篇就够：从零开发挪动端IM》。► 如果你不理解Netty是什么，倡议浏览以下几篇Netty的根底入门好文章： 1）新手入门：目前为止最透彻的的Netty高性能原理和框架架构解析2）写给初学者：Java高性能NIO框架Netty的学习办法和进阶策略3）史上最艰深Netty框架入门长文：根本介绍、环境搭建、入手实战► 如果你已把握IM理论知识，同时也对Netty根本把握，正筹备入手实战，则能够浏览《基于Netty，从零开发IM》和《跟着源码学IM》这个系列文章，有各种入门级实战代码，图文并茂，适宜学习。► 如果你对IM、Netty已基本上手，但对IM平安方面的技术概念有点理不清，倡议必读《基于Netty的IM聊天加密技术学习：一文理清常见的加密概念、术语等》。 3、什么是NettyNetty是一个Java NIO技术的开源异步事件驱动的网络编程框架，用于疾速开发可保护的高性能协定服务器和客户端。往艰深了讲，能够将Netty了解为：一个将Java NIO进行了大量封装，并大大降低Java NIO应用难度和上手门槛的超牛逼框架。（援用自《史上最艰深Netty框架入门长文：根本介绍、环境搭建、入手实战》）PS：限于篇幅，对于Netty方面的入门常识就不再赘述，如有必要，请认真跟着本文第二节“2、常识筹备”里无关Netty的文章进行浏览。 4、什么是OpenSSLOpenSSL是一个凋谢源代码的软件库，应用程序能够应用这个包来进行平安通信，它包含代码、脚本、配置和过程的汇合。其次要库是以 C 语言所写成，实现了根本的加密性能，实现了 SSL 与 TLS 协定。OpenSSL整个软件包大略能够分成三个次要性能局部：SSL协定库、应用程序、明码算法库。PS：OpenSSL的介绍就点到为止，如有趣味，可仔细阅读《基于Netty的IM聊天加密技术学习：一文理清常见的加密概念、术语等》。 5、下载和装置OpenSSL1）办法一：能够从OpenSSL的Github仓库下载源码自行编译（源码下载地址），对于个别使用者来说，自已编译着实有点麻烦，不举荐这么玩。2）办法一：也能够从这个网站下载第3方编译好的OpenSSL安装程序（安装程序下载地址），这样上手简略快捷。具体能够参考《openssl装置教程（windows7零碎，超具体）》这篇文章。3）办法一：也能够间接用上面附件里的安装程序（这是我始终用的版本，版本较老，有趣味可间接下载应用）： Openssl-windows-0.9.8k(52im.net).rar (874.97 KB , 下载次数: 1 , 售价: 1 金币)4）解决 “openssl.cnf找不到” 的问题：如果你装置好OpenSSL后，应用时报“openssl.cnf找不到”或“计算机短少openssl.cnf”等之类谬误提醒，能够下载上面这个 openssl.cnf文件。openssl.cnf 文件附件下载： openssl_conf(52im.net).rar (4.63 KB , 下载次数: 1 , 售价: 1 金币)openssl.cnf 文件解压缩后：openssl.cnf文件配置应用：以下是 openssl.cnf 文件的配置应用命令：（以我的装置目录为例） C:\Openssl-windows-0.9.8k-out32dll>set OPENSSL_CONF=c:/WINDOWS/system32/openssl.cnf准备就绪，接下来咱们就能够开始生成SSL/TLS证书了！ 6、生成Netty可用的SSL/TLS证书6.1概述通过实际，生成Netty可用的SSL/TLS证书须要4步：1）创立私钥证书；2）将私钥格局转成pk8；3）创立证书申请；4）生成公钥证书。接下来，跟着本节内容，一步步应用OpenSSL生成一个真正能在Netty中能应用的自签名证书。 6.2第一步：创立私钥证书在CMD管制台下执行如下指令：（记得手动创立 netty 目录） openssl genrsa -des3 -out netty/netty-key.pem 1024提醒：以上指令中，如无“-des3”参数，则Netty的代码中应用时将报“File does not contain valid private key”等谬误（如下图所示）。 6.3第二步：将私钥格局转成pk8在CMD管制台下执行如下指令： openssl pkcs8 -innetty/netty-key2.pem -topk8 -out netty/netty-key2.pk8提醒1：如不转pk8格局，则Netty的代码中应用时会报以下谬误：提醒2：如代码中不为key退出明码，则Netty的代码中应用时会报以下谬误：提醒3：Netty的代码中应用时要退出上方生成Key证书时的明码即可： 6.4第三步：创立证书申请在CMD管制台下执行如下指令： openssl req -new -out netty/netty-req2.csr -key netty/netty-key2.pem提醒：经上指令中，Common Name指明的是证书绑定的域名，你能够用域名或ip，本次生成用了子域名。 6.5第四步：生成公钥证书在CMD管制台下执行如下指令： openssl x509 -req -inca/ca-req2.csr -out netty/netty-cert2.crt -signkey netty/netty-key2.pem -days 3650提醒：out 参数生成的是.crt，而在后面的是.pem，这只是扩展名区别，内容都一样。 ...

本文作者：丁同舟，来自金蝶顺手记技术团队。1、引言接上篇《金蝶顺手记团队的Protobuf利用实际(原理篇)》，本文将以iOS端的Objective-C代码为例，图文并茂地向您菔救绾卧趇OS工程中疾速应用Protobuf，心愿对你有帮忙。  学习交换： 挪动端IM开发入门文章：《新手入门一篇就够：从零开发挪动端IM》开源IM框架源码：https://github.com/JackJiang2...（备用地址点此）（本文已同步公布于：http://www.52im.net/thread-41...） 2、系列文章本文是系列文章中的第 9 篇，本系列总目录如下：《IM通信协定专题学习(一)：Protobuf从入门到精通，一篇就够！》《IM通信协定专题学习(二)：疾速了解Protobuf的背景、原理、应用、优缺点》《IM通信协定专题学习(三)：由浅入深，从根上了解Protobuf的编解码原理》《IM通信协定专题学习(四)：从Base64到Protobuf，详解Protobuf的数据编码原理》《IM通信协定专题学习(五)：Protobuf到底比JSON快几倍？全方位实测！》《IM通信协定专题学习(六)：手把手教你如何在Android上从零应用Protobuf》（稍后公布..）《IM通信协定专题学习(七)：手把手教你如何在NodeJS中从零应用Protobuf》《IM通信协定专题学习(八)：金蝶顺手记团队的Protobuf利用实际(原理篇)》《IM通信协定专题学习(九)：手把手教你如何在iOS上从零应用Protobuf》（* 本文）另外：如果您还打算系统地学习IM开发，倡议浏览《新手入门一篇就够：从零开发挪动端IM》。 3、根本介绍Protobuf（全称 Protocol buffers） 是 Google 提出的一种跨平台、多语言反对且开源的序列化数据格式。绝对于相似的 XML 和 JSON，Protobuf 更为玲珑、疾速和简略。绝对于传统的 XML 和 JSON， Protobuf 的劣势次要在于：更加小、更放慢，其语法目前分为proto2和proto3两种格局。如果你没不理解Protobuf是什么，倡议先浏览本系列的前几篇《Protobuf从入门到精通，一篇就够！》、《疾速了解Protobuf的背景、原理、应用、优缺点》、《金蝶顺手记团队的Protobuf利用实际(原理篇)》，本篇就不再反复介绍了。目前 Google 官网的 Protobuf最新 release 版本为3.21.12，但本文写作时用的是3.5.1，以下截图都是基于此版本的环境搭建，如果你应用最新版本，差别并不大，因为只是小版本更新。对于 Protobuf的应用能够查阅官网文档：https://developers.google.com...，倡议养成浏览文档的习惯。 4、筹备工作4.1环境要求最低开发环境要求：1）Objective-C 2.0 Runtime (32bit & 64bit iOS, 64bit OS X)2）Xcode 7.0 以上版本留神：Protobuf 出于性能思考没有应用 ARC，但在 ARC 下是能够应用的。 4.2下载安装下载 Protobuf 代码包(https://github.com/protocolbu...)，因文章截图时用的是v3.5.1，所以我这里的为了保持一致抉择的是 protobuf-objectivec-3.5.1.tar.gz，版本区别不大，倡议依此类推。 4.3解压代码包编译 Protobuf，这里可能须要装置局部工具:$ brew install autoconf$ brew install automake$ brew install libtool运行上面脚本进行编译：$ ./autogen.sh$ ./configure$ make$ makeinstall查看protobuf是否装置胜利：$ protoc --version如果胜利打印版本号则装置胜利：libprotoc 3.5.1 5、在 iOS 中应用 Protobuf5.1创立.proto文件这里应用官网文档上的一份示例数据结构创立Person.proto：syntax = "proto3"; message Person {  string name = 1;  int32 id = 2;  string email = 3;   enumPhoneType {    MOBILE = 0;    HOME = 1;    WORK = 2;  }   message PhoneNumber {    string number = 1;    PhoneType type = 2;  }   repeated PhoneNumber phone = 4;}应用命令行编译Person.proto为objective-c的文件，编译进去的文件为Person.pbobjc.h和Person.pbobjc.m：protoc Person.proto --objc_out=./ ...

对于MobileIMSDK MobileIMSDK 是一套专门为挪动端开发的开源IM即时通讯框架，超轻量级、高度提炼，一套API优雅反对UDP 、TCP 、WebSocket 三种协定，反对iOS、Android、H5、规范Java平台，服务端基于Netty编写。 工程开源地址是： 1）Gitee码云地址：https://gitee.com/jackjiang/M...2）Github托管地址：https://github.com/JackJiang2...对于RainbowChat► 具体产品介绍：http://www.52im.net/thread-19...► 版本更新记录：http://www.52im.net/thread-12...► 全副运行截图：Android端、iOS端► 在线体验下载：专业版(TCP协定)、专业版(UDP协定)      （对于 iOS 端，请：点此查看）  RainbowChat是一套基于开源IM聊天框架 MobileIMSDK 的产品级挪动端IM零碎。RainbowChat源于实在经营的产品，解决了大量的屏幕适配、细节优化、机器兼容问题（可自行下载体验：专业版下载安装）。 RainbowChat可能是市面上提供im即时通讯聊天源码的，惟一一款同时反对TCP、UDP两种通信协议的IM产品（通信层基于开源IM聊天框架  MobileIMSDK 实现）。 v8.4 版更新内容此版更新内容（更多历史更新日志）：（1）Android端次要更新内容【通信核心层优化！】： 1）[优化] 可依据http接口的url主动判断并启用https加密；2）[优化] 降级外围长连贯通信层库 MobileIMSDK 至 v6.3；3）[优化] 提供了灵便的接口定制和开启长连贯的SSL/TLS加密传输。（2）服务端次要更新内容： 1）[优化] 降级外围长连贯通信层库MobileIMSDK 至 v6.3；2）[优化] 凋谢了灵便的接口定制和开启长连贯的SSL/TLS加密传输。此版次要性能运行截图（更多截图点此查看）：

本文由钉钉技术专家啸台、万泓分享，为了取得更好的浏览成果，本文已对内容进行少订正和从新排版。1、引言 钉钉后端架构的单元化工作从2018年开始到往年，曾经是第五个年头了。五年的工夫，钉钉单元化迭代了三个版本，从最后的毛头小子，达到往年曾经小有成就。咱们在进行单元化架构建设的过程中，除了网上能找到的比比皆是的文章外，能够间接应用的零碎更是乏善可陈，使咱们不得不从最根底的零碎开始造轮子，极大的影响建设效率。侥幸的是，近几年云原生技术的衰亡，让咱们能复用很多基础设施，进而疾速晋升咱们的单元化建设能力，助力钉钉的倒退。 明天想借此文和大家分享咱们在钉钉单元化架构施行过程中的心路历程和一些最佳实际。因波及的技术和业务面太广，本文的分享无奈做到八面玲珑，次要是想在同路人中造成共鸣，进而能复用一些架构或子系统的设计和实现思路。 学习交换： 挪动端IM开发入门文章：《新手入门一篇就够：从零开发挪动端IM》开源IM框架源码：https://github.com/JackJiang2...（备用地址点此）（本文同步公布于：http://www.52im.net/thread-41...）2、系列文章 本文是系列文章的第 10 篇，总目录如下： 《阿里IM技术分享(一)：企业级IM王者——钉钉在后端架构上的过人之处》《阿里IM技术分享(二)：闲鱼IM基于Flutter的挪动端跨端革新实际》《阿里IM技术分享(三)：闲鱼亿级IM音讯零碎的架构演进之路》《阿里IM技术分享(四)：闲鱼亿级IM音讯零碎的牢靠投递优化实际》《阿里IM技术分享(五)：闲鱼亿级IM音讯零碎的及时性优化实际》《阿里IM技术分享(六)：闲鱼亿级IM音讯零碎的离线推送达到率优化》《阿里IM技术分享(七)：闲鱼IM的在线、离线聊天数据同步机制优化实际》《阿里IM技术分享(八)：深度解密钉钉即时消息服务DTIM的技术设计》《阿里IM技术分享(九)：深度揭密RocketMQ在钉钉IM零碎中的利用实际》《阿里IM技术分享(十)：深度揭密钉钉后端架构的单元化演进之路》（* 本文） 3、术语概念本文内容中应用了一些专有的技术名词，为了不便大家了解，我把要害的几个术语概念的缩写及其含意专门列出来，供大家参考。次要是以下几个：1）Geo：钉钉专有化部署单位，解决数据合规需要，Geo间数据按需互通，并且互通数据在Geo外部做镜像拷贝，解决两化问题；2）Unit: Geo外部资源物理分区隔离的最小单位，解决Geo内的容灾和容量的问题；3）L0：客户端路由，决定了用户客户端接入钉钉服务器的所属单元，用户长连贯所在的逻辑单元，起到连贯减速作用。用户接入单元；4）L1：接入层路由，以用户为维度进行调度，即用户操作产生的单元。用户归属单元；5）L2：业务层路由，以业务资源为维度进行调度，大部分的业务资源所在单元应该和用户调度单元统一，但一些业务无奈依照用户划分单元，如IM的会话，音视频的会议。 业务归属单元；6）DMB：负责钉钉利用跨单元RPC调用的转发，能够认为是钉钉单元化RPC路由中间件；7）DMR：负责钉钉利用跨单元MQ音讯的转发，能够认为是钉钉单元化MQ路由中间件；8）DTIM：钉钉IM零碎。 4、单元化架构1.0版：合规驱动下的部署架构 2018年，局部大客户出于法律政策、商业秘密数据存储的要求，要求钉钉的数据存储、拜访接入、服务部署须要在其信赖的区域内。既须要满足其数据存储私有化要求，同时须要满足跨地区网络的rt性能要求。于是咱们联合阿里云机房部署地位、物理间隔、用户数据安全等方面登程，钉钉在客户的阿里云机房内建设了一个单元，将通讯录、IM信息等企业数据独自存储在客户机房。 咱们通过一条专线，将两个机房逻辑串联到一起，外部通过DMB/DMR零碎，实现了申请互通，这就是钉钉单元化架构的1.0版。1.0版比较简单，纯正是业务驱动，和支付宝单元化建设的初衷——“容灾驱动”有较大区别。两个站点通过UID分段，将用户划分为核心用户和专有用户。上图只是一个简化的逻辑构造，外部实现远比上图简单，然而1.0建设次要是从0到1，和大多数异地多活的零碎较类似，这里就只简略的和大家分享一下。 5、单元化架构2.0版：逼出来的容量架构 2020年是一个非凡的年份，因为疫情的起因，带给大家十分多的扭转，其中也包含钉钉。因为在线办公与教育流量的突增，开年第一天下班就给钉钉一个下马威，平峰的流量曾经和元旦跨年的持平，然而和元旦不同的是这个流量是继续的，即便节前筹备了三倍容量，也抵挡不住流量对系统的冲击。只能借助阿里云的能力，一直的扩容。 然而每天将近30%的流量增幅，单纯的扩容也能难保障服务的连续性，最终也遇到了扩无可扩的场景，张北机房没有机位了，有机器资源然而没有机位让咱们无力无处使。咱们不得不一直进行系统优化，同时借助限流、降级、双推等措施，勉强抗住了流量的最高峰。疫情之前，咱们始终在做高可用，然而这个高可用次要集中在容灾机制上，比方搭建容灾单元。如同支付宝一样，是因为过后光纤被挖断；又比方银行的两地三核心架构，是放心某一个地区因为人祸或者和平导致数据失落。疫情的流量给咱们上了一课，仅仅关注容灾是不够的，特地是钉钉的DAU从千万走向亿级别之后，更须要在容量上做出提前布局。正因如此，咱们认为“容量架构不是设计进去而是真真切切被逼出来的”，所以容量架构就成为咱们单元化外围因素之一。容量架构是将流量划分到不同单元，每个单元承载各自的流量。容灾架构是单元异样时，能保障外围的能力可用，也能够将流量动静调度到别的单元，实现服务的疾速复原。因而钉钉单元化进入了2.0时代，专一于容量和容灾的建设。 6、2.0版是基于什么维度进行流量划分的？ 要实现流量的划分，必然要基于一个维度进行划分，一部分到A单元，一部分到B单元。钉钉单元化架构也是参考了淘系和支付宝的单元化架构，前两者都是基于UID划分，钉钉单元化的第一个版本其实也是一样的，基于UID做拆分。然而当咱们设计容量架构时，发现基于UID划分无奈解决咱们的容量问题。以IM为例：一条音讯其实属于聊天单方的，群聊亦是如此。用户能和任意一个人聊天，这样咱们根本无法找到一个切入点来划分流量，强行依照UID拆分，必然导致一个用户的音讯呈现在N个单元，单元的自关闭就无奈做了。也有同学会说：为什么音讯不依照每个人存储，这不就能依照UID划分了吗？论断是不行。首先这个音讯变成了写扩散，长久化的时候会变成多单元写，其次是老本翻倍，在DTIM这种过亿规模的场景这条路走不通。这里能够多说一点，因为这个观点来之不易，大家都晓得，人是有惯性的，既然淘宝、支付宝甚至是微信都是UID划分，为什么钉钉要特立独行？过后咱们团队受到了绝大部分钉钉技术团队的挑战，继续长达将近一个月的技术选型的“争吵”，最终还是达成了一致意见。DTIM次要有3个维度，别离是UID、会话（CID）、音讯。其中会话和音讯是绑定的，而零碎中最大量的是音讯，依照第一性准则来看，肯定要将音讯划分开来，能力做到将容量划分开来的成果。咱们再来看看音视频，是依照房间维度组织流量和数据的，和IM又齐全不同。同样，文档其实更适宜依照企业维度来划分。不同的业务领有不同的维度，因而咱们认为：单元化最重要的找到本身“最大”的业务维度，将这个保护拆分，能力实现单元的横向扩大，咱们称之为“业务路由”。回头来看：咱们之前其实是进入了思考误区，认为淘系和支付宝都是UID维度，咱们也要这个维度，其实UID正是前者的业务维度，比方订单，也是围绕用户，并不会有交加的状况，会话就是IM的划分维度，因而做单元化之前要先找到属于本人的业务维度。 7、2.0版是如何实现IM音讯的全局路由能力的？ 7.1概述 UID路由有个最大的益处，就是能够依照UID分段，能实现高效的动态路由，也不必放心多单元之间的一致性问题。然而这种分段路由局限性也比拟显著，须要事后调配，单元之间动静调度流量和数据老本极高，而且只能反对这种数值+程序的场景。在钉钉的场景中，有会话维度、房间维度、企业维度等等，想简略采纳这种预分段机制难以满足业务需要。因而咱们须要构建一个业务路由零碎（RoutingService），实现音讯流量的准确路由。   以IM为例：每次音讯的发送，在单元化框架层面，会通过音讯的会话（CID），查问路由信息，如果是本单元，流量上行并长久化；如果是非本单元，路由到对应的单元中。 下图是三个会话：别离是cid:1001、cid:1002、cid:1003，三个会话附属不同单元，不论用户从哪个单元发送音讯，都会路由到会话所在的单元。比方：用户在Unit B的cid:1001 中发送音讯，当音讯进入Receiver之后，会先查问此cid:1001所在的单元，发现是Unit A，路由框架将申请转到A单元，音讯在A单元长久化并通过A单元的同步协定，将数据推送到客户端。    从上图可知：每次音讯发送，都要查问路由服务，DTIM百万的峰值，对路由必然会带来超大的压力，同时咱们能发现，路由数据在多单元实现一致性是一个微小的挑战。 7.2边缘计算： 端到端路由在DTIM的场景中，会话的路由信息简直不会变更，只有当咱们决定将某些超大的会话或者企业腾挪到新单元时，才会发动路由的变更，因而会话的路由信息简直能够认为是恒定不变的。那么每次查问路由服务端，效费比太低，是极大的节约。既然路由信息简直不可变，是否将路由信息缓存呢？最常见的是应用一个集中式的Cache零碎，缓存Hot的会话，咱们也是这么做的，然而这么做还是不够，一旦Cache零碎生效，DTIM还是会呈现大面积故障，而且这个百万级的申请对Cache也是一个极大的压力。思考到钉钉有弱小的客户端，借用边缘计算的思路，咱们将用户的会话数据缓存到客户端。对于客户端来说，也只用缓存用户本身最热的N会话路由数据，音讯发送时，通过Header将路由数据携带到服务端，服务端路由SDK只有做合法性和续约即可，这样就将路由流量升高了95%以上。当路由服务出现异常时，还能够持续应用客户端路由，将路由的可用性晋升到一个新的高度。SDK本地会根据上行申请的返回中是否有新的路由信息，进而更新客户端路由。同时能够借助钉钉有被动下推的能力，通过同步协定将新的路由信息被动推送给客户端，使会话迁徙做到更平顺。 7.3计算下沉： 多单元一致性对于新会话：比方小明要创立一个群聊，是应该创立在那个单元呢？如果在A单元创立了，当会话音讯来到B单元，零碎怎么能第一工夫晓得会话曾经在被绑定到A单元。这里个别的形式有两种：1）单元之间的存储系统采纳相似DTS的机制进行异步同步，这种机制有秒级提早；2）在应用层被动同步，比方接入音讯队列。这两种形式因为都是异步的起因，都会呈现不统一的问题，如果会话同时被绑定在两个单元，逻辑上会导致用户的历史音讯失落，这个是不能承受的。多地区（Region）数据同步其实是通用的技术挑战，咱们认为存储系统提供是最好的形式，正如Google的Spanner一样，这样对咱们下层才是最敌对的形式。因而咱们找到了存储的OTS、Nuwa团队一起共建了GlobalTable。GlobalTable的外围原理还是借助Nuwa的一致性组，组散布在多个地区，采纳多数派写入胜利即返回的原理，做到20ms以内的一致性写。 8、2.0版的容灾能力钉钉单元化的容灾能力是深度联合钉钉的业务层场景落地的，和淘系支付宝等有明确的区别。 以DTIM为例，最大的特点是当服务单元异样时，服务侧仍能提供最外围的服务，保障最根本的能力。实质上是因为DTIM是最终一致性零碎，能够短暂容许局部环节失败。 能够看一下DTIM发送音讯的容灾场景。当某个单元齐全不可用的状况下，用户音讯发送链路通过降级为local模式，在本地校验非本单元会话数据通过之后间接做音讯发送，processor遇到非本单元的会话音讯数据能够做单元间投递做数据回放，本地是否落库可选，同步协定推送不用辨别是否为本单元会话音讯数据间接通过本单元的topic推送给客户端，配合用户无状态疾速迁徙能力，单元间能够实现真正的分钟级别容灾切换能力。 9、2.0版的成绩与冲破 以上是钉钉单元化2.0提供给利用的外围能力，在满足容灾和容量设计需要之后，钉钉单元化给利用带来了更多的能力和设想空间。比方：1）疾速迁徙：当某一地区资源有余时，钉钉单元化能够将业务疾速的从A单元迁徙到B单元；2）常态化切流：比方新建的教育会话，能够放到独立的单元；3）热点治理：以后某一个会话过热，非凡期间能够迁徙到独立集群；4）SLA：满足不同的VIP客户需要，基于不同的SLA和售卖价格，将VIP客户放到对应地单元。外围还是咱们领有单元化能力之后，实现了多单元流量的疾速调度，为业务解决了后顾之忧。 10、2.0版在新时代面临的新挑战 10.1鱼和熊掌不可兼得 2022年对钉钉来说是老本之年，老本的压力不光落到了团队，还落到了每个人身上。正如存储的CAP实践是一样的，咱们同时只能满足两个维度，对于流量（性能P）、老本（C）、体验（E）也是一样，在流量不可预知和干涉的状况下，抉择老本必然导致体验受损，反之抉择体验，必然导致老本升高。进入下半年，疫情重复带来流量的重复，为了实现可控的教育老本，只能在高峰期降级局部能力，这又导致体验受损，这段时间的工单量能够窥见一斑。流量是用户侧触发的，咱们无奈干涉，只能在老本和体验之间寻求均衡。和后面提及的一样，为了减小老本的耗费这就导致咱们在扩容和缩容之间疲于奔命，反馈不及时甚至有故障的危险，这种机制不可取也不可继续。到底是要流量与老本，还是要流量与体验，给咱们技术团队带来了微小的挑战和矛盾。 10.2商业化路在何方以后钉钉为反对大客户提供了多种解决方案，业余钉钉、专属存储与打包、专有钉钉。专属钉钉通过APP专属化以及局部专属性能，比方为一个企业定制一个领有独立Logo的APP，能满足个别的中大型客户的业务诉求。对于大型以及超大型客户，咱们提供专有钉钉，提供专有化输入，齐全隔离的计划，比方浙政钉。随同着钉钉的商业化进入深水区，客户对钉钉提出了新的诉求，特地是数据安全与归属、互联互通、残缺的能力栈等诉求，以后钉钉输入产品状态都无奈同时地满足以上需要。前几年互联网上呈现的几起数据安全事件，数据失落与泄露，未经客户受权擅自拜访客户数据，让大多数客户不信赖服务提供商，即便服务商的平安能力曾经是业界一线能力。其实这个是能够了解的，数据即客户的生命线，数据无奈在本身可控范畴内，特地是对于很多非凡行业，这是无奈承受的，本身性命岂能假手于人。专属钉钉在面临这种客户时，火线售卖同学是无能为力。那么很多同学必定会提“如果专属钉钉满足不了需要，咱们专有钉钉不是能解决这些问题吗？”，其实单单从诉求来看，专有钉钉场景是切合客户的业务诉求，提供齐全独立运行环境、可控的数据安全。然而专有钉钉因为其独特的架构带来昂扬的售价以及前期的运维代价，对于超大型的客户来说也难以承当如此高的老本。对于钉钉本身来说，从研发到后续运维，保护一套独立体系也难以在客户侧大面积推广。 11、单元化架构3.0版：混合云架构 11.1概述 钉钉单元化通过四年的倒退，在容灾和容量上做出肯定的积淀，同时实现了一些核心技术的积攒。当整体架构成熟之后，咱们也在思考，单元化是否从技术架构降级为业务架构，比方搭建独立的高可用单元，依照售卖的SLA提供给VIP客户，反对钉钉商业化的倒退。同时咱们在云原生逐渐发力，将局部外围利用放到云上，通过这一年多的运行，遇到了新的挑战，但更取得云下无奈取得的计算弹性能力，云上的弹性对云下是一个降维打击，从一个新的方向解决计算问题。如上文提到的两个外围挑战，钉钉单元化同样面临这个问题，在继续的倒退中找到了一个适合的架构方向。 基本思路是： 1）云下作为根本盘，保障外围流量的问题，毕竟云下通过团体多年的打磨，不论是稳定性还是流程的合理性都有保障；2）云上应答低落异样的流量，比方和疫情正相干的教育流量，既保证了服务的稳定性，又能充分利用云上弹性能力，在提供残缺能力的前提下做到一个绝对较低的老本。 其次是降级Geo概念：1）将Geo作为一个独立的业务域，实现Geo级别齐全独立部署，分布式云模式；2）同时Geo之间按需互通，从研发体系上能做到一套代码。 因而，钉钉单元化来到了3.0版本，咱们称之为钉钉单元化混合云架构。混合云次要是从两个维度来看：第一：是云上云下，咱们认为云上云下并不是取代的关系，而是互相补充的关系，是一个长期的状态，正如很多大客户随着规模的继续扩张，最终依赖的局部外围能力必然走向自研情理一样，这能做老本的进一步升高，所以架构是一个混合云架构；第二：业务架构上也是混合云架构，通过不同的Geo，将不同的业务逻辑上聚合到一起，构建起一张钉钉的大网，不同Geo按需互通，实现了业务架构的混合。3.0从零碎架构上绝对于2.0，最大的区别就是云原生技术的使用和互通网关的建设。 11.2云原生技术 ：抵制零碎架构熵增的无效伎俩 近几年，互联网圈最火的技术莫过于以Docker为代表的云原生技术最为炽热，各大云厂商也都在不遗余力的推广云原生技术以及对应的产品。同时钉钉服务过亿DAU的客户，面对各种可靠性、服务连续性、并发、容灾等技术挑战，也都走到了现有技术的边界。所以咱们也在一直排汇新的技术和架构，心愿从体系与架构上升高咱们的技术复杂度，以抵制熵增。咱们在2021年底启动了云原生降级策略，降级云原生技术并不是为了技术而降级，而是切实面临微小的技术挑战。 1）首先咱们面临多语言的挑战：咱们以IM为例，IM的外围逻辑都是应用C++构建，然而咱们罕用的中间件三大件：存储、缓存、异步队列，其中缓存和异步队列在C++客户端上长期建设有余，导致IM长期在应用低版本。低版本因为长时间不足保护，常常会出现异常，比方队列假死、生产不均等，导致咱们本人不得不亲自上阵批改SDK的代码，以至最初难以使用到产品的新能力，妨碍IM服务能力的晋升。 2）其次是多产品多云的挑战：咱们以阿里云为例，数据库类目下的产品，从类别上就有关系数据库、NoSQL数据库、数仓等等，还有存储也是一样。对于咱们下层业务，其实绝大部分服务都只依赖了底层的CURD，这么多产品，每次对接一个产品都要开发一轮。配置零碎也是一样，弹内有Diamond，云上有Nacos、Mse，K8s有本人的Configmap等，而且这些配置零碎不像数据库有规范，而是百花齐放，然而这样却苦了咱们使用者。这些内容不是咱们的外围门路，节约大把工夫在各种产品接口的适配上，显著连累了钉钉的倒退。 3）最初就是通用的流量治理挑战：钉钉很多零碎都是最终统一的零碎，IM就是典型的最终统一零碎，这类零碎和强同步零碎在架构设计有一个显著的区别，强统一零碎如果遇到失败，必须要继续重试直到胜利，所以个别编程上都是重试+退却。然而最终统一零碎不是，这类零碎容许局部节点失败，不要妨碍其余流程，失败的流量通过一个异步盘旋的队列，将数据逐渐回放回来即可。这种盘旋须要借助异步队列，而且要设计各种生产机制，比方限速、比方抛弃等等，这是一个通用的逻辑，然而每个业务方或多或少都在实现本人的盘旋零碎，反复的造轮子。又比方各种故障注入，单元化路由流量等等，要想领有这个能力，团队不得不投入人力研发。在凑合架构复杂度上，咱们次要从两个维度来屏蔽复杂度。首先代码层面咱们抉择了DDD模式，咱们应用DDD分层外围是把对外零碎的依赖全副收拢到Infrastructure这一层，全副采纳纯虚函数(Interface)对外提供接口。屏蔽底层中间件差别和细节。在架构上采纳Sidecar的模式，相似于Dapr的思维，通过规范的GRPC和PB实现利用与中间件解耦。Sidecar中集成了各种中间件、配置零碎、灰度零碎等，等价实现了利用和中间件的解耦。上文中提到的不论是多语言挑战、多云多产品的挑战、反复造轮子等问题，都能很好的解决。 11.3互通网关 ：混合架构的基石 云上云下互通，或者说多个云账户VPC之间的互通， 咱们常见的有两种计划：1）其一是VPC间接买通，让多个VPC之间造成一个大的局域网，RealServer实现点对点互通；2）其一是两头搭建一个负载均衡器，通过裸露EIP实现互通。两个计划都有本人的优缺点。对于计划一：买通的VPC波及到IP布局，如果后期没有正当布局，后续很难买通；还有这种计划有水桶短板平安问题，一旦一个VPC被攻破，这张网也被攻破；然而对于外部的利用来说架构就比较简单，能够仅仅借助K8s DNS service就能做到服务发现。对于计划二：最大的毛病就是两头有一个集中式的负载平衡，须要申请独立的LB才可拜访；然而这种计划隔离性好。对于钉钉单元化来说，波及N个业务方，N * M个利用，对应X个VPC，要想VPC之间买通，简直没有可能性，而且VPC买通，还面临利用之间的安全性问题。要实现Geo之间互通，环境之间的隔离性是根本要求，与此同时，咱们也要思考到零碎的可扩展性，所以咱们必须要构建一套独立的流量网关，实现流量加密、寻址、转发等通用能力。钉钉互通网关是构建在Envoy之上的零碎，双向Ingress和Egress，反对GRPC和钉钉自研协定。具备流量治理、传输加密、单元寻址等能力。钉钉单元化借助互通网关的能力，再配合全局流控系统，咱们能够在多单元之间实现准确的流量管制和调度。 ...

本文由金蝶顺手记技术团队丁同舟分享。 1、引言跟挪动端IM中谋求数据传输效率、网络流量耗费等需要一样，顺手记客户端与服务端交互的过程中，对局部数据的传输大小和效率也有较高的要求，一般的数据格式如 JSON 或者 XML 曾经不能满足，因而决定采纳 Google 推出的 Protocol Buffers 以达到数据高效传输。本文将基于顺手记团队的Protobuf利用实际，分享了Protobuf的技术原理、上手实战等（本篇要分享的是技术原理），心愿对你有用。学习交换： 挪动端IM开发入门文章：《新手入门一篇就够：从零开发挪动端IM》开源IM框架源码：https://github.com/JackJiang2...（备用地址点此）（本文已同步公布于：http://www.52im.net/thread-41...） 2、系列文章本文是系列文章中的第 8 篇，本系列总目录如下：《IM通信协定专题学习(一)：Protobuf从入门到精通，一篇就够！》《IM通信协定专题学习(二)：疾速了解Protobuf的背景、原理、应用、优缺点》《IM通信协定专题学习(三)：由浅入深，从根上了解Protobuf的编解码原理》《IM通信协定专题学习(四)：从Base64到Protobuf，详解Protobuf的数据编码原理》《IM通信协定专题学习(五)：Protobuf到底比JSON快几倍？全方位实测！》《IM通信协定专题学习(六)：手把手教你如何在Android上从零应用Protobuf》（稍后公布..）《IM通信协定专题学习(七)：手把手教你如何在NodeJS中从零应用Protobuf》《IM通信协定专题学习(八)：金蝶顺手记团队的Protobuf利用实际(原理篇)》（* 本文）《IM通信协定专题学习(九)：金蝶顺手记团队的Protobuf利用实际(实战篇) 》（稍后公布..） 3、根本介绍Protocol buffers 为 Google 提出的一种跨平台、多语言反对且开源的序列化数据格式。绝对于相似的 XML 和 JSON，Protocol buffers 更为玲珑、疾速和简略。其语法目前分为proto2和proto3两种格局。绝对于传统的 XML 和 JSON， Protocol buffers 的劣势次要在于：更加小、更放慢。对于自定义的数据结构，Protobuf 能够通过生成器生成不同语言的源代码文件，读写操作都十分不便。 假如当初有上面 JSON 格局的数据:{"id":1,"name":"jojo","email":"123@qq.com",}应用 JSON 进行编码，得出byte长度为43的的二进制数据：7b226964 223a312c 226e616d 65223a22 6a6f6a6f 222c2265 6d61696c 223a2231 32334071 712e636f 6d227d如果应用 Protobuf 进行编码，失去的二进制数据仅有20个字节：0a046a6f 6a6f1001 1a0a3132 33407171 2e636f6d 4、编码原理绝对于基于纯文本的数据结构如 JSON、XML等，Protobuf 可能达到玲珑、疾速的最大起因在于其独特的编码方式。《Protobuf从入门到精通，一篇就够！》对 Protobuf 的 Encoding 作了很好的解析。例如：对于int32类型的数字，如果很小的话，protubuf 因为采纳了Varint形式，能够只用 1 个字节示意。 5、Varint原理Varint 中每个字节的最高位 bit 示意此 byte 是否为最初一个 byte 。1 示意后续的 byte 也示意该数字，0 示意此 byte 为完结的 byte。 ...

融云再度荣膺多项大奖，产品服务播种多方认可。 雷锋网近期颁布 2022【飞天入地出海】年度科技榜，融云获即时通讯云翻新产品标杆奖；产业家今日公布 2022 年度【产业数字化金铲奖】，融云登上【中国产业数字化领军企业榜单】云计算模块、协同办公模块，融云服务案例更是荣获【产业数字化案例金奖】。“飞天”意在前沿科技，“入地”强调可用性、可行性和可复制性，“出海”则指向商业全球化。旧商业秩序正在被突破，“飞天、入地、出海”给全新商业秩序的建设过程提出了一种下半场实践。 雷峰网年度科技榜已历经六届评比，2022 年榜单以“飞天入地出海”命名，心愿从更业余和丰盛的维度，找出那些最具生命力的产品和企业。 全新的商业秩序下，科技企业当以全球化商业竞争为锚，以外围技术创新为志，以千行百业的实际落地为基，飞天入地，无远弗届。 这与融云的倒退理念高度符合，融云孵化自中国移动飞信团队，业内独创即时通讯云服务概念，专一通信技术和业务十余年，是国内为数不多领有承载近 2 亿日活成功经验的核心技术团队之一。 创建以来，融云始终保持走在「专一、业余」的技术进阶之路上，同时将核心技术与各类业务场景相结合，推出适配千行百业、贴近市场的产品和服务，并以一站式全生态出海解决方案反对中国创业者走上全球化倒退路线，让中国的产品与服务触达更多人群。 2022 年，融云重磅推出了“百幄”政企数智办公平台，将即时通讯云服务开创者的技术劣势与 PaaS 服务商的门路劣势相结合，为政府及公共事业、公安军工、金融保险、交通、能源电力等行业客户提供高并发、高可用，组件灵便，平安可信的数智办公解决方案。 正因如此，融云胜利登榜雷锋网的 2022 年度科技榜，荣获即时通讯云翻新产品标杆奖。 产业数字化，曾经成为当代中国的主旋律。 今日，产业家联结数字化报、IT 桔子重磅公布第二届【产业数字化金铲奖】，独特记录贬责过来一年中国产业数字化过程中最有价值的企业品牌、实际案例。 融云作为以通信服务助力产业数字化的前排标兵和布道者，登上【2022 中国产业数字化领军企业榜单】云计算模块，2022 年重磅上线的政企数智办公平台“融云百幄”则登上协同办公模块。 另外，融云为泰隆银行打造的协同办公产品还荣获【产业数字化案例金奖】。早在 2018 年左右，融云便开始以通信中台能力与搭档单干赋能政企协同办公场景。 在多年服务过程中，融云服务从简略的 IM 即时通讯能力调用，逐步随着客户的需要向业务场景深刻，提供残缺封装的办公、会议、通讯录、工作台、近程导办、超级群六大场景化 Kit，供政企客户依据需要灵便选用，助力政企行业实现平安、高效的数字化能力建设。 多年积淀，深刻业务，融云政企办公解决方案备受好评、屡获点赞。

近期，融云又播种了来自行业和媒体的一波集中“点赞”，别离是——产品方面来自掘金的年度翻新产品奖；技术方面来自思否的年度技术团队、掘金的人气技术团队荣誉；出海方面入选爱剖析出海通信厂商全景报告。打 Call 组团来袭，融云彰显实力。 超级群年度翻新产品 掘金引力榜的年度翻新产品 Top10 特地颁发给了融云超级群产品，表彰其作为业内首款超级群 PaaS 产品的新陈代谢和对 IM 即时通讯产品图谱的补齐欠缺。 作为 IM 即时通讯云服务的创始品牌，融云超级群的推出令开发者眼前一亮，让行业看到即时通讯这个通信外围能力，在经典之外的焕新能力。随着落地实际的倒退，挪动办公的演进，即时通讯在各个领域大放异彩。 融云 IM 以高并发、高可用、平安稳固的性能劣势成为开发者和政企客户构建各类利用的首选产品。在互联网畛域，社交泛娱乐场景不断丰富，挑战着 IM 服务的创新能力。在原有群组、聊天室等之外，产生了服务趣味社区、游戏社区、元宇宙社交等场景的超级群产品需要。 而在政企畛域，超级群产品也与党建学习、企业社区、网格治理等多个场景非常适配。融云超级群的首发推出，适时填补了行业空白，领先其余服务商一个身位，成为构建各类社区产品的第一抉择。 IM、RTC 技术年度团队 2022 年，融云在技术方面仍旧继续精进，且立足商业逻辑，撑持业务场景，围绕核心技术走出了一条「专一、业余」的技术进阶之旅。此外，融云踊跃投入开源生态服务，宽泛参加技术社区建设，在国内各类技术公布通信核心技术文章百余篇，少数内容取得技术媒体的置顶、举荐，更有多篇文章播种开发者的珍藏、点赞。 继获 2022 中国技术先锋年度评比「中国技术品牌影响力企业」奖后，融云再度取得技术社区思否和掘金的年度技术团队、人气技术团队荣誉。 出海场景业余通信厂商 2022 年，融云在 IM+RTC+X “全”通信能力和笼罩寰球 233 个国家和地区的通信网络根底上，推出一站式全生态出海解决方案，笼罩“社交+Dating”“社交+社区”“社交+游戏”“社交+音频”“社交+视频”“社交+虚构形象”等热门场景，让开发者的业务发展更加简略高效。 同时，融云还携手白鲸出海公布《2022 社交泛娱乐出海白皮书》，对中国厂商出海的 4 个次要指标市场进行察看梳理，揭示价值洼地的造成因素及胜利案例的参考样板。 鉴于其出海服务的多年积攒和行业奉献，融云近期入选爱剖析出海通信厂商全景报告的出海通信厂商全景地图。

1、前言Protobuf是Google开源的一种混合语言数据规范，已被各种互联网我的项目大量应用。 Protobuf最大的特点是数据格式领有极高的压缩比，这在挪动互联时代是极具价值的（因为挪动网络流量到目前为止依然低廉的），如果你的APP能比竞品更省流量，无疑这也将成为您产品的亮点之一。 当初，尤其IM、音讯推送这类利用中，Protobuf的利用更是十分宽泛，基于它的优良体现，微信和手机QQ这样的支流IM利用也早已在应用它。当初随着WebSocket协定的越来越成熟，浏览器反对的越来越好，Web端的即时通讯利用也逐步领有了真正的“实时”能力，相干的技术和利用也是层出不穷，而Protobuf也同样能够用在WebSocket的通信中。 而且目前比拟沉闷的WebSocket开源计划中，都是用NodeJS实现的，比方：socket.io和sockjs都是如此，因此本文介绍Protobuf在NodeJS上的应用，也恰是时候。 学习交换： 挪动端IM开发入门文章：《新手入门一篇就够：从零开发挪动端IM》开源IM框架源码：https://github.com/JackJiang2...（备用地址点此）（本文同步公布于：http://www.52im.net/thread-41...） 2、系列文章本文是系列文章中的第 7 篇，本系列总目录如下：《IM通信协定专题学习(一)：Protobuf从入门到精通，一篇就够！》《IM通信协定专题学习(二)：疾速了解Protobuf的背景、原理、应用、优缺点》《IM通信协定专题学习(三)：由浅入深，从根上了解Protobuf的编解码原理》《IM通信协定专题学习(四)：从Base64到Protobuf，详解Protobuf的数据编码原理》《IM通信协定专题学习(五)：Protobuf到底比JSON快几倍？全方位实测！》《IM通信协定专题学习(六)：手把手教你如何在Android上从零应用Protobuf》（稍后公布..）《IM通信协定专题学习(七)：手把手教你如何在NodeJS中从零应用Protobuf》（* 本文）《IM通信协定专题学习(八)：金蝶顺手记团队的Protobuf利用实际(原理篇) 》（稍后公布..）《IM通信协定专题学习(九)：金蝶顺手记团队的Protobuf利用实际(实战篇) 》（稍后公布..） 3、Protobuf是个什么鬼？Protocol Buffer（下文简称Protobuf）是Google提供的一种数据序列化协定，上面是我从网上找到的Google官网对Protobuf的定义：Protocol Buffers 是一种轻便高效的结构化数据存储格局，能够用于结构化数据序列化，很适宜做数据存储或 RPC 数据交换格局。它可用于通信协定、数据存储等畛域的语言无关、平台无关、可扩大的序列化构造数据格式。目前提供了 C++、Java、Python 三种语言的 API。 情理咱们都懂，而后并没有什么卵用，看完下面这段定义，对于Protobuf是什么我还是一脸懵逼。 4、NodeJS开发者为何要跟Protobuf打交道作为JavaScript开发者，对咱们最敌对的数据序列化协定当然是赫赫有名的JSON啦！咱们本能的会想protobuf是什么鬼？还我JSON！这就要说到protobuf的历史了。Protobuf由Google出品，08年的时候Google把这个我的项目开源了，官网反对C++，Java，C#，Go和Python五种语言，然而因为其设计得很简略，所以衍生出很多第三方的反对，基本上罕用的PHP，C，Actoin Script，Javascript，Perl等多种语言都已有第三方的库。 因为protobuf协定相较于之前风行的XML更加的简洁高效(前面会提到这是为什么)，因而许多后盾接口都是基于protobuf定制的数据序列化协定。而作为NodeJS开发者，跟C++或JAVA编写的后盾服务接口打交道那是粗茶淡饭的事儿，因而咱们很有必要把握protobuf协定。 为什么说应用应用相似protobuf的二进制协定通信更好呢？ 1）二进制协定对于电脑来说更容易解析，在解析速度上是http这样的文本协定不可比较的；2）有tcp和udp两种抉择，在一些场景下，udp传输的效率会更高；3）在后盾开发中，后盾与后盾的通信个别就是基于二进制协定的。甚至某些native app和服务器的通信也抉择了二进制协定（例如腾讯视频）。但因为web前端的存在，后盾同学往往须要顺便开发保护一套http接口专供咱们应用，如果web也能应用二进制协定，能够节俭许多后盾开发的老本。在大公司，最重要的就是优化效率、节省成本，因而二进制协定显著优于http这样的文本协定。上面举两个简略的例子，应该有助于咱们了解protobuf。 5、抉择反对protobuf的NodeJS第三方模块以后在Github上比拟热门的反对protobuf的NodeJS第三方模块有如下3个：  依据star数和文档欠缺水平两方面综合思考，咱们决定抉择protobuf.js（前面2个的地址：Google protobuf js、protocol-buffers）。 6、应用 Protobuf 和NodeJS开发一个简略的例子6.1 概述我打算应用 Protobuf 和NodeJS开发一个非常简略的例子程序。该程序由两局部组成：第一局部被称为 Writer，第二局部叫做 Reader。Writer 负责将一些结构化的数据写入一个磁盘文件，Reader 则负责从该磁盘文件中读取结构化数据并打印到屏幕上。筹备用于演示的结构化数据是 HelloWorld，它蕴含两个根本数据：1）ID：为一个整数类型的数据；2）Str：这是一个字符串。6.2 书写.proto文件首先咱们须要编写一个 proto 文件，定义咱们程序中须要解决的结构化数据，在 protobuf 的术语中，结构化数据被称为 Message。proto 文件十分相似 java 或者 C 语言的数据定义。代码清单 1 显示了例子利用中的 proto 文件内容。清单 1. proto 文件：package lm;message helloworld{   required int32     id = 1;  // ID   required string    str = 2;  // str   optional int32     opt = 3;  //optional field}一个比拟好的习惯是认真对待 proto 文件的文件名。比方将命名规定定于如下：packageName.MessageName.proto在上例中，package 名字叫做 lm，定义了一个音讯 helloworld，该音讯有三个成员，类型为 int32 的 id，另一个为类型为 string 的成员 str。opt 是一个可选的成员，即音讯中能够不蕴含该成员。1、2、3这几个数字是这三个字段的惟一标识符，这些标识符是用来在音讯的二进制格局中辨认各个字段的，一旦开始应用就不可能再扭转。6.3 编译 .proto 文件咱们能够应用protobuf.js提供的命令行工具来编译 .proto 文件。用法:# pbjs <filename> [options] [> outFile]咱们来看看options:  --help, -h        Show help  [boolean] 查看帮忙  --version, -v     Show version number  [boolean] 查看版本号  --source, -s      Specifies the source format. Valid formats are:                       json       Plain JSON descriptor                       proto      Plain .proto descriptor指定起源文件格式，能够是json或proto文件。  --target, -t      Specifies the target format. Valid formats are:                       amd        Runtime structures as AMD module                       commonjs   Runtime structures as CommonJS module                       js         Runtime structures                       json       Plain JSON descriptor                       proto      Plain .proto descriptor指定生成文件格式，能够是合乎amd或者commonjs标准的js文件，或者是单纯的js/json/proto文件。  --using, -u       Specifies an option to apply to the volatile builder                    loading the source, e.g. convertFieldsToCamelCase.  --min, -m         Minifies the output.  [default: false] 压缩生成文件  --path, -p        Adds a directory to the include path.  --legacy, -l      Includes legacy descriptors from google/protobuf/ if                    explicitly referenced.  [default: false]  --quiet, -q       Suppresses any informatory output to stderr.  [default: false]  --use, -i         Specifies an option to apply to the emitted builder                    utilized by your program, e.g. populateAccessors.  --exports, -e     Specifies the namespace to export. Defaults to export                    the root namespace.  --dependency, -d  Library dependency to use when generating classes.                    Defaults to 'protobufjs' for CommonJS, 'ProtoBuf' for                    AMD modules and 'dcodeIO.ProtoBuf' for classes.重点关注- -target就好，因为咱们是在Node环境中应用，因而抉择生成合乎commonjs标准的文件。命令如下：# ./pbjs ../../lm.message.proto  -t commonjs > ../../lm.message.js失去编译后的合乎commonjs标准的js文件：module.exports = require("protobufjs").newBuilder({})'import'.build();6.4 编写 Writervar HelloWorld = require('./lm.helloworld.js')'lm';var fs = require('fs');// 除了这种传入一个对象的形式， 你也能够应用get/set 函数用来批改和读取结构化数据中的数据成员varhw = newHelloWorld({    'id': 101,    'str': 'Hello'})varbuffer = hw.encode();fs.writeFile('./test.log', buffer.toBuffer(), function(err) {    if(!err) {        console.log('done!');    }});6.5 编写Readervar HelloWorld = require('./lm.helloworld.js')'lm';var fs = require('fs');var buffer = fs.readFile('./test.log', function(err, data) {    if(!err) {        console.log(data); // 来看看Node里的Buffer对象长什么样子。        var message = HelloWorld.decode(data);        console.log(message);    }})6.6 运行后果因为咱们没有在Writer中给可选字段opt字段赋值，因而Reader读出来的opt字段值为null。这个例子自身并无意义，但只有您稍加批改就能够将它变成更加有用的程序。比方将磁盘替换为网络 socket，那么就能够实现基于网络的数据交换工作。而存储和替换正是 Protobuf 最无效的应用领域。 ...

本文由钉钉技术专家尹启绣分享，有订正和从新排版。 1、引言短短的几年工夫，钉钉便迅速成为一款国民级利用，倒退速度堪称迅猛。IM作为钉钉最外围的性能，每天须要反对海量企业用户的沟通，同时还通过 PaaS 模式为淘宝、高德等 App 提供根底的即时通讯能力，是日均千亿级音讯量的 IM 平台。在钉钉的IM中，咱们通过 RocketMQ实现了零碎解耦、异步削峰填谷，还通过定时音讯实现分布式定时工作等高级个性。同时与 RocketMQ 深刻共创，一直优化解决了很多RocketMQ自身的问题，并且孵化出 POP 生产模式等新个性，使 RocketMQ 可能完满反对对性能稳定性和时延要求十分高的 IM 零碎。本文将为你分享这些内容。 学习交换： 挪动端IM开发入门文章：《新手入门一篇就够：从零开发挪动端IM》开源IM框架源码：https://github.com/JackJiang2...（备用地址点此）（本文已同步公布于：http://www.52im.net/thread-41...） 2、系列文章本文是系列文章的第9篇，总目录如下：《阿里IM技术分享(一)：企业级IM王者——钉钉在后端架构上的过人之处》《阿里IM技术分享(二)：闲鱼IM基于Flutter的挪动端跨端革新实际》《阿里IM技术分享(三)：闲鱼亿级IM音讯零碎的架构演进之路》《阿里IM技术分享(四)：闲鱼亿级IM音讯零碎的牢靠投递优化实际》《阿里IM技术分享(五)：闲鱼亿级IM音讯零碎的及时性优化实际》《阿里IM技术分享(六)：闲鱼亿级IM音讯零碎的离线推送达到率优化》《阿里IM技术分享(七)：闲鱼IM的在线、离线聊天数据同步机制优化实际》《阿里IM技术分享(八)：深度解密钉钉即时消息服务DTIM的技术设计》《阿里IM技术分享(九)：深度揭密RocketMQ在钉钉IM零碎中的利用实际》（* 本文） 3、钉钉IM面临的微小技术挑战3.1 概述钉钉作为企业级 IM 领先者，面临着微小的技术挑战。市面上DAU过亿的App里，只有钉钉是2B产品，咱们不仅须要和其余 2C 产品一样，反对海量用户的低时延、高并发、高性能、高可用，还需保障企业级用户在应用钉钉时可能晋升沟通协同效率。下图是概括的是钉钉的次要能力： 3.2 技术挑战1：ToB与ToC的差别作为企业级利用，须要保障帮忙用户晋升沟通体验。ToB 的工作沟通和 ToC 的场景生存沟通存在较大差别， ToC的IM产品比方微信，在有残缺的关系链后，只需满足大部分用户需要即可。然而微信的很多体验其实并不敌对：比方聊天音讯中的视频图片在固定工夫内没有关上则会无奈下载，卸载重装之后聊天记录全副失落。而 ToB 场景下：聊天记录是十分重要的内容，钉钉为保障用户音讯不失落，提供了多端同步和音讯云端存储的能力，用户任意换端都能查看残缺的聊天记录。在工作过程中，大量会议是工作效率杀手，钉钉还提供了已读、Ding 等效率套件，为工作沟通提供新选项。3.3 技术挑战2：平安要求高在ToB 的工作场景下，用户对信息安全要求十分高，信息安全是企业的生命线。钉钉提供了人和组织架构买通的工作群，用户来到组织后主动退出企业工作群，这样就很好地保障了企业信息的平安。同时，在曾经反对的全链路加密能力上提供了三方加密能力，能够最大水平保障企业用户的信息安全性。3.4 技术挑战3：稳定性要求高企业用户对稳定性的要求也十分高，如果钉钉呈现故障，深度应用钉钉的企业都会受到微小影响。因而，钉钉 IM 零碎在稳定性上也做了十分深刻的建设，架构上对依赖和流量做了深刻治理，外围能力所有依赖都为双倍。比方尽管 RocketMQ 曾经十分稳固，也没有产生过故障，然而对 RocketMQ 可能呈现故障的产品仍然做了很好的爱护，应用 RocketMQ 定时音讯和沉积能力做热点治理和流量防护，让零碎面对大规模流量时能从容应对，并且建设了异地多活和可弹性扩缩容能力，疫情期间很好地保障了学生们的在线课堂。在稳定性机制上，常态化容灾演练、突袭演练、自动化衰弱巡检等也能很好地保障线上稳定性。比方波浪式流量就是在做断网演练时发现。3.5 技术挑战4：业务多样性针对不同行业的业务多样性，还要尽可能地满足用户的通用性需要，比方万人群、全员群等，目前钉钉曾经做到可能反对 10 万人级别的群。更多的业务需要将依赖于咱们形象出的通用凋谢能力，将 IM 能力尽可能地凋谢给企业和三方 ISV，使得不同状态的业务都能在钉钉平台上失去满足 。 4、音讯队列在钉钉IM零碎中的重要作用4.1 概述在如此丰盛的企业级能力下，钉钉IM要与微信等 ToC 产品一样，反对亿级用户低时延沟通，零碎架构须要具备高并发、高性能、高可用的能力，挑战十分之大。IM 自身是异步化沟通零碎，与散会或者电话沟通相比，让沟通单方异步解决音讯可能缩小打断次数，晋升沟通效率。这种异步的个性和音讯队列的能力很符合，音讯队列能够很好地帮忙 IM 实现异步化解耦、失败重试、削峰填谷等能力。这里，咱们以钉钉IM零碎最外围的发消息和已读链路简化流程（如下图所示），来具体阐明音讯队列在零碎里的重要作用。 4.2 发消息链路钉钉IM零碎的发消息链路流程如下：1）处于登录状态的钉钉用户发送一条音讯时，首先会将申请发送到 receiver 利用；2）为保障发消息体验和成功率，receiver 利用只做这条音讯是否发送的校验，其余如音讯入库、接收者推送等都交由上游利用实现；3）校验实现之后将音讯投递给音讯队列，胜利后即可返回给用户；4）音讯发送胜利，processor 会从音讯队列里订阅到这条音讯，并对音讯进行入库解决，再通过音讯队列将音讯交给同步服务 syncserver 做解决，将音讯同步给在线接收者。上述过程中，对于不在线的用户：能够通过音讯队列将音讯推给离线 push 零碎。离线 push 零碎能够对接接苹果、华为、小米等推送零碎进行离线推送。用户发消息过程中的每一步，失败后都可通过音讯队列进行重试解决。如 processor 入库失败，可将音讯打回音讯队列，持续盘旋解决，达到最终统一。同时，能够在订阅的过程中对生产限速，防止线上突发峰值给零碎带来灾难性的结果。4.3 音讯已读链路钉钉IM零碎的音讯已读链路流程如下：1）用户对一条音讯做读操作后，会发送申请到已读服务；2）已读服务收到申请后，间接将申请放到音讯队列进行异步解决，同时能够达到削峰填谷的目标；3）已读服务解决完之后，将已读事件推给同步服务，让同步服务将已读事件推送给音讯发送者。从下面两个链路能够看出，音讯队列是 IM 零碎里十分重要的组成部分。 ...

1、引言在社区中，分享了很多篇基于Netty编写的IM聊天入门文章（比方《跟着源码学IM》系列、《基于Netty，从零开发IM》系列等），在这些文章中分享了各种IM通信算法原理和性能逻辑的实现。然而这样简略的IM聊天零碎是比拟容易被窃听的，如果想要在外面说点悄悄话是不太平安的。怎么办呢？学过密码学的敌人可能就想到了一个解决办法，聊天的时候对音讯加密，解决的时候再对音讯进行解密。是的，情理就是这样。但密码学自身的实践就很简单，加上相干的常识和概念又太多太杂，对于IM入门者来说，想要疾速理清这些概念并实现适合的加解密计划，是比拟头疼的。本文正好借此机会，以Netty编写的IM聊天加密为例，为入门者理清什么是PKI体系、什么是SSL、什么是OpenSSL、以及各类证书和它们间的关系等，并在文末附上简短的Netty代码实示例，心愿能助你通俗易懂地疾速了解这些常识和概念！补充阐明：本文为了让文章内容尽可能长篇累牍、通俗易懂，尽量不深入探讨各个技术常识和概念，感兴趣的读者能够自行查阅相干材料进一步学习。 学习交换： 挪动端IM开发入门文章：《新手入门一篇就够：从零开发挪动端IM》开源IM框架源码：https://github.com/JackJiang2...（备用地址点此）（本文已同步公布于：http://www.52im.net/thread-41...） 2、相干文章《即时通讯平安篇（一）：正确地了解和应用Android端加密算法》《即时通讯平安篇（二）：探讨组合加密算法在IM中的利用》《即时通讯平安篇（三）：罕用加解密算法与通信平安解说》《即时通讯平安篇（四）：实例剖析Android中密钥硬编码的危险》《即时通讯平安篇（五）：对称加密技术在Android平台上的利用实际》《即时通讯平安篇（六）：非对称加密技术的原理与利用实际》《即时通讯平安篇（十）：IM聊天系统安全伎俩之通信连贯层加密技术》《即时通讯平安篇（十一）：IM聊天系统安全伎俩之传输内容端到端加密技术》 3、什么是PKI？咱们须要先理解一下公钥和私钥的加密规范体系PKI。3.1 基本概念PKI的全称是Public Key Infrastructure，是指反对公钥管理体制的基础设施，提供甄别、加密、完整性和不可否认性服务。艰深讲：PKI是集机构、零碎（硬件和软件）、人员、程序、策略和协定为一体，利用公钥概念和技术来实现和提供平安服务的、普适性的平安基础设施。在公钥明码中，发送者用公钥（加密密钥）加密，接收者用私钥（解密密钥）解密。公钥个别是公开的，不再放心窃听，这解决了对称明码中的密钥配送问题。然而接收者仍然无奈判断收到的公钥是否非法（有可能是中间人混充的）。事实上，仅靠公钥明码自身，无奈进攻中间人攻打。于是，须要（认证机构）对公钥进行签名，从而确认公钥没有被篡改。加了数字签名的公钥称为公钥证书，个别简称证书。有了证书来认证，能够无效进攻中间人攻打，随之带来了一系列非技术性工作。例如：谁来发证书？如何发证书？不同机构的证书怎么互认？纸质证书作废容易，数字证书如何作废？解决这些问题，须要制订对立的规定，即PKI体系。PKI体系是通过颁发、治理公钥证书的形式为终端用户提供服务的零碎，最外围的元素是证书。围绕证书形成了PKI体系的因素：1）应用PKI的用户；2）颁发证书的机构（Certificate Authority，CA）；3）保留证书的仓库。总之：PKI是一个总称，既包含定义PKI的根底规范，也包含PKI的利用规范。3.2 PKI体系现状事实上PKI曾经有两代了。第一代的PKI规范次要是由美国RSA公司的公钥加密规范PKCS、国际电信联盟的ITU-T X.509、IETF的X.509、WAP和WPKI等规范组成。然而因为第一代PKI规范是基于形象语法符号ASN.1进行编码的，实现起来比较复杂和艰难，所以产生了第二代PKI规范。第二代PKI规范是由微软、VeriSign和webMethods三家公司在2001年公布的基于XML的密钥治理标准也叫做XKMS。事实上当初CA核心应用的最广泛的标准还是X.509系列和PKCS系列。X.509系列次要由X.209、X.500和X.509组成，其中X.509是由国际电信联盟（ITU-T）制订的数字证书规范。在X.500根底上进行了性能加强，X.509是在1988年公布的。X.509证书由用户公共密钥和用户标识符组成。此外还包含版本号、证书序列号、CA标识符、签名算法标识、签发者名称、证书有效期等信息。而PKCS是美国RSA公司的公钥加密规范，包含了证书申请、证书更新、证书作废表公布、扩大证书内容以及数字签名、数字信封的格局等方面的一系列相干协定。它定义了一系列从PKCS#1到PKCS#15的规范。其中最罕用的是PKCS#7、PKCS#12和PKCS#10。PKCS#7 是音讯申请语法，罕用于数字签名与加密，PKCS#12是集体音讯替换与打包语法次要用来生成公钥和私钥（题外话：iOS程序员对PKCS#12不生疏，在实现APNs离线消推送时就须要导出.p12证实，正是这个）。PKCS#10是证书申请语法。 4、什么是SSL？4.1 基本概念SSL（全称 Secure Socket Layer）安全套接层是网景公司（Netscape）率先采纳的网络安全协定。它是在传输通信协议（TCP/IP）上实现的一种平安协定，采纳公开密钥技术。艰深地说：SSL被设计成应用TCP来提供一种牢靠的端到端的平安服务，它不是单个协定，而是二层协定。低层是SSL记录层，用于封装不同的下层协定，另一层是被封装的协定，即SSL握手协定，它能够让服务器和客户机在传输利用数据之前，协商加密算法和加密密钥，客户机提出本人可能反对的全副加密算法，服务器抉择最适宜它的算法。SSL特点是：它与应用层协定独立无关。下层的应用层协定（例如：HTTP、FTP、Telnet等）能通明的建设于SSL协定之上。SSL协定在应用层协定通信之前就曾经实现加密算法、通信密钥的协商以及服务器认证工作。在此之后应用层协定所传送的数据都会被加密，从而保障通信的私密性。4.2 与TLS的关系SSL是网景公司（Netscape）设计，但IETF将SSL作了标准化，即RFC2246，并将其称为TLS（Transport Layer Security），其最新版本是RFC5246、版本1.2。实际上：TLS是IETF在SSL3.0根底上设计的，相当于SSL的后续版本。所以咱们通常都是SSL/TLS放一起说。 5、什么是OpenSSL？5.1 基本概念 OpenSSL是一个凋谢源代码的软件库，应用程序能够应用这个包来进行平安通信，它包含代码、脚本、配置和过程的汇合。例如：如果您正在编写一个须要简单平安加密的软件，那么只有增加一个平安加密库才有意义，这样您就不用本人编写一大堆简单的加解密函数（而且密码学自身很简单，要写好它们并不容易）。其次要库是以 C 语言所写成，实现了根本的加密性能，实现了 SSL 与 TLS 协定。OpenSSL整个软件包大略能够分成三个次要性能局部：1）SSL协定库；2）应用程序；3）明码算法库。OpenSSL的目录构造天然也是围绕这三个性能局部进行布局的。OpenSSL 能够运行在 OpenVMS、 Microsoft Windows 以及绝大多数类 Unix 操作系统上。5.2 具体来说密钥和证书治理是PKI的一个重要组成部分，OpenSSL为之提供了丰盛的性能，反对多种规范。OpenSSL实现了ASN.1的证书和密钥相干规范，提供了对证书、公钥、私钥、证书申请以及CRL等数据对象的DER、PEM和BASE64的编解码性能。OpenSSL提供了产生各种公开密钥对和对称密钥的办法、函数和应用程序，同时提供了对公钥和私钥的DER编解码性能。并实现了私钥的PKCS#12和PKCS#8的编解码性能。OpenSSL在规范中提供了对私钥的加密爱护性能，使得密钥能够平安地进行存储和散发。在此基础上，OpenSSL实现了对证书的X.509规范编解码、PKCS#12格局的编解码以及PKCS#7的编解码性能。并提供了一种文本数据库，反对证书的治理性能，包含证书密钥产生、申请产生、证书签发、撤消和验证等性能。5.3 倒退历程OpenSSL 打算在 1998 年开始，其指标是创造一套自在的加密工具，在互联网上应用。OpenSSL 以 Eric Young 以及 Tim Hudson 两人开发的 SSLeay 为根底，随着两人返回 RSA 公司任职，SSLeay 在 1998 年 12 月进行开发。因而在 1998 年 12 月，社群另外分支出 OpenSSL，持续开发上来。▲ 上图为 Tim HudsonOpenSSL 治理委员会以后由 7 人组成有 13 个开发人员具备提交权限（其中许多人也是 OpenSSL 治理委员会的一部分）。只有两名全职员工（研究员），其余的是志愿者。该我的项目每年的估算不到 100 万美元，次要依附捐款。 TLS 1.3 的开发由 Akamai 资助。5.4 下载办法OpenSSL能够从其官网上下载，地址是：https://www.openssl.org/source/，感兴趣的读者能够自行下载安装钻研。 ...

本文由陶文分享，InfoQ编辑公布，有订正和改变。 1、前言本系列的前几篇次要是从各个角度解说Protobuf的基本概念、技术原理这些内容，但回过头来看，比照JSON这种事实上的数据协定工业规范，Protobuf到底性能到底高多少？本篇将以Protobuf为基准，比照市面上的一些支流的JSON解析库，通过全方位测试来证实给你看看Protobuf到底比JSON快几倍。 学习交换： 挪动端IM开发入门文章：《新手入门一篇就够：从零开发挪动端IM》开源IM框架源码：https://github.com/JackJiang2...（备用地址点此）（本文已同步公布于：http://www.52im.net/thread-40...） 2、系列文章本文是系列文章中的第 5 篇，本系列总目录如下：《IM通信协定专题学习(一)：Protobuf从入门到精通，一篇就够！》《IM通信协定专题学习(二)：疾速了解Protobuf的背景、原理、应用、优缺点》《IM通信协定专题学习(三)：由浅入深，从根上了解Protobuf的编解码原理》《IM通信协定专题学习(四)：从Base64到Protobuf，详解Protobuf的数据编码原理》《IM通信协定专题学习(五)：Protobuf到底比JSON快几倍？全方位实测！》（* 本文）《IM通信协定专题学习(六)：手把手教你如何在Android上从零应用Protobuf》（稍后公布..）《IM通信协定专题学习(七)：手把手教你如何在NodeJS中从零应用Protobuf》（稍后公布..）《IM通信协定专题学习(八)：金蝶顺手记团队的Protobuf利用实际(原理篇) 》（稍后公布..）《IM通信协定专题学习(九)：金蝶顺手记团队的Protobuf利用实际(实战篇) 》（稍后公布..） 3、写在后面拿 JSON 烘托 Protobuf 的文章真的太多了，常常能够看到文章中写道：“快来用 Protobuf 吧，JSON 太慢啦”。然而 Protobuf 真的有吹的那么牛么？我感觉从 JSON 切换到 Protobuf 怎么也得快一倍吧，要不然对不起付出的切换老本。然而，DSL-JSON 的家伙们竟然说在Java语言里 JSON 和那些二进制的编解码格局有得一拼，这太让人诧异了！尽管你可能会说，咱们能不必苹果和梨来做比拟了么？两个货色基本用处齐全不一样好么。咱们用 Protobuf 是冲着跨语言无歧义的 IDL 的去的，才不仅仅是因为性能呢。 好吧，这个我批准。然而依然有那么多人自觉置信，Protobuf 肯定会快很多，我感觉还是有必要彻底终结一下这个对于速度的传说。DSL-JSON 的博客里只给了他们的测试论断，然而没有给出任何起因，以及优化的细节，这很难让人服气数据是实在的。你要说 JSON 比二进制格局更快，真的是很反直觉的事件。略微推敲一下这个问题，就能够列出好几个 Protobuf 应该更快的理由。比方： 1）更容容易绑定值到对象的字段上。JSON 的字段是用字符串指定的，相比之下字符串比对应该比基于数字的字段tag更耗时；2）JSON 是文本的格局，整数和浮点数应该更占空间而且更费时；3）Protobuf 在注释前有一个大小或者长度的标记，而 JSON 必须全文扫描无奈跳过不须要的字段。然而仅凭这几点是不是就能够盖棺定论了呢？未必。也有相同的观点： 1）如果字段大部分是字符串，占到决定性因素的因素可能是字符串拷贝的速度，而不是解析的速度。在这个评测中，咱们看到不少库的性能是十分靠近的。这是因为测试数据中大部分是由字符串形成的；2）影响解析速度的决定性因素是分支的数量。因为分支的存在，解析依然是一个实质上串行的过程。尽管Protobuf里没有[] 或者 {}，然而依然有相似的分支代码的存在。如果没有这些分支的存在，解析不过就是一个 memcpy 的操作而已。只有 Parabix 这样的技术才有革命性的意义，而 Protobuf 相比 JSON 只是改进而非反动；3）兴许 Protobuf 是一个实践上更快的格局，然而实现它的库并不一定就更快。这取决于优化做得好不好，如果有不必要的内存调配或者反复读取，理论的速度未必就快。有多个 benchmark 都把 DSL-JSON列到前三名里，有时甚至比其余的二进制编码更快。通过我仔细分析，起因出在了这些 benchmark 对于测试数据的形成抉择上。因为结构测试数据很麻烦，所以个别评测只会对雷同的测试数据，去测不同的库的实现。这样就使得后果是重大偏向于某种类型输出的。比方 https://github.com/eishay/jvm... 抉择的测试数据的构造是这样的：message Image {  required string uri = 1;      //url to the thumbnail  optional string title = 2;    //used in the html ALT  required int32 width = 3;     // of the image  required int32 height = 4;    // of the image  enum Size {    SMALL = 0;    LARGE = 1;  }  required Size size= 5;       // of the image (in relative terms, provided by cnbc for example)} message Media {  required string uri = 1;      //uri to the video, may not be an actual URL  optional string title = 2;    //used in the html ALT  required int32 width = 3;     // of the video  required int32 height = 4;    // of the video  required string format = 5;   //avi, jpg, youtube, cnbc, audio/mpeg formats ...  required int64 duration = 6;  //time in miliseconds  required int64 size= 7;      //file size  optional int32 bitrate = 8;   //video  repeated string person = 9;   //name of a person featured in the video  enum Player {    JAVA = 0;    FLASH = 1;  }  required Player player = 10;   //in case of a player specific media  optional string copyright = 11;//media copyright} message MediaContent {  repeated Image image = 1;  required Media media = 2;}无论怎么去结构 small/medium/large 的输出，benchmark 依然是存在特定倾向性的。而且这种倾向性是不明确的。比方 medium 的输出，到底阐明了什么？medium 对于不同的人来说，可能意味着齐全不同的货色。所以，在这里我想扭转一下游戏的规定。不去抉择一个所谓的最事实的配比，而是结构一些极其的状况。这样，咱们能够高深莫测的晓得，JSON的强项和弱点都是什么。通过把这些缺点放大进去，咱们也就能够对最坏的状况有一个清晰的预期。具体在你的场景下性能差距是怎么的一个区间内，也能够大略预估进去。 ...

为了更好地分类浏览52im.net 总计1000多篇精编文章，我将在每周三推送新的一期技术文集，本次是第7 期。[- 1 -] 长连贯网关技术专题(二)：知乎千万级并发的高性能长连贯网关技术实际 [链接] http://www.52im.net/thread-2737-1-1.html [摘要]通过了一年多的开发和演进，通过咱们服务面向内和外的数个 App、接入十几个需要和形态各异的长连贯业务、数百万设施同时在线、突发大规模音讯发送等等场景的锻炼，咱们提炼出一个长连贯零碎网关的通用解决方案：知乎长连贯网关致力于业务数据解耦、音讯高效散发、解决容量问题，同时提供肯定水平的音讯可靠性保障。 [- 2 -] 长连贯网关技术专题(三)：手淘亿级挪动端接入层网关的技术演进之路 [链接] http://www.52im.net/thread-31... [摘要]手机淘宝从过来的HTTP API网关，到起初扛住双十一战场次要流量的自研高性能、全双工、平安的ACCS（阿里云通道服务），无论是基础架构的演进、网络调优、协定的优化、异地多活、网络调度上，都有不少贵重的教训与大家分享，本文借此机会总结了整个技术演进过程。 [- 3 -] 长连贯网关技术专题(五)：喜马拉雅自研亿级API网关技术实际 [链接] http://www.52im.net/thread-35... [摘要] 本文将分享在喜马拉雅API网关在亿级流量前提下，进行的技术演进倒退历程和实际经验总结。 [- 4 -] 长连贯网关技术专题(六)：石墨文档单机50万WebSocket长连贯架构实际 [链接] http://www.52im.net/thread-37... [摘要] 本文分享了石墨文档长连贯网关从1.0架构演进到2.0的过程，并总结了整个性能优化的实际过程。 [- 5 -] 长连贯网关技术专题(七)：小米小爱单机120万长连贯接入层的架构演进 [链接] http://www.52im.net/thread-38... [摘要]小爱接入层是小爱云端负责设施接入的第一个服务，也是最重要的服务之一，本篇文章介绍了小米技术团队2020至2021年在这个服务上所做的一些优化和尝试，最终将单机可承载长连接数从30w晋升至120w+，节俭了机器30+台。 [- 6-] 长连贯网关技术专题(八)：B站基于微服务的API网关从0到1的演进之路 [链接] http://www.52im.net/thread-39... [摘要] 随着B 站投稿量激增，访问量随之成倍回升，而过来的 PHP 全家桶也开始逐步展露出颓势，运维难、监控难、排查故障难、调用门路深不见底。也就是在这一年，B 站开始正式用 Go 重构 B 站，从此B站的API网关技术子开始了从0到1的继续演进 [- 7 -] P2P技术详解(一)：NAT详解——具体原理、P2P简介 [链接] http://www.52im.net/thread-50... [摘要] 这是一篇介绍NAT技术要点的精髓文章，来自华3通信官网资料库，文中对NAT技术原理的介绍很全面也很权威，对网络应用的应用层开发人员而言有很高的参考价值。 [- 8-] P2P技术详解(二)：P2P中的NAT穿梭(打洞)计划详解(基本原理篇） [链接] http://www.52im.net/thread-54... ...

本文由码农的荒岛求生陆小风分享，为了晋升浏览体验，进行了较多订正和排版。1、引言搞即时通讯IM方面开发的程序员，在谈到通信层实现时，必然会提到网络编程。那么计算机网络编程中的一个十分根本的问题：到底该怎么组织Client与server之间交互的数据呢？本篇文章咱们不探讨IM零碎中的那些高端技术话题，咱们回归到通信的实质——也就是数据在网络中交互时的编解码原理，并由浅入深从底层了解Protobuf的编解码技术实现。 学习交换：-- 挪动端IM开发入门文章：《新手入门一篇就够：从零开发挪动端IM》--开源IM框架源码：https://github.com/JackJiang2...（备用地址点此）（本文已同步公布于：http://www.52im.net/thread-40...） 2、系列文章本文是系列文章中的第 3 篇，本系列总目录如下：《IM通信协定专题学习(一)：Protobuf从入门到精通，一篇就够！》《IM通信协定专题学习(二)：疾速了解Protobuf的背景、原理、应用、优缺点》《IM通信协定专题学习(三)：由浅入深，从根上了解Protobuf的编解码原理》（* 本文）《IM通信协定专题学习(四)：从Base64到Protobuf，详解Protobuf的数据编码原理》（稍后公布..）《IM通信协定专题学习(五)：Protobuf到底比JSON快几倍？请看全方位实测！》（稍后公布..）《IM通信协定专题学习(六)：手把手教你如何在Android上从零应用Protobuf》（稍后公布..）《IM通信协定专题学习(七)：手把手教你如何在NodeJS中从零应用Protobuf》（稍后公布..）《IM通信协定专题学习(八)：金蝶顺手记团队的Protobuf利用实际(原理篇)  》（稍后公布..）《IM通信协定专题学习(九)：金蝶顺手记团队的Protobuf利用实际(实战篇) 》（稍后公布..） 3、共识与协定针对引言中引出的“到底该怎么组织Client与Server之间交互的数据呢？”。这个问题可不像看上去那样简略，因为Client过程和Server过程运行在不同的机器上，这些机器可能运行在不同的处理器平台、可能运行在不同的操作系统、可能是由不同的编程语言编写的，Server要怎样才能辨认出Client发送的是什么数据呢？就像这样：如上图所示，Client给Server发送了一段数据：0101000100100001Server怎么能晓得该怎么“解读”这段数据呢？显然：Client和Server在发送数据之前必须首先达成某种对于怎么解读数据的共识，这就是所谓的协定。这里的协定能够是这样的：“将每8个比特为一个单位解释为无符号数字”。如果协定是下面这样定义的：那么Server接管到这串二进制后就会将其解析为 81(01010001) 与 33(00100001)。当然，这里的协定也能够是这样的：“将每8个比特为一个单位解释为ASCII字符”，那么Server接管到这串二进制后就将其解析为“Q!”。可见：同样一串二进制在不同的“上下文/协定”下有齐全不一样的解读，这也是为什么计算机明明只认知0和1然而却能解决非常复杂工作的根本原因，因为所有都能够编码为0和1，同样的咱们也能够从0和1中解析出咱们想要的信息，这就是所谓的编解码技术。实际上不止0和1，咱们也能够将信息编码为摩斯明码（Morse code）等，只不过计算机善于解决0和1而已。扯远了，回到本文的主题。 4、一个例子：近程过程调用（RPC）作为程序员咱们晓得，Client以及Server之间不会简略传递一串数字以及字符这样简略，尤其在互联网大厂后端服务这种场景下。当咱们在电商App里搜寻商品、打车App里呼叫出租车以及刷短视频时，每一次申请的背地在后端都波及大量服务之间的交互。就像这样：实现一次客户端申请gateway这个服务要“调用”N多个上游服务，所谓“调用”是说A服务向B服务发送一段数据（申请），B服务接管到这段数据后执行相应的函数，并将后果返回给A服务。只不过对于服务A来说并不想关怀网络传输这样的底层细节，如果能像调用本地函数一样调用近程服务就好了，这就是所谓的RPC。经典的实现形式是这样的：RPC对下层提供和一般函数一样的接口，只不过在实现上封装了底层简单的网络通信（当然也包含协定的定义，协定的解解码等）。RPC框架是以后互联网后端的基石之一，很多所谓互联网后端的职位无非就是在此基础之上堆业务逻辑。本文咱们不关怀其中的细节，咱们只关怀在网络层Client是怎么对申请参数进行编码、Server怎么对申请参数进行解码的，也就是本文结尾提出的问题。5、信息的编解码5.1纯文本的编解码对人类很敌对在思考怎么进行编解码之前，咱们必须意识到：1）Client和Server可能是用不同语言编写的（你的编解码计划必须通用且不能和语言绑定）；2）编解码办法的性能问题必须要思考（尤其是对工夫要求刻薄的服务）。首先，咱们最应该能想到的就是以纯文本的模式来示意。纯文本素来都是一种十分有敌对的信息载体。为什么？很简略，因为人类（咱们）能够间接看懂。就像这段：{ "widget": {  "window": {   "title": "Sample Konfabulator Widget",   "name": "main_window",   "width": 500,   "height": 500  },  "image": {   "src": "Images/Sun.png",   "name": "sun1",   "hOffset": 250,   "vOffset": 250,  }, }}是不是高深莫测：只有咱们实现约定好文本的构造（也就是语法），那么Client和Server就能利用这种文本进行信息的编码以及解码，不论Client和Server是运行在x86还是ARM、是32位的还是64位的、运行在Linux上还是Windows上、是大端还是小端，都能够无障碍交换。因而：在这里，文本的语法就是一种协定（如下图所示）。顺便说一句：你都规定好了文本的语法，实际上就相当于创造了一种语言。这里用来举例用的语言就是所谓的JSON，只不过JSON这种语言不是用来示意逻辑（代码）而是用来存储数据的。JSON就是这个老头提出来的：除了JSON，另一种利用文本存储数据的示意办法是XML。来一段XML感触下：<note><to>Tove</to><from>Jani</from><heading>Reminder</heading><body>Don't forget me this weekend!</body></note>绝对JSON来说是不是就没那么容易看懂了，自从JSON呈现后在Web畛域就逐步取代了XML。当两段数据量很少的时候——就像浏览器和服务端的交互，JSON能够工作的十分好（如下图所示）。这个场景就是这样：在这里是JSON的天下。5.2纯文本对计算机来说不够敌对在上大节中咱们晓得，JSON这类纯文本的编解码形式对于人类十分敌对。但对于后端服务之间的交互（或者具体如IM里Client和Server之间的交互）来说就不一样了，后端服务之间的RPC调用可能会传输大量数据，如果全副用纯文本的模式来示意数据那么不论是网络带宽还是性能可能都会差强人意。在这种场景下，JSON并不是最好的选项，次要起因之一就在于性能以及数据的体积。咱们晓得：文本示意对人类是最敌对的，对机器来说则不是这样，对机器来说最好的还是01二进制。那么有没有二进制的编码方法吗？答案是必定的，这就是以后互联网后端中风行的Protobuf，Google公司开源我的项目。那么Protobuf有什么神奇之处吗？假如Client端想给Server端传输这样一段信息：“我有一个id，其值为43”。那么在XML下是这样示意的：<id>43</id>数一数这这段数据占据了多少字节，很显然是11字节。而如果用JSON来示意呢？{"id":43}数一数这段数据占据了多少字节，显然是9字节。而如果用Protobuf来示意呢? 是这样的：//音讯定义message Msg {  optional int32 id= 1;}//实例化Msg msg;msg.set_id(43);其中Msg的定义看上去比JSON和XML更加简单了，但这些只是给人看的，这些还会被protbuf进一步解决。最终被Protobuf编码为：1082b也就是0x08与0x2b，这占据了多少字节呢？答案是2字节。从JSON的9字节到Protobuf的2字节，数据大小缩小了4倍多。数据量的缩小意味着：1）更少的网络带宽；2）更快的解析速度。那么，Protobuf是怎么做到这一点的呢？6、Protobuf是怎么实现编解码的？首先，咱们来思考最简略的状况，失常状况下，咱们该怎么示意数字。你可能会想这还不简略，对立用固定长度，比方用64个比特（8字节）。这种办法可行，但问题是不管一个数字有多小，比如2，那么用这种办法示意2也须要占据64个比特（8字节），如下所示。明明只有一个字节就能示意而咱们却用了8个，后面的全都是0，这也太侈靡太节约了吧。显然，在这里咱们不能应用固定长度来示意数字，而须要应用变长办法来示意。什么叫变长？意思是说如果数字自身比拟大，那么其应用的比特位能够较多，但如果数字很小那么就应该应用较少的比特位来示意，这就叫变长，随机应变，不死板。那怎么变长呢？咱们规定：对于每一个字节来说，第一个比特位如果是1那么示意接下来的一个比特仍然要用来解释为一个数字，如果第一个比特为0，那么阐明接下来的一个字节不是用来示意该数字的。也就是说对于每个8个比特（1字节）来说，它的有效载荷是7个比特，第一个比特仅仅用来标记是否还应该把接下来的一个字节解析为数字。依据这个规定，假如来了这样一串01二进制：1010110000000010依据规定，咱们首先取出第一个字节，也就是：10101100此时咱们发现第一个比特位是1，因而咱们晓得接下来的一个字节也属于该数字。将以后字节的1去掉就是：0101100而后咱们看下一个字节：00000010咱们发现第一个bit为0，因而咱们晓得下一个字节不属于该数字了。接下来咱们将解析到的0101100（第一个字节去掉第一个比特位）以及第二个字节0000010（第二个字节去掉第一个比特位）翻转之后拼接到一起（这里之所以翻转是因为咱们规定数字的高位在后）。这个过程就是：     1010110000000010 ->  10101100 | 00000010 //解析失去两个字节    _          _->  0101100  |  0000010  //各自去掉最高位->  0000010  |  0101100  //两个字节翻转程序    0000010  +  0101100->  100101100           //拼接最初咱们失去了100101100，这一串二进制示意数字300。这种数字的变长示意办法在Protobuf中被称之为varint。因而在这种示意办法下，如果数字较大，那么应用的比特就多，如果数字较小那么应用比特就少，聪慧吧。有的同学看到这里可能会问题，方才解说的办法只能示意无符号数字，那么有符号数字该怎么示意呢？比方-2该怎么示意？7、Protobuf的有符号数示意依照方才变长编码的思维，-2147483646应用的比特位应该比-2要少。然而咱们晓得在计算机世界中正数应用补码示意的，也就是说最高位（最左侧的比特位）肯定是1，假如咱们应用64位来示意数字，那么如果咱们仍然用补码来示意数字的话那么无论这个正数有多大还是多小都须要占据10个字节的空间。为什么是10个字节呢？不要忘了varint每个字节的无效负荷是7个比特，那么对于须要64位示意的数字来说就须要64/7向上取整也就是10个字节来示意。这显然不能满足咱们对数字变长存储的要求。该怎么解决这个问题呢？既然无符号数字能够不便的进行变长编码，那么咱们将有符号数字映射称为无符号数字不就能够了，这就是所谓的ZigZag编码，是不是很聪慧。ZigZag编码就像这样：原始信息      编码后0            0-1           11            2-2           32            4-3           53            6...          ...2147483647   4294967294-2147483648  4294967295这样咱们就能够将有符号数字转为无符号数字，接管方接管到该数据后再复原出有符号数字。当初数字的问题彻底解决了，但这仅仅是万里长征第一步。8、Protobuf的字段名称与字段类型对于任何一个有用的信息都蕴含这样几局部：1）字段名称；2）字段类型；3）字段值。就像C/C++中定义变量时：int i = 100;在这里，字段名称就是i，字段类型是int，字段值是100。方才咱们用varint以及ZigZag编码解决了字段值示意的问题，那么该怎么示意字段名称和字段类型呢？首先，对于字段类型还比较简单，因为字段类型就那么多。Protobuf中定义了6种字段类型：对于6种字段类型咱们应用3个比特位来示意就足够了。接下来比拟乏味的是字段名称该怎么示意呢？假如咱们须要传递这样一个字段：int long_long_name = 100;那么咱们真的须要把“long_long_name”这么多字符通过网络传递给对端吗？既然通信单方须要协定，那么“long_long_name”这字段其实是Client和Server都晓得的，它们惟一不晓得的就是“哪些值属于哪些字段”。为解决这个问题，咱们给每个字段都进行编号，比方通信单方都晓得“long_long_name”这个字段的编号是2。那么对于“int long_long_name = 100; ”咱们该怎么示意呢。这个信息咱们只须要传递：1）字段名称：2 (2对应字段“long_long_name”)；2）字段类型：0 (0示意varint类型，参见上图)；3）字段值：100。所以咱们能够看到，无论你用如许简单的字段名称也不会影响编码后占据的空间，字段名称基本就不会呈现在编码后的信息中，so clever。9、从宏观上看Protobuf的编码原理咱们曾经在Protobuf中看到了数字以及字段名称以及字段类型是怎么示意了，当初是时候从宏观角度来看看多个字段该怎么编码了。从实质上讲，Protobuf被编码后造成一系列的key-value，每个key-value对应一个proto中的字段。也就是键值对：其中value比较简单，也就是字段值；而字段名称和字段类型会被拼接成key。Protobuf中共有6种类型，因而只须要3个比特位即可。字段名称只须要存储对应的编号。这样就能够这样编码：(字段编号 << 3) | 字段类型假如Server接管到了一个key为0x08，其二进制的示意为：0000 1000因为key也是利用varint编码的，因而须要将第一个比特位去掉。这样我的失去：000 1000依据key的编码方式，其后三个比特位示意字段类型，即：000也就是0，这样咱们晓得该key的类型是Varint(第0号类型)，而字段编号为抹掉后3个比特位的值，即：0001这样，咱们就晓得了该key对应的字段编号为1，失去编号咱们就能依据编号找到对应的编号名称。 ...

为了更好地分类浏览52im.net 总计1000多篇精编文章，我将在每周三推送新的一期技术文集，本次是第6 期。[- 1 -] 古代挪动端网络短连贯的优化伎俩总结：申请速度、弱网适应、平安保障 [链接] http://www.52im.net/thread-14... [摘要]短连贯的优化在某些场景下对于挪动端IM来说可能显示的更为特出。在这方面，微信做的比拟彻底和极其，简直再造了一套针对挪动端IM的网络层框架（详见：《如约而至：微信自用的挪动端IM网络层跨平台组件库Mars已正式开源》）。 [- 2 -] 挪动端IM开发者必读(一)：通俗易懂，了解挪动网络的“弱”和“慢” [链接] http://www.52im.net/thread-15... [摘要] 本文的目标，就是心愿以通俗易懂的语言，帮忙挪动端IM开发者更好地了解挪动网络的各种个性，使得开发出的性能能更好地适应挪动网络，给用户带来更好的应用体验。 [- 3 -] 挪动端IM开发者必读(二)：史上最全挪动弱网络优化办法总结 [链接] http://www.52im.net/thread-15... [摘要]本文将针对上篇中提到的个性，联合咱们的实践经验，总结了四个办法来谋求极致的“痛快”：快链路、轻往返、强监控、多异步，从实践讲到实际、从技术讲到产品，实践联系实际，触类旁通，心愿给您带来启发。 [- 4 -] 全面理解挪动端DNS域名劫持等杂症：原理、本源、HttpDNS解决方案等 [链接] http://www.52im.net/thread-21... [摘要] 本文将就鹅厂团队在这一块的技术实际，做一个深度的总结和技术分享，心愿给大家带来些许启发。 [- 5 -] 美图App的挪动端DNS优化实际：HTTPS申请耗时减小近半 [链接] http://www.52im.net/thread-21... [摘要] 本文介绍美图APP在挪动端DNS优化的实际（次要针对HTTPS协定），文章内容从DNS问题、原理到最终优化成果，解说的较全面，值得学习和借鉴。 [- 6 -] 百度APP挪动端网络深度优化实际分享(一)：DNS优化篇 [链接] http://www.52im.net/thread-24... [摘要]DNS（Domain Name System），它的作用是依据域名查出IP地址，它是HTTP协定的前提，只有将域名正确的解析成IP地址后，前面的HTTP流程能力进行，所以个别做网络优化会首选优化DNS。 [- 7 -] 百度APP挪动端网络深度优化实际分享(二)：网络连接优化篇 [链接] http://www.52im.net/thread-24... [摘要] HTTP协定的根底是连贯，所以咱们的《百度APP挪动端网络深度优化实际分享(二)：网络连接优化篇》应运而生，心愿对大家在网络方向的学习和实际有所帮忙。 [- 8 -] 百度APP挪动端网络深度优化实际分享(三)：挪动端弱网优化篇 [链接] http://www.52im.net/thread-26... [摘要]网络优化解决的外围问题有三个，第一是平安问题，第二是速度问题，第三是弱网问题，它是网络优化中最为简单且须要重复验证和剖析的问题，咱们的《百度APP挪动端网络深度优化实际分享(三)：挪动端弱网优化篇(本文 *)》就是要深入探讨这个问题。 [- 9 -] 爱奇艺挪动端网络优化实际分享：网络申请成功率优化篇 ...

对于MobileIMSDK MobileIMSDK 是一套专门为挪动端开发的开源IM即时通讯框架，超轻量级、高度提炼，一套API优雅反对UDP 、TCP 、WebSocket 三种协定，反对iOS、Android、H5、规范Java平台，服务端基于Netty编写。 工程开源地址是： 1）Gitee码云地址：https://gitee.com/jackjiang/M...2）Github托管地址：https://github.com/JackJiang2...对于RainbowChat► 具体产品介绍：http://www.52im.net/thread-19...► iOS端更新记录：http://www.52im.net/thread-27...► 全副运行截图：iOS端全副运行截图 （另：Android端运行截图 点此查看）► 在线体验下载：App Store装置地址 （另：Android端下载体验 点此查看） RainbowChat是一套基于开源IM聊天框架 MobileIMSDK 的产品级挪动端IM零碎。RainbowChat源于实在经营的产品，解决了大量的屏幕适配、细节优化、机器兼容问题（可自行下载体验：专业版下载安装）。 * RainbowChat可能是市面上提供im即时通讯聊天源码的，惟一一款同时反对TCP、UDP两种通信协议的IM产品（通信层基于开源IM聊天框架 MobileIMSDK 实现）。 v6.1 版更新内容此版更新内容（更多历史更新日志）： 1）[bug] 在聊天信息界面中查找音讯时，点击查看指定音讯，在聊天界面中不能主动滚动到这条音讯；2）[bug] 点击首页“音讯”列表中遗留的陌生人聊天信息时，无奈重置音讯未读数的问题；3）[bug] 在聊天界面中进入别的界面再回来时，底部面板没有主动敞开/收起；4）[优化] 优化了标题栏弹出菜单的圆角成果（使之更合乎最新iOS美感设计）；5）[优化] 优化了APP中各种文本输入框UI成果，以及其它UI细节；6）[优化] 优化了短视频录制界面在iOS16“灵动岛”手机上的ui适配。此版次要性能运行截图（更多截图点此查看）：  

1、引言在《IM音讯ID技术专题》系列文章的前几篇中，咱们曾经深切体会到音讯ID在分布式IM聊天零碎中的重要性以及技术实现难度，各种音讯ID生成算法及实现尽管各有劣势，但受制于具体的利用场景，也并不能一招吃遍天下，所以真正在IM零碎中该如何落地音讯ID算法和实现逻辑，还是要因地致宜，依据自已零碎的设计逻辑和产品定义取其精华，综合利用之。本文将基于网易严选的订单ID应用现状，分享咱们是如何联合业内罕用的分布式ID解决方案，从而在此基础之上进行ID个性丰盛，并一直晋升零碎可用性和稳定性保障。同时，也对ID生成算法的落地实际过程中遇到坑进行了深刻分析。本篇中的订单ID尽管不同于IM零碎中的音讯ID，但其技术实际依然相通，心愿能给你的IM零碎音讯ID技术选型也来更多的启发。学习交换： 挪动端IM开发入门文章：《新手入门一篇就够：从零开发挪动端IM》开源IM框架源码：https://github.com/JackJiang2...（备用地址点此）（本文已同步公布于：http://www.52im.net/thread-40...）2、对于作者西狂：服务端研发工程师, 晚期参加严选洽购、严选财务、严选合伙人以及报警平台等零碎后端建设，目前次要致力于严选交易域技术演进以及业务研发工作。 3、系列文章本文是系列文章中的第7篇，本系列总目录如下：《IM音讯ID技术专题(一)：微信的海量IM聊天音讯序列号生成实际（算法原理篇）》《IM音讯ID技术专题(二)：微信的海量IM聊天音讯序列号生成实际（容灾计划篇）》《IM音讯ID技术专题(三)：解密融云IM产品的聊天音讯ID生成策略》《IM音讯ID技术专题(四)：深度解密美团的分布式ID生成算法》《IM音讯ID技术专题(五)：开源分布式ID生成器UidGenerator的技术实现》《IM音讯ID技术专题(六)：深度解密滴滴的高性能ID生成器(Tinyid)》《IM音讯ID技术专题(七)：网易严选分布式ID的技术选型、优化、落地实际》（* 本文） 4、为什么须要分布式ID？4.1 业务背景如上图所示，对于网易严选的主站、分销和tob都会生成各自的订单ID，在同步订单数据到订单核心的时候，订单核心会生成一个订单核心外部的一个订单号，只是推送给到上游仓配时应用的订单ID略有不同。4.2 带来的问题 因为订单ID应用的凌乱，导致了一系列问题的产生，例如: 沟通壁垒 、管控艰难以及代码腐化等等。4.3 技术指标 咱们心愿通过分布式ID来帮忙生成订单ID，在业务规定上必须全局惟一、安全性高，在性能上要高可用、低提早。 5、咱们的分布式ID架构原理5.1 技术选型下表是业内常见的分布式ID解决方案：综合思考是否反对程度扩大以及可能显示指定ID长度，最终抉择的是Leaf的Segment模式（详见《深度解密美团的分布式ID生成算法》）。5.2 架构简介Leaf采纳了预散发的形式来生成ID（如下图所示），在DB之上搭载若干个Server，每个Server在启动的时候，都会去DB中拿固定长度的ID列表，寄存于内存中，因为ID是基于内存散发的，所以能够做到很高效。在数据长久化方面，每次去DB拿固定长度的ID列表，只是把最大的ID长久化。整体架构实现比较简单，次要是为了尽快解决业务层DB压力的问题，然而在生产环境中也暴露出一些问题。比方：1）TP999数据稳定大，当号段应用完之后还是会hang在更新数据库的I/O上，tp999数据会呈现偶然的尖刺；2）当更新DB号段的时候，如果DB宕机或者产生主从切换，会导致一段时间的服务不可用。5.3 可用性优化为了解决下面提到这个两个问题，引入双Buffer机制和异步更新策略，当一个Buffer耗费到某个临界点时，就会异步的触发工作，把下一个号段加载到内存中。保障无论何时DB呈现问题，都能有一个Buffer的号段能够失常对外提供服务，只有DB在一个Buffer的下发的周期内复原，就不会影响整个Leaf的可用性。5.4 步长动静调整号段长度在固定不变的前提下，流量的突增和锐减都会使得失常流量下维持原有号段失常工作的工夫缩短和晋升。能够尝试应用以下关系表达式来形容：Q T = L(Q：服务qps  L：号段长度  T：号段更新周期)然而Leaf的实质是心愿T固定，如果Q和L能够正相干，T就能够趋于一个定值。所以在Leaf每次更新号段的时候，会依据上一次号段更新的周期T和号段长度step，来决定下一次号段长度nextStep。如下所示：T < 15min，nextStep = step 215min < T < 30min，nextStep = stepT > 30min，nextStep = step / 2(初始指定step <= nextStep <= 最大值(自定义：100W)) 6、咱们做了什么改良？6.1 个性丰盛 通过联合严选的理论业务场景，进行了个性化反对，例如反对批量ID获取、大促提前扩容以及提前跳段解决。6.2 可用性保障1）针对DB： DB（MySql）采纳主从模式（读写拆散、升高主库压力），一主两从的配置形式，Master和Slave之间采纳的是半同步复制（数据一致性要求，前期可思考应用MySql Group Replication）。同时还增加了双1配置，保障不丢数据。2）引入SDK：通过引入SDK能够升高各个业务方的接入老本、升高Leaf服务端压力以及在Leaf服务不可用时，客户端起到短暂降级的成果。SDK的实现原理和Leaf相似，在我的项目启动之初会加载业务关怀参数配置信息，在利用构建本地缓存，同样采纳了双Buffer存储模式。6.3 稳定性保障1）运维方面：次要分为3个方面：1）日志监控：能够帮忙发现预期之外的异常情况；2）流量监控：流有助于号段长度的评估范畴，预防号段被疾速生产的极其场景；3）线上巡检：能够时刻对服务进行存活校验。2）SLA高可用方面：除了运维之外还做了SLA的接入，通常用SLA来掂量零碎的稳定性，除此之外咱们还依照接口维度设定了SLO指标规定，目前的指标项比拟繁多只有申请提早和错误率这两项。 7、咱们遇到的坑7.1 问题发现如下图所示，咱们发现每次服务启动上线接口的rt（响应工夫）都要比平时高的多，然而过了一段时间之后却又复原成失常程度。7.2 问题探索在剖析之前，咱们能够先简略的回顾下java虚拟机是如何运行Java字节码的。虚拟机视角下Java字节码如何被虚拟机运行：Java虚拟机将class文件加载到虚拟机中，而后将字节码翻译成机器码给底层硬件执行，而这里的翻译有两种模式，解释执行和编译执行。前者的劣势在于无需期待编译，后者的劣势在于理论运行速度更快。HotSpot默认采纳混合模式，它会先解释执行字节码，而后将其中重复执行的热点代码，以办法为单位进行即时编译，JVM是根据办法的调用次数以及循环回边的执行次数来触发JIT编译的。在Java7之前咱们能够依据程序的个性抉择对应的即时编译器。Java7开始引入分层编译机制（-XX:+TieredCompilation）：综合了C1的启动性能劣势和C2的峰值性能劣势。分层编译将JVM的执行状态分为了5个档次：L0：解释执行（也会profiling）；L1：执行不带profiling的C1代码；L2：执行仅带办法调用次数和循环回边执行次数profiling的C1代码；L3：执行带所有profiling的C1代码；L4：执行C2代码。对于C1编译的三个档次，按执行效率从高至低：L1 > L2 > L3, 这是因为profiling越多，额定的性能开销越大。通常状况下，C2代码的执行效率比C1代码高出30%以上。（这里须要留神的是Java8默认开启了分层编译）这张图列出了常见的分层编译的编译门路：1）通常状况下，热点办法会被第三层的C1编译器编译，再被C2编译器编译(0-> 3-> 4)；2）如果办法的字节数目比拟少并且第三层的profilling没有可收集的数据，jvm会断定该办法对于C1和C2的执行效率雷同，在通过3层的C1编译过后，间接回到1层的C1(0-> 3-> 1)；3）在C1繁忙的状况下，JVM在解释执行过程中对程序进行profiling，而后间接由4层的C2编译(0-> 4)；4）在C2繁忙的状况下，办法会被2层的C1编译，而后再被3层的C1编译，以缩小办法在3层的执行工夫(0-> 2-> 3-> 4)。上图是我的项目启动时的分层编译日志以及整个过程接口响应RT。从图中能够看到先是执行了C1编译，再执行C2编译（日志文件中的3和4别离打标L3和L4），满足 0->3->4 编译程序。发现从C1编译到C2编译耗时过程比拟长，这合乎咱们一开始提出的疑难，为什么我的项目启动须要通过一段时间接口RT能力趋于稳定。7.3 解决方案为了能在我的项目启动之初，疾速达到接口RT峰值，因而只有尽最大水平缩短解释执行这个两头过程即可。相应的解决方案：计划 1：敞开分层编译，升高编译阈值；计划 2：Mock接口数据, 疾速触发JIT编译以及C2编译；计划 3：Java9 AOT提前编译。针对计划3：Java9中反对新个性AOT提前编译，相比拟于JIT即时编译而言，AOT在运行前就曾经编译好了，防止 JIT 编译器的运行时性能耗费，同时防止解释程序的晚期性能开销，能够极大进步java代码性能。 ...

本文干货短缺篇幅较长，倡议珍藏后浏览防止迷路。文末可获取【主动聊天机器人源码和Demo】。 本教程教大家应用即构 ZIM SDK 创立一个能与微信端互动音讯的主动聊天机器人利用。ZIM SDK可广泛应用于娱乐社交、电商购物、在线教育、互动直播等多种场景下即时通讯性能实现原文作者：RTC_程序猿_Wang 原文链接：https://mp.weixin.qq.com/s/-z... 前言应用即构 SDK 和 微信PC端创立主动聊天IM利用非常简单，反对单聊音讯、群组音讯、房间音讯等的收发，以及查问历史音讯、删除音讯等IM根底性能，除此之外，即构还提供许多拓展性能，能够进步企业客户即时通讯的安全性和便利性。● 呼叫邀请● 平安审核● 离线推送● 离线音讯● 音讯云存储 即时通讯IM概述如果能开发一款即时聊天App，能和微信音讯互通，并且只需少许代码量，应该是件十分兴奋的事件吧。首先，心愿疾速开发平安稳固的即时聊天App，最好借助（白嫖短缺的收费额度）第三方提供的即时聊天SDK。其次，跟微信音讯买通，只需借助本文提供的SDK。明天咱们学习如何疾速实现一款与微信音讯互通的聊天App。 最终成果如下（可在文末获取源码）： 1-【主动聊天】 2-【聊天】 3-【主动回复】 1 技术实现原理整个技术实现原理如下图所示 2 微信音讯劫持2.1 第三方已有的微信音讯劫持工具本文不会教你从零开发微信音讯劫持，而是借助第三方已有的工具：pc-wechat-hook-http-api。相干文档在这里https://www.apifox.cn/apidoc/project-1222856/doc-1012539。 须要留神的是，此工具基于3.6.0.18版本微信。下载此版本微信后间接笼罩装置，这样能够保留之前的微信聊天记录。 2.2 如何应用微信音讯劫持工具？首先返回官网下载好压缩包，如果不晓得怎么官网怎么下载，能够间接拉到本文文末获取。 将HPSocket4C.dll文件复制到微信目录下（例如E:\Tencent\WeChat\[3.6.0.18]） 2.2.1 注入dll点击Daen注入器.exe文件： 其中： 文件目录是指微信装置门路，参考上图。DLL门路指的是DaenWxHook.dll文件的残缺门路。过程参数间接应用默认即可。其中图中8089指本地用于接管微信实时音讯的http server端口。8055指的是dll开启的http server端口，发送音讯时只需往这个端口post数据即可。点击注入并启动，登录微信即可。这里已实现微信音讯的劫持，下一步咱们尝试发送微信音讯验证。 2.2.2 发送微信音讯发送音讯形式为往指定端口post http申请即可，具体端口值为下面注入dll工具中指定的8055，如果用nodejs实现，post申请体如下所示： function post(data, callback) { var options = { hostname: '127.0.0.1', port: 8055, path: '/DaenWxHook/client/', method: 'POST', headers: { 'User-Agent': 'apifox/1.0.0 (https://www.apifox.cn)', 'Content-Type': 'application/json' } }; var req = http.request(options, function (res) { var body = ""; res.setEncoding('utf8'); res.on('data', function (chunk) { body += chunk; }); res.on('end', function () { var json = JSON.parse(body); callback(json); }); }); req.on('error', function (e) { console.log('problem with request: ' + e.message); }); req.write(JSON.stringify(data)); req.end();}其中data是JSON类型，其数据结构具体模式能够参考官网文档或者间接看本文提供的代码。 ...

业务特点在互联网行业流行一句话，技术是为业务服务的。具体到实际中，一个重要方面就是要面向业务特点设计技术计划。因而，想要理解「圈组」的关系零碎设计，就要首先理解「圈组」的关系业务特点。 「圈组」的关系业务特点是什么？其一是关系简单，即关系主体多、管理机制杂、联动耦合重；其二是规模微小，即成员数量可达百万量级、变更批量可达百万量级。 所谓关系简单，具体来讲：首先是关系主体多。在「圈组」业务中，关系主体包含服务器、频道、身份组、频道分组等，服务器承载社群关系，负责社群成员关系保护；频道从属于服务器，承载内容关系，负责内容互动关系保护；身份组可从属于服务器或频道，承载身份权限关系，负责身份设定和权限配置；频道分组从属于服务器，又关联一组频道，承载频道模版关系，负责分类频道和共享配置。其次是管理机制杂。在「圈组」业务中，仅就成员管理机制而言，服务器成员采纳邀请/申请机制，频道成员采纳公开/私密模式+黑/白名单机制，身份组成员采纳退出/移出机制，频道分组成员与频道成员采纳同步机制。最初是联动耦合。在「圈组」业务中，以频道成员保护为例，频道成员不仅受到公开/私密模式+黑/白名单配置变更的影响，而且会随同服务器成员变更、身份组变更、身份组成员变更等做联动变更。 所谓规模微小，具体来讲：一方面是成员数量可达百万量级。在「圈组」业务中，服务器成员数量能够达到数百万人，进一步，百万成员服务器下的频道和身份组，其成员数量也能够达到百万量级。另一方面是变更批量可达百万量级。在「圈组」业务中，不仅成员数量规模微小，而且变更操作一个批次数量也能够达到百万量级。包含：删除百万成员的服务器/频道/身份组，增删频道/频道分组黑白名单中的百万成员身份组等。 从「圈组」关系业务的两大特点登程，能够发现「圈组」关系是不同于群组关系的全新业务场景，将会面临全新的技术难点。 技术难点「圈组」关系零碎的技术难点次要有两个方面。其一是多关系主体、多管理机制在层级构造下关联耦合导致的业务逻辑的复杂性；其二是成员数量、变更批量规模微小导致的业务解决在工夫、空间、资源等开销上的复杂性。 业务逻辑复杂性首先「圈组」有多级构造。包含服务器/频道二级构造、服务器/频道分组/频道三级构造等。单个关系主体变更，不仅波及本身的变更，而且波及上下级关系主体的变更，能够说牵一动员全身。相比而言，群组是没有层级的，群组变更只有独善其身就好。 其次「圈组」有身份组。一个身份组是一组有独特权限的服务器成员的汇合，不同身份组的成员能够互相穿插，身份组会作为整体参加到成员治理中。也就是说，成员变更不再只是个别成员（1-100人）的进入退出，将会呈现整组成员（1-1000000人）的大进大出。相比而言，群组是没有身份组的，群组非凡成员包含群主、管理员等也都数量不多、互不反复。 最初「圈组」有多种成员管理机制。服务器成员和身份组成员的管理机制与群组相似，频道成员和频道分组成员的管理机制却是全新模式。频道分为公开和私密两种，公开模式默认容许所有服务器成员可见，但要排除黑名单身份组和黑名单成员；私密模式默认不许所有服务器成员可见，但要放开白名单身份组和白名单成员。除了受到公开/私密模式+黑/白名单配置变更的影响，频道成员也受到所依赖的关系主体（服务器成员、身份组、身份组成员）变更的影响。进一步，频道成员还受到所同步的频道分组变更的影响。相比而言，群组成员的邀请/申请机制，能够说是小巫见大巫。 业务解决复杂性首先是成员数量规模微小。因为成员数量可达百万，整个成员列表的存储空间开销、网络传输开销，变得非常微小，不管全量成员列表数据的服务器缓存，还是全量成员列表数据从服务器到客户端的同步，都将变得难以实现。 其次是变更批量规模微小。单次接口调用的关系变更，可能随同百万规模的联动关系变更，这会导致微小的解决工夫开销、计算资源开销，不管所有变更同步实现解决，还是所有变更单机实现解决，都将变得难以实现。 最初是告诉音讯规模微小。关系零碎不仅须要做关系变更的数据处理，而且须要告诉变更后果到客户端。因为在「圈组」中各个关系主体的成员数量规模微小，使得单个变更须要扩散为百万告诉同时下发，所需计算资源开销、网络传输开销非常微小。 相比而言，群组计划因为成员数量、变更批量规模无限，并不波及这些技术难点。 从「圈组」关系零碎的两个方面技术难点登程，能够发现「圈组」关系零碎面临不同于群组的全新技术难点，想要解决这些技术难点，须要翻新的技术计划。 技术分析「圈组」关系零碎是整个「圈组」计划的重要组成部分，在具体介绍「圈组」关系零碎技术计划之前，有必要首先理解「圈组」计划的整体架构。 「圈组」整体架构 下面展现了「圈组」计划的整体架构，能够看到「圈组」整体是一个分层架构。从上到下看： 客户层：包含可供客户端集成的挪动端、桌面端、跨平台 SDK，和可供服务器调用的 OpenAPI。接入层：包含 LBS 服务、长连贯服务和 API 网关，别离对应客户端 SDK 和用户服务器。网络层：包含自研的寰球实时传输网络 WE-CAN。业务层：包含用于 SDK 业务解决的 App 服务和用于 OpenAPI 业务解决的 WebServer 服务。服务层：划分有登录、音讯、关系、身份组、反对等服务模块，每个服务模块包含有多个微服务或消费者。基础设施层：包含零碎所用的数据库和中间件。关系零碎架构 上图展现了「圈组」关系零碎的技术架构，能够看到「圈组」关系零碎遍布「圈组」架构的接入层、网络层、业务层和服务层。从性能登程整体上分为三个局部，包含：关系操作同步解决模块、关系事件异步解决模块和变更告诉在线播送模块。 关系零碎技术细节在「圈组」关系零碎中，上面具体探讨三个计划要点的技术细节，包含频道成员关系治理、变更告诉在线播送和关系数据云端检索。 频道成员关系治理频道成员关系治理，是「圈组」中极具挑战性的问题。频道成员波及多关系主体、多管理机制、联动变更耦合重大，成员数量和变更批量规模微小，能够说是「圈组」关系业务的典型代表。频道成员关系治理在业务逻辑和业务解决两方面的复杂性可想而知。针对频道成员关系治理问题，「圈组」设计了两大机制加以解决。包含：终态保护与过渡计算相结合机制、事件按序异步并行处理机制。 终态保护与过渡计算相结合机制，具体来讲，频道成员关系数据最终被保护在长久化数据库中，并在频道成员没有变更的终态阶段，间接反对频道成员数据的查问需要。当频道成员产生变更时，因为变更逻辑和变更解决两方面的复杂性，实现关系变更须要一段时间，称之为过渡阶段。在过渡阶段，数据库长久化的频道成员表数据是不齐全精确的，无奈间接反对频道成员数据的查问需要。此时转为由频道成员配置元数据间接计算频道成员以反对查问需要。因为频道成员配置元数据的变更是同步解决的，所以在过渡阶段由频道成员配置元数据间接计算频道成员能够保障查问准确性。通过将频道成员关系治理分为终态和过渡两个阶段，并在不同阶段采纳不同频道成员查问计划，不仅解决了单纯由计算获取频道成员资源开销大的问题，而且解决了频道成员变更提早导致由数据库获取频道成员后果不精确的问题。 除了频道成员的获取查问问题，频道成员的变更解决也很重要。事件按序异步并行处理机制，就是用于解决频道成员的变更解决问题。其一通过将影响频道成员关系的变更操作分层级、系统化定义为变更事件，显著升高频道成员关系治理的业务逻辑复杂性。其二通过 ID 哈希、分布式锁、事件版本号管制等保障变更事件的按序解决，无效防止事件处理乱序导致的长久化数据谬误。其三通过音讯队列直达事件并在消费者上异步解决，无效解决联动变更批量过大导致接口调用阻塞的问题。其四通过在单个事件处理中的多线程并行减速和本地缓存重用减速，显著缩短频道成员关系变更的时间延迟。 变更告诉在线播送关系零碎不仅须要做关系变更的数据处理，而且须要告诉变更后果到客户端。在百万量级的「圈组」关系中，每条关系变更告诉，都会面临海量扩散的接收者。除了告诉散发量激增，不同接收者对于告诉接管的缓急差别也值得关注。针对变更告诉在线播送问题，「圈组」设计了两大机制加以解决。包含：变更分类告诉机制、数据告诉拉取机制。 在变更分类告诉机制中，一方面，依据相干人员在变更中的角色，划分为参与者和观察者分类做告诉，即参与者肯定告诉，观察者依照订阅需要告诉。其中参与者个别是变更中的多数要害人员，观察者则是除了参与者之外能够看到变更后果的其它人员。通过分类告诉，不同接收者对于告诉接管的缓急差别失去正当关注，变更告诉的扩散规模也失去精准放大。另一方面，观察者依照订阅需要告诉，能够充分发挥「圈组」的在线播送订阅模式的劣势。所谓在线播送订阅模式，是指在用户登陆之后，须要订阅感兴趣的服务器/频道的告诉，「圈组」零碎会记录下这些订阅信息，当有新的告诉时，「圈组」零碎通过订阅关系而非成员列表 + 在线状态获取须要在线播送的用户列表，从而不再须要遍历服务器/频道的所有成员及其在线状态。通过采纳在线播送订阅模式，不仅显著升高变更告诉在线播送的计算开销和带宽开销，而且能够实现变更告诉在线播送在长连贯服务集群的并行减速和程度扩大。 变更告诉的最终目标是将变更后的数据给到客户端。不同于群组，「圈组」并不将变更后的数据间接由告诉带给客户端，而是采纳告诉客户端有变更再触发客户端拉取后果数据的机制。究其原因，不同于群组将关系数据全量同步到客户端，「圈组」客户端不再存储关系数据的全量镜像，因而不再须要通过全量历史 + 增量变更的形式保护客户端上的关系数据全量镜像。与此同时，订阅变更告诉的观察者也并不是每时每刻都要关怀变更的后果数据，关怀某次变更后果数据的观察者相比订阅变更告诉的观察者在数量上会少很多，因而，数据告诉拉取机制会显著升高变更告诉的资源开销。另外，相比带变更数据告诉，只告诉有变更，便于间接合并雷同类型的告诉，而不必关怀合并变更数据存在的时序、并发等问题，如此，数据告诉拉取机制能够通过短时间内告诉合并显著升高服务器在线播送开销和客户端告诉接管开销。 关系数据云端检索在「圈组」中，随同关系规模的大幅增长，群组基于应用服务器全量查问关系数据或客户端全量同步关系数据实现精准查问和灵便排序的计划不再实用。对此，「圈组」采纳了关系数据云端检索的计划。 「圈组」关系数据云端检索计划能够反对服务器、频道、成员等的检索能力。从检索场景上分，包含广场检索和外部检索。 广场检索：用于检索感兴趣的服务器。能够依据名称、类别等多种维度检索。检索后果能够依据预约义字段（成员数量等）或自定义值（数据热度等）等进行排序。 外部检索：用于检索用户可见的服务器、频道、成员等。能够依据名称、昵称等多种维度检索。检索后果能够依据预约义字段（创立工夫等）或自定义值（数据热度等）等进行排序。  总结说了这么多，云信「圈组」作为一款全新设计的产品，没有任何历史包袱的限度（然而却能够充沛排汇历史长处），你能够应用它构建一个类 Discord 产品，或者任何你想得到的社交/娱乐/游戏产品，欢送大家抉择。  

为了更好地分类浏览52im.net 总计1000多篇精编文章，我将在每周三推送新的一期技术文集，本次是第3 期。第 1 篇[题目] 高性能网络编程(一)：单台服务器并发TCP连接数到底能够有多少 [链接] http://www.52im.net/thread-56... [摘要] 到底一台服务器可能反对多少TCP并发连贯呢？这就是本文要探讨的问题。 第 2 篇[题目] 高性能网络编程(二)：上一个10年，驰名的C10K并发连贯问题 [链接] http://www.52im.net/thread-56... [摘要] 理解C10K问题及其解决思路，通过触类旁通，或者能够为你当前面对相似问题提供更多可借鉴的思维和解决问题的实际思路。 第 3 篇[题目] 高性能网络编程(三)：下一个10年，是时候思考C10M并发问题了 [链接] http://www.52im.net/thread-56... [摘要] 本文将探讨单机服务器实现C10M（即单机千万并发连贯）的可能性及其思路。 第 4 篇[题目] 高性能网络编程(四)：从C10K到C10M高性能网络应用的实践摸索 [链接] http://www.52im.net/thread-57... [摘要] 本文内容由京东的资深架构师闫国旗分享，以分享者多年的实际和总结，进一步探讨解决C10M问题的实践可行性。 第 5 篇[题目] 高性能网络编程(五)：一文读懂高性能网络编程中的I/O模型 [链接] http://www.52im.net/thread-19... [摘要] 本文旨在为大家提供有用的高性能网络编程的I/O模型概览以及网络服务过程模型的比拟，以揭开设计和实现高性能网络架构的神秘面纱。 第 6 篇[题目] 高性能网络编程(六)：一文读懂高性能网络编程中的线程模型 [链接] http://www.52im.net/thread-19... [摘要] 限于篇幅起因，请将本文与《高性能网络编程(五)：一文读懂高性能网络编程中的I/O模型》连起来读，这样会让常识更连贯。 第 7 篇[题目] 高性能网络编程(七)：到底什么是高并发？一文即懂！ [链接]http://www.52im.net/thread-31... [摘要] 在面视即时通讯相干工作的时候，高并发也是必谈问题，那到底什么是高并发？嗯，真要说出个所以然来，还真有点懵...本文就与大家一起探讨学习一下。 第 8 篇[题目] 从根上了解高性能、高并发(一)：深刻计算机底层，了解线程与线程池 [链接] http://www.52im.net/thread-32... [摘要] 返璞归真、回归实质，这些技术特色背地的底层原理到底是什么？如何能通俗易懂、毫不费力真正透彻了解这些技术背地的原理，正是《从根上了解高性能、高并发》系列文章所要分享的。 第 9 篇[题目] 从根上了解高性能、高并发(二)：深刻操作系统，了解I/O与零拷贝技术 ...

现互联网上深受用户青睐的软件次要有几个：微信，qq，钉钉等等。然而微信qq动不动就封号，风控严格，如果您对本人做的聊天软件感兴趣的话，请您浏览上来。比照与第三方软件来讲，咱们的【劣势】就很显著： 做本人的社交零碎，社交商城，资源零碎，辞别微信QQ封号无奈和苦楚。数据安全本人一手把握。 零碎功能丰富以及欠缺，已开发减少多种个性化定制性能。不坑不忽悠，反对服务器私有化部署。 星动云即时通讯是为外围、独立部署的即时通讯平台；分服务端、客户端；用户自主装置服务端，成员间的音讯、语音、文件等数据，通过用户本人的服务器直达，不经由第三方服务器；不会成为任何互联网公司大数据的一部分、独立部署、自主治理服务器，用户们的首选平安交流平台。 1、信息安全毕竟第三方软件背地都是公有企业，天然就会有很多人狐疑是不是在监听咱们的聊天记录，偷看咱们的聊天信息，咱们的信息会不会被拿来做大数据分析，并对咱们每个人做画像。而在企业办公中，频繁地传文件是个刚需，秘密的文件传来传去。应用星动云IM公有部署就不会有这个问题，星动云IM公有部署，全链路加密，能够将聊天信息和文件数据牢牢地把握在本人手中。 2、自在第三方软件是个公共场所，对舆论的管控严格。应用星动云即时通讯就能够领有本人掌控的自在，本人的地盘本人说了算。 3、可定制第三方软件是个关闭软件，你只能无条件承受应用，休想去”教他做产品”。而星动云IM开源范畴十分大，能够自在的定制开发，特地是星动云设置时就思考了跟其它零碎的对接，能够跟客户的零碎做深度的对接或者交融，把所有的业务零碎全副接入到星动云中去，或者反过来星动云融入到客户本人的app中，这样可能极大地提高公司的信息化程度，所有的告诉和流程全在手机上实现。这是关闭的第三方软件不可能实现的工作。 4、无限度第三方零碎会有各种各样的限度，比方公众号每天只能发一条，比方群大小只有500人，比方发个文件最大只有200M，比方我的音讯没有存储在服务器上，甚至我想全员播送发个告诉更基本是不可能的事件。这些如果用星动云全都不是问题，公众号想发几条就发几条，群下限想改多大就改多大，文件最大可发送4GB等等。 理解更多能够登录官网征询 https://www.tokim.cn

即时通讯软件曾经成为互联网时代倒退必不可少的通信工具了，即时通讯软件不仅领有便捷的通信条件，还可能高质量的传输视音频文字等，为人们的社交生活和商务工作提供良好的帮忙。即时通讯软件在咱们的生存中占据着重要的位置，然而深究其发展史，大家晓得最早的即时通讯软件是什么吗？ 早在1996年，家用电脑倒退初期，网络通讯晚期就有几名以色列青年研发了一款网络呼叫软件，这也是目前公认的最早的即时通讯服务，而这也是咱们已知最早的即时通讯软件——ICQ。ICQ是目前已知最早的即时通讯软件，于1996年由以色列人发明，这四名发明者于1996年7月成立了名为Mirabilis的公司，并在11月份公布了ICQ的初代版本，仅六个月内有85万用户注册应用。ICQ的母公司Mirabilis于1998年被美国互联网巨头AOL以4.07亿美元收买，但随后的ICQ并没有在即时通讯畛域掀起太大的水花，被收买后的ICQ没有做大做强造成一家独大的位置，而是于2010年被AOL以1.87亿美元价格发售给了DST，逐步被市场所淘汰。若理解即时通讯源码，可征询星动云IM。 ICQ作为最早的即时通讯软件也为起初的即时通讯行业倒退提供了良好的案例和范本。ICQ尽管在创造上具备前瞻性，但其最初倒退过程却并没有咱们熟知的facebook或者推特那么侥幸，后续进入即时通讯畛域的竞争者逐步减少，竞争者实力的一直倒退，ICQ在技术上和概念上的倒退并没可能顺应时代的潮流，在当初曾经少有人提及。 ICQ的倒退还是为后续即时通讯软件的倒退提供了很好的指引方向的，在ICQ倒退晚期还不非常稳固时，过后的互联网一哥雅虎也推出了Yahoo!pager这一工具，参加到即时通讯畛域的角逐中，而微软更是靠着Windows messenger内置零碎退出到了即时通讯的赛道中。国内的即时通讯起家不得不说腾讯QQ，作为目前国内最大的即时通讯软件，其于1998年创立胜利，但倒退初期却远不如ICQ顺畅，晚期一度想要卖身给电信公司，最初通过一系列挫折，成为目前排行前列的互联网公司。随着工夫的推移，最早的即时通讯软件逐步匿影藏形，而早年间即时通讯畛域的王者，当初也面临着新的问题。在互联网时代倒退背景下，即时通讯软件所施展的作用不单单是代替电话等电信通信形式，而是依靠互联网技术这一重要的技术类型，实现更高质量，更高品质的即时通讯交换，比方咱们现阶段熟知的视频即时通讯、语音即时通讯、文字以及图片，大型数据文件的传输等等，都是即时通讯软件为当今时代生存带来的条件和扭转。

在信息时代背景下，即时通讯能够说是与咱们生存相干最为亲密的工具了，即时通讯不仅能够帮忙咱们在亲朋好友之间交换通信，也能够为互联网时代的企业员工交换，企业信息互通发明良好的条件。 那么企业即时通讯工具又应该怎么抉择呢？那些企业即时通讯工具是最好用的呢？理解更多能够登录官网征询 https://www.tokim.cn 企业即时通讯工具是企业工作中帮忙企业办公的重要工具，企业内员工能够通过即时通讯工具进行信息互通，实现各项工作的交换，进步企业办公效率。企业即时通讯工具的抉择有很多思考方面，首先咱们能够来简略理解一下企业即时通讯工具的排行状况。 企业微信能够说是企业即时通讯工具中的龙头老大。在社交通信类软件中腾讯系的位置是不可比较的。而企业微信作为与微信同源的社交软件，则更适宜企业进行工作交换以及工作汇报。以后企业微信能够疾速链接本人的员工，并且通过在线查问等形式，察看员工是否在线，以及员工在线是挪动端还是电脑端登陆状况。企业微信在公司业务性能上极为全面，不仅能够传输文件，还能够进行视频通话、语音通话等等，不便了企业进行信息交换，腾讯的企业微信会议还能够满足企业召开网络会议的作用。 谈到企业即时通讯工具，其实更多人思考的是一些具备商务性质的通信软件。而腾讯系列的企业即时通讯工具中企业QQ其实是一款比企业微信更加具备代表性的即时通讯软件。企业QQ作为商务版QQ囊括了企业办公须要的各类型条件，企业能够通过企业QQ进行客户分割，疾速统计客户相干信息，与企业客户进行商务单干和沟通，帮忙企业进行会议交换和信息沟通。 而同为企业即时通讯工具的阿里巴巴旗下的钉钉天然也不落后。以后钉钉在社交网络中占据的地位并不显著，但要说企业办公，钉钉以优越的关上零碎，日志统计等各类型企业专用的工作条件胜利位居了企业即时通讯工具的帮手，也是以后大中小企业在抉择办公类企业即时通讯工具时的首选。 除了腾讯系列和阿里系列的企业即时通讯工具外，当然还有其余类型的企业即时通讯工具，比方网易旗下的易信等等，另外一些即时通讯工具也能够帮忙企业进行通信交换，然而与上文介绍的工具相比，他们在功能性和稳定性上略有差别。 企业在抉择企业即时通讯工具时应该留神什么呢？首先是即时通讯的便捷性，也就是这款即时通讯工具到底是否满足企业的日常办公须要，其性能以及后续的服务都要欠缺，以保障企业顺利工作。其次就是企业即时通讯工具的稳定性，企业在抉择这类通信工具的时候肯定要留神察看工具网络连接、主动定位等性能是否稳固，更好的满足企业的办公须要。

当今时代互联网技术的倒退突飞猛进，很多传统的软件都有了更多的性能，比方音乐播放软件中的聊天性能、评论性能，视频软件中的弹幕性能等等。而置信很多人对这些软件中是如何实现音频视频聊天性能的存在纳闷，其实通过集成版即时通讯就能够轻松地让软件具备相应的音视频聊天性能。 首先让咱们简略理解一下音视频聊天性能软件的开发流程。对于一个音视频聊天性能来说，如果想要进行语音通信，咱们须要保障软件具备以下几个根底内容，也就是语音采集、回音打消、静音检测、编码、网络传输、解码、缓冲、混音、语音播放。视频聊天同样如此，也须要进行视频的采集、检测、编码和网络传输以及解码等过程，最初进行播放。由上可知，音视频聊天其实是有肯定提早的，这里的提早就是咱们说出语音、发送视频之后解码和传输的过程，在这个过程中处理速度越快，其中的提早也越低，继而就能够实现咱们罕用的即时通讯性能。 而在理论编撰代码时想要达到上述目标，则须要进行很多代码的编写。比方咱们在进行视音频采集时，须要进行客户端的视音频采集、编解码、播放、传输，而在服务端进行治理时，也须要抉择类stun，穿透nat，中专等性能的编撰。局部开源我的项目的解码性能也能够利用起来，比方罕用的视频采集CCameraDS,声音采集PortAudio，以及编解码ffmpeg等。能够说，要在软件中实现视音频通信，齐全通过本身进行代码编写是具备肯定难度的，并且工作量宏大。理解更多能够登录官网征询 https://www.tokim.cn 而现阶段的软件想要具备音视频聊天性能，为了节约工夫，并且进步工作效率，通常会抉择集成版即时通讯来实现。集成版即时通讯顾名思义就是汇合了多种性能的即时通讯零碎，咱们能够在理论工作中依据本人的需要，在即时通讯中进行性能的抉择和利用，更好的实现即时通讯相干内容的扩大。集成版就是能够疾速将单群聊、聊天室、零碎告诉等IM能力集成到客户的产品上，例如可接入到ERP、OA、MES、CRM、游戏聊天室等零碎中。 视音频聊天能够说是即时通讯中最根底且常见的性能了，在进行软件开发和软件钻研时，很多集成版即时通讯自带视音频聊天的性能，在根底条件曾经具备的状况下，想要再去进行视音频聊天性能的细化和优化就更加简略了。比方能够在即时通讯中进行变声、美颜等不同的性能，或者在传输中通过代码优化和改良的形式，更好的进行传输速度的优化，帮忙实现更快捷的即时通讯等。

为了更好地分类浏览52im.net 总计1000多篇精编文章，我将在每周三推送新的一期技术周刊，本次是第2 期。第 1 篇[题目] 脑残式网络编程入门(一)：跟着动画来学TCP三次握手和四次挥手 [链接] http://www.52im.net/thread-17... [摘要]网络编程中TCP协定的三次握手和四次挥手的问题，在面试中是最为常见的知识点之一。本篇文章尝试应用动画图片的形式，来对这个知识点进行“脑残式”解说（哈哈），冀望读者们能够更加简略、直观地了解TCP网络通信交互的实质。 第 2 篇[题目] 脑残式网络编程入门(二)：咱们在读写Socket时，到底在读写什么？ [链接] http://www.52im.net/thread-17... [摘要] 套接字socket是大多数程序员都十分相熟的概念，它是计算机网络编程的根底，TCP/UDP收发音讯都靠它。本篇文章仍然尝试应用动画图片的形式，来对这个知识点进行“脑残式”解说（哈哈），冀望读者们能够更加简略、直观地了解Socket通信的数据读写实质。 第 3 篇[题目] 脑残式网络编程入门(三)：HTTP协定必知必会的一些常识 [链接] http://www.52im.net/thread-17... [摘要]无论是即时通讯利用还是传统的信息系统，Http协定都是咱们最常打交道的网络应用层协定之一，它的重要性可能不须要再强调。然而实际上很多人（包含我本人），尽管每天都会跟http的代码打交道，但对http理解的并不够深刻。本文就我本人的学习心得，分享一下我认为须要晓得的http常见的相干知识点。 第 4 篇[题目] 脑残式网络编程入门(四)：疾速了解HTTP/2的服务器推送(Server Push) [链接] http://www.52im.net/thread-17... [摘要] 服务器推送（server push）是 HTTP/2 协定外面惟一一个须要开发者本人配置的性能。其余性能都是服务器和浏览器主动实现，不须要开发者关怀。本文具体介绍新一代HTTP/2服务器推送技术（server push）的原理和配置办法等。 第 5 篇[题目] 脑残式网络编程入门(五)：每天都在用的Ping命令，它到底是什么？ [链接] http://www.52im.net/thread-19... [摘要] Ping命令很简略，但作为为数不多的网络检测工具，却十分有用，是开发网络应用时最罕用到的命令。尽管“Ping”这个动作这么简略，但你晓得Ping命令背地后的逻辑吗？这就是本文要通知你！ 第 6 篇[题目] 脑残式网络编程入门(六)：什么是公网IP和内网IP？NAT转换又是什么鬼？ [链接] http://www.52im.net/thread-20... [摘要] 搞网络通信利用开发的程序员，可能会常常听到外网IP（即互联网IP地址）和内网IP（即局域网IP地址），但他们的区别是什么？又有什么关系呢？另外，外行都晓得，提到外网IP和内网IP就不得不提NAT路由转换这种货色，那这又是什么鬼？本文就来简略讲讲这些到底都是怎么回事。 第 7 篇[题目] 脑残式网络编程入门(七)：面视必备，史上最艰深计算机网络分层详解 [链接] http://www.52im.net/thread-28... [摘要] 输出URL，到页面出现进去，其中经验了什么？这道面试题的背地，波及到了很多网络原理的常识，咱们这篇文章不会全副分享到，而是先把由来和网络档次划分弄清楚，就实现了这篇文章的目标。 第 8 篇[题目] 脑残式网络编程入门(八)：你真的理解127.0.0.1和0.0.0.0的区别？ [链接] http://www.52im.net/thread-29... [摘要] 对于后端程序员来说，127.0.0.1和0.0.0.0这两个IP地址再相熟不过了，看起来如同就那么回事，但真正较起真来，这两个IP地址到底有什么作用以及到底有什么不同？貌似谁能够轻松答复，但张嘴却又不知从何说起。本文将系统地总结127.0.0.1和0.0.0.0这两个IP地址的作用，以及它们之间的区别，心愿能为你解惑。 ...

即时通讯软件置信大家并不生疏，在互联网技术一直倒退的背景下，现在咱们所应用的即时通讯软件也日渐欠缺，各种基础性的文字、语音、视频即时通讯不再是新鲜事，而即时通讯软件也随之产生了各种变动。当初市面上收费即时通讯和付费即时通讯的数量都不算少，二者之间有何区别呢？理解更多能够登录官网征询 https://www.tokim.cn 收费即时通讯就是咱们最常见的即时通讯工具，通常以软件模式装置在手机或者电脑当中，收费即时通讯的一大特点就是软件应用是收费的，用户可失常应用语音、视频通话以及文字对话等都是收费的。收费即时通讯尽管根底性能是收费的，但在理论利用中也会有一些附加性能免费，并且收费即时通讯软件为了维持经营，服务商在提供给用户即时通讯服务的同时，会承受相应的广告投放业务，应用收费即时通讯难免会接管相应的广告，局部手机上的广告可能还有一些常见的套路，比方广告闪屏持续时间较长或者敞开键难以寻找等。 付费即时通讯在即时通讯工具的用户体验上有更好的体现，最直观的体现就是语音、视频等即时通讯的品质直线回升，除了在即时通讯品质上的晋升外，付费即时通讯也是以后企业最常应用的即时通讯工具。付费即时通讯在软件系统设计中为了投合市场，有更多适宜个人隐私以及企业商务的相干性能，付费即时通讯工具中除了咱们理解的根底文本、语音、视频通信外，还有聊天加密、文件技术传输等性能，能够为用户提供更好的商务性质的即时通讯服务。对于个人用户而言，付费即时通讯除了在通信稳定性和视音频信号保障上有良好的体现外，免广告性能也为很多个人用户提供了更加舒服的即时通讯服务。收费即时通讯与付费即时通讯都是以后互联网市场上比拟常见的即时通讯工具，对于更多的用户来说，抉择收费还是付费类型的即时通讯工具是须要联合本身理论须要来思考的。付费即时通讯软件中依据性能不同、服务范畴不同等，也会有更多的细分，很多企业用户在尝试抉择付费即时通讯时还须要依据企业的需要来定制相应性能，从而更好的实现工作。 收费即时通讯与付费即时通讯不仅在价格上有差别，在性能上以及服务体验方面都有很多的差异，用户在进行抉择的时候最好依据本人的需要和爱好来抉择更加适宜的即时通讯工具，并且留神即时通讯工具的品牌筛选，以便在后续取得良好的售后服务。

置信很多人都据说过开源和非开源这两个概念，在不同畛域中开源与非开源所代表的理念各不相同。明天让咱们从开源即时通讯源码和非开源即时通讯源码角度来简略剖析一下两种源码的差异，继而更好的做出抉择。 开源通常指开放性更高的权限代码。在代码开发畛域，开源个别是可对源代码进行二次开发，批改代码中bug的代码，开源代码在版权标注时显示为开放源码，个别由非营利组织OS协会注册认证并标记。开源代码可被公共应用，并且在后续软件应用、批改、发行的过程中也不会受到限制。能够说开源代码是外部代码齐全凋谢的存在，用户能够依据本人的需要随便的进行性能转变和性能的增加。 与之绝对应的非开源代码则是咱们所说的不晓得源码内容，无奈对源码进行批改和扭转，源码归属开发人所有的代码。非开源的通信源码属于开发人所有的，用户无奈晓得源码的内容，也无奈进行批改。 通过下面的简略概念介绍，咱们就能够分明开源和非开源im即时通讯源码之间的区别了。首先开源即时通讯源码是凋谢权限更高的源码，应用开源即时通讯源码进行软件研发，不仅能够自在的在源码框架上进行批改和性能增加，也能够在后续应用中进行bug修复和一直的性能开发。理解更多能够登录官网征询 https://www.tokim.cn 而非开源im即时通讯源码在应用中的限度更多。首先因为im即时通讯源码属于非开源特点，客户对于源码的内容是并不分明的，想要进行源码的批改或者性能改良，往往须要分割开发人，由开发人进行性能改良。另外非开源im即时通讯源码也有着版权限度，普通用户或者客户想要在非开源im即时通讯中依照本人的动向随便进行源码的开发和改变，属于侵权行为，可能受到相应的处罚。 开源在代码开发畛域具备非常重要的意义，有数用户利用开源的im即时通讯源码研发出更多更先进的内容，实现资源的优化。很多人认为开源等于收费，这种想法是全面的，开源代码最大的特点在于其开放性，可能让任何人在此基础上进行学习改良和发放，但也是有相应的版权限度的。而非开源也不齐全意味着免费，非开源更是一种对版权的保护，也是对开发人权利的保障。 在古代网络倒退中，开源代码与非开源代码的协同利用才可能更好的推动信息技术的提高和倒退。而对于im即时通讯开发来说，普通人想要进行im即时通讯开发，应该抉择相应的开源代码，在版权许可中进行性能的改良和优化，实现本人的软件开发和优化。非开源im即时通讯源码的限度较多，会影响咱们的开发过程。

互联网时代造就了一批新型产业和体系，而在各类型互联网企业中，软件开发特地是即时通讯软件的开发与利用更是重要的形成。很多人在想到即时通讯时都会被其高质量的信息通信技术以及疾速的信息传输速度所折服，同时也会开始好奇，开发即时通讯到底须要什么样的技术，须要多久的工夫，有须要破费多少资金。接下来让咱们一一解答。 即时通讯的开发是互联网行业中比拟具备技术性的软件开发内容，随着互联网技术的倒退，以后的软件开发曾经不须要工程师从头进行所有程序的编写了，大量开源代码以及共享体系的利用，使得很多工程师能够独立实现一些小型软件的开发制作，无论是工作量还是工作破费上都有了很大的缩小。而即时通讯作为软件开发中具备技术性的一类，在当初的破费和工期依然具备肯定不确定性，能够说，开发即时通讯所须要的工夫和破费在很多状况下是依据软件开发的要求以及开发公司本身技术所提供的。理解更多能够登录官网征询 https://www.tokim.cn 即时通讯的开发工夫会随着即时通讯的性能与内容需要而产生变动。要理解即时通讯开发的具体工夫，首先须要思考本次开发即时通讯的相干要求，在即时通讯开发中须要通过需要剖析、UI设计、APP开发以及零碎测试等阶段实现的。其中需要剖析须要理解即时通讯应该具备什么性能，满足何种需要；在进行UI设计时能够依据理论状况抉择业余设计师或者其余资源来进行UI的设计；在进行APP开发时，更是须要第一阶段的性能需要来进行理论的性能程序编写；最初当所有工序实现后还须要通过零碎测试来跑代码，测验即时通讯是否设计胜利。即时通讯开发的所需工夫通常是不固定的，大厂的工作效率与小厂的工作效率不同，不同复杂程度的即时通讯软件须要的开发工夫也各不相同。如果是集成版的即时通讯，那么开发到交付实现，蔚可云只须要不到一周的工夫，就可部署到客户的app上，让用户立刻领有即时通讯聊天性能。再来谈即时通讯的开发费用问题。很多人感觉即时通讯能够通过集成技术以及开源代码的利用等疾速实现软件的开发，那么价格应该比拟低，而理论状况也同样与上述开发内容一样，依据不同即时通讯的复杂程度、开发工期，最终须要的破费也是不固定的。以蔚可云为用户提供的即时通讯为例，体验版、集成版、定制版以及源码版各具备不同的价格。通常集成版因为汇合了大量的性能和内容价格个别2W起，而定制版即时通讯的价格从10W起，依据客户开发的不同需要，还会有具体的价格计算等。 即时通讯作为互联网时代的重要工具，想要开发即时通讯所须要耗费的工夫和费用都是须要认真剖析的，只有做到充沛理解，才可能更好的研发合乎本人需要的软件。

即时通讯当初曾经随着互联网技术的利用走进了千家万户，跟早些年的通信工具不同，当初的即时通讯技术曾经涵盖了语音即时通讯、视频即时通讯、文字即时通讯等多种形式，而开发即时通讯也成了很多互联网企业投身这一行业后想要尝试的内容。开发即时通讯容易吗？开发即时通讯都须要用到什么技术呢？ 即时通讯软件的开发切实算不上容易，因为在开发即时通讯软件的过程中牵扯到的可不仅仅是通信技术，受到以后网络技术倒退和网络信息安全保障等条件的影响，咱们明天的即时通讯开发还须要牵扯到网络技术、窃密技术以及P2P技术等多种技术类型。接下来让咱们对它们进行简略的剖析。 即时通讯的开发首先波及到通信技术。通信技术是即时通讯中最为要害且重要的技术类型，现阶段的即时通讯除了须要传输文字、图片、短视频等媒体文件外，为了保障通信的综合性还须要实现音视频语音对话的性能，也就对咱们的通信技术提出了更高的要求。在通信技术应用中，设计人员须要进行视频、文字、音频等多种信息的信号编码录入和输入技术的利用，让通信技术可能与网络相结合，从而实现即时通讯的过程。 网络技术也是即时通讯中不可短少的内容。咱们把即时通讯与传统通信技术相比拟，就会发现即时通讯是一种将传统通信转移到网络系统中的新型通信形式，即时通讯中网络施展的作用也不单单是网络根底连贯和沟通，还有网络信号的传输速度和传输稳定性。即时通讯中如果网络传输速度慢，就会产生通信提早的问题，如果传输不稳固就会产生卡顿等状况，影响咱们的即时通讯过程，尤其在以后无线网络信号广泛应用的背景下，即时通讯的网络技术更是比拟重要的内容。理解更多能够登录官网征询 https://www.tokim.cn 说起P2P技术，很多敌人或者不理解它与即时通讯之间的关系。P2P也就是咱们常说的点对点技术，也能够被称为对等互联网技术，这样解释大家或者就会明确它跟网络技术之间的蕴含关系了。以后的P2P技术被广泛应用于实时媒体业务的数据通信中，能够对互联网通信中的客户端-服务器模型等进行更好的服务，帮忙咱们进行即时通讯的无效设计。 窃密技术天然也是即时通讯中不可短少的技术。即时通讯不单单是一种信息的交换或者沟通，更在于信息的保密性，如果即时通讯过程中不进行信号的爱护或者信息的爱护，很容易呈现即时通讯内容泄露等问题，也影响了即时通讯单方的信息安全，造成严重后果，因而以后的即时通讯必须要在窃密技术高低足功夫。 即时通讯的开发并不容易，全副从零开始是须要很长时间的，然而如果想要疾速开发零碎，也能够应用即时通讯源码等业余解决方案进行疾速开发。即时通讯开发的性能越多，那么所须要的工夫越多，有的一个月不到可实现，有的可能须要好几个月，如果有须要，可找星动云业余的即时通讯开发商，可提供集成板、定制版、源码版等多版本，欢送征询星动云客服。

即时通讯当初曾经随着互联网技术的利用走进了千家万户，跟早些年的通信工具不同，当初的即时通讯技术曾经涵盖了语音即时通讯、视频即时通讯、文字即时通讯等多种形式，而开发即时通讯也成了很多互联网企业投身这一行业后想要尝试的内容。开发即时通讯容易吗？开发即时通讯都须要用到什么技术呢？ 即时通讯软件的开发切实算不上容易，因为在开发即时通讯软件的过程中牵扯到的可不仅仅是通信技术，受到以后网络技术倒退和网络信息安全保障等条件的影响，咱们明天的即时通讯开发还须要牵扯到网络技术、窃密技术以及P2P技术等多种技术类型。接下来让咱们对它们进行简略的剖析。 即时通讯的开发首先波及到通信技术。通信技术是即时通讯中最为要害且重要的技术类型，现阶段的即时通讯除了须要传输文字、图片、短视频等媒体文件外，为了保障通信的综合性还须要实现音视频语音对话的性能，也就对咱们的通信技术提出了更高的要求。在通信技术应用中，设计人员须要进行视频、文字、音频等多种信息的信号编码录入和输入技术的利用，让通信技术可能与网络相结合，从而实现即时通讯的过程。 网络技术也是即时通讯中不可短少的内容。咱们把即时通讯与传统通信技术相比拟，就会发现即时通讯是一种将传统通信转移到网络系统中的新型通信形式，即时通讯中网络施展的作用也不单单是网络根底连贯和沟通，还有网络信号的传输速度和传输稳定性。即时通讯中如果网络传输速度慢，就会产生通信提早的问题，如果传输不稳固就会产生卡顿等状况，影响咱们的即时通讯过程，尤其在以后无线网络信号广泛应用的背景下，即时通讯的网络技术更是比拟重要的内容。理解更多能够登录官网征询 https://www.tokim.cn 说起P2P技术，很多敌人或者不理解它与即时通讯之间的关系。P2P也就是咱们常说的点对点技术，也能够被称为对等互联网技术，这样解释大家或者就会明确它跟网络技术之间的蕴含关系了。以后的P2P技术被广泛应用于实时媒体业务的数据通信中，能够对互联网通信中的客户端-服务器模型等进行更好的服务，帮忙咱们进行即时通讯的无效设计。 窃密技术天然也是即时通讯中不可短少的技术。即时通讯不单单是一种信息的交换或者沟通，更在于信息的保密性，如果即时通讯过程中不进行信号的爱护或者信息的爱护，很容易呈现即时通讯内容泄露等问题，也影响了即时通讯单方的信息安全，造成严重后果，因而以后的即时通讯必须要在窃密技术高低足功夫。 即时通讯的开发并不容易，全副从零开始是须要很长时间的，然而如果想要疾速开发零碎，也能够应用即时通讯源码等业余解决方案进行疾速开发。即时通讯开发的性能越多，那么所须要的工夫越多，有的一个月不到可实现，有的可能须要好几个月，如果有须要，可找星动云业余的即时通讯开发商，可提供集成板、定制版、源码版等多版本，欢送征询星动云客服。

说起即时通讯大家都不会感到生疏，即时通讯软件是与咱们生存非亲非故的一种软件系统。而在收集相干资讯的时候，很多敌人也常常看到即时通讯源码的相干信息，那么平时常常看到的即时通讯源码是什么呢？ 即时通讯源码是即时通讯零碎中最为重要的内容。咱们都晓得，即时通讯软件作为一种信息化的软件系统，其外围在于开发，而不同的互联网公司在进行即时通讯软件设计的时候，须要设计初始的即时通讯源码，在源码的根底上进行二次开发。因而咱们能够将其简略了解为源代码，也成为开源代码，它能够认为是即时通讯软件的骨骼。 如果将即时通讯源码作为骨骼或者灵魂来进行剖析的，咱们就会对即时通讯软件有更深刻的认知了。作为现代化的软件系统之一，即时通讯软件同样是依靠于初始的即时通讯源码进行开发的，互联网大厂有本人造成一套残缺体系的即时通讯源码，而很多小厂想要真正意义上实现原创和开发，还须要在即时通讯源码中很下功夫，依据本人对于编程的了解进行设计和一直的优化。 对于互联网公司来说，把握即时通讯源码就好比在科技研发中把握外围科技一样，能够在后续的开发工作中进行更加精确无效的研发。咱们在即时通讯源码的开发和利用中须要分外留神的一点就是保障即时通讯源码的平安。一方面，对于互联网公司而言，即时通讯源码属于商业秘密，一旦泄露可能被其余公司拿去进行换皮应用，发明出本人的通信软件，并且还可能陷入版权纷争。另一方面，对于网络黑客而言，一旦公司的即时通讯源码泄露，黑客很可能从源代码动手进行攻打和勒索，导致互联网公司的即时通讯软件安全性受到影响。 即时通讯源码是互联网公司进行即时通讯软件设计以及后续软件开发的重要条件，是一个即时通讯软件的骨骼与灵魂，对即时通讯软件来说极为要害。即时通讯源码并不是一个美中不足的代码，对于很多互联网企业来说，把握一个根底的即时通讯源码，在后续想要进行更加深刻的零碎开发以及功能完善，都须要耗费相当长的工夫与能源。 即时通讯源码的初始条件越好，可扩展性越高，后续能够搭载的性能和倒退的后劲就越好。理解更多能够登录官网征询 https://www.tokim.cn 即时通讯源码作为以后互联网企业钻研即时通讯软件时不可短少的极为重要的源代码，无论是研发的人员还是研发的技术要求都比拟高，在以后互联网高速倒退的背景下，其发展潜力仍不可漠视。想要更好的进行即时通讯软件IM的设计以及后续经营和推广，就必须对即时通讯源码进行更好的把握，从主观理论以及程序编撰角度登程，一直优化和欠缺来实现即时通讯源码的改进。

即时通讯是近年来比拟热门的话题，互联网技术的倒退以及信息时代的推动让当今时代每个人都通过网络连接起来，即时通讯的呈现更是逐步取代了传统通信形式，让网络视频、语音、直播等成了拉近人们关系的重要媒介。即时通讯不仅在私人通信中施展着良好的作用，在企业办公以及业务办理上更是具备重要的意义。那么即时通讯个别须要用什么技术开发，即时通讯的离线推送又是怎么实现的呢？ 即时通讯是一种软件系统，想要设计和开发一项即时通讯软件首先须要具备良好的网络工程学常识，可能编写即时通讯源码，以后市场上各大平台和服务商也为不同需要的客户提供了开源和非开源的源码，可能帮忙大家更好的进行即时通讯程序的编撰。 想要开发一个优质的即时通讯软件，不仅须要具备根底的编程技术，还要具备通信技术、网络技术、P2P技术以及窃密技术等诸多技术手段，另外现阶段即时通讯大多须要整合视音频输出和传输零碎，在进行即时通讯软件开发时也须要具备相应的教训。理解更多能够登录官网征询 https://www.tokim.cn 即时通讯软件开发中不仅须要对系统的底层逻辑有良好的认知，还要理解不同即时通讯软件的功能设计以及网络通讯编程等不同内容，在进行即时通讯软件开发是，选用c语言等不同开发语言也会对即时通讯的最终成果产生影响，目前的支流即时通讯，采纳的Java技术进行开发的比拟广泛。以后市面上存在的即时通讯软件中不乏优质的编程实用案例，而更多的服务商也可能为客户提供更加个性化、集成化的优质即时通讯软件，客户能够依据本人的需要定制相应的即时通讯软件。 即时通讯的离线推送是一项比拟重要的性能。现阶段大多数即时通讯软件都须要具备肯定的离线推送能力，以便于在APP退至后盾或者过程终止的状况下及时揭示用户新音讯，防止用户在应用即时通讯软件时产生信息脱漏，或者解决不及时等问题。并且鉴于现阶段即时通讯软件在IOS零碎和Android零碎中的不同特点，在进行离线推送时也须要构建不同的推送条件。IOS零碎中APNs推送通常须要进行设置Token、切后盾上报未读讯息、切前台进行告诉以及Ext扩大设置等环节，在设置推送Ext扩大字段时，为了不便用户点击跳转，还须要填写到即时通讯的Ext字段，便于即时通讯IM将字段填写至推送中，帮忙用户及时进行信息查阅。另外推送还应该留神设计音讯揭示，常见的比方推送振动、推送声音等揭示，也须要在TIMCustomElem中设置相应的字段，来帮忙实现推送声音和振动等设置。Android零碎的离线推送设置与IOS的推送设置环节具备肯定相似性，在理论设计中可依据具体情况进行调整。

谈到即时通讯视频聊天，置信大家都不会感到生疏，以后市面上各种类型的即时通讯聊天工具数量不胜累举，社交即时通讯软件、工作即时通讯软件、集体即时通讯软件、商用即时通讯软件、免费软件、付费软件等等，用户总可能依据本人的需要抉择一款适合的即时通讯软件工具。 明天咱们来理解一下，市面上常见的即时通讯视频聊天原理是什么。 任何网络软件在探讨其原理的时候，都不可避免的须要说道编程相干的内容，即时通讯视频聊天同样如此，并且与惯例理解的软件程序不同，即时通讯视频聊天不仅须要思考到视频和音频信号的传输，还须要思考到信号的采集与编码等各项常识。因而在剖析即时通讯视频聊天原理时，首先咱们要理解即时通讯软件进行视频聊天的数据传输全过程。若理解即时通讯源码，可征询星动云IM。  以后即时通讯视频聊天不仅包含动静图像的传输，同样也随同着语音的传输，因而即时通讯工具在进行视频聊天时，须要具备相应的信息采集性能以及传输性能。咱们常见的视频聊天就是通过视频图像采集、检测、编码、网络传输、解码、缓冲等诸多环节实现的，并且因为少数的视频聊天同样随同着音频聊天，在传输视频图像的同时，软件还须要实现语音采集、回音打消、静音检测、编码、网络传输、解码、缓冲、混音、语音播放的流程，从而实现即时通讯的残缺过程。  而即时通讯视频聊天的原理就是在上述流程中，通过各类型的采集工具与程序进行编程与解码，依据不同环节的差别，在理论进行视音频播放采集过程中，须要抉择不同类型的性能我的项目，比方服务端治理中stun、穿透nat、直达等程序的编写是不可或缺的内容，解码性能中开源解码程序的应用，ffmpeg编解码的利用，视频采集CCameraDS，声音采集PortAudio等，都是即时通讯视频聊天中应该关注到的内容。

2011年推出微信，腾讯在买通中国熟人关系链的同时，也在一直打造微信生态，拓展微信领取、小程序等性能。尽管微信生态颇具体量，但尾大不掉也是事实。 腾讯2018年度Q2财报显示，微信用户数量已超10亿。但用户总量数据讨喜的背地，是增速的放缓。 据极光大数据《2017年Q4暨全年挪动互联网行业数据钻研报告》，从2017年第四季度开始，QQ、微信都呈现了不同幅度的增速下滑，QQ下滑0.68% 、微信下滑0.52%。 微信的用户增长已逐步迫近天花板，用户数量已靠近饱和。这不仅是微信的焦虑，它反映的更是曾经陈词滥调的话题——中国移动互联网的红利期行将完结。去年第四季度起智能手机出货量疲软、微博京东往年一季度月活较去年第四季度增速减缓，都进一步佐证了这一观点。 从2018年6月开始，腾讯改版微信公众号、弱化订阅号本身品牌，强化“信息流”概念。起因在于，微信公众号已不复凋敝态势。据新榜公布的《2017年中国微信500强年报》，公众号整体均匀阅读数降落了24%。头条的信息流模式也让腾讯感到缓和。因而，微信的信息流尝试，一是心愿加强用户粘性和应用时长，二是心愿通过信息流广告实现变现。 除了在微信生态内进行改版，在应用场景上，腾讯更是将微信与其车联网策略联合。10月18日，在世界智能网联汽车大会上，马化腾称腾讯正在研发车载微信，采纳全语音交互的模式收发微信音讯，并且能够跟车载硬件联合，通过方向盘按键就能平安地收发音讯。 这意味着微信的应用场景在进一步拓宽，应用的频率和时长都会进一步减少。 腾讯2017财报指出，年龄在21岁及以下用户的智能终端月沉闷账户同比增长。另外， 腾讯QQ主推的信息流模块QQ看点中，21岁及以下用户占比超过50%，QQ趣味部落中的年老沉闷用户更是超过八成。 网友YOLO对钛媒体示意，00后的熟人圈子都在QQ上，下面有他们的同学敌人和班级群，QQ空间里沉闷的全是00后。“我给妹妹发微信她根本不回，然而打QQ电话一打一个准。”理解更多能够登录官网征询 https://www.tokim.cn 自2014年起腾讯就对QQ进行了年轻化转型，推出QQ看点和趣味部落两个模块，也上线了像斗图、变声、高能舞室等小性能。QQ转型的最大变动就是推出了QQ看点和趣味部落。可是，QQ看点内容品质参差不齐。趣味部落在QQ面板中的地位也较为荫蔽，属于边缘产品。在同学和班级群的熟人关系外，趣味部落尽管能通过话题和趣味圈层将00后的关系打散重组，可陌生人社交与QQ的固有调性不符。而且QQ的各项性能都是为熟人社交而设计，用户的应用习惯很难扭转。另外，尽管趣味部落的年老沉闷用户超过八成，然而其属性更像百度贴吧，用户更偏向于看帖子而非交友。 QQ的年轻化路线取得了00后的认可，却难以冲破熟人社交的瓶颈，所以激荡不起陌生人社交的水花。 QQ的窘境不止于此。首先，当00后走出校园，社交圈不再围绕同学和班级时，他们会因为工作生存再转回微信中。另外，出于拓展社交圈的须要，QQ和微信都无奈满足的陌生人社交需要，将由陌陌、探探和新兴的社交产品来分担。最初，从2017年第四季度开始，QQ用户的增速开始下滑也是挑战之一。 微信和QQ确实是挡在社交创业者背后的大山，但未被满足的需要仍然强劲，有待发掘。

在互联网如此发达的明天，即时通讯软件曾经是以后各类型软件中比拟重要的工作和生存中须要用到的工具了，不过对于即时通讯软件的常见类型，大家都分明吗？ 微信是咱们日常生活中最近常应用的即时通讯软件。很多敌人对于即时通讯软件的认知是比拟全面的，因为阿里等公司推出的即时通讯软件办公类软件逐步在工作中被广泛应用，大家就广泛将IM与咱们的办公软件混同，其实即时通讯软件从实质上来说，除了用于工作以外生存也是比拟罕用的类型。那么在咱们日常生活中出场频率最高的微信天然是其中之一了。 腾讯QQ以及其TIM版本同样在即时通讯软件这个分类中占据了极为重要的地位。说起即时通讯软件腾讯系社交类软件无出其右，作为国内倒退最早也是倒退品质最好的社交类零碎，腾讯的QQ以及TIM版无论是在内容上还是在性能拓展方面都有着其余即时通讯软件无可比拟的劣势。腾讯系列的QQ与TIM也是最早反对视频会议等相干群组会议的软件之一，在没有正式化的工作即时通讯软件之前，腾讯系的即时通讯软件是咱们进行会议交换，直播等必不可少的工具。 阿里旗下的即时通讯软件大家的第一反馈或者是工作关上类的软件就是钉钉。相较于其余即时通讯软件中对于对话、会议以及生存和工作互相融合的设计，阿里旗下的即时通讯软件更是间接为社畜服务的一款通信类软件。阿里在资金反对以及软件开发方面的力度并不小，钉钉现在相较于阿里最后想要推的即时通讯软件，更偏向于一款业余的关上办公软件，也算是在即时通讯软件中进行了进一步的市场细分。 除了咱们上文提到的这些比拟常见的互联网大厂开发的即时通讯软件外，还有很多并不非常闻名，然而性能也比拟不便好用的即时通讯软件。在当初互联网市场上，次要经营即时通讯类软件的厂商并不算多，大家更偏向于在社群等方面下功夫。理解更多能够登录官网征询 https://www.tokim.cn 然而即时通讯软件作为当代人进行社交时不可短少的工具，市场需求始终存在，如何从细分畛域动手，在即时通讯软件这一畛域进行深刻开掘和精准的需要定位，是以后很多互联网软件开发公司正在探寻的。

本文由vivo技术团队Yang Kun分享，原题“electron 利用开发优良实际”，本文有订正。 1、引言在上篇《Electron初体验(疾速开始、跨过程通信、打包、踩坑等)》的分享中，咱们曾经对Electron跨端框架的开发有了大略的理解。本篇将基于vivo技术团队的技术实际，具体论述了vivo在应用Electron进行跨端桌面开发时的技术栈选型考量，同时分享了在打包构建、版本更新、性能优化、品质保障、安全性等方面的实际计划和踩坑总结。 学习交换：- 挪动端IM开发入门文章：《新手入门一篇就够：从零开发挪动端IM》- 开源IM框架源码：https://github.com/JackJiang2...（备用地址点此）（本文已同步公布于：http://www.52im.net/thread-40...） 2、系列文章本文是系列文章中的第3篇，本系列总目录如下： 《IM跨平台技术学习(一)：疾速理解新一代跨平台桌面技术——Electron》《IM跨平台技术学习(二)：Electron初体验(疾速开始、跨过程通信、打包、踩坑等)》《IM跨平台技术学习(三)：vivo的Electron技术栈选型、全方位实际总结》（* 本文）《IM跨平台技术学习(四)：蘑菇街基于Electron开发IM客户端的技术实际》（稍后公布.. ）《IM跨平台技术学习(五)：融云基于Electron的IM跨平台SDK革新实际总结》（稍后公布.. ）《IM跨平台技术学习(六)：网易云信基于Electron的IM音讯全文检索技术实际》（稍后公布.. ） 3、技术背景因业务倒退，咱们须要用到桌面端技术，技术个性波及离线可用、调用桌面零碎能力等要求。那么什么是桌面端开发？一句话概括就是：以 Windows 、MacOS 和 Linux 为操作系统的桌面软件开发。对此咱们做了具体的技术调研：桌面端的开发方式次要有 Native 、 QT 、 Flutter 、 NW 、 Electron 、 Tarui 。这些技术各自优劣势如下表格所示： 咱们最终的桌面端技术选型是 Electron，Electron 是一个能够应用 Web 技术来开发跨平台桌面利用的开发框架。其技术组成如下：Electron = Chromium + Node.js + Native API各技术能力如下图所示：整体架构如下图所示： Electron 是多过程架构，架构具备以下特点：1）由一个主过程和 N 个渲染过程组成；2）主过程承当主导作用，用于实现各种跨平台和原生交互；3）渲染过程能够是多个，应用 Web 技术开发，通过浏览器内核渲染页面；4）主过程和渲染过程通过过程间通信来实现各种性能。这里回顾一下 Electron 过程间通信技术原理。electron 应用 IPC （interprocess communication） 在过程之间进行通信。如下图所示： 其提供了 IPC 通信模块，主过程的 ipcMain 和渲染过程的 ipcRenderer。从 electron 源码中能够看出， ipcMain 和 ipcRenderer 都是 EventEmitter 对象。源码如下图所示： 看到源码实现，是不是感觉 IPC 不难理解了。知其本质，方可熟能生巧。限于篇幅，这里对Electron的基础知识就不再开展，有趣味的读者可回顾一下本系列的前两篇《疾速理解新一代跨平台桌面技术——Electron》、《Electron初体验(疾速开始、跨过程通信、打包、踩坑等)》（这篇中的“5、过程详解”特地介绍了Electron过程间的关系以及通信原理）。 4、开发技术栈选型4.1编程语言选型咱们最终抉择的是Typescript，理由如下。针对开发者：1）Javascript 的超集（无缝反对所有的 es2020+ 所有的个性，学习老本小）；2）编译生成的 JavaScript 的代码放弃很好的可读性；3）可维护性明显增强；4）残缺的 OOP 的反对（extends, interface， private， protect， public等）；5）类型即文档；6）类型的束缚，更少的单元测试的笼罩；7）更平安的代码。针对工具：1）更好的重构能力；2）动态剖析主动导包；3）代码谬误查看；4）代码跳转；5）代码提醒补齐。社区反对：大量的社区的类型定义文件 晋升开发效率。4.2构建工具选型咱们抉择的是 Electron-Forge。理由很充沛：Electron-Forge简略而又弱小，目前 electron 利用最好的构建工具之一。这里提一下 electron-builder 其和 electron-forge 的介绍和区别。看下图所示：两者最大的区别在于自由度，两者在能力上根本没什么差别了，从官网组织中的排序看，无意优先举荐 electron-forge 。4.3Web计划选型咱们采纳的是 Vue3 ，同时应用 Vite 作为构建工具，具体长处，大家能够查看官网介绍，这套组合是目前支流的 Web 开发计划。4.4monorepo计划选型目前的 monorepo 生态百花齐放，正确的实际办法应该是集大成法，也就是取各家之长，目前的趋势也是如此，各开源 monorepo 工具达成默契，专一本人善于的能力。如 pnpm 善于依赖治理， turbo 善于构建工作编排。遂在 monorepo 技术选型上，我抉择了 pnpm 和 turbo 。以下是pnpm的官网：pnpm 理由如下：1）目前最好的包管理工具（pnpm 排汇了npm、yarn、lerna等支流工具的精髓，并去其糟粕）；2）生态、社区沉闷且弱小；3）联合 workspace 能够实现 monorepo 最佳设计和实际；4）在治理多我的项目的包依赖、代码格调、代码品质、组件库复用等场景下，表现出色；5）在框架、库的开发、调试、保护方面，表现出色。相比于 vue 官网，在应用 pnpm 上，我加了 workspace 。turbo 理由如下：1）它是一个高性能构建零碎（领有增量构建、云缓存、并行执行、运行时零开销、工作管道、精简子集等个性）；2）具备十分优良的工作编排能力（能够补救 pnpm 在工作编排上的短板）。4.5本地数据库选型Electron 利用数据库有十分多的抉择如 lowdb 、 sqlite3 、 electron-store 、 pouchdb 、 dedb 、 rxdb 、 dexie 、 ImmortalDB 等。这些数据库都有一个个性，那就是无服务器。Electron本地数据库技术选型思考因素次要有：1）生态（使用者数量、保护频率、版本稳定度）；2）能力；3）性能；4）其余（和使用者技术匹配度）。咱们通过以下渠道进行了相干调研：1）github 的 issues、commit、fork、star；2）sourcegraph 关键字搜寻后果数；3）npm 包下载量、版本公布；4）官网和博客。给出四个最优抉择，别离是 lowdb 、 sqlite3 、 nedb 、 electron-store 。咱们的理由如下：1）lowdb：生态、能力、性能三方面体现优良， json 模式的存储构造， 反对 lodash 、 ramda 等 api 操作，利于备份和调用；2）sqlite3：生态、能力、性能三方面体现优良， Nodejs 关系型数据库第一抉择计划；3）nedb：能力、性能三方面体现优良，毛病是根本不保护了，但底子还在，尤其操作是 MongoDB 的子集，对于相熟 MongoDB 的使用者来说是绝佳抉择；4）electron-store：生态体现优良，轻量级长久化计划，简略易用。咱们应用的数据库最终选型是 lowdb 计划。PS：提一下 pouchdb ，如果须要将本地数据同步到远端数据库，能够应用 pouchdb ，其和 couchdb 能够轻松实现同步。4.6脚本工具选型软件开发过程中，将一些流程和操作通过脚本来实现，能够无效地进步开发效率和幸福度。依赖 node runtime 的优良抉择就两个：shelljs 和 zx 。抉择 zx 的理由如下：1）自带 fetch 、 chalk 等罕用库，应用方便快捷；2）多个子过程方便快捷（执行远端脚本、解析 md 、 xml 文件脚本、反对 ts），功能丰富且弱小；3）谷歌出品、大厂背景，生态十分沉闷。至此，技术选型就介绍完了。 ...

互联网倒退与咱们的生存和工作有着密切联系，在以后互联网倒退背景下，利用即时通讯软件进行日常工作和生存交换曾经成为新的热潮，随着互联网办公日益衰亡后，即时通讯集成版也走入了大家的视线中，依靠即时通讯集成版可能更好更快的实现工作上的交换和交接，那么即时通讯集成版能够接入到那些行业中呢？ 即时通讯集成版是一种性能更加弱小并且专业性更强的即时通讯工具，通过即时通讯集成版咱们能够轻松地与集体、个人等进行信息交换和互通。以后的即时通讯集成版能够疾速构建群聊、聊天室、零碎告诉等流动，帮忙企业更好的进行外部工作交换，同时也能够帮忙企业与客户之间搭建良好的沟通平台。 即时通讯集成版能够连贯销售产业的ERP零碎中。企业资源打算（ERP）是一种企业系统化管理工具，以后各类型的ERP零碎不仅为企业外部调动人力物力资源提供了迷信的计划，同时也对市场剖析、进行灵便的业务流动提供良好的服务，而即时通讯集成版能够接入ERP零碎中，为企业ERP提供良好的服务和帮忙。理解更多能够登录官网征询 https://www.tokim.cn 即时通讯集成版也能够与办公OA零碎相连接。办公自动化（OA）是以后少数企业在经营倒退中都面临的一种工作模式转型，OA零碎的利用为企业日常进行工作事物解决，流转、审批、公布公文等提供了更加规范化、信息化的条件，而想要进步OA零碎工作效率，也能够通过即时通讯集成版来实现。即时通讯集成版接入OA可能无效缩短工作流程中单方交换的工夫和空间间隔，更加疾速无效的做出信息交换和沟通，从而晋升OA工作效率，让企业实现良好的倒退。 即时通讯集成版能够接入生产制造业的MES零碎。MES零碎是以后企业倒退中的优化管理系统，对于工业农业生产来说，MES可能对制造业中的人、设施、物料、客户需要等进行精准定位和无效剖析，而想要实现MES从订单下达到产品实现整个生产过程的优化治理，也离不开即时通讯集成版的反对。即时通讯集成版的助理可能让MES零碎在工作中更加及时无效的接管最新信息资源，进步工作解决能力。即时通讯集成版也能够接入服务产业的CRM零碎中。客户关系治理（CRM）是新态企业治理的重要理念形式，在CRM零碎中，只有通过无效的形式更加靠近客户、理解客户、满足客户才可能最大限度的增加利润，而即时通讯集成版在这个过程中能够为CRM提供良好的连贯，帮忙服务产业企业更好的与客户进行交换沟通，进步工作的效率和品质。 即时通讯集成版与各行业和现代化企业倒退有亲密的分割，通过即时通讯集成版的接入能够让办公更加先进、便捷，能进步行业倒退的工作效率。蔚可云即可提供IM即时通讯集成版服务，可让企业软件疾速领有聊天性能。

本文由蘑菇街前端技术团队分享，原题“Electron 从零到一”，有订正和改变。 1、引言在上篇《疾速理解新一代跨平台桌面技术——Electron》，咱们曾经对Electron跨端框架有了根本的意识。 本篇将带你简略上手Electron框架开发跨平台桌面端，内容包含一个疾速开始例子、跨过程通信原理、打包和散发、以及一些典型的技术踩坑等。心愿能带给你启发。 学习交换： 挪动端IM开发入门文章：《新手入门一篇就够：从零开发挪动端IM》开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）（本文已同步公布于：http://www.52im.net/thread-4039-1-1.html） 2、系列文章本文是系列文章中的第2篇，本系列总目录如下： 《IM跨平台技术学习(一)：疾速理解新一代跨平台桌面技术——Electron》《IM跨平台技术学习(二)：Electron初体验(疾速开始、跨过程通信、打包、踩坑等)》（* 本文）《IM跨平台技术学习(三)：vivo的Electron具体技术栈选型、踩坑总结等 》（稍后公布.. ）《IM跨平台技术学习(四)：蘑菇街基于Electron开发IM客户端的技术实际》（稍后公布.. ）《IM跨平台技术学习(五)：融云基于Electron的IM跨平台SDK革新实际总结》（稍后公布.. ）《IM跨平台技术学习(六)：网易云信基于Electron的IM音讯全文检索技术实际》（稍后公布.. ） 3、Electron简介Electron 是一个赋力前端进行跨平台开发的框架，让开发人员应用 JavaScript、HTML 和 CSS 等前端技术构建跨平台的桌面利用。 Electron 通过将 Chromium（所有类Chrome的浏览器都是基于这个开源工程而来） 和 Node.js 合并到同一个运行时环境中（见下图），并将其打包为 Mac，Windows 和 Linux 零碎下的利用，而开发人员只需关注前端代码的开发。▲ 上图援用自《疾速理解新一代跨平台桌面技术——Electron》 Chromium、Node.js、Native API这三者的作用别离是： 1）Chromium ：为Electron提供了弱小的UI能力，能够不思考传统浏览器兼容性的状况下，利用弱小的Web生态来开发界面；2）Node.js：让Electron有了底层的操作能力（比方文件的读写，甚至是集成C++等等操作），并能够应用大量开源的npm包来实现开发需要。3）Native API：Native API让Electron有了跨平台和桌面端的原生能力（比如说它有对立的原生界面，窗口、托盘、音讯告诉这些）。Electron就是通过这三者的奇妙组合，让咱们开发跨平台利用变的非常高效。 实质上就是chromium（chrome开源版本）浏览器，有最新的货色都会在chromium测试，所以electron能够体验最新的api，这也是益处之一。 无关Electron的根本介绍等，这里就不再赘述，如果您还未曾理解，能够先浏览本文的上篇。 4、疾速开始4.1 材料筹备Electron 官网提供了一个名为electron-quick-start 的我的项目，能够 clone 下来当成模版应用，本文应用 create-react-app 来一步一步学习。 其它重要的Electron开发资源： 1）Electron官网：https://electronjs.org；2）Electron Github：https://github.com/electron；3）Electron开发手册：https://www.electronjs.org/zh...。4.2 创立一个 react 我的项目 # 装置 create-react-app 命令,如果已将装置请疏忽npm install -g create-react-app# 创立 electron-react 我的项目create-react-app electron-react# 启动我的项目cd electron-react && npm start4.3 配置 Electron 环境1）在 public 文件夹下新建 index.html，轻易写点内容： ...

最近有不少敌人对即时通讯和即时通信感到好奇，不晓得这两个概念的差别，明天咱们就来简略剖析一下，看即时通讯与即时通信到底有什么不同，二者又有什么特点。 首先来说即时通讯。即时通讯软件是咱们进行讯息通信的重要工具，即时通讯在互联网通信零碎倒退中具备重要的作用，咱们目前应用的QQ、微信以及易信或者阿里巴巴旗下的钉钉等，都属于即时通讯软件。而即时通讯的概念也是从及时通信软件中流传进去的，咱们能够通过及时通信软件来进行信息和资讯的替换，更好的实现信息资源的累积，帮忙咱们在工作上和生存上取得更多的便当。 即时通信的概念比拟好了解，通信是一个信息互通的过程，即时通信能够简略了解为进行信息沟通和交换。相比于依附互联网即时通讯软件进行的即时通讯，即时通信零碎在进行沟通时候的形式则更为便捷，任何能够进行即时通信的工具都能够帮忙咱们实现信息的互通，比方咱们应用无线电对讲机、电话、手机等等，这些通信工具可能帮忙咱们实现即时通信。 通过下面的简略介绍，大家对即时通讯和即时通信是不是有了新的认识？是的，即时通讯在当初来说，广泛是使用互联网和新媒体软件等进行沟通和信息交换的过程，而即时通信的领域则更大，不须要借助软件系统能够间接实现工夫上的即时通信内容的过程，都能够认为是即时通信的领域。 咱们在日常利用即时通讯和即时通信的时候应该留神他们的什么特点呢？ 即时通讯在应用的时候须要借助网络，这是目前市面上普遍存在的即时通讯软件的独特特点。通过无线网络或者光纤网络的形式，咱们应用即时通讯软件能够实现图片、数据、文字的传输，也能够进行视频、音频的通信对接，从而更好的进行工作上的交换和生存上的沟通。 即时通信在应用的时候并不需要网络，但须要相应的信号接管工具。比方咱们应用电话进行通信的时候应该有电话线，应用手机进行通信的时候须要有信号塔，应用无线电进行沟通的时候单方要有无线电接收器等等，即时通信不须要依附网络流量等条件进行通信，然而在理论通信的时候，也是须要思考主观信号载体的。理解更多能够登录官网征询 https://www.tokim.cn 即时通讯和即时通信给咱们的生存带来了很多的便当条件，日常生活中应用即时通讯软件进行视频对话、语音交换，在工作和生存上利用即时通信工具进行对话沟通等，都是以后比拟常见的情景了，随着网络技术和通信技术的一直倒退，即时通讯与即时通信也将继续提高。

对于MobileIMSDKMobileIMSDK 是一套专门为挪动端开发的开源IM即时通讯框架，超轻量级、高度提炼，一套API优雅反对UDP 、TCP 、WebSocket 三种协定，反对iOS、Android、H5、规范Java平台，服务端基于Netty编写。 工程开源地址是：1）Gitee码云地址：https://gitee.com/jackjiang/M...2）Github托管地址：https://github.com/JackJiang2... 对于RainbowChat► 具体产品介绍：http://www.52im.net/thread-19...► iOS端更新记录：http://www.52im.net/thread-27...► 全副运行截图：iOS端全副运行截图 （另：Android端运行截图 点此查看）► 在线体验下载：App Store装置地址 （另：Android端下载体验 点此查看）  RainbowChat是一套基于开源IM聊天框架 MobileIMSDK 的产品级挪动端IM零碎。RainbowChat源于实在经营的产品，解决了大量的屏幕适配、细节优化、机器兼容问题（可自行下载体验：专业版下载安装）。 * RainbowChat可能是市面上提供im即时通讯聊天源码的，惟一一款同时反对TCP、UDP两种通信协议的IM产品（通信层基于开源IM聊天框架  MobileIMSDK 实现）。 v5.0 版更新内容此版更新内容【新增“扫一扫”等性能】（更多历史更新日志）：1）[新增] “扫一扫”界面及性能逻辑；2）[新增] “我的二维码”界面及性能逻辑；3）[新增] “群聊二维码”界面及性能逻辑；4）[优化] 相干界面中的弹出菜单UI细节优化。 此版次要新增性能运行截图（更多截图点此查看）：

很多人对即时通讯这一概念感到生疏，但如果说起信息时代社交分割的通信工具，想必每个人手中都能拿出两个。即时通讯能够简略了解为互联网信息时代为人们提供网络信息传输与沟通的软件工具，无论是手机还是电脑上的即时通讯工具，都可能为人们提供信息交换、数据互通等服务，能够帮忙用户实现即时信息交换。 即时通讯产业的发展前景非常微小，我国的即时通讯软件产生与倒退经验了一个比拟零碎的倒退流程，从晚期的文字聊天到图片音频的发送，演变到现如今的即时语音与视频传输，即时通讯软件的倒退根本代表了即时通讯行业的发展壮大。在互联网信息时代背景下，即时通讯可能给人们带来的福利日益减少，人们的日常生活也日益以来即时通讯。若理解即时通讯源码，可征询星动云IM。 即时通讯在社交生活中扮演着重要的角色。即时通讯是古代社会生存中极为重要的一项社交工具，提到即时通讯很多人的第一反馈是通过APP与软件进行信息交换，与亲朋好友聊天与沟通，这是即时通讯在社交中表演的根底性功能，但即时通讯并不仅在信息传输上取代传统电信服务为人们传输信息。即时通讯在办公畛域的利用也极为宽泛，并且可能发明良好的利用价值。即时通讯是现代化办公中不可短少的工具，通过即时通讯技术的利用可能让企业中各项工作第一工夫汇总到相应的板块中，帮忙决策者理解工作进展的理论状况，让各部门工作人员能够互相交换工作状态，身处不同空间也能够在同一时间进行视音频的交换，便于交换工作状态，进步工作效率。 即时通讯不仅在生产与生存中有良好的作用，其倒退速度也在一直增长。即时通讯软件正随着互联网技术的倒退而不断进步，以后的即时通讯技术不单单能够在视频、音频等服务上为用户提供帮忙，同样增加了更加便捷无效的性能。即时通讯软件能够进行信息的推送，反对离线信息承受，晋升用户的视音频传输速度等等，通过性能上的扩大让即时通讯能够更好的表演相应的角色。集体和企业对即时通讯的需要也在一直减少。互联网时代对人们沟通速度的晋升也在很大水平上减少了人们对于即时通讯的需要度，谋求更加稳固、便捷、牢靠的即时信息交换将成为将来社交倒退的重要趋势；同样企业办公以及工业生产中对即时通讯的各种性能与通信条件的需要也更为丰盛，这些都促使即时通讯向着更加广大、高速的方向倒退。 即时通讯是一项前景光明，具备极高利用价值的倒退畛域，随同互联网技术的提高，即时通讯也将逐步走进新的时代。理解更多能够登录官网征询 https://www.tokim.cn

即时通讯工具曾经逐步成为现代人生存和工作中最重要的通信工具之一了，不同人在进行即时通讯工具抉择上会有不同的偏向。不可否认的是，即时通讯工具以其优质的性能为咱们带来便捷的同时，本身也是存在着肯定毛病的。那么即时通讯工具都有什么优缺点呢？ 即时通讯工具的有点是比拟好概括的。作为一种参加人们日常信息交换的工具，即时通讯工具有着良好的信息交换和沟通性能，在这也是即时通讯工具的次要有点，及信息流传和交互能力。不同类型的即时通讯工具因为外部性能设置不同，在即时通讯工具的交互能力和流传能力上都有肯定差别。蔚可云作为新一代即时通讯工具在为用户提供信息交互和流传时，不仅重视数据信息的传输稳定性和有效性，还保障了信息的加密，更好的满足了用户对信息交换的需要。若理解即时通讯源码，可征询星动云IM。 即时通讯工具的长处还有良好的UI互动。即时通讯工具与传统的通信工具不同，即时通讯工具不仅在通信上能够实现优质的语音、视频交换，在会话窗口优化等方面也有良好的体现。一个优质的即时通讯工具在UI设计上更加人性化，且满足用户的体验，这也是很多人抉择即时通讯工具用来进行社交和工作的次要起因，可能更加简略便捷的实现各项信息交换，文件传输性能等，让即时通讯更加简便。 即时通讯工具还具备功能强大的长处。即时通讯工具的性能不是变化无穷的，古代的即时通讯工具供应商除了提供根底版本的即时通讯工具以外，还会依据理论状况为用户提供性能定制等服务，更好的满足用户的需要。蔚可云的即时通讯工具为个人用户、企业用户和业余用户提供了不同品种的即时通讯工具，包含集成版、定制版、源码版即时通讯工具等。 即时通讯工具除了具备上述诸多长处之外，也是有肯定毛病存在的，当然因为不同供应商的差别，即时通讯工具的毛病也不是全副的。很多即时通讯工具在应用时有着海量的广告，广告投放是不少收费即时通讯工具取得盈利的重要条件，而即时通讯工具的广告天然也是用户应用时颇为诟病的内容。除了广告毛病外，即时通讯工具的资源损耗也是比拟重要的内容，局部即时通讯工具在装置后外部缓存大量的图片和数据，导致即时通讯工具占用大量内存，影响了用户电子产品的应用。 即时通讯工具是咱们工作和生存中的好帮手，正确认识到即时通讯工具的常见优缺点，依据本人的需要进行工具的抉择是极为重要的。理解更多能够登录官网征询 https://www.tokim.cn

本文由微信客户端技术团队工程师“Jon”分享，原题“Windows微信：音讯数据库架构演进”，有较多订正。 1、引言本文分享的是，微信客户端团队基于对微信用户日常应用场景和数据分析，通过拆散重要和非重要数据、采纳牢靠的分库策略等，对微信Windows端IM本地数据库的架构进行的优化和革新，并最终失去一个具备良好实际成果的技术改造计划。 以下是相干技术文章，有趣味的读者能够一并浏览：微信客户端SQLite数据库损坏修复实际微信挪动端的全文检索优化之路微信挪动端的全文检索多音字问题解决方案微信iOS端的最新全文检索技术优化实际微信本地数据库破解版(含iOS、Android)，仅供学习钻研 [附件下载] 学习交换： 挪动端IM开发入门文章：《新手入门一篇就够：从零开发挪动端IM》开源IM框架源码：https://github.com/JackJiang2...（备用地址点此）（本文已同步公布于：http://www.52im.net/thread-40...） 2、背景阐明微信的Windows客户端自2014年上线以来，用户数稳步增长。随着工夫的一直推移，很多用户本地积攒的音讯量越来越大。最后的本地IM数据库设计秉着遵循“简略易用、方便管理”的准则，把用户收到的所有音讯都对立寄存在用户以后客户端本地的“同一个SQLite数据文件中”。(作者注：微信不会保留聊天记录，聊天内容只存储在用户手机、电脑等终端设备上。) 3、以后问题因为初期这套本地数据库设计方案的短板，随着目前微信应用越来越宽泛、音讯沉积越来越多，从而逐步暴露出了许多技术问题。3.1 问题1：数据查问慢随着应用工夫的推移，数据也逐步增多，当数据量越来越宏大：1）数据库的查问和插入效率会受到影响；2）即便音讯数据库存在索引，索引的查问效率也随之降落。 从文件系统的角度，数据库文件是逐页增长的。 因为长时间的应用微信会使得音讯量的逐渐累积，让数据库体积逐步增长，也会导致碎片化更重大，这在机械硬盘下，也会进一步影响读写效率。对用户最直观的影响就是——切换聊天变得很卡，这个问题对于重度用户尤甚，甚至会呈现点击聊天就卡顿的状况。 3.2 问题2：存储文件大随着工夫的推移，音讯量的逐渐累积，数据库存储文件的体积也是越来越大，显著占用用户存储空间。 3.3 问题3：磁盘文件损坏磁盘文件意外损坏也有可能导致数据失落。因为所有音讯都放到一个数据库文件，就相似把所有鸡蛋放在一个篮子。数据库文件也可能会因为存储坏道、电脑意外断电、sqlite本身bug等起因导致数据库文件产生损坏。如果产生损坏时，有可能导致用户失落音讯数据。即便有DB复原机制，也无奈保障能复原出所有历史记录。 当这种状况产生时，对用户影响非常大，因为聊天记录可能没了！ PS：微信挪动端也有相似困扰，有趣味能够浏览《微信客户端SQLite数据库损坏修复实际》。 4、起因剖析4.1 概述上述数据库存储文件变大和查问变慢的问题，都是因为音讯数据的一直增多引起。但音讯数的增长是无奈防止的，那么有没有方法管制增长速度，并且管制数据库的大小？咱们从两个方向进行剖析：音讯状况、日常应用场景 4.2 剖析1：音讯状况微信里的IM音讯可分为三大类：1）单人聊天音讯；2）群聊音讯；3）以及订阅号/服务号音讯（统称为公众号音讯）。按音讯的重要性来说：1）单聊/群聊音讯：这是用户的私人音讯，被删除或者失落无奈复原，对用户损失最大；2）公众号的音讯：因为只有关注了公众号，都能够拉取浏览，属于公共音讯，所以对用户来说重要性稍低。 按音讯的大小来说：1）基于对测试帐号的音讯大小数据分析，咱们发现：占总条数比例不高的公众号音讯，占用了超过一半的数据库空间；2）通过对测试帐号音讯类型的剖析：网页卡片类音讯是公众号音讯的次要类型，其均匀音讯体大小是文本音讯的几十倍。 4.3 剖析2：日常利用场景剖析家喻户晓，咱们日常应用微信，都是收发音讯，或者浏览最近的音讯。对于更早的音讯，咱们个别很少会被动去浏览。越早的音讯，浏览的概率越低。所以：在大多数场景下，咱们要让最常拜访的音讯，不受老数据的影响。 5、解决方案5.1 概述针对前述问题并联合上述剖析，咱们从以下方面对微信Windows端本地SQLite数据库的架构进行了演进和优化。 波及的次要优化内容和伎俩有：1）分库革新；2）建设音讯索引；3）音讯体积优化；4）进步数据库健壮性。 上面咱们将逐个具体介绍。 5.2 分库革新基于以上剖析，首先把公众号音讯划分进来，存到独自的一个数据库，跟用户的一般音讯隔离，同时也能够大幅缩小一般音讯数据库的体积。 基于日常应用场景的剖析，大部分老数据读取的频率很低，所以应该进步最近一段时间的读写效率。对于上述这种状况，咱们采取了以工夫和空间动静划分数据库的计划。初始默认值是每个数据库寄存半年的音讯，超过工夫之后新建一个数据库寄存。对于大部分应用场景，咱们只须要读写最新的数据库就能够满足需要，如果须要浏览更早的音讯，能够再关上之前的数据库进行读取。除了工夫维度，咱们还思考了空间维度的划分：如果半年内音讯一般音讯规模超过阈值，也会新建一个数据库进行存储，让每个数据库大小和数据规模不至于太大，能晋升最近一段时间音讯的读写效率。 5.3 建设音讯索引对于最宽泛的应用场景——查看每一个聊天的音讯，这种场景须要对每一个聊天会话建设一个索引。这里的索引计划咱们参考了安卓端：行将每一个聊天转换成一个数值型的ID，从而缩小每条索引的长度，进步索引的读写效率。（对于微信的挪动端SQLite残缺数据库构造，能够参考：《微信本地数据库破解版(含iOS、Android)，仅供学习钻研 [附件下载]》） 除此之外，咱们还对一些常常拜访的内容，独自提取成为一个字段，并且减少索引。比方音讯的子类型（这个在老数据库中是一个序列化字段），它没有索引，但这个字段常常须要用到，所以独自提出成为一列，并且加上索引，为音讯按类型查找提供方便。 5.4 音讯体积优化IM中音讯显然总是会越来越多的，但如何可能在不影响读写效率的同时，缩小/压缩音讯数据的体积，也是咱们的优化方向。从下面的数据看，局部音讯体积较大，曾经超过了数据库每页的大小（Page Size）。数据库是按页存储数据的，Page Size是数据库一页可能包容的数据。如果一条数据，一个页放不下，就须要用到溢出页，把多进去放不下的数据放到溢出页中，溢出页能够有多个。这时候，如果读取这条数据，就须要把溢出页也全副读出来，会减少IO的耗费。如果压缩数据，可能把音讯体压缩到一个页能放得下，缩小溢出页的应用，是能够减少IO性能的。SQLite数据库溢出页构造：(上图援用自书籍《The Definitive Guide to SQLite》第308页)PS：《The Definitive Guide to SQLite》这本书的电子版我也给你找到了，请从上面附件处下载： The Definitive Guide to SQLite (2nd edition, 2010)-52im.net.pdf.zip (3.61 MB) 然而压缩须要占用CPU资源，这里抉择一种可能均衡性能和压缩率的算法是要害。通过比照压缩算法的Benchmark，并且对音讯体压缩性进行实测，最终抉择了一个高性能压缩算法：lz4。 通过对测试帐号的数据分析，不同类型的音讯体大小差别较大。一般来说：文本音讯的长度不会特地大，然而网页卡片类型的音讯，体积会较大。因为不同的音讯长度，取得的压缩率不一样，太短的文本长度，压缩起来并没有意义。所以通过音讯体长度、压缩、，压缩性能的剖析，最终确定对网页卡片等进行压缩，在较低性能耗费的前提下，综合压缩率可达到40%，缩小了IO次数 。 5.5 进步健壮性如果数据库文件因为内部起因产生损坏，则会对体验造成较大影响。升高损坏率和缩小损坏带来的数据损失，也是咱们改良的方向。依照工夫维度划分数据库之后，相当于把音讯按工夫扩散存储。最新的数据库负责读写最近的音讯，其余的数据库只须要依据需要反对浏览查看音讯。对于老数据库而言：能够做到按需加载，从而缩小了对数据库的读写，也缩小了这些数据库损坏的几率。一旦有数据库呈现损坏，即便无奈复原，也不会所有音讯全副失落，只会失落该数据库对应时间段的音讯，这也能够缩小局部数据库损坏带来的损失。在晚期应用的单数据库架构中，因为数据会越攒越多，数据库体积会继续变大，很难去做备份。 分库之后，每个数据库体积变小，因此数据库备份变得更为可行。因为最新的数据库存在频繁的音讯读写，产生损坏的概率远高于老数据库，所以这里对最新的一个数据库做定期的备份。默认配置下，咱们每距离一段时间会对最新的数据库进行一次备份，该备份是最新的一个数据库的残缺拷贝。若最新的数据库在读写时产生损坏，会先尝试从备份数据恢复。若复原胜利，则最多失落从备份到复原这段时间的数据，进一步升高损坏造成的损失。 6、优化比照通过比照，对于一个在测试帐号中原始的音讯数据库，压缩后大小能够缩小靠近一半，同时溢出页数和须要应用溢出页的记录数缩小也超过一半。对于读写性能，比照压缩前，压缩后的读取和解压缩性能比之前有靠近10%的晋升。 7、将来瞻望后续咱们微信客户端团队将持续钻研数据库修复相干的实际，继续关注数据库相干的性能数据，晋升可靠性，打造更好的用户体验！ 附录：更多大厂IM文章汇总[1] 微信团队原创技术文章：《微信朋友圈千亿访问量背地的技术挑战和实际总结》《IM全文检索技术专题(二)：微信挪动端的全文检索多音字问题解决方案》《微信团队分享：iOS版微信的高性能通用key-value组件技术实际》《微信团队分享：iOS版微信是如何避免特殊字符导致的炸群、APP解体的？》《微信团队原创分享：iOS版微信的内存监控零碎技术实际》《iOS后盾唤醒实战：微信收款到账语音揭示技术总结》《微信团队分享：视频图像的超分辨率技术原理和利用场景》《微信团队分享：微信每日亿次实时音视频聊天背地的技术解密》《微信团队分享：微信Android版小视频编码填过的那些坑》《IM全文检索技术专题(一)：微信挪动端的全文检索优化之路》《企业微信客户端中组织架构数据的同步更新计划优化实战》《微信团队披露：微信界面卡死超级bug“15。。。。”的前因后果》《月活8.89亿的超级IM微信是如何进行Android端兼容测试的》《一篇文章get微信开源挪动端数据库组件WCDB的所有！》《微信客户端团队负责人技术访谈：如何着手客户端性能监控和优化》《微信后盾基于工夫序的海量数据冷热分级架构设计实际》《微信团队原创分享：Android版微信的臃肿之困与模块化实际之路》《微信后盾团队：微信后盾异步音讯队列的优化降级实际分享》《微信团队原创分享：微信客户端SQLite数据库损坏修复实际》《微信Mars：微信外部正在应用的网络层封装库，行将开源》《如约而至：微信自用的挪动端IM网络层跨平台组件库Mars已正式开源》《开源libco库：单机千万连贯、撑持微信8亿用户的后盾框架基石 [源码下载]》《微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解》《微信团队原创分享：Android版微信后盾保活实战分享(过程保活篇)》《微信团队原创分享：Android版微信后盾保活实战分享(网络保活篇)》《Android版微信从300KB到30MB的技术演进(PPT讲稿) [附件下载]》《微信团队原创分享：Android版微信从300KB到30MB的技术演进》《微信技术总监谈架构：微信之道——大道至简(演讲全文)》《微信技术总监谈架构：微信之道——大道至简(PPT讲稿) [附件下载]》《如何解读《微信技术总监谈架构：微信之道——大道至简》》《微信海量用户背地的后盾零碎存储架构(视频+PPT) [附件下载]》《微信异步化革新实际：8亿月活、单机千万连贯背地的后盾解决方案》《微信朋友圈海量技术之道PPT [附件下载]》《微信对网络影响的技术试验及剖析（论文全文）》《一份微信后盾技术架构的总结性笔记》《架构之道：3个程序员成就微信朋友圈日均10亿发布量[有视频]》《疾速裂变：见证微信弱小后盾架构从0到1的演进历程（一）》《疾速裂变：见证微信弱小后盾架构从0到1的演进历程（二）》《微信团队原创分享：Android内存透露监控和优化技巧总结》《全面总结iOS版微信降级iOS9遇到的各种“坑”》《微信团队原创资源混同工具：让你的APK立减1M》《微信团队原创Android资源混同工具：AndResGuard [有源码]》《Android版微信安装包“减肥”实战记录》《iOS版微信安装包“减肥”实战记录》《挪动端IM实际：iOS版微信界面卡顿监测计划》《微信“红包照片”背地的技术难题》《挪动端IM实际：iOS版微信小视频性能技术计划实录》《挪动端IM实际：Android版微信如何大幅晋升交互性能（一）》《挪动端IM实际：Android版微信如何大幅晋升交互性能（二）》《挪动端IM实际：实现Android版微信的智能心跳机制》《挪动端IM实际：iOS版微信的多设施字体适配计划探讨》《IPv6技术详解：基本概念、利用现状、技术实际（上篇）》《IPv6技术详解：基本概念、利用现状、技术实际（下篇）》《微信多媒体团队访谈：音视频开发的学习、微信的音视频技术和挑战等》《腾讯技术分享：微信小程序音视频技术背地的故事》《微信多媒体团队梁俊斌访谈：聊一聊我所理解的音视频技术》《腾讯技术分享：微信小程序音视频与WebRTC互通的技术思路和实际》《微信技术分享：微信的海量IM聊天音讯序列号生成实际（算法原理篇）》《微信技术分享：微信的海量IM聊天音讯序列号生成实际（容灾计划篇）》《微信团队分享：Kotlin渐被认可，Android版微信的技术尝鲜之旅》《社交软件红包技术解密(二)：解密微信摇一摇红包从0到1的技术演进》《社交软件红包技术解密(三)：微信摇一摇红包雨背地的技术细节》《社交软件红包技术解密(四)：微信红包零碎是如何应答高并发的》《社交软件红包技术解密(五)：微信红包零碎是如何实现高可用性的》《社交软件红包技术解密(六)：微信红包零碎的存储层架构演进实际》《社交软件红包技术解密(十一)：解密微信红包随机算法(含代码实现)》《微信团队分享：极致优化，iOS版微信编译速度3倍晋升的实际总结》《IM“扫一扫”性能很好做？看看微信“扫一扫识物”的残缺技术实现》《微信团队分享：微信领取代码重构带来的挪动端软件架构上的思考》《IM开发宝典：史上最全，微信各种性能参数和逻辑规定材料汇总》《微信团队分享：微信直播聊天室单房间1500万在线的音讯架构演进之路》《企业微信的IM架构设计揭秘：音讯模型、万人群、已读回执、音讯撤回等》《IM全文检索技术专题(四)：微信iOS端的最新全文检索技术优化实际》《微信团队分享：微信后盾在海量并发申请下是如何做到不解体的》《微信Windows端IM音讯数据库的优化实际：查问慢、体积大、文件损坏等》 ...

即时通讯是当代人生存中必不可少的应用软件了，无论应用QQ、微信还是钉钉，咱们都能够通过这些即时通讯软件来进行信息的替换以及文件的传输。那么即时通讯传送文件的办法有几种呢？接下来咱们一起盘点一下。 即时通讯软件传送文件波及数据库技术，咱们在即时通讯软件上进行内容的传输往往是采纳post或get的形式进行参数传输，并对数据库进行写入和读取，而依靠这些技术产生的即时通讯软件，则依据其不同的软件类型以及源代码等差别，在传输文件形式上有不同的区别。能够说，目前市面上有多种能够传输文件的通信软件就有多少传送文件的办法。咱们盘点即时通讯传送文件的形式，应该关注即时通讯自身的作用。 即时通讯中QQ是目前受众范畴最广，性能最全面，也是体现最优良的即时通讯传输软件。咱们在QQ零碎中能够进行各类型文件的传输，包含压缩文件、音乐文件、视频文件、图片文件以及蕴含多文件的文件夹等。QQ同样也反对离线文件传输性能，文件传输后会在服务器保留一周工夫，便于用户下载和查阅。若理解即时通讯源码，可征询星动云IM。 与QQ同源的微信在即时通讯的文件传输中也有不错的体现。微信的传输性能并不比QQ弱小，然而微信在局部年龄层群体中有着良好的利用范畴，操作简略便捷，微信的验证登录保密性比拟好，应用微信进行工作文件传输可能满足相当一部分敌人工作的需要，更好的实现相干工作内容。 同样是腾讯旗下的即时通讯产品，TIM或者说QQ办公简洁版，在文件传输中也具备不错的体现。这是一款抛出了QQ产品自身很多娱乐性能，在办公文件传输方面有显著增强的业余版本即时通讯软件，可能对云文件、在线文件等进行传输，保障了办公的有效性。 腾讯系产品能够说是即时通讯的王者，近年来，阿里、百度等互联网服务商也尝试在即时通讯畛域与其抢占份额，然而理论利用成果并不显著，网易系列的云信产品在即时通讯中也有着不错的体现，然而市场份额相较腾讯系来说并不突出，次要以社交沟通为主，文件传输性能具备肯定限度。 在疫情期间，网络办公的衰亡促使阿里旗下的钉钉等办公软件得以怀才不遇，在即时通讯零碎中抢占了另一份额，其在文件传输方面的成果体现也比较突出，可能为用户提供绝对良好的服务。 即时通讯作为以后人们生存中必不可少的社交通信软件，不仅在日常社交中施展着重要的作用，在文件传输以及办公工作上也具备良好的体现，理解更多即时通讯的文件传输内容，有利于咱们进一步观测互联网的倒退历程。理解更多能够登录官网征询 https://www.tokim.cn

咱们罕用“跨服聊天”来形容不在对立频道、无奈顺畅沟通的鸡同鸭讲景象。仅一字之差，在通信能力中，“跨 App 聊天”性能则代表着业务资源的共享和沟通效率的晋升。关注【融云寰球互联网通信云】理解更多跨利用通信是指实现两个 App 之间相互通信，在同一公司经营多个同类型利用时，能够通过跨利用通信性能，实现利用间主播、用户的互通。 典型代表是去年 Facebook 的动作，将本人开发的 Messenger 与收买的 Instagram 买通。两款 App 均为月活 10 亿以上级别的受欢迎产品，买通后反对用户跨利用聊天，实现对流量效应的放大。 融云的跨利用通信能力，以简洁高效的形式反对 1V1 为外围的娱乐社交场景利用间互通，助力业务方实现同类多利用的互联互通、凋谢共享。 跨利用通信能力解析在 1V1 音视频等社交泛娱乐场景，业务方出于市场拓展需要思考，可能在已有成熟产品的状况下新开设一个利用，以多个应用服务更多用户，合力获取流量。 那么，为了获取原有利用中的主播资源，实现对资源的最大化开释，新的利用产品就须要和原有利用实现互通。 即，多个利用（多个 AppKey）进行通信，以满足主播资源共享、新老利用流量援用等跨利用之间的互相聊天、通话性能。（融云跨利用通信架构图） 融云自研该项服务，只需携带发送方和接管方的 AppKey 到信令中即可实现性能，毋庸独自对接接口或注册第三方平台。 相应场景开发者可分割对应商务开明该服务，或关注公众号辨认扫码注册详询。全能力多场景，欢送详询 跨利用通信用例及劣势以 1V1 音视频利用为例：☑用户进入利用后，首页举荐的能够是来自于其余利用（可多个）的经营账号或沉闷用户信息。 ☑选中其中某个来自其余利用的用户，进入聊天会话界面（界面中材料信息展现为其余利用的用户信息）。 ☑在聊天界面通过融云的 IM 和 RTC 能力进行音讯互动、音视频互动等。 IM 业务：单聊、音讯互动RTC 业务：一对一语音、视频等融云跨利用通信能力劣势接入简略携带两方 AppKey 到信令中即可，毋庸独自对接接口及注册第三方平台。平台稳固相比于三方代理商平台，融云自研服务，服务可控、稳固且危险低。利用联动满足客户的多个利用互通需要，晋升沉闷留存。多种场景满足以 1V1 为外围的通话、相亲、社交等场景。

本文由融云技术团队分享，原题“互联网通信安全之端到端加密技术”，内容有较多订正和改变。 1、引言在上篇《IM聊天系统安全伎俩之通信连贯层加密技术》中，分享了对于通信连贯层加密的相干技术和实际，包含在传输即时通信音讯时启用 TLS 链路加密（保障音讯在达到服务器前无奈被窃听和篡改）、应用 CA 认证机制（杜绝中间人攻打）等。本篇将围绕IM传输内容的平安问题，以实际为根底，为你分享即时通讯利用中的“端到端”加密技术。 学习交换： 挪动端IM开发入门文章：《新手入门一篇就够：从零开发挪动端IM》开源IM框架源码：https://github.com/JackJiang2...（备用地址点此）（本文已同步公布于：http://www.52im.net/thread-40...） 2、系列文章本文是IM通信平安常识系列文章中的第11篇，此系列总目录如下：《即时通讯平安篇（一）：正确地了解和应用Android端加密算法》《即时通讯平安篇（二）：探讨组合加密算法在IM中的利用》《即时通讯平安篇（三）：罕用加解密算法与通信平安解说》《即时通讯平安篇（四）：实例剖析Android中密钥硬编码的危险》《即时通讯平安篇（五）：对称加密技术在Android平台上的利用实际》《即时通讯平安篇（六）：非对称加密技术的原理与利用实际》《即时通讯平安篇（七）：如果这样来了解HTTPS原理，一篇就够了》《即时通讯平安篇（八）：你晓得，HTTPS用的是对称加密还是非对称加密？》《即时通讯平安篇（九）：为什么要用HTTPS？深入浅出，探密短连贯的安全性》《即时通讯平安篇（十）：IM聊天系统安全伎俩之通信连贯层加密技术》《即时通讯平安篇（十一）：IM聊天系统安全伎俩之传输内容端到端加密技术》（* 本文） 3、为什么须要端到端加密？上篇中提到的连贯层加密技术，这是晋升IM客户端到服务器之间数据传输的安全性伎俩，然而这并不能解决用户间的通信隐衷性以及安全性危险。因为在将数据传输到服务器之后，所有有权拜访此服务器的人，包含员工、供应商及其他无关人员（甚至黑客），都有可能读取到用户的数据。有鉴于此，端到端加密技术在即时通讯IM畛域被广泛应用，包含WhatsApp、Signal、Telegram 等国外即时通信软件中都有应用。 PS：无关端到端加密的基础知识，能够从这两篇里失去，倡议详读：《挪动端平安通信的利器——端到端加密（E2EE）技术详解》《简述实时音视频聊天中端到端加密（E2EE）的工作原理》 4、端到端加密的技术设计思路4.1 简化版思路说到端到端加密，咱们首先想到的解决方案是：在发送端发送音讯前对整个音讯进行加密，接收端接管到音讯后进行解密。如上这样：音讯直达服务器就无奈获取咱们的音讯内容了。事实上：这的确是端到端加密中音讯收发的简化版解决方案，只是咱们在理论利用中要更加简单，成果也更加平安。 4.2 如何平安地传递用于音讯加解密的密钥对于端到端加密，咱们须要先解决的前置平安问题是：如何平安地传递用于音讯加解密的密钥。 答案是：用非对称加密的形式传输密钥（与 SSL / TLS 中平安替换密钥的形式相似）。非对称加密传输对称加密密钥的算法，个别归纳两种形式：1）一种是以 RSA、ECC 等为主（公钥加密私钥解密的形式，实质是加解密的算法）；2）另一种是以 DH、ECDH 为主的生成共享密钥的形式（实质是通过计算协商一个独特的密钥而不是加解密算法）。 实际上：大部分即时通信软件中的端到端加密都采纳生成共享密钥的形式来传输会话密钥。这是为什么呢？这就波及到 DH 算法（即 Diffie-Hellman 密钥替换算法），对于DH算法的材料，有趣味能够详读《Diffie-Hellman密钥协商算法》，限于篇幅，这里不专门探讨。 Diffie-Hellman 密钥替换算法的安全性依赖于这样一个事实：尽管计算以一个素数为模的指数绝对容易，但计算离散对数却很艰难。对于大的素数，计算出离散对数简直是不可能的。这里简要形容一下 DH 共享密钥的过程如下：（其中“密钥 S”即为最终的共享密钥） 4.3 采纳共享密钥的起因端到端加密采纳共享密钥的形式来传输会话密钥有如下几个起因：1）如果采纳 RSA、ECC 等公钥加密私钥解密的形式传输密钥，须要在创立会话时生成长期密钥，并通过对方公钥加密后传输到接收端。这就须要齐全保障音讯的可靠性，如果该音讯在任何一个环节中失落或损坏，则后续通信都无奈进行。或者，须要采纳更为牢靠的传输计划，通常做法为须要接收端在线，通过各种确认来保障这个可靠性。而采纳共享密钥的形式则只须要晓得对方的公钥，就能够实现生成共享密钥，并不一定须要对方在线。 2）如果曾经生成的长期对称密钥失落，则须要从新协商密钥。而采纳共享密钥的形式则只须要晓得对方的公钥，就能够实现生成共享密钥，不须要从新协商。 3）采纳公钥加密私钥解密的形式至多会比生成共享密钥形式多一次替换对称密钥的通信过程。 4）密钥协商形式，不仅仅能够实现两个点之间的密钥协商，还能够延展到多人之间的独特协商出雷同的密钥，这样能满足多人群体沟通的需要。 5、端到端加密的初步实际计划咱们联合对于 DH 算法（即 Diffie-Hellman 密钥替换算法）这种共享密钥形式的认知（即公钥可随便公开），先设计一个简略的端到端音讯加密的过程。 这个过程的逻辑流程如下：1）在客户端 APP 首次装置时，基于服务器公开的两个全局的参数，生成本人的 DH 公钥和私钥；2）将本人的公钥上传证书服务器，证书服务器上保留用户标识与其公钥的关系。私钥则保留在客户端上；3）首次给对方发送音讯或首次接管到对方音讯时，便到证书服务器查问对方的公钥；4）依据对方公钥和本人的私钥计算出共享密钥；5）后续与对方所有的音讯都基于这个密钥和雷同的对称加解密算法进行加密解密操作。 端到端音讯加密过程示意： 至此：咱们实现了一个简略的端到端音讯加密计划，在这个计划中咱们引入了一个第三方的用于存储用户公钥的角色，这个角色的存在能够让任何一方都不必关怀对方的在线状态，随时给对方发送加密过音讯，而音讯转发服务器无奈解密音讯。接下来，咱们针对这个简略计划存在的各种安全隐患问题，进行逐渐剖析和优化。 6、端到端加密实际计划的进一步优化和演进6.1 应用HMAC作为音讯完整性认证算法在音讯传输过程中，单方须要确认彼此音讯的完整性，简略的做法就是将音讯进行 Hash，失去的 Hash 值附加到音讯后，随音讯一起发送；对端接管后，同样进行 Hash，来验证音讯是否被篡改。关键点在于不同数据失去的 Hash 值肯定不同，其中带密钥的 Hash 值就是 MAC算法。另外，为了防止应用同样的 Hash 函数对雷同数据进行操作总是得出同样的值，额定退出一个密钥，这样应用不同密钥就能够得出不同的 MAC。当然，这个密钥是两个对端都晓得的。这样，咱们就失去了基于加密 Hash 的音讯完整性认证的算法——Hash-based MAC（简称HMAC）。 ...

即时通讯软件是咱们日常交换和办公的好帮手，在互联网信息时代即时通讯的应用在很大水平上扭转了传统依附电话、短信等通信实现交换的形式路径，让交换和沟通更加便捷，让用户的需要失去最大化满足。明天咱们简略理解一下即时通讯集成版和sdk版本的区别。 即时通讯软件置信大家都不算生疏，但对于即时通讯的具体分类很多敌人一头雾水，以后罕用于企业单位信息交换沟通的即时通讯软件有集成版和sdk版两种类型，这两种版本的即时通讯软件性能特点上有肯定相似性，但具体划分下来还是有很大区别的。 即时通讯集成版顾名思义就是信息系统集成技术下产生的即时通讯软件。即时通讯集成版在软件市场上具备很高的价值，集成版能够将即时通讯软件的各种独立性能集成后汇聚成一个整体，从而为用户提供性能服务，因而咱们通常认为即时通讯集成版的性能更加全面，并且能够定制。即时通讯集成版的性能定制特点也是很多企业抉择它的次要起因，在互联网信息时代系统集成技术的利用可能让用户向互联网厂商定制不同类型的即时通讯软件，而即时通讯集成版因为能够依据客户需要进行定制，在性能上更加具备灵活性、发展性与可操作性，即时通讯集成版在投资方面也具备更好的体现。若理解即时通讯源码，可征询星动云IM。相较于即时通讯集成版来说sdk版的即时通讯软件在普通用户中知名度不显。sdk版本也就是常说的软件开发工具包版本，不同于集成版即时通讯能够在软件性能上进行增加删减，sdk版本在开发性上具备更好的体现，可能实用于软件工程师的工作要求，能够给予软件包、软件框架、硬件平台等进行开发。即时通讯sdk版对于软件工程来说具备更高的利用价值，客户也能够依据本人的需要通过程序语言的设计，让即时通讯软件更加合乎本人的需要，同时sdk版的即时通讯软件能够用于进行一些更加高品质的即时通讯软件开发，比惯例性能堆砌的集成版具备更强的创新性。 无论是即时通讯集成版还是sdk版在现阶段的网络通讯中都具备重要的意义，对于客户来说想要通过即时通讯软件的投资、开发和利用获取更好的利益，须要着重剖析本人的需要在二者之间进行取舍。性能导向以及需要导向是现阶段抉择即时通讯软件的要害，集成版在系统集成的横向纵向划分中也有了更深刻的体现，而sdk版也在一直倒退和演变，只有依据理论需要进行抉择能力更好的施展即时通讯软件的作用与价值。理解更多能够登录官网征询 https://www.tokim.cn

本文由融云技术团队分享，原题“互联网通信安全之端到端加密技术”，内容有订正和改变。 1、引言随着挪动互联网的遍及，IM即时通讯类利用简直代替了传统运营商的电话、短信等性能。得益于即时通讯技术的实时性劣势，使得人与人之间的沟通和交换冲破了空间、工夫等等限度，让信息的传递变的无处不在。 但互联网为咱们的生存带来极大便当的同时，用户的隐衷和通信安全问题也随之而来。对于IM利用开发者来说，信息沟通的开放性也意味着风险性，用户与网络和挪动设施的高度依赖，也为不法之徒提供了可乘之机。因而，晋升即时通讯利用的安全性尤其重要。 本篇文章将围绕IM通信连贯层的平安问题及实现计划，聚焦IM网络“链路平安”，心愿能带给你启发。 学习交换： 挪动端IM开发入门文章：《新手入门一篇就够：从零开发挪动端IM》开源IM框架源码：https://github.com/JackJiang2...（备用地址点此）（本文已同步公布于：http://www.52im.net/thread-40...） 2、系列文章本文是IM通信平安常识系列文章中的第10篇，此系列总目录如下：《即时通讯平安篇（一）：正确地了解和应用Android端加密算法》《即时通讯平安篇（二）：探讨组合加密算法在IM中的利用》《即时通讯平安篇（三）：罕用加解密算法与通信平安解说》《即时通讯平安篇（四）：实例剖析Android中密钥硬编码的危险》《即时通讯平安篇（五）：对称加密技术在Android平台上的利用实际》《即时通讯平安篇（六）：非对称加密技术的原理与利用实际》《即时通讯平安篇（七）：如果这样来了解HTTPS原理，一篇就够了》《即时通讯平安篇（八）：你晓得，HTTPS用的是对称加密还是非对称加密？》《即时通讯平安篇（九）：为什么要用HTTPS？深入浅出，探密短连贯的安全性》《即时通讯平安篇（十）：IM聊天系统安全伎俩之通信连贯层加密技术》（* 本文）《即时通讯平安篇（十一）：IM聊天系统安全伎俩之传输内容端到端加密技术》（稍后公布...） 3、即时通讯面临的平安问题1）窃取内容：如果在整个即时通讯的通信过程中，其数据内容是未加密或弱加密的，那么其信息被截获后就能够间接被读取进去。那么，这就会导致用户数据（包含个人隐私数据）的泄露，甚至可能危害用户的财产平安（比方微信这类IM中，红包、钱包都会波及财产平安）。如果在办公场景下，被窃取的还可能是公司商业秘密，那势必将会造成更大的经济损失。 2）篡改内容：如果通信内容被截获后，对其进行批改再发送，会毁坏信息的正确性和完整性（此音讯已非彼音讯）。 3）伪造内容：如果用户通信凭证（比方token）被窃取或在通信过程中交叉其余信息，就可能为冒用用户身份骗取与之通信者的信赖发明可能，埋下更大的安全隐患。 4）流传不法内容：基于即时通讯零碎的音讯推送能力，不法分子除了可能流传涉黄、涉赌、暴恐或危害国家平安的信息外，还可能流传计算机木马病毒等，可能带来的危害范畴将进一步扩充。 4、罕用的互联网攻打伎俩网络通信过程中常见的攻打伎俩：1）移植木马：过在终端移植木马，截获或篡改信息。 2）伪造利用：通过伪造 APP 或在 APP 中增加后门等形式，使终端用户误以为是失常利用进行应用，从而达到其不法目标。 3）网络抓包：通过在网络设备上进行抓包，获取用户通信内容。 4）中间人攻打：通过劫持 DNS 等伎俩，使用户通信连贯通过攻击者的设施，从而达到窃取、篡改等目标。 5）破绽开掘：服务端或终端除了自有的程序以外还蕴含了各种三方组件或中间件，通过开掘其上的破绽，达到不法目标。从上图和伎俩可知，聊天信息从利用通过网络达到服务端，这期间的任何一个环节都有可能被人利用。所以，在“危机四伏”的互联网络通信中，“平安”必须器重。 5、密码学在即时通讯零碎中的利用5.1 基本常识针对前述的平安问题和攻打伎俩，将密码学利用在即时通讯零碎连贯上，对通信数据进行加密就变得尤为重要。 密码学解决信息安全的三要素（CIA）即：1）机密性（Confidentiality）：保障信息不泄露给未经受权的用户；2）完整性（Integrity）：保障信息从实在的发信者传送到实在的收信者手中，传送过程中没有被非法用户增加、删除、替换等；3）可用性（Availability）：保障受权用户能对数据进行及时牢靠的拜访。 以上表述，如同有点绕口，咱们换个艰深一点的表述。。。 密码学在网络通信中的三大作用就是：1）加密：避免好人获取你的数据；2）认证：避免好人批改了你的数据而你却并没有发现；3）鉴权：避免好人混充你的身份。 除 CIA 外，还有一些属性也是要求达到的，如可控性（Controllability）和不可否认性（Non-Repudiation）。 5.2 在即时通讯中的利用作为即时通讯中的要害组成，IM即时通讯零碎为了实现音讯的疾速、实时送达，个别须要客户端与服务器端建设一条socket长连贯，用以疾速地将音讯送达到客户端。通常即时通讯客户端会以 TCP 或 UDP 的形式与服务器建设连贯，同时某些场景下也会应用 HTTP 的形式从服务器获取或提交一些信息。整个过程中所有的数据都需进行加密解决，简略的数据加密和解密过程能够演绎为：发送方输出明文 -> 加密 -> 生成密文 -> 传输密文 -> 接管方解密 -> 失去明文。 这其中，会波及：1）对称加密算法（详见《对称加密技术在Android平台上的利用实际》）2）非对称加密算法（详见《非对称加密技术的原理与利用实际》）；3）信息摘要算法（详见《罕用加解密算法与通信平安解说》）。 这其中，我国也有一套自有的明码算法（国密算法）：国密算法，即国家商用明码算法，是由国家明码管理局认定和颁布的明码算法规范及其利用标准，其中局部明码算法曾经成为国际标准。如 SM 商用系列明码：对称加密算法 SM4、非对称加密算法 SM2、信息摘要算法 SM3。 6、通信连贯层的会话加密对于连贯层面（链路层面）面的加密，应最先思考的是基于 SSL/TLS 协定进行链路加密（比方微信的作法：《微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解》），这是古代网络通信平安的基石。很多人认为 SSL/TLS 协定是附加在 HTTP 协定上的，是 HTTPS 的一部分（详见《为什么要用HTTPS？深入浅出，探密短连贯的安全性》）。其实这种了解不完全正确，SSL/TLS 是独立于应用层协定的，高层协定能够通明地散布在 SSL/TLS 协定下面。因而基于socket长连贯的IM即时消息通信协定也能够构建在 SSL/TLS 协定下面。 SSL/TLS 是独立于应用层协定： SSL/TLS 能够被简略地演绎为：利用基于公私钥体系的非对称加密算法，传输对称加解密算法的密钥，并将后续通信的数据包基于单方雷同的对称加解密算法和密钥进行加密并传输，从而达到保障数据安全通信的目标。非对称加密算法外面的公钥和私钥在数学上是相干的，这样能力用一个加密、用另一个解密。不过，只管是相干的，但以现有的数学算法，是没有方法从一个密钥算出另一个密钥。另外须要着重强调的是：在零碎中不要应用自签证书，而要应用具备 CA 认证的证书，这样能够无效的避免中间人攻打。 ...

在互联网时代，各种类型的软件层出不穷，人们日常生活的吃喝玩乐，日常工作的快捷化办公都与即时通讯软件这种新型软件密不可分。即时通讯软件不仅在传输音讯上克服了传统通信形式的毛病，还创始了社交交换、工作汇报等一系列新的性能，让信息时代人们的社交与工作状态产生扭转。 即时通讯软件对人们的社交状态有着微小的影响，这次要依靠于即时通讯软件便捷的通信零碎以及多功能的通信模式。即时通讯软件不同于传统通信形式中只能通过电话语音或者公布文字等形式进行简略的通信，即时通讯软件中蕴含有语音输入、视频录制、即时的视频语音通话等等。即时通讯软件与传统电信通信最大的差别就在于即时通讯软件过分依赖网络，网络连接的可靠性以及网络信号的稳定性都间接关系着通信品质，也会对咱们社交造成影响。但在5G网络高速倒退的明天，即时通讯软件的这些网络因素带来的局限性也日渐改善，并逐步演变成一种新型无效的社交工具。 相比于即时通讯软件在社交上的作用，即时通讯软件对于工作来说具备更为重要的意义。即时通讯软件带来的是信息时代下的高科技软件系统，从根底性能来说，即时通讯软件具备即时通讯的特点，能够为日常办公提供根本的信息交换和数据分享。公司内部人员能够通过独立的即时通讯软件进行交换和沟通，分享工作中的问题，通过即时通讯软件随时随地召开探讨会议，交流经验与状况。对于须要现场勘查的工作，即时通讯软件可能通过即时连贯的形式，第一工夫传播现场的状况，便于各行业积极开展工作。 即时通讯软件不仅在工作的根本交换中施展着重要的作用，在工作的安全性与保障性上同样有突出表现。即时通讯软件是一种便于工作交换，并且能够对工作内容进行加密防护的新型办公工具。以后很多即时通讯软件针对企业工作研发出了加密通话、加密数据传输、文件平安扫描等诸多性能，通过即时通讯软件的这些从属性能，可能让公司在新的时代背景下取得更好的网络安全服务，防止网络安全问题造成公司损失。理解更多能够登录官网征询 https://www.tokim.cn 即时通讯软件还能够自在构建群组，召开公司会议，对突发状况，重大事件等做出过更加及时的解决。即时通讯软件最大的特点在于其便捷性以高速度，即时通讯软件不仅可能更加便捷的对公司外部成员进行分割，让公司不同成员在同一个群组内进行问题探讨，同样能够依靠其即时通讯技术，更加及时的对事件作出反馈，进步工作效率。 即时通讯软件对于信息时代的社交以及工作具备极为重要的影响，想取得更好的社交生活与工作生存体验，该当踊跃的理解和应用即时通讯软件。

二十一世纪是互联网倒退的时代，在这个时代咱们所领有的不仅是通过互联网进行信息的查问和解决，更在于利用互联网技术实现即时通讯，让人与人之间的交换更便捷，让工作交换更迅速，谈到互联网时代的交换和信息互通，即时通讯就是一个绕不开的话题。 im即时通讯是什么呢？咱们将instant message的缩写IM与即时通讯分割在一起，就形成了现在大家常常谈到的im即时通讯，这是一种依靠于互联网技术倒退而来的软件系统，现在也成了咱们生存和工作中不可短少的内容。日常生活中应用的QQ、微信、MSN等都是罕用的im即时通讯软件，而在商业活动中企业微信、企业QQ、钉钉等都是工作中不可短少的好工具。 im即时通讯为咱们的生存带来了很多便当，这些软件通常具备文字、图片、表情、语音、视频等聊天性能，同时也具备电脑与手机端，安卓与IOS端等不同的互通要求，能够进行信息的疾速收集。在im即时通讯的安全性上，受到独立自主开发通信协定、动静加密技术的条件的影响，im即时通讯的安全性很高，并且具备较高的可扩展性，为咱们的即时通讯带来了更好的条件。 im即时通讯在哪里有是一个比拟要害的问题。对于用户来说，用户在手机利用商店或者相干互联网企业的官网就能够找到其配套的im即时通讯软件，从而进行网络即时通讯。而对于互联网企业来说，想要开发im即时通讯则须要思考更多的内容，包含抉择什么类型的通信厂商进行软件开发，在开发定制的时候有什么对应要求，以及开发定制的免费价格等等因素。 那么im即时通讯软件开发贵吗？这就波及到im即时通讯的行业倒退状态了。新近im即时通讯的开发技术处于严格窃密状态，很多小企业与业余厂商im即时通讯开发技相差过多，在进行im即时通讯开发时须要的资金也比拟多。但近年来在信息技术一直倒退，im即时通讯开发源码日益丰盛的状况下，im即时通讯的开发价格在肯定水平上降落了，并且很多im即时通讯开发厂商也开始基于本人的平台提供业务定制性能，帮忙企业更好地进行im即时通讯的定制开发，满足企业对软件的需要。理解更多能够登录官网征询 https://www.tokim.cn 不同的im即时通讯软件开发说须要的价格并不相同，im即时通讯软件在开发时依据企业个性化定制的复杂程度、工作量等不同会有不同的免费规范，通常是依据工作量来进行价格的划定，在这种状况下价格越高的im即时通讯软件其性能也会更加全面，可能更好地合乎企业对于im即时通讯软件的应用要求。

本文援用自InfoQ社区“5亿用户如何高效沟通？钉钉首次对外揭秘即时消息服务DTIM”一文，作者陈万红等、策动褚杏娟，有订正和改变。 一、引言本文是国内企业IM的事实王者钉钉首次对外深度解密其即时消息服务（即DingTalk IM，简称DTIM）的技术设计实际。本篇文章内容将从模型设计原理到具体的技术架构、最底层的存储模型到跨地区的单元化等，全方位展示了 DTIM 在理论生产利用中所遇到的各种技术挑战及相应的解决方案，心愿借本文内容的分享能为国内企业级IM的开发带来思考和启发。学习交换： 挪动端IM开发入门文章：《新手入门一篇就够：从零开发挪动端IM》开源IM框架源码：https://github.com/JackJiang2...（备用地址点此）（本文已同步公布于：http://www.52im.net/thread-40...） 二、系列文章本文是系列文章的第8篇，总目录如下：《阿里IM技术分享(一)：企业级IM王者——钉钉在后端架构上的过人之处》《阿里IM技术分享(二)：闲鱼IM基于Flutter的挪动端跨端革新实际》《阿里IM技术分享(三)：闲鱼亿级IM音讯零碎的架构演进之路》《阿里IM技术分享(四)：闲鱼亿级IM音讯零碎的牢靠投递优化实际》《阿里IM技术分享(五)：闲鱼亿级IM音讯零碎的及时性优化实际》《阿里IM技术分享(六)：闲鱼亿级IM音讯零碎的离线推送达到率优化》《阿里IM技术分享(七)：闲鱼IM的在线、离线聊天数据同步机制优化实际》《阿里IM技术分享(八)：深度解密钉钉即时消息服务DTIM的技术设计》（* 本文） 相干文章：古代IM零碎中聊天音讯的同步和存储计划探讨钉钉——基于IM技术的新一代企业OA平台的技术挑战(视频+PPT)企业微信的IM架构设计揭秘：音讯模型、万人群、已读回执、音讯撤回等 三、钉钉的技术挑战钉钉曾经有 2100 万 + 组织、5 亿 + 注册用户在应用。DTIM 为钉钉用户提供即时消息服务，用于组织内外的沟通，这些组织包含公司、政府、学校等，规模从几人到百万人不等。DTIM 有着丰盛的性能，单聊、各种类型的群聊、音讯已读、文字表情、多端同步、动静卡片、专属平安和存储等等。同时：钉钉外部很多业务模块，比方文档、钉闪会、Teambition、音视频、考勤、审批等，每个业务都在应用 DTIM，用于实现业务流程告诉、经营音讯推送、业务信令下发等。每个业务模块对于 DTIM 调用的流量峰值模型各有差异，对可用性要求也不尽相同。DTIM 须要可能面对这些简单的场景，保持良好的可用性和体验，同时兼顾性能与老本。通用的即时消息系统对音讯发送的成功率、时延、达到率有很高的要求，企业 IM 因为 ToB 的个性，在数据安全可靠、零碎可用性、多终端体验、凋谢定制等多个方面有着极致的要求。构建稳固高效的企业 IM 服务，DTIM 次要面临的挑战是：1）企业 IM 极致的体验要求对于零碎架构设计的挑战：比方数据长期保留可漫游、多端数据同步、动静音讯等带来的数据存储效率和老本压力，多端数据同步带来的一致性问题等；2）极限场景冲击、依赖零碎谬误带来的可用性问题：比方超大群音讯，突发疫情带来的线上办公和线上教学高并发流量，零碎须要可能应答流量的冲击，保障高可用；同时在中间件广泛可用性不到 99.99% 的时候，DTIM 服务须要保障外围性能的 99.995% 的可用性；3）不断扩大的业务规模，对于零碎部署架构的挑战：比方持续增长的用户规模，突发事件如席卷寰球的疫情，单地区架构曾经无奈满足业务倒退的要求。DTIM 在零碎设计上：1）为了实现音讯收发体验、性能和老本的均衡，设计了高效的读写扩散模型和同步服务，以及定制化的 NoSQL 存储；2）通过对 DTIM 服务流量的剖析，对于大群音讯、单账号大量的音讯热点以及音讯更新热点的场景进行了合并、削峰填谷等解决；3）外围链路的利用中间件的依赖做容灾解决，实现了繁多中间件失败不影响外围音讯收发，保障根底的用户体验。在音讯存储过程中，一旦呈现存储系统写入异样，零碎会盘旋缓冲重做，并且在服务复原时，数据能被动向端上同步。随着用户数一直增长，繁多地区已无奈承载 DTIM 的容量和容灾需要，DTIM 实现了异地多单元的云原生的弹性架构。在分层上听从的准则为重云轻端：业务数据计算、存储、同步等简单操作尽量后移到云端解决，客户端只做终态数据的接管、展现，通过升高客户端业务实现的复杂度，最大化地晋升客户端迭代速度，让端上开发能够专一于晋升用户的交互体验，所有的性能需要和零碎架构都围绕着该准则做设计和扩大。以下章节咱们将对 DTIM 做更加具体的介绍。 四、模型设计4.1、DTIM零碎架构低提早、高触达、高可用始终是 DTIM 设计的第一准则，根据这个准则在架构上 DTIM 将零碎拆分为三个服务做能力的承载。三个服务别离是：1）音讯服务：负责 IM 外围音讯模型和凋谢 API，IM 根底能力包含音讯发送、单聊关系保护、群组元信息管理、历史音讯拉取、已读状态告诉、IM 数据存储以及跨地区的流量转发；2）同步服务：负责用户音讯数据以及状态数据的端到端同步，通过客户端到服务端长连贯通道做实时的数据交互，当钉钉各类设施在线时 IM 及上游各业务通过同步服务做多端的数据同步，保障各端数据和体验统一；3）告诉服务：负责用户第三方通道保护以及告诉性能，当钉钉的自建通道无奈将数据同步到端上时，通过三方提供的告诉和透传能力做音讯推送，保障钉钉音讯的及时性和有效性。同步服务和告诉服务除了服务于音讯服务，也面向其余钉钉业务比方音视频、直播、Ding、文档等多端 (多设施) 数据同步。图1：DTIM架构图 ▼上图展现了 DTIM 零碎架构，接下来具体介绍音讯收发链路。4.2、音讯收发链路图2：DTIM音讯解决架构 ▼1）音讯发送：音讯发送接口由 Receiver 提供，钉钉对立接入层将用户从客户端发送的音讯申请转发到 Receiver 模块，Receiver 校验音讯的合法性（文字图片等平安审核、群禁言性能是否开启或者是否触发会话音讯限流规定等）以及成员关系的有效性（单聊校验二者聊天、群聊校验发送者在群聊成员列表中），校验通过后为该音讯生成一个全局惟一的 MessageId 随音讯体以及接收者列表打包成音讯数据包投递给异步队列，由上游 Processor 解决。音讯投递胜利之后，Receiver 返回音讯发送胜利的回执给客户端。2）音讯解决 ：Processor 生产到 IM 发送事件首先做按接收者的地区散布（DTIM 反对跨域部署， Geography，Geo）做音讯事件分流，将本域用户的音讯做本地存储入库（音讯体、接收者维度、已读状态、集体会话列表红点更新），最初将音讯体以及本域接收者列表打包为 IM 同步事件通过异步队列转发给同步服务。3）音讯接管 ：同步服务按接收者维度写入各自的同步队列，同时查取以后用户设施在线状态，当用户在线时捞取队列中未同步的音讯，通过接入层长连贯推送到各端。当用户离线时，打包音讯数据以及离线用户状态列表为 IM 告诉事件，转发给告诉服务的 PNS 模块，PNS 查问离线设施做三方厂商通道推送，至此一条音讯的推送流程完结。4.3、存储模型设计理解 IM 服务最快的路径就是把握它的存储模型。业界支流 IM 服务对于音讯、会话、会话与音讯的组织关系尽管不尽相同，然而归纳起来次要是两种模式：写扩散读聚合、读扩散写聚合。所谓读写扩散其实是定义音讯在群组会话中的存储模式。如下图所示。图3：读模式和写模式 ▼如上图所示：1）读扩散的场景：音讯归属于会话，对应到存储中相当于有张 conversation_message 的表存储着该会话产生的所有音讯 (cid->msgid->message，cid 会话 ID、msgid 音讯 ID、message 音讯)，这样实现的益处是音讯入库效率高，只存储会话与音讯的绑定关系即可；2）写扩散的场景：会话产生的音讯投递到相似于集体邮件的收件箱，即 message_inbox 表，存储集体的所有音讯（uid->msgid->message， uid 用户 ID、msgid 音讯 ID、message 音讯），基于这种实现，会话中的每条音讯面向不同的接收者能够呈现出不同状态。DTIM 对 IM 音讯的及时性、前后端存储状态一致性要求异样严格，特地对于历史音讯漫游的诉求非常强烈，以后业界 IM 产品对于音讯长时间存储和客户端历史音讯多端漫游都做得不尽如人意，次要是存储老本过高。因而在产品体验与投入老本之间须要找到一个平衡点。采纳读扩散：在个性化的音讯扩大及实现层面有很大的束缚。采纳写扩散带来的问题也很显著：一个群成员为 N 的会话一旦产生音讯就会扩散 N 条音讯记录，如果在音讯发送和扩散量较少的场景，这样的实现相比于读扩散落地更为简略，存储老本也不是问题。然而 DTIM 会话活跃度超高，一条音讯的均匀扩散比能够达到 1：30，超大群又是企业 IM 最外围的沟通场景，如果采纳齐全写扩散所带来存储老本问题势必制约钉钉业务倒退。所以，在 DTIM 的存储实现上，钉钉采取了混合的计划，将读扩散和写扩散针对不同场景做了适配，最终在用户视角零碎会做对立合并，如下图所示。图4：DTIM 读写混合模式 ▼作为读扩散、写扩散计划的混合模式存在，用户维度的音讯别离从 conversation_message 和 message_inbox 表中获取，在利用侧按音讯发送工夫做排序合并，conversation_message 表中记录了该会话面向所有群成员接管的一般音讯 N（Normal），而 message_inbox 表在以下两种场景下被写入：1）第一种是：定向音讯 P（Private，公有音讯），群会话中发送的音讯指定了接收者范畴，那么会间接写入到接收者的 message_inbox 表中，比方红包的支付状态音讯只能被红包发送者可见，那么这种音讯即被定义为定向音讯。2）第二种是：归属于会话音讯的状态转换 NP（Normal to Private，一般音讯转公有音讯），当会话音讯通过某种行为使得某些音讯接收者的音讯状态产生转换时，该状态会写入到 message_inbox 表中，比方用户在接管侧删除了音讯，那么音讯的删除状态会写入到 message_inbox 中，在用户拉取时会通过 message_inbox 的删除状态将 conversation_message 中的音讯做笼罩，最终用户拉取不到本人已删除的音讯。当用户在客户端发动某个会话的历史音讯漫游申请时，服务端依据用户上传的音讯截止工夫（message_create_time）别离从 conversation_message 表和 message_inbox 表拉取音讯列表，在应用层做状态的合并，最终返回给用户合并之后的数据，N、P、NP 三种类型音讯在音讯个性化解决和存储老本之间获得了很好的均衡。4.4、同步模型设计4.4.1 推送模型用户在会话中收回的音讯和音讯状态变更等事件是如何同步到端上呢？业界对于音讯的同步模型的实现计划大抵有三种：1）客户端拉取计划；2）服务端推送计划；3）服务端推送位点之后客户端拉取的推拉联合计划。三种计划各有优劣，在此简短总结：1）首先：客户端拉取计划的长处是该计划施行简略、研发成本低，是传统的 B/S 架构。劣势是效率低下，拉取距离控制权在客户端，对于 IM 这种实时的场景，很难设置一个无效的拉取距离，距离太短对服务端压力大，距离太长时效性差；2）其次：服务端被动推送计划的长处是低提早、能做到实时，最重要的主动权在服务端。劣势绝对拉取计划，如何协调服务端和客户端的解决能力存在问题；3）最初：推拉联合这个计划整合了拉和推的长处，然而计划更简单，同时会比推的计划多一次 RTT，特地是在挪动网络的场景下，不得不面临功耗和推送成功率的问题。DTIM 绝对传统 toC 的场景，有较显著的区别：1）第一是对实时性的要求：在企业服务中，比方员工聊天音讯、各种零碎报警，又比方音视频中的共享画板，无不要求实时事件同步，因而须要一种低延时的同步计划。2）第二是弱网接入的能力：在 DTIM 服务的对象中，上千万的企业组织波及各行各业，从大城市 5G 的高速到偏僻的山区弱网，都须要 DTIM 的音讯能发送、能触达。对于简单的网络环境，须要服务端能判断接入环境，并根据不同的环境条件调整同步数据的策略。3）第三是功耗可控老本可控：在 DTIM 的企业场景中，音讯收发频率比传统的 IM 多出一个数量级，在这么大的音讯收发场景怎么保障 DTIM 的功耗可控，特地是挪动端的功耗可控，是 DTIM 必须面对的问题。在这种要求下，就须要 DTIM 尽量升高 IO 次数，并基于不同的音讯优先级进行合并同步，既能要保障实时性不被毁坏，又要做到低功耗。从以上三点可知，服务端被动推送的模型更适宜 DTIM 场景：1）首先能够做到极低的延时，保障推送耗时在毫秒级别；2）其次是服务端能通过用户接入信息判断用户接入环境好坏，进行对应的分包优化，保障弱网链路下的成功率；3）最初是被动推送绝对于推拉联合来说，能够升高一次 IO，对 DTIM 这种每分钟过亿音讯服务来说，能极大的升高设施功耗，同时配合音讯优先级合并包的优化，进一步升高端的功耗。虽说被动推送有诸多劣势，然而客户端会离线，甚至客户端处理速度无奈跟上服务端的速度，必然导致音讯沉积。DTIM 为了协调服务端和客户端解决能力不统一的问题，反对 Rebase 的能力，当服务端音讯沉积的条数达到肯定阈值时触发 Rebase，客户端会从 DTIM 拉取最新的音讯，同时服务端跳过这部分音讯从最新的位点开始推送音讯。DTIM 称这个同步模型为推优先模型（Preferentially-Push Model，PPM）。在基于 PPM 的推送计划下，为了保障音讯的牢靠达到，DTIM 还做一系列优化。这些优化具体是：1）反对音讯可重入：服务端可能会针对某条音讯做反复推送，客户端须要依据 msgId 做去重解决，防止端上音讯反复展现。2）反对音讯排序：服务端推送音讯特地是群比拟沉闷的场景，某条音讯因为推送链路或者端侧网络抖动，推送失败，而新的音讯失常推送到端侧，如果端上不做音讯排序的话，音讯列表就会产生乱序，所以服务端会为每条音讯调配一个工夫戳，客户端每次进入音讯列表就是依据工夫戳做排序再投递给 UI 层做音讯展现。3）反对缺失数据回补：在某个极其状况下客户端群音讯事件比群创立事件更早达到端上，此时端上没有群的根本信息音讯也就无奈展示，所以须要客户端被动向服务端拉取群信息同步到本地，再做音讯的透出。4.4.2 多端数据一致性多端数据一致性问题始终是多端同步最外围的问题，单个用户能够同时在 PC、Pad 以及 Mobile 登录，音讯、会话红点等状态须要在多端保持一致，并且用户更换设施状况下音讯能够做全量的回溯。基于下面的业务诉求以及零碎层面面临的诸多挑战，钉钉自研了同步服务来解决一致性问题。钉钉的同步服务的设计理念和准则如下：1）对立音讯模型形象，对于 DTIM 服务产生的新音讯以及已读事件、会话增删改、多端红点革除等事件对立形象为同步服务的事件；2）同步服务不感知事件的类型以及数据序列化形式。同步服务为每个用户的事件调配一个自增的 ID（注：这里非间断递增），确保音讯能够依据 ID 做遍历的有序查问；3）对立同步队列，同步服务为每个用户调配了一个 FIFO 的队列存储，自增 id 和事件串行写入队列；当有事件推送时，服务端依据用户以后各端在线设施状态做增量变更，将增量事件推送到各端；4）依据设施和网络品质的不同能够做多种分包推送策略，确保音讯能够有序、牢靠、高效的发送给客户端。下面介绍了 DTIM 的存储模型以及同步模型的设计与思考：1）在存储优化中，存储会基于 DTIM 音讯特点进行深度优化，并会对其中原理以及实现细节做深入分析与介绍；2）在同步机制中，会进一步介绍多端同步机制是如何保障音讯必达以及各端音讯一致性。 ...

im即时通讯的价格依据不同厂商、不同性能有肯定差异，但在以后市场竞争条件下，各大场上的im即时通讯价格差别并不非常显著，而且在细节内容上还各有千秋。以后面向企业的即时通讯中，很多知名企业都提供了优质的im即时通讯，当然他们的价格划定也有肯定区别。 从以后比拟常见的im即时通讯来进行剖析，目前市面上的im即时通讯的价格计费模式中，有些企业提供了套餐包预付费、月结后付费等模式，一种是依据套餐包内蕴含的业务和超过套餐包独自计费进行费用计算，一种则是按月结算每月定期扣除费用。不同厂商的im即时通讯计费模式跟咱们的话费结算零碎具备肯定相似性，在在理论利用中其价格差别还是表显著的。 其实不同类型的im即时通讯在定价方面的价格差别比拟显著，但在定价模式方面根本类似，比方少数厂商的im即时通讯都抉择了根底服务费和增值服务费两种计费模式，另外依据im即时通讯的品种不同，在套餐范畴内也提供了相应的可选范畴。以我司提供的im即时通讯来说，体验版、集成版、定制版以及源码版等都有不同的价格区间。im即时通讯集成版因为汇合了大量的性能和内容价格个别2W起，而定制版im即时通讯的价格从10W起，另外依据客户的需要差别，还会在价格计算上有其余划定，比方新增需要性能是会额定计费的，个别市面上的都是这样，在选购im即时通讯的时候须要依据理论状况进行剖析。 从上述信息来看，公司应用im即时通讯的老本还是比拟可观的，特地是局部大型公司每年破费在im即时通讯上的资金数量并不算少，那么制作一个im即时通讯的老本又如何呢？其实相比于间接应用互联网公司的im即时通讯，制作im即时通讯的老本也并不低廉。 制作im即时通讯首先须要收集相应的源码，而不同类型的源码有开发权限限度，独自开发一套源码的价格也着实不菲，而且差别显著。以我司源码版的im即时通讯来说，依据其性能以及具体要求不同在价格区间设计上通常较为简单，而且因为不同类型工程师的抉择，以及im即时通讯开发中无奈精确预估的内容，具体价格须要进行商谈。 无论是抉择im即时通讯还是本人制作im即时通讯都有肯定的优缺点，企业在抉择im即时通讯服务时应该依据理论状况进行剖析。当然，如果你不晓得制作一个即时通讯要找谁？理解更多能够登录官网征询 https://www.tokim.cn专一即时通讯开发，可提供一站式即时通讯服务，欢送征询。

随着信息社会的疾速倒退，网络作为扭转世界的最重要的因素。泛滥的企业纷纷应用局域网聊天来满足工作与交换高效、疾速执行的需要。企业中应用外部局域网能够使外部信息交互的过程得以简化，从而达到进步工作效率的目标。所以经上所述，公司外部应用即时通讯的形式在各台计算机之间进行交换曾经是时代倒退的趋势。 即时通讯软件即所谓的聊天工具，作为进行文字传输、文件传输的工具被应用在互联网的客户端上。从业余角度来介绍，即时通讯软件个别分为依赖于服务器的与依赖于P2P的。 从现状来看，互联网上深受用户青睐的即时通讯软件次要有以下几个：微信、QQ、YY等等。现在的社会是信息社会，正是因为用户大量的需要促成了即时通讯的开发，信息疾速的传递越来越受到重视同时使得互联网技术越来越成熟，在其中即时通讯软件承当了相当一部分的作用，在这些软件中，一些优良且易用的聊天工具被各位用户所青睐。在中国，腾讯QQ无疑获得了极大的胜利，简略易用，功能齐全，在满足用户根本需要的同时为各位用户提供其它使人满意的性能。即时通讯软件之所以可能取得成功，正是因为其适应了时代，合乎了信息时代用户的需要，它不仅能够提供全面，大量信息给用户，同时也能够使用户的生存更加的精彩，胜利满足了本身商业利益的获取也构建了人们谐和便当的生存。 星动云是做真正稳固的IM即时通讯服务定制商，本产品为纯原生开发。源码破费大量工夫修复开发，非h5,wap网页封装网上下载不能用的产品。星动云IM齐全自主研发，技术难度大，目前性能90%曾经修复成熟，二开开源版已足够定制开发，彻底辞别第三方每月费用！全原生开发技术端：JAVA，C#，OC等。零碎在后续中是会持续进行性能的欠缺与拓展，来实现文件传输，语音传输等各种形式来增强用户的体验，为用户带来极大的便当。 （1）客户提供需要列表，我方依据需要评估费用（2）交易可走线上担保也可走线下合同形式，每个我的项目有专属服务开发qq群对接（3）我的项目最终交付依据需要列表以客户称心为准，提供可上线运行的产品和最终源码（4）任何bug问题，我方随时收费批改，新的需要，依据需要评估酌情免费 理解更多能够登录官网征询 https://www.tokim.cn

局部基本功能聊天：单聊，群聊，音视频通话。发消息：语音，图片，视频，文字，表情，表情包，文件，名片。自定义音讯：发红包，转账。聊天记录：清空聊天记录，群治理，加群二维码管制是否可加。能够自定义增加链接，发现页面也能够增加，二者互不影响。我的钱包：后盾能够充值，用户充值，提现等。创立群：可任意创立群，群成员数量不受限制，好友数量不受限。群性能：设置群二维码，群布告，昵称，头像，群共享文件，顶置聊天，音讯免打搅，屏蔽群信息，指定某人单禁言，整体禁言，举报，群治理，查找聊天记录，禁止全员互相加好友，清空聊天记录等。群治理：群主管理权转让，指定管理员，指定隐身人，对群成员备注，群邀请确认，群组增员设置，容许显示群成员。群音讯销毁：群主和治理能够撤回群内任何音讯等。 操作系统：CentOS 7.0 64位以上，采纳自研websocket协定；视频服务器采纳CentOS 7.0 64位以上，国内jitsi组件其余环境：jdk1.8+mongodb3.4.0+自研websocket通信协定+Redis4.01+Nginx1.9.1服务端：编译环境为IDEA，采纳Java语言，应用Java spring boot框架iOS版：编译环境为XCode6.X以上，采纳Object C++语言，SDK为自研websocket框架。运行环境ios11+安卓版：编译环境为Andriod Studio 1.4以上，采纳Java原生语言，SDK为自研websocket框架PC桌面版：编译环境为MicroSoft .NET，采纳C#语言，Winform框架，SDK为自研websocket框架，.Net framework 4.5.2以上 理解更多能够登录官网征询 https://www.tokim.cn 局部基本功能群聊天：文字，语音，珍藏，照片，小视频，GIF动态图，推送名片，传送文件，音讯告诉，发送地位，援用回复，转发，撤回，复制，删除，多选，发红包，群助手，@提醒，@全体成员，音讯逐条转发，合并转发，合并分享和珍藏，合并删除和保留等。好友聊天：同上朋友圈：能够发送，图文，语音，视频，可点赞，评论，举报等。会员登录：注册登录，短信登录。账号设置：批改明码，语言切换，字体设置，隐衷设置，平安设置，一键群发好友音讯等。用户治理：登录工夫，登陆IP，封禁用户，更换头像，更换名称，设置明码，批量生成用户。所有用户：音讯群发默认好友，配置默认好友，可一键发送音讯。后盾治理：数据总览，系统配置，客户端配置，服务端配置，用户治理，角色治理，群组治理，单聊治理，红包治理，零碎账单治理等治理性能。 基本上该有的性能都有了，次要是不卡顿，不提早，这个才是聊天软件最重要外围的问题。

即时通讯软件曾经成为互联网时代倒退必不可少的通信工具了，即时通讯软件不仅领有便捷的通信条件，还可能高质量的传输视音频文字等，为人们的社交生活和商务工作提供良好的帮忙。即时通讯软件在咱们的生存中占据着重要的位置，然而深究其发展史，大家晓得最早的即时通讯软件是什么吗？ 早在1996年，家用电脑倒退初期，网络通讯晚期就有几名以色列青年研发了一款网络呼叫软件，这也是目前公认的最早的即时通讯服务，而这也是咱们已知最早的即时通讯软件——ICQ。ICQ是目前已知最早的即时通讯软件，于1996年由以色列人发明，这四名发明者于1996年7月成立了名为Mirabilis的公司，并在11月份公布了ICQ的初代版本，仅六个月内有85万用户注册应用。ICQ的母公司Mirabilis于1998年被美国互联网巨头AOL以4.07亿美元收买，但随后的ICQ并没有在即时通讯畛域掀起太大的水花，被收买后的ICQ没有做大做强造成一家独大的位置，而是于2010年被AOL以1.87亿美元价格发售给了DST，逐步被市场所淘汰。理解更多能够登录官网征询 https://www.tokim.cn ICQ作为最早的即时通讯软件也为起初的即时通讯行业倒退提供了良好的案例和范本。ICQ尽管在创造上具备前瞻性，但其最初倒退过程却并没有咱们熟知的facebook或者推特那么侥幸，后续进入即时通讯畛域的竞争者逐步减少，竞争者实力的一直倒退，ICQ在技术上和概念上的倒退并没可能顺应时代的潮流，在当初曾经少有人提及。 ICQ的倒退还是为后续即时通讯软件的倒退提供了很好的指引方向的，在ICQ倒退晚期还不非常稳固时，过后的互联网一哥雅虎也推出了Yahoo!pager这一工具，参加到即时通讯畛域的角逐中，而微软更是靠着Windows messenger内置零碎退出到了即时通讯的赛道中。国内的即时通讯起家不得不说腾讯QQ，作为目前国内最大的即时通讯软件，其于1998年创立胜利，但倒退初期却远不如ICQ顺畅，晚期一度想要卖身给电信公司，最初通过一系列挫折，成为目前排行前列的互联网公司。随着工夫的推移，最早的即时通讯软件逐步匿影藏形，而早年间即时通讯畛域的王者，当初也面临着新的问题。在互联网时代倒退背景下，即时通讯软件所施展的作用不单单是代替电话等电信通信形式，而是依靠互联网技术这一重要的技术类型，实现更高质量，更高品质的即时通讯交换，比方咱们现阶段熟知的视频即时通讯、语音即时通讯、文字以及图片，大型数据文件的传输等等，都是即时通讯软件为当今时代生存带来的条件和扭转。

在信息时代背景下，即时通讯能够说是与咱们生存相干最为亲密的工具了，即时通讯不仅能够帮忙咱们在亲朋好友之间交换通信，也能够为互联网时代的企业员工交换，企业信息互通发明良好的条件。 那么企业即时通讯工具又应该怎么抉择呢？那些企业即时通讯工具是最好用的呢？ 企业即时通讯工具是企业工作中帮忙企业办公的重要工具，企业内员工能够通过即时通讯工具进行信息互通，实现各项工作的交换，进步企业办公效率。企业即时通讯工具的抉择有很多思考方面，首先咱们能够来简略理解一下企业即时通讯工具的排行状况。 企业微信能够说是企业即时通讯工具中的龙头老大。在社交通信类软件中腾讯系的位置是不可比较的。而企业微信作为与微信同源的社交软件，则更适宜企业进行工作交换以及工作汇报。以后企业微信能够疾速链接本人的员工，并且通过在线查问等形式，察看员工是否在线，以及员工在线是挪动端还是电脑端登陆状况。企业微信在公司业务性能上极为全面，不仅能够传输文件，还能够进行视频通话、语音通话等等，不便了企业进行信息交换，腾讯的企业微信会议还能够满足企业召开网络会议的作用。 谈到企业即时通讯工具，其实更多人思考的是一些具备商务性质的通信软件。而腾讯系列的企业即时通讯工具中企业QQ其实是一款比企业微信更加具备代表性的即时通讯软件。企业QQ作为商务版QQ囊括了企业办公须要的各类型条件，企业能够通过企业QQ进行客户分割，疾速统计客户相干信息，与企业客户进行商务单干和沟通，帮忙企业进行会议交换和信息沟通。 而同为企业即时通讯工具的阿里巴巴旗下的钉钉天然也不落后。以后钉钉在社交网络中占据的地位并不显著，但要说企业办公，钉钉以优越的关上零碎，日志统计等各类型企业专用的工作条件胜利位居了企业即时通讯工具的帮手，也是以后大中小企业在抉择办公类企业即时通讯工具时的首选。 除了腾讯系列和阿里系列的企业即时通讯工具外，当然还有其余类型的企业即时通讯工具，比方网易旗下的易信等等，另外一些即时通讯工具也能够帮忙企业进行通信交换，然而与上文介绍的工具相比，他们在功能性和稳定性上略有差别。 企业在抉择企业即时通讯工具时应该留神什么呢？首先是即时通讯的便捷性，也就是这款即时通讯工具到底是否满足企业的日常办公须要，其性能以及后续的服务都要欠缺，以保障企业顺利工作。其次就是企业即时通讯工具的稳定性，企业在抉择这类通信工具的时候肯定要留神察看工具网络连接、主动定位等性能是否稳固，更好的满足企业的办公须要。理解更多能够登录官网征询 https://www.tokim.cn

一、对于RainbowChat-WebRainbowChat-Web是一套Web网页端IM零碎，是RainbowChat的姊妹产品（RainbowChat是一套基于开源IM聊天框架 MobileIMSDK(Github地址) 的产品级挪动端IM零碎）。 不同于市面上某些开源或淘宝售卖的demo级代码，RainbowChat-Web的产品级代码演变自真正经营过的商业产品，其所依赖的通信层外围SDK（即MobileIMSDK-Web）已在数年内通过大量客户及其辐射的最终用户的应用和验证。 ► 具体产品介绍：http://www.52im.net/thread-24...► 版本更新记录：http://www.52im.net/thread-24...► 全副运行截图：http://www.52im.net/thread-24...► 全副运行视频：http://www.52im.net/thread-24... 二、v4.1 版更新内容此版更新内容（更多历史更新日志）：1）bug解决了掉线后收回的音讯，在被断定未送达的状况下，重连胜利时会再次重发的问题（这是MobileIMSDK-Web的bug）；2）优化解决了发送的html等内容，对方显示失常，而自已这边显示不失常的问题（没被本义）；3）优化解决了log4j2的两个jar包抵触导致在linux下不能失常输入log的问题；4）优化优化了应用mysql8.0驱动时，不能正确读取SQL异样信息的问题（会报空指针异样）；5）优化解决了地位音讯发送性能无奈失常应用的问题（高德地图官网API降级，已适配并降级实现）；6）优化解决了地位音讯查看时的地图管制工具不失常的问题（高德地图官网API降级，已适配并降级实现）。降级后的地位音讯相干性能截图（更多截图点此查看）： 三、对于兼容性截止目前：RainbowChat-Web致力保障在各支流零碎、支流浏览器、不同分辨率屏幕上的统一体验，包含但不限于：Chrome、Safari、FireFox、Edge、360浏览器、世界之窗浏览器等▼ ▲ 在各种支流浏览器上的运行状况（更多截图点此进入、更多演示视频点此进入） ▲ 超宽屏上的显示状况（更多截图点此进入、更多演示视频点此进入）  ▲ 不同零碎、不同分辨率屏幕的真机运行状况（更多截图点此进入、更多演示视频点此进入）  四、次要界面截图概览 ▲ 主界面（更多截图点此进入、更多演示视频点此进入）▲ 主界面(聊天窗全屏时)（更多截图点此进入、更多演示视频点此进入）▲ 主界面(聊天窗敞开时)（更多截图点此进入、更多演示视频点此进入）

即时通讯软件置信大家并不生疏，在互联网技术一直倒退的背景下，现在咱们所应用的即时通讯软件也日渐欠缺，各种基础性的文字、语音、视频即时通讯不再是新鲜事，而即时通讯软件也随之产生了各种变动。当初市面上收费即时通讯和付费即时通讯的数量都不算少，二者之间有何区别呢？ 收费即时通讯就是咱们最常见的即时通讯工具，通常以软件模式装置在手机或者电脑当中，收费即时通讯的一大特点就是软件应用是收费的，用户可失常应用语音、视频通话以及文字对话等都是收费的。收费即时通讯尽管根底性能是收费的，但在理论利用中也会有一些附加性能免费，并且收费即时通讯软件为了维持经营，服务商在提供给用户即时通讯服务的同时，会承受相应的广告投放业务，应用收费即时通讯难免会接管相应的广告，局部手机上的广告可能还有一些常见的套路，比方广告闪屏持续时间较长或者敞开键难以寻找等。若理解即时通讯源码，可征询星动云IM。 付费即时通讯在即时通讯工具的用户体验上有更好的体现，最直观的体现就是语音、视频等即时通讯的品质直线回升，除了在即时通讯品质上的晋升外，付费即时通讯也是以后企业最常应用的即时通讯工具。付费即时通讯在软件系统设计中为了投合市场，有更多适宜个人隐私以及企业商务的相干性能，付费即时通讯工具中除了咱们理解的根底文本、语音、视频通信外，还有聊天加密、文件技术传输等性能，能够为用户提供更好的商务性质的即时通讯服务。对于个人用户而言，付费即时通讯除了在通信稳定性和视音频信号保障上有良好的体现外，免广告性能也为很多个人用户提供了更加舒服的即时通讯服务。收费即时通讯与付费即时通讯都是以后互联网市场上比拟常见的即时通讯工具，对于更多的用户来说，抉择收费还是付费类型的即时通讯工具是须要联合本身理论须要来思考的。付费即时通讯软件中依据性能不同、服务范畴不同等，也会有更多的细分，很多企业用户在尝试抉择付费即时通讯时还须要依据企业的需要来定制相应性能，从而更好的实现工作。 收费即时通讯与付费即时通讯不仅在价格上有差别，在性能上以及服务体验方面都有很多的差异，用户在进行抉择的时候最好依据本人的需要和爱好来抉择更加适宜的即时通讯工具，并且留神即时通讯工具的品牌筛选，以便在后续取得良好的售后服务。 理解更多能够登录官网征询 https://www.tokim.cn

互联网时代造就了一批新型产业和体系，而在各类型互联网企业中，软件开发特地是即时通讯软件的开发与利用更是重要的形成。很多人在想到即时通讯时都会被其高质量的信息通信技术以及疾速的信息传输速度所折服，同时也会开始好奇，开发即时通讯到底须要什么样的技术，须要多久的工夫，有须要破费多少资金。接下来让咱们一一解答。 即时通讯的开发是互联网行业中比拟具备技术性的软件开发内容，随着互联网技术的倒退，以后的软件开发曾经不须要工程师从头进行所有程序的编写了，大量开源代码以及共享体系的利用，使得很多工程师能够独立实现一些小型软件的开发制作，无论是工作量还是工作破费上都有了很大的缩小。而即时通讯作为软件开发中具备技术性的一类，在当初的破费和工期依然具备肯定不确定性，能够说，开发即时通讯所须要的工夫和破费在很多状况下是依据软件开发的要求以及开发公司本身技术所提供的。若理解即时通讯源码，可征询星动云IM。 即时通讯的开发工夫会随着即时通讯的性能与内容需要而产生变动。要理解即时通讯开发的具体工夫，首先须要思考本次开发即时通讯的相干要求，在即时通讯开发中须要通过需要剖析、UI设计、APP开发以及零碎测试等阶段实现的。其中需要剖析须要理解即时通讯应该具备什么性能，满足何种需要；在进行UI设计时能够依据理论状况抉择业余设计师或者其余资源来进行UI的设计；在进行APP开发时，更是须要第一阶段的性能需要来进行理论的性能程序编写；最初当所有工序实现后还须要通过零碎测试来跑代码，测验即时通讯是否设计胜利。即时通讯开发的所需工夫通常是不固定的，大厂的工作效率与小厂的工作效率不同，不同复杂程度的即时通讯软件须要的开发工夫也各不相同。如果是集成版的即时通讯，那么开发到交付实现，蔚可云只须要不到一周的工夫，就可部署到客户的app上，让用户立刻领有即时通讯聊天性能。再来谈即时通讯的开发费用问题。很多人感觉即时通讯能够通过集成技术以及开源代码的利用等疾速实现软件的开发，那么价格应该比拟低，而理论状况也同样与上述开发内容一样，依据不同即时通讯的复杂程度、开发工期，最终须要的破费也是不固定的。以蔚可云为用户提供的即时通讯为例，体验版、集成版、定制版以及源码版各具备不同的价格。通常集成版因为汇合了大量的性能和内容价格个别2W起，而定制版即时通讯的价格从10W起，依据客户开发的不同需要，还会有具体的价格计算等。 即时通讯作为互联网时代的重要工具，想要开发即时通讯所须要耗费的工夫和费用都是须要认真剖析的，只有做到充沛理解，才可能更好的研发合乎本人需要的软件。理解更多能够登录官网征询 https://www.tokim.cn

即时通讯当初曾经随着互联网技术的利用走进了千家万户，跟早些年的通信工具不同，当初的即时通讯技术曾经涵盖了语音即时通讯、视频即时通讯、文字即时通讯等多种形式，而开发即时通讯也成了很多互联网企业投身这一行业后想要尝试的内容。开发即时通讯容易吗？开发即时通讯都须要用到什么技术呢？ 即时通讯软件的开发切实算不上容易，因为在开发即时通讯软件的过程中牵扯到的可不仅仅是通信技术，受到以后网络技术倒退和网络信息安全保障等条件的影响，咱们明天的即时通讯开发还须要牵扯到网络技术、窃密技术以及P2P技术等多种技术类型。接下来让咱们对它们进行简略的剖析。 即时通讯的开发首先波及到通信技术。通信技术是即时通讯中最为要害且重要的技术类型，现阶段的即时通讯除了须要传输文字、图片、短视频等媒体文件外，为了保障通信的综合性还须要实现音视频语音对话的性能，也就对咱们的通信技术提出了更高的要求。在通信技术应用中，设计人员须要进行视频、文字、音频等多种信息的信号编码录入和输入技术的利用，让通信技术可能与网络相结合，从而实现即时通讯的过程。 网络技术也是即时通讯中不可短少的内容。咱们把即时通讯与传统通信技术相比拟，就会发现即时通讯是一种将传统通信转移到网络系统中的新型通信形式，即时通讯中网络施展的作用也不单单是网络根底连贯和沟通，还有网络信号的传输速度和传输稳定性。即时通讯中如果网络传输速度慢，就会产生通信提早的问题，如果传输不稳固就会产生卡顿等状况，影响咱们的即时通讯过程，尤其在以后无线网络信号广泛应用的背景下，即时通讯的网络技术更是比拟重要的内容。理解更多能够登录官网征询 https://www.tokim.cn 说起P2P技术，很多敌人或者不理解它与即时通讯之间的关系。P2P也就是咱们常说的点对点技术，也能够被称为对等互联网技术，这样解释大家或者就会明确它跟网络技术之间的蕴含关系了。以后的P2P技术被广泛应用于实时媒体业务的数据通信中，能够对互联网通信中的客户端-服务器模型等进行更好的服务，帮忙咱们进行即时通讯的无效设计。