- 数据完整性检查
app 通过https/http协议 以json字符串的格式 请求包： 1 定长header(uid、sessionId(请求唯一标识、cmd(请求命令号)、body length)) 2 变长body 原则： 不会对价格字段做检查（不会处理具体业务语意） 但要做非空检查（通用逻辑）
- 请求鉴权
- 粗粒度：ip白名单
- 细粒度：请求参数中有token，基于过滤器做token验证
1、登陆鉴权是属于具体业务 不属于请求鉴权 放在业务逻辑层 2、鉴权规则配置到配置中心 可视化方式获取
- 协议转换
请求进入网关之后 不用短连接
传输协议
rpc oven tcp 可以提升传输效率
数据协议
protobuf google （用json传输量大 pb二进制且压缩）
网关不需要理解具体的业务语意 1、json{k1,v1}转hashmap(string,object) 2、hashmap序列化pb
路由转发
负载均衡
网关开源组件
简单解释： 1、Kong基于nginx(Lua) 写了扩展性脚本 2、BIO是阻塞IO模型 3、Netty 用的NIO（N是New IO:IO复用） 4、epoll （linux具体网络实现,实现NIO） 5、AIO 异步IO模型 （用的不多 业务复杂度很高 性能最好） 6、Zuul 已贡献给 Spring Cloud 推荐Zuul 简单扩展： 1、国际化 在APP启动层做 2、第三方调用的场景用oauth授权 app用oauth意义不大 3、多版本号场景 业务逻辑根据不同版本号做差异 4、不同业务团队用一个网关 5、网关层是无状态的 每一个部署的模块是对等的 不存储数据 6、selct和poll不用 性能较差 epoll用的更多 7、springcloud大公司用的很少 中小型公司用的多 用的是http协议 没有用rpc 8、服务治理每层都要做 9、Zuul尽量少启动 一启动连接就丢了 10、app(混合式： 经常变的页面做成h5(不需要发版本) native)
业务逻辑层功能
数据访问层功能
orm映射 : pb->mysql协议
最难的是Sharding
1 原因： 很多情况 sharding不了 对商品留言功能 几十个亿 分片不了 留言id 留言商品id 留言人 留言时间 留言状态（有没有删除） 未分表 只需要建立index就可以 分表 parditing key只有一个 其他的查询字段要遍历所有表 2 解决方式： 通过映射表 基因法 3、分库分表查询的业务逻辑在业务逻辑层实现
最好的方式是不分片
将分表逻辑下推到db层
数据库进化史
- rdbms
1、单机关系型数据库 2、08年之前 3、比如mysql oracle
- nosql
1、数据量大 互联网事务要求不高 (acid) 分布式非关系型数据库 2、解决了分库分表 3、一致性解决不好 比如mongodb redis hive hbase 4、mongodb 3.0之前事务性不好 4.0及以后支持事务
