逻辑层的职责，功能上：
用户相关：用户登录登出，用户信息设置查询。
好友相关：添加好友，删除好友，修改好友。
消息相关：收发好友消息，收发陌生人消息等。
A给B发消息，先判断B是否把A拉黑，如果拉黑消息直接丢弃。如果没有，还要判断消息是否有涉黄政治病毒等内容，这部分验证交给反垃圾系统来处理。如果通过，接下来判断B用户数是否在线，在线发送到在线队列。离线，发送到离线队列。
逻辑层整体架构：
ALL IN ONE（业务垂直划分）方式----一个单独的业务一个组件（目录和文件）。优点：业务独立，耦合性降低，业务之间开发互不影响，开发效率高，运维相对简单。缺点：物理上一个模块，编译成本高，一个业务修改，重新上线，重启影响所有业务。使用场景，互联网公司使用较多，58，百度。
业务间物理崔志划分方式，每个业务一个独立的业务模块（进程）。用户，商品，搜索，交易，推荐，社区，运营活动，客服分成不同的独立进程（独立部署）
无状态业务逻辑层如何设计？
什么是无状态，系统不存储业务的上下信息，仅根据每次请求携带数据进行相应的业务逻辑处理。多个模块（子系统）之间完全对称。请求提交到任何服务器，处理结构都是完全一样的。
设计的关键因素：业务逻辑层不保存请求状态，业务逻辑层不保存数据，所有业务逻辑层服务器完全对称，当一台或多台宕机请求提交集群中的任意可用服务器，业务逻辑层通过负载均衡高可用。
负载均衡：服务器可用状态实时监控高的机制，自动转椅失败任务（机器）的机制，请求量和数据较高，将流量和数据分摊到集群中多台服务器的能力。通过心跳机制发现下游服务器不可用，剔除掉。一旦服务器可用，可以自动重建恢复。
同步调用：调用者阻塞模式，没有得到结果就不返回。
异步调用：调用后立即返回，结果完成后，通过状态、通知和回到来通知调用者。掉用着是非线程阻塞模式。
如果异步调用：例如：新用户注册请求，假设需要两步，一用户名和密码写入数据库，二发送注册成功邮件。异步方式实现：一新用户注册请求写入消息队列，直接返回成功给请求调用者。业务逻辑层通过消息队列中读取请求，异步执行第一步和第二步。调用者步阻塞，效率高，性能高。
异步调用场景：I/O模型：阻塞I/O模型，轮询非阻塞I/O模型，I/O复用模型（监听的文件句柄ID数字要小于1024）
高性能纯异步网络调用设计
server端链接池|server端收发队列，client端连接池|client端收发队列；超时队列与超时管理器；上下文管理器+状态机。
分级管理
硬件上：核心系统用好机器，边缘熊使用差机器。
部署层面上：服务部署隔离，避免故障带来的连锁反应，核心系统部署在物理机上，核心系统部署在不同机房上，边缘系统部署在虚拟机，边缘系统部署在共用机器上。
监控层面上：核心服务更多类型的监控（进程，语义，错误日志），监控力度更细，邮件和短信通知。
响应层面上：核心服务开发响应迅速，核心服务上线响应迅速，核心服务运维响应迅速，核心服务上线问题处理迅速。
设置合理超时
业务逻辑层和下游模块交互次数多，设置合理超时非常重要，下游服务宕机，线程死锁等，请求得不到响应，请求占用资源，调用方得不到响应，用户体验差。
请求的超时设置根据请求的平均响应延迟的2倍，响应延迟高超时可以设置3S，响应延迟低超时可以设置100MS。下游请求超时后，业务层根据预设的调度策略重试，一般3次，多次请求无好处（会造成下游压力，雪崩），请求转椅到下游其他同样的服务商。
业务逻辑层服务降级设计
网站高峰期，并发量大。服务能力有限，性能下降，服务宕机，系统雪崩。
保证核心服务可用（下单，交易），非核心服务弱可用，甚至不可用，降级设计方案（拒绝部分请求，关闭请求）
拒绝部分请求：拒绝低优先级服务的调用（评论，留言，私信），消息到达队列的时候工作线程会接收队列，如果发现消息队列已经超过1S就可以对此消息丢弃，另外还有一个方式直接丢弃非核心业务消息。减少服务调用并发数，随机丢弃一定比例的消息，或者按优先级丢弃消息。
关闭部分服务：非核心服务直接关闭，上游不直接不调用下游服务。
服务器幂等设计：请求失败会重试，保证服务重试调用和一次调用结果相同（幂等性）。不能保障幂等结果是悲剧的：转账，交易，支付。
天然幂等：离线消息设置为已读，多次设置都是一样的。
非幂等需要幂等设计：支付ID，支付状态，这两个一定要是原子的。每次支付前判断支付状态，未支付状态继续进行，已支付了就终止。也可以用记录的方式处理幂等设计。
超时管理器设计：发送下游包的超时管理，避免无限等待，单独线程，定时扫描，超时处理触发其回调。
上下文管理器：请求上下文，请求会带一个唯一的package_key，超时等删除上下文，所以在上游调用时一定要存储一个package_key，回调时候只可以对应上。
状态机管理器：异步调用的状态机，标志请求的状态，串行执行的状态机