一个人实现一套app系统（1.3： 流程）

一个人实现一套app系统（1.3： 流程）

2015-11-22李万胜风铃草科技

第 3 节流程

内容摘要

上一节 讲解了系统的组成单元，从比较粗的粒度上分解了模块的功能。本节将在此基础上，讲解模块与模块之间的关系，我们需要通过流程图的形式展现模块与模块之间的关系。我们将以数据流向为线索，讲解各个功能中数据的流向及处理逻辑。

登陆流程

修改个人资料流程

聊天流程

推送流程

登陆流程

用户输入用户名密码。

用户名密码不符合要求，提示用户，流程结束。

APP把用户名密码发送到服务器。

不符合密码规则，返回提示给客户端，流程结束。

查询数据库，获取服务器存储的用户的密码。

将用户密码返回给服务器，服务器判断密码是否正确，如果不正确，走到4，如果正确，走到7。

返回登陆成功提示给客户端。

客户端根据正确登陆提示，从登陆界面跳转到主界面，流程结束。

本部分内容比较简单明了，我们把上一节讲到的组成模块，用数据流关联了起来。通过讲解模块在流程处理中的功能，来解释系统的实现原理。

修改个人资料流程

登陆成功之后，请求用户个人资料。

业务服务器查询数据库。

查询用户的所有字段信息给业务服务器。

业务服务加工数据库信息并返回给客户端。

客户端修改个人信息，并提交业务服务器。

业务服务器做处理后，将数据存入数据库，如果提交数据不符合业务要求，则通过步骤8提示客户端重新修改。

数据库提示存储成功与否给业务服务器。

业务服务器提供修改结果给客户端，流程完毕。

本部分内容与登陆类似，只涉及客户端，业务服务器和数据库。但不同之处是该业务需要首先查询，然后再做修改，是集查询与修改一体的一个操作流程。

聊天流程

客户端A发送消息到B:通过Websocket协议，A将聊天内容发送到聊天服务器，并告诉聊天服务器，接受者为B。

聊天服务器根据接受者B的信息，查询B的消息监听频道。（B在上线后首先要做的就是告诉聊天服务器，自己能够接受消息的频道）。B的监听频道和A的发送频道都由Redis来管理。在聊天服务器查询到B的监听频道之后，将消息内容通过A的发送频道发送到Redis。

Redis感知到从A发送来的消息，并且明确知道目标是B之后，将消息路由到B的监听通道。

聊天服务器从B的监听通道得到聊天内容之后发送给客户端B，流程结束。

Redis会保留A->B的聊天内容，但是Redis组件主要负责内存级存储，为了将聊天内容永久保存，可以配置Redis将内容定时保存到磁盘上。

本部分内容从逻辑上来说是最简单的了，但是从技术实现上却是复杂的部分，主要体现在聊天服务器需要多线程并发的处理大规模的聊天请求，还要准确无误的路由消息到各个客户端。

推送流程

客户端产生业务请求到业务服务器。

业务服务器处理逻辑，判断该业务需要产生推送消息。将推送消息发送到推送服务器，并标明接受者信息。

如果接受者是Android用户，则消息直接推送到客户端手机，流程结束。

如果接受者是IOS手机，将推送消息缓存起来。

推送服务器的定时任务到缓存中读取推送消息。

定时器读取消息后，将消息推送到苹果官方的推送服务器。

通过IOS系统，苹果服务器会将推送内容发送到IOS客户端的，流程结束。

本部分内容在流程处理上是最复杂的，因为涉及的模块比较多，既有本方自己开发的服务，又有与第三方系统的交互。但在技术实现上却是最简单的，因为每一个部分的实现都不需要编写太复杂的逻辑，同时推送消息是不需要可靠性保证的，就是说推送消息是无法保证100%到达的，从理论上我们不需要过多的考虑可靠性，一致性的技术设计。

本小节内容比上一节要清晰很多，从细分功能的角度分解系统比较容易理解。实际上从这个角度分解内容之后，将有共同属性的服务集中在一起，就是一个模块，一个功能集模块就是上节我们讲到的架构。架构与流程实际上是从不同维度分解系统的方式。

下一章我们将正式讲解技术细节。本章的各个小节只是从比较粗的粒度分解系统，给大家一个直观的系统感受，如果没有看懂本章的设计理念，也并不影响接下来的章节学习。实际上本章的作用也只是给大家一个直观的感受而已，并且本书的设计，模块与模块之间也并不是强相关的，适合分解开各自学习。

下一章我们首先开始讲解Android界面的开发，请同学们准备好一台电脑和一台Android的手机。

欢迎同学们关注并转发本公众号