TCP接入层负载均衡 高可用 扩展性架构
浏览器请求，dns解析，反向代理服务器负载均衡，http短连接以及web应用无状态特性，但tcp有状态，如何均衡
单机->客户端绑定IP之类的，但更新不及时->服务端负载均衡->心跳上报保证可用->服务器拉取tcp-server的状态
=======================================================================================
配置中心
不同的演进阶段 服务集群增减节点配置的变更影响：
每个上游都有一个专属的私有配置，这样会导致反向依赖->全局配置，需要调用方重启，需要增加文件监控毁掉或者动态配置连接池等->配置中心，基于zk等，容易知道全局依赖关系并且调用方不用重启，必须保证配置中心的高可用
=======================================================================================
跨公网调用的大坑与架构优化
跨公网调用一个第三方服务提供的接口，抽象一个服务，接触调用方和第三方接口的耦合，有什么坑？内部服务可能对上游业务提供了很多服务接口，当有一个接口跨公网第三方调用超时，可能导致所有接口都不可用，即使大部分接口不依赖于跨公网第三方调用
内部服务会对业务方提供N个接口，会共用服务容器内的工作线程，假设这N个接口的某个接口跨公网依赖第三方接口，发生网络抖动或超时，该线程会被占用超时时长，所以其他线程会被短暂卡卡住
解决
异步代理法，就是用代理，跟RPC一样，屏蔽了本地调用还是远程调用细节，读取本地数据，异步代理定期更新数据
第三方接口备份与切换法，本身第三方服务有备份
异步调用法，本地调用成功就返回陈宫，异步调用第三方接口同步数据，本地写成功就算成功，异步向第三方同步数据
=======================================================================================
DNS在架构中的巧用
防止反向代理服务器达到性能极限，所以dns配置同一域名多个Ip，每次dns解析轮询不同的ip，实现nginx水平扩展
就近访问，根据客户端ip来分配最近的服务器机房访问
=======================================================================================
Session一致性架构
session 服务器为每个用户创建一个会话，存储用户相关信息，以便多次请求能定位到同一个上下文
多台web服务器，每次http短连接请求如何能路由到正确的session
解决
session同步，占用带宽，无法水平扩展
客户端存储，将session存储到浏览器cookie中，占用带宽，安全隐患，大小
反向代理使用用户IP做HASH，使用Http协议中某些业务属性来做hash，当web-server重启会丢失部分，rehash后也有写不行了
将session存储在web-server后端的存储层，数据库或者缓存
=======================================================================================
暂时跳过智能广告系统架构----
计数系统架构
比如关注，转发，评论，点赞数等；业务复杂，技术扩展频繁，数据量大，并发量大
第一个介绍的是每个一个接口去算，这个没意义
设计通用的计数服务，抽象出两个表，用户维度和微博消息维度统计，这时进行统计的时候不用多次数据库计算而会转为一条数据的多个属性查询
此时需要关注的是当有微博被转发评论点赞的时候，计数服务如何同步计算数据的变更？
通过MQ，业务发生变化时，向MQ发消息；计数外置-通过counting-service单独保存计数，MQ同步计数变更，多条消息的多个计数，一个批量IN查询完成
冗余的思想
如何保证数据的一致，要有定期check并fix的机制，例如关注计数，粉丝计数，微博消息计数等
如何再优化，对于变化频率低，查询频率很高，这类读多写少的业务场景，适合用缓存来优化，减少DB负担
k/v的缓存uid:type来做Key，value为计数
如何再提升： k/v结构，可以变为uid: 100:200:333 减少业务和缓存的交互次数，提升性能
还可以通过类似ext之类的来扩展