newsql
1、金融电信银行 数据量大 事务要求很高 2、分布式关系型数据库 3、比如国内tidb a、tidb是强一致性的 支持事务acid 对一致性要求不高的 不用关系型数据库也可以 比如用redis b、tidb用的是mysql协议 业务不需要升级 c、单机mysql数据存储的下的话 tidb比mysql慢 因为tidb是分布式的 d、异构存储 一致性很难保证 4、用newsql 线上单表 1200多亿 查询只需要4毫秒
同步架构
1、为什么用mq做异步 mq顺序写入磁盘 append 追加 效率高 db随机写写磁盘 2、mq要放在网关和业务逻辑层之间变成异步 3、异步目的提升吞吐量 4、推荐使用rocketmq 5、读请求不能用mq 写请求可以用mq 数据一致性要求强:充值 不能用异步 吞吐量不高 低并发 数据一致性要求弱:发朋友圈 社交 可以用异步 吞吐量高 高并发 写场景是异步 读场景不是异步 发朋友圈 缓存到本地 读从本地读 不是从网关->业务逻辑层->数据存储层->db 发好了直接看 解决自己看问题就好了 好多秒之后再看 就已经入DB了 但异步也不定写成功到db 微信怎么办的 有未发送成功的消息
层次划分个数
- 过多
1、请求路径变长 2、平均响应延迟变高 3、定位问题复杂 分布式请求跟踪系统 4、运维成本增加
- 过少
单体
- 适中
缺点
每层粒度过粗
扩展
1、reacter 模型 本质是异步架构 是一个实现手段 2、app和网关长连接 失败了会推给app 若http必须长轮询 3、使用nginx\f5\lvs意义会使请求更加健壮 因为网关会频繁重启 4、nginx反向代理 ip限流 5、mq不适合用udp协议（高性能udp） mq要保证数据可靠性
同步水平分层架构
dns解析 ->静态资源获取->动态资源获取
1、路由器虚拟化 NetGW 2、对象存储 a、fastdfs(规模小) b、ceph(规模大 运维压力大 快存储、挂硬盘)
面向服务SOA
垂直拆分
1、多个独立服务（每个服务都是单体） 2、通过ESB交互 对ESB依赖严重 3、SOA不是微服务架构
微服务架构
垂直和水平都拆分
1、独立进程 2、围绕业务建模能力 3、独立部署 4、去中心化管理 （网关、业务逻辑 数据访问、存储层 都可以用各种语言写 但会带来很多问题）
1、用zk、consul做注册中心不行 eurka 可以 2、配置中心推荐 appllo 携程开源；不要用disconf(springcloud的生态) 3、交易系统是同步分层架构 4、注册中心不知道哪个服务挂掉 通过熔断可以知道 5、forupdate并发锁 粒度大 量大不行 6、同层之间不调用
本质
两个拆分
垂直（业务）拆分比较难 继续拆分 读、写微服务（按功能拆分 （api））
业务架构
微服务架构是业务架构 不是系统架构
组织架构
事业部制 公司->房产(产品、研发、销售) 招聘(产品、研发、销售) 二手车(产品、研发、销售) 效率高 公司->产品、研发、销售 效率低
应用场景
需求层面
变化频繁 比如内部OA系统 ERP系统 不频繁 微服务意义不大
性能层面
1、吞吐量变高 平均响应延迟变高 2、高频交易 量化交易 不合适微服务
数据一致性层面
一致性分为： 强一致性 和最终一致性（用微服务其实解决这个问题） 多个db 分布式事务解决强一致性问题 性能就没了 往往最终一致性 （分为同步、异步场景）
目的
快速迭代、持续交付 降本（人力、机器）提效（开发、运维、测试）
后记
后续会介绍服务网格架构ServiceMesh
