想做后台服务器架构设计，要把握以下几个因素
1. 要处理多大的数据量
2. 有多少种的数据
3. 延迟有多高
4. 要不要处理通知
通常情况下，数据种类越多，数据量越大，系统架构越复杂； 比如 处理 百万级的请求 一台单机便能搞定，处理上亿次的请求，通常会选用微服务架构；
后台设计中 一个典型的三层架构设计：接入，逻辑，存储， 虽然这个架构不能包治百病，但是从一定程度上通过变型能说明问题；
接入层 通常是要有的，例如 bs 模型中 http 请求通过 nginx 分发， nginx 属于 接入层；cs模型中通常会有长连接， 接入层通常会维护连接，鉴权，路由，以及负责通知；
逻辑层 通常是处理数据，进行运算的， 为了系统稳定可靠， 每个逻辑服务器可能会有多个备份，请求实现负载均衡
数据层 分为数据库以及缓存数据， 这个根据数据量和数据种类而定， 就数据库而言， 关系数据库， 非关系数据库，文件，kafka 均可以当数据库来用，当数据库遇到性能瓶颈时，我们通常会引入缓存，来缓解数据库压力； 至于缓存击穿，缓存与数据库同步属于另外的问题；
延迟 和数据量 互相矛盾， 延迟小意味着处理数据能力有限， 笔者曾把文件数据读取到内存，接入层，逻辑层合并成一个程序，从而实现了最快速度；缺点也很明显，文件数据容易出错，单机容易达到性能瓶颈； 延迟小要求通常也会限定应用层协议，比如
json， protobuf，avro 流化与反向流化， 都是一笔不小的时间开支； 延迟要求小还会限定 通讯协议的 加密与压缩算法，以及采用的协议类型， 当数据量大时，http协议没有tcp以及websocket长连接协议效率高；
路由其实在系统设计中也重要的一环， 笔者认为 SOA 与 微服务架构 比较 重要的区别在于 路由上， 微服务服务注册与发现 注定了 微服务架构 的处理能力 比 SOA强太多，腾讯 tars 有100多个业务、1.6多万台服务器上运行使用是 任何SOA都实现不了的；
1. 终端要处理通知 ： tcp，websocket ，不处理通知： http， 当然通知也可以通过轮询来模拟实现通知功能；
2. 延迟要求: 延迟要求小时，很大程序上限制采用的协议，压缩加密算法， 通讯协议； 延迟要求不高：可以采用avro，protobuf或者自定义应用层协议，请参考《手把手教你实现自定义的应用层协议》 以及《深入理解 RPC 消息协议设计》 两篇文章
3. 处理数据量以及数据种类，对于一个普通企业而言，数据量不大的情况，没必要为了采用什么架构争来争去，通常情况下都能满足业务要求，有句话说的好，系统是通过业务量和访问量的提升来考虑重构架构设计，以便能够适应当前的环境。
4. 好的系统 数据的同步和通知是必不可少的， 比如数据库主从同步， 数据库发生变更向 缓存通知种种，业务量上来以后这些功能都是必不可少的，主从同步通常数据库会内置， 数据库变更向缓存通知 阿里提供了canal解决方案， github上读取binlog同步的方案非常多； 做通知 必然要有PUB-SUB模型， 可以采用 现有的总线，也可以自己写一个PUB-SUB模块，这些都有现成的例子或者demo
兵无常势 水无常形， 限制条件少时 后台服务器并不会难写，有非常多的途径或者办法来实现目标；当限制条件慢慢增多时，那么设计系统就要小心，再小心，可能某种机制了解错误就会导致整个系统推倒重来，或者随着业务量和访问量增加导致系统设计失败；