主页

一、引言 对于我司的长连接架构而言，我们除了全面 MQTT 化之外，也可以选择逐渐走向全自研方向。从我司现有的业务场景与技术需求来看，使用自定义二进制协议也可以实现。 基于我司需求的长连接整套架构的重新优化，我们需要实现高可控，高性能，高产出的技术形态，并与业务深度结合的形式，提供一个清晰明确的迭代路径。 二、现状与问题 目前长连接消息架构有几个问题需要考虑： 对于基于C/S架构的长连接服务，在我司这种多场景多模态共享连接的消息机制下，发布订阅机制其实是没有必要的，取消订阅环节可以减少业务复杂性，在非对等连接状态下，客户端没必要维护一个本地服务消息通路路由，这种模式一般是用于p2p下直接向其他用户发送消息的模式才使用的，在我司的业务场景下，由服务端维护用户状态即可 ...

背景 在 Android 应用开发中，使用多进程，为不同服务创建独立进程是非常常见的。比如推送、保活、WebView、内存不够等优化策略。 目前 Android IPC 均是在 Java 层处理，随着 Android、iOS 一些底层组件、通用业务等使用 Rust 跨平台开发，为了更好的支持业务开发，因此调研已提供 Rust 侧 IPC 能力。 IPC 目的 在不同的进程之间安全有效地共享数据和消息，从而实现进程间的协作和数据交换。 IPC 机制有哪些 管道（Pipes）、消息队列（Message Queues）、共享内存（Shared Memory）、信号量（Semaphores）、套接字（Sockets）、文件、Binder（Android）、广播（Android）等 ...

一、引言 目前我们对于MQTT的使用策略是将其作为一种纯粹的消息协议来使用的，对于整个MQTT技术栈来说，协议只占其中大约三分之一的应用开发范围；就如同W3C Trace Context协议之于OpenTelemetry，MQTT本身也是有一套基于OASIS提供的标准开发、实施、部署的完整解决方案。 而我司对MQTT的使用则是只使用了其中的协议层，并且这个协议层本身的特性也只实现了最基础的部分，更为复杂的协议特性大多都是放在业务层进行实现而非通过框架开发或者架构设计进行通用性处理，以致于我们在长连接消息任务的处理上经常遇到由于基础能力依赖业务实现导致的代码功能职责混乱，从而产生很多难以排查难以预警的问题，出现一种bug如同“打地鼠”的感觉。 因此对于我司的长连接架构使用我们应当进...

背景 技术背景 23 年客户端提出了客户端容器化的架构，整个 23 年都是围绕着跨平台基础层和平台基础层进行建设。 经过一年时间的推进，基本上达成了下面的成果： 模块 目标 业务接入情况 我司业务覆盖率 基础能力层 长链接 我司全部长链接都使用跨平台长链接组件 接入 Push、wChat 、matchRamdom、世界服、花园、冰饮、match等业务场景 75% 短链接 新增业务都采用跨平台短链接组件 接入平台化 Pas...

前置信息 本文翻译自cncf-tag-observability-whitepaper，可能会有语句不通顺或者某些专有名词翻译错误的问题，建议对照英文原版进行阅读。 以下内容为正文： 欢迎来到观测性白皮书社区驱动的1.0版本。由CNCF生态系统中的TAG Observability主导，于2023年10月发布。 我们的白皮书的这个版本只是一个开始！有许多更多的主题要涵盖和要添加的内容。 请查看贡献部分，提出对此白皮书的更改并帮助我们为所有CNCF用户扩展这个知识库。 执行摘要 随着系统复杂性和我们每秒处理的数据的不断增长，我们需要更好的观测性来了解我们工作负载的状态。在观测性工具的基础上，现在更普遍地期望每个负责运行其软件作为服务的工程师了解如何监视和观察他们的应用程序。随...

背景简介 在我司的发展中，业务系统逐渐复杂化，微服务的规模也在不断膨胀，而对于后端乃至整个应用体系的可观测性一直缺少一个系统化的方案。这些问题主要分为四类： 故障定位困难，用户一个简单的操作，可能背后会涉及到十几个甚至数十个微服务去共同完成，一旦出现问题，排查起来将十分困难。 容量预估困难，在微服务系统中由于每个服务在不同链路中的重要性与参与度并不相同，我们并不能对每个系统做等比例扩容，因此相对精准的容量预估很困难。 资源浪费多，这也是由于无法准确预估容量导致的一个结果，同时也隐含了性能优化困难的问题，比如一个业务执行缓慢，由于链路关系复杂，无法直观确定瓶颈，需要进行针对性的排查，导致优化滞后迟缓；同时此类问题不断积累，为了快速解决问题，可能就粗暴的对整条业务进行扩容...

背景 技术背景 在22年，我们的主要是以平台化为主的技术发展方向，其中在去年的规划文档中，我们大概提出了容器化的概念与一个初步的演进方向（如下图所示）。 经过一年的尝试与不断的调整，我们逐渐总结出了之前架构设计的一些问题，明确了一些模糊的概念，建立了一些基础设施，通过这些积累，我们清晰的认识到适合于整个我司平台的客户端应用架构应该是什么样的。 去年一年我们的Rust基建逐步成熟，具有Rust开发能力的人员对这个技术方向不断深入；组内同学对跨平台交互逐渐熟悉，并有了一定的跨平台UI建设的积累；部分领域架构也有了统一的设计，对特定领域的技术演进也有了一定的沉淀；游戏在客户端中的重要性逐渐提升，App本身逐渐往平台支撑的方向演化。这一切都提示我们，之前的容器化架构在设计上存在着诸多...

背景 实现一个可以完成游戏端/Web端与业务服务之间的跨语言协议交互的网关，主要实现以下功能： 基于 Cocos 运行的游戏 基于 Unity 运行的游戏 基于 WebView 运行的游戏或业务 协议相关 协议调用方式 目前协议调用方式有以下六种情况： 只要请求，无需协议实现方回复 请求和回复协议使用相同协议名 请求协议与回复协议使用不同协议名 请求协议与回复协议使用不同协议名，且回复协议有多个，会根据处理结果选择其中一个协议进行回复，1vN 由协议实现方（例如长连接、RTC等持续服务）主动向游戏业务发发送消息 多场景共存情况，协议调用结果不止要回复给调用方，还需发送给其他关注方。例...