最开始的时候 业务简单 人少 业务都放在一个进程 好维护 粒度粗
垂直方向拆分
公共逻辑层 1、组件化 jar包 2、服务化 下沉为独立服务 提供兼容接口
继续水平拆分
互联网核心技术实践
1、高可用设计手段 2、高并发设计手段（从架构、代码、算法） 3、服务无状态化（高可用其中一个手段之一） 4、负载均衡 （常用的负载均衡算法 更多广义角度阐述） 5、服务幂等性（依赖于分布式锁） a 请求重复执行多次 服务保证最终结果完全一致 b 业务 库存只剩一个 多个用户同时抢购 保证商品不超卖 c 用户下单 用户没有结束之前 不允许重复下单 d 消息发到mq 发了多次 下游消费保证消息去重 6、分布式事务 7、服务降级 限流 熔断 8、灰度发布 9、服务全链路压测
高可用设计
硬件总是会有生命周期
1、 x86 32cpu 128内存 万兆 1T硬盘 一台5万左右 基本上使用3年 宕机和服务器台数相关 台数越多宕机可能性越大 2、 分布式 CAP 单机CA不存在 没有网络划分 AP和CP更多 机房多个硬盘 网络发生划分 机器还可不可用
软件总会有Bug
评价维度
- 不科学(因流量有低峰和高峰)
一年/一季度/一月 停机时间占比 99表示365*24*60*1%=88小时 1个9是90% 365*24*60*90%=1/10 880个小时
- 科学
停机时间影响的总的请求量/总的请求量
冗余 部署多份
服务部署在不同的机柜和不同机架 无状态化（完全对等）可以快速扩容 弹性缩容 比如两台机器 每一台都是全量的session数据 不是无状态的 如果一台服务挂了 重启 session没了 就不对等了
负载均衡
网关->业务逻辑层1和业务逻辑层2 过程： 若业务逻辑层1挂了 负载均衡组件会知道1挂了 踢掉1 转移到2上 恢复1 异步是高并发手段也是高可用手段 不太关心返回结果 不是请求的关键路由 核心流量同步 非核心异步 不仅仅服务层面高可用 数据层面也要高可用
服务实时监控
实时监控 实现逻辑: 基于日志来做 5秒记录一个日志 耗时打在日志记录上 写在本地磁盘 通过flume 数据采集 发送到kafaka消息队列 然后spark实时统计实时耗时
服务分级-降低和避免服务出现故障
如何无缝停止线上服务
目标:停机对用户没有伤害 即如果接受了你的请求 我100%处理完 在网关层面拒绝掉
网关热切换功能
热开关切换 比如8点停机 8点过来的请求都处理完 8点之后的请求 开关从0变1 所有请求都拒绝
