多点登录和消息漫游设计实现

“多点登录”是指多个端同时登录一个帐号，同时收发消息，关键点是： (1) 需要在服务端存储同一个用户多个端的状态与登陆点； (2) 发出消息时，要对发送方的多端与接收端的多端，都进行消息投递； “消息漫游”是指一个用户在任何端，都可以拉取到历史消息，关键点是： (1) 所有消息存储在云端； (2) 每个端本地存储last_msg_id，在登录时可以到云端同步历史消息； (3) 云端存储所有消息成本较高，一般会对历史消息时间(或者条数)进行限制；

Google BigTable

BigTable是一个稀疏的、分布式的、持久化的、多维度排序的、大数据量存储系统，它能够解决符合上述map数据模型业务的存储问题。

离线消息设计实现

“离线消息”的玩法，可能比大家想象的要复杂，常见的优化有： (1) 对于同一个用户B，一次性拉取所有用户发给ta的离线消息，再在客户端本地进行发送方分析，相比按照发送方一个个进行消息拉取，能大大减少服务器交互次数； (2) 按需拉取，是无线端的常见优化； (3) 分页拉取，是一个请求次数与包大小的折衷； (4) 应用层的ACK，应用层的去重，才能保证离线消息的不丢不重； (5) 下一页的拉取，同时作为上一页的ACK，能够极大减少与服务器的交互次数；

消息顺序性设计实现

（1）要“有序”，先得有衡量“有序”的标尺，可以是客户端标尺，可以是服务端标尺； （2）大部分业务能够接受大范围趋势有序，小范围误差；绝对有序的业务，可以借助服务器绝对时序的能力； （3）单点序列化，是一种常见的保证多机时序统一的方法，典型场景有db主从一致，gfs多文件一致； （4）单对单聊天，只需保证发出的时序与接收的时序一致，可以利用客户端seq； （5）群聊，只需保证所有接收方消息时序一致，需要利用服务端seq，方法有两种，一种单点绝对时序，另一种id串行化；

领域模型和微服务的关系

微服务架构首先要关注的不是RPC/ServiceDiscovery/Circuit Breaker这些概念，也不是Eureka/Docker/SpringCloud/Zipkin这些技术框架，而是服务的边界、职责划分，划分错误就会陷入大量的服务间的相互调用和分布式事务中，这种情况微服务带来的不是便利而是麻烦。 DDD给我们带来了合理的划分手段，但是DDD的概念众多，晦涩难以理解，如何抓住重点，合理的运用到微服务架构中呢？ 我认为如下的几个架构思想是重中之重 • 充血模型 • 事件驱动

群消息设计实现

群消息还是非常有意思的，做个简单总结： (1)不管是群在线消息，还是群离线消息，应用层的ACK是可达性的保障； (2)群消息只存一份，不用为每个用户存储离线群msg_id，只需存储一个最近ack的群消息id/time； (3)为了减少消息风暴，可以批量ACK； (4)如果收到重复消息，需要msg_id去重，让用户无感知； (5)离线消息过多，可以分页拉取（按需拉取）优化；

微服务架构服务拆分粒度

总的来说，细粒度拆分的优点有： • 服务都能够独立部署 • 扩容和缩容方便，有利于提高资源利用率 • 拆得越细，耦合相对会减小 • 拆得越细，容错相对会更好，一个服务出问题不影响其他服务 • 扩展性更好 细粒度拆分的不足也很明显： • 拆得越细，系统越复杂 • 系统之间的依赖关系也更复杂 • 运维复杂度提升 • 监控更加复杂 • 出问题时定位问题更难

微服务架构，RPC细节

什么是RPC调用？ 像调用本地函数一样，调用一个远端服务。 为什么需要RPC框架？ RPC框架用于屏蔽RPC调用过程中的序列化，网络传输等技术细节。让调用方只专注于调用，服务方只专注于实现调用。 什么是序列化？为什么需要序列化？ 把对象转化为连续二进制流的过程，叫做序列化。磁盘存储，缓存存储，网络传输只能操作于二进制流，所以必须序列化。 同步RPC-client的核心组件是什么？ 同步RPC-client的核心组件是序列化组件、连接池组件。它通过连接池来实现负载均衡与故障转移，通过阻塞的收发来实现超时处理。 异步RPC-client的核心组件是什么？ 异步RPC-client的核心组件是序列化组件、连接池组件、收发队列、收发线程、上下文管理器、超时管理器。它通过“请求id”来关联请求包-响应包-回调函数，用上下文管理器来管理上下文，用超时管理器中的timer触发超时回调，推进业务流程的超时处理。

关于负载均衡

负载均衡（Load Balance）是分布式系统架构设计中必须考虑的因素之一，它通常是指，将请求/数据均匀分摊到多个操作单元上执行，其的关键在于均匀： • 反向代理层的负载均衡，是通过“DNS轮询”实现的 • 站点层的负载均衡，是通过“nginx”实现的 • 服务层的负载均衡，是通过“服务连接池”实现的 • 数据层的负载均衡，要考虑“数据的均衡”与“请求的均衡”两个点，常见的方式有“按照范围水平切分”与“hash水平切分”

微服务设计

• 每个服务都是一个轻量级、独立和松散耦合的业务单元。 • 每个服务都有自己的代码库，由一个小团队管理和开发（主要是用于敏捷环境中）。 • 每个服务负责一部分功能或者说业务能力，并且做得很好。 • 每个服务都可以为其用例选择最佳的技术栈（无需将整个应用程序绑定在一个框架中）。 • 每个服务都有自己的DevOps计划（测试、发布、部署、扩展、集成和独立维护）。 • 每个服务都部署在一个独立自给的环境中。 • 服务通过使用定义良好的API（智能端点）和简单协议如基于HTTP 的REST协议（哑管道）相互通信。 • 每个服务负责持久化自己的数据和保持外部状态（只有当多个服务使用相同的数据时，这种情况才在公共数据层中处理）。