分布式架构
分布式改造是让系统无状态化，或者让信息封装在一定的范围内，以免限制应用横向扩展。
以便撑起更大流量，以及在部分节点宕掉后，不影响整体业务的稳定性。
横向扩展：主要解决容量问题
纵向扩展：主要解决业务扩展问题，如web渲染以及API接口的分层
1.分布式配置框架的管理方式
a: 拉取模式，配置简单，但更新不及时
b: 推送模式，需要感知client状态，保持连接，不适合client数量较大的场景
注意点：1.不要让ConfigServer的带宽成为瓶颈。2.需要确认配置下发成功，通常用配置版本号实现
2.分布式RPC框架
服务注册：让proxy知道server能提供什么服务
服务发现：从调度器获取服务列表
服务调度和负载均衡：摘除故障server
统一SDK封装：IDL接口封装，以及通信、重试等逻辑的封装
3.分布式消息框架
实时消息：
异步解偶，降低系统耦合，跨语言，以及生产者和消费者的处理速度差异
多端消费
延时消息：
除了时间触发外，还有可能其他条件触发，这样逻辑会比较复杂
4.分布式数据层
分库分表，读写分离
5.应用的服务化改造
1.应用分层设计
垂直分层：服务层、业务逻辑层、数据层，每一层尽量解耦，上层以来下层，下层不依赖上层
2.微服务化
功能单元拆分的更小，业务逻辑更单一
6.无线化的架构演变
客户端：合并网络请求，压缩cookie，CDN动态加速（通过DNS合理调度请求）,WebP图片优化
服务端：接口JSON化，
7.网站架构演化
1.单机
2.分布式
3.按业务拆分
4.服务化？？
5.中台，基础服务？？半定制化服务？？可以理解成把部分通用的功能移到基础平台？
8.QPS优化
减少CPU时间能更有效的提升QPS
减少IO能更有效的减少请求耗时
秒杀系统
业务隔离，系统隔离，数据隔离
不想看了，看不下去了，最近看的好多技术文章都是基于java的，恨不得各种框架直接替换成Spring Cloud，Seta、RocketMQ等等，对于java盲真的有点不友好。。。。
