前言
作为Android移动端的一枚小菜鸟，时不时的也会想想自己未来的路该如何走。架构师是个不错的方向，作为一个门外汉，仅以此篇记录下自己那些七零八碎靠谱或者不靠谱的想法。
欢迎加入学习小组QQ群: 193765960。
版权归作者所有，如有转发，请注明文章出处：https://xiaodanchen.github.io/archives/
通讯协议和数据格式
request、response
head、body
error code、error message
客户端、服务端统一参数定义格式，统一大小写，统一编码格式
接口版本技术：
为了兼容不同的软件版本或者业务版本，在后台接口设计的时候加入版本信息字段。后台根据版本信息做逻辑处理。
数据库主键设计
数据同步技术：
唯一标识方案(主键设计参看上面文章)：
1、服务器端产生GUID作为数据的唯一标识同步到本地（优点：唯一性；缺点：需要存储多终端oldGUID，数据处理逻辑稍复杂。）
2、使用几个特殊字段拼出一个字符串做加密（MD5?），使用密文作为唯一标识（优点：同步逻辑简单。缺点：字段如果有变化，数据不会作为修改数据而是作为新增数据）
3、业务ID与物理ID：
使用GUID作为物理ID；使用某些业务数据拼出的MD5加密字符串作为业务ID。
新增、修改、删除数据在向服务器同步时，服务器需要校验业务ID。
如果服务器已存在业务ID，根据物理ID来进行数据是新增还是合并。如果数据存在合并，服务器需要向客户端返回合并后的物理ID和客户端原来的物理ID，客户端接收到合并信息后，对本地的数据的物理ID进行修改。
数据同步方案：
方案一：
1，同步方法：
对所有需要同步的数据按新增、修改、删除进行分类。
按照修改 -> 删除 -> 新增 -> 查询的流程逐条同步。在每一条同步结束后，回调同步方法。
2，缺点：
如果在某条数据同步失败，容易使整个同步流程陷入死循环或者卡壳。
死循环：造成应用卡顿，同步失败。
卡壳：数据同步失败。
3，解决办法：
客户端和服务端要协定好各种业务异常的通知机制。
方案二：
1，同步方法：
设定初始同步起始物理ID（最小比如“0000”）
根据同步起始物理ID，检出本地所有需要同步的数据，数据按物理ID从小到大排序。
取出第一条数据，判断数据是新增、修改还是删除。
将该条数据的物理ID设置为同步起始物理ID。
对该条数据调用相应的同步接口。
该条数据返回后，不论是否出现异常，继续回调同步方法（本条数据的物理ID为同步起始ID）。
当所有同步数据同步完成后，清零化同步起始物理ID，查询服务器数据到本地。
2，优点：
不会死循环和卡壳
3，缺点：
失败的数据不会同步到服务器，除非服务器做特定的兼容和适配。
注意：
以上两种方案，在获取到批量数据更新到本地数据库时，需要判断本地数据的状态，本地未同步的数据不允许被服务器的数据覆盖。
增量更新。
数据备份技术：
双机热备份技术
未完，待续
