这是我参与[第三节青训营-后端厂]笔记创作活动的第一篇笔记
服务发布： 蓝绿部署 需要使用多一倍的物理设备 灰度部署（金丝雀部署）
流量控制，可以通过地区，集群，机器，请求等维度来进行流量控制，
负载均衡，一致性哈希，round，Robin等策略
稳定性治理（关键功能）： 原因，线上的服务一定会出问题，和代码的正确性无关，有大量外界因素会威胁到线上的服务，如黑客攻击，流量攻击，光纤被挖，网络故障等。所以稳定性治理非常重要 如何治理： 1.限流 限制流量的输入，拒接部分流量，让服务能够稳定进行 2.熔断 服务处理不过来了，断掉连接，类比跳闸， 3.过载保护 通过动态过载组件来检测服务的CPU的使用程度，如果有过载迹象，则拒绝一些请求 4.降级 会给流量分等级，如果压力过大，拒绝等级低的请求，保持用户的正常体验。
字节跳动服务治理实践 在服务重试上的实践探索 关注两个问题，为什么要重试，是否有必要重试？ 本地函数调用没有重试的必要，远程函数的调用由于网络不稳定等因素，有重试的意义。
重试的意义： 降低错误率，降低长尾延迟，容忍暂时性的错误，避开下游故障实例。
重试的难点？ 不能给所有的请求都加上重试 post发起多次可能会造成数据错误 重试风暴（雪崩） 微服务有很深的调用链路，可能有几十层，链路加深，会对错误进行放大 解决方法， 限制重试比例，如果大比率失败，则没有必要重试 防止链路重试，，最理想就只有最底层进行重试，避免放大 幂等性 超时设置 重试策略 Hedged request对于延迟高的请求，可以对它下游的实例再发起请求
