本文介绍了服务端在搭建 Web 版的百万人级别的群聊系统时，遇到的技术挑战和解决思路，内容包括：通信方案选型、消息存储、消息有序性、消息可靠性、未读数统计。

B端前端交互领域是处于视觉设计师、产品和前端之间的交叉地带，交互量化、实践及优化指引有助于B端体验、操作作业效率的提升。

“提交订单”这一词大家应该都是再熟悉不过了，不管你是不是软件研发人员，还是普通使用电商APP购买商品的用户，只要你在购买商品时必然会遇到。

消息丢失和消息重复消费这两个情况，相信是业务工程师在使用 Kafka 的时候最害怕的事情，今天我们就聊这两个问题。

一、订单系统概述 1.1 业务范围 服务业务线：快递、快运、中小件、大件、冷链、国际、B2B合同物流、CLPS、京喜、三入三出（采购入、退货入、调拨入、销售出、退供出、调拨出）等 1.2 订单中心价值

众所周知，构建一个完整的日志体系是保障开发顺畅的第一步。而一个构建完整的日志体系所耗费的时间其实并不少于开发几个功能模块的时间了，那么在日常开发中为了节省这时间简单记录日志，我做出来以下一些尝试

面试官：“滴滴打车用过是吧！看你简历里写道会架构设计是吧，如果让你设计一个网约车系统，你会从哪些方面考虑呢？”

这篇文章以 Dubbo 为出发点，向我们详细介绍了 Spring Cloud、Dubbo、gRPC、Istio 等几个框架产品以及它们各自的优势与差异，相信对我们微服务技术选型能带来一定的帮助。但正如

伴随政府采购业务的快速发展，政采云的商品数据量也在快速膨胀，其中由 ES 进行提供的商品检索服务压力，也越来越大。由于商品模型中基础商品和交易商品的定义，导致商品本身的量会相对一般的电商场景多出一倍。