核心化
核心系统核心团队维护，通过提升人来提升系统的稳定性，发布垂直化，核心系统开发团队有自己的系统权限，在紧要关头可以直接进行一些干预，减少事故时间
人、单点环节要少、架构要简单其实这些都是针对核心系统而言，因为互联网业务飞速发展，如果寄希望于稳定的业务，稳定的架构来实现稳定的系统，那么你错了。业务的变更比你想象的快，比你想象的复杂，比你想象的难搞。
稳定的前提是简单：较少（稳定）的系统、较少（稳定）的业务、较少（稳定）的人员
技术上来说各个系统间的依赖会有传导性
系统的依赖只有一种：那就是直接依赖
直接依赖
A<----B
A依赖系统B的接口，如果B的接口挂了或者响应缓慢，那么会导致A系统的业务受到牵连，调用B系统接口的线程会被一指挂起。随着线程消耗殆尽，A系统也挂了。这里的根本原因是B系统的接口是一个依赖资源,称为必须不可替代资源。A系统本身的硬资源没有任何消耗。如果A系统的容错性做的比较好，比如预先认定 B资源是一个风险，那么可能只是相应的业务不能使用。那么在线程上限制线程的数量，采用队列方式堵塞、或者直接抛弃新的请求。如果做的不好，则整个A系统也会跟着挂掉
A<-----B<-----E<----硬件资源
C<-----D<-----E<----硬件资源
一种是技术错误导致的，可以是人为引发的，可以是bug引发的
一种是容量限制导致的，比如上面E资源的容量满了(硬件不能够支撑新的流量了)，不能满足对B和D新的请求，导致B和D挂掉。当然因为E只是被B和D依赖，所以E的容量肯定也是被B和D消耗掉的
E依赖的硬件资源
限制流量的意义：
1。增长的流量是可以预见的，这总一般会被提前识别出来，反而风险不会非常大，一般会根据流量的增加提前调整系统的架构，比如增加新的硬件资源，调整新的架构使其支撑更多的请求。
2。不可以预见的增量。比如因为系统问题导致的流量暴增，这一类问题往往可能是数量级的增长。
扩容：
硬件扩容
软件架构优化带来的扩容
后者依赖于稳定的人员，必须对业务系统是非常之熟悉
1+1=2那么简单，而不是 i ++ ++ i那么复杂
如果核心业务复杂，那么需要能处理复杂业务的人来维护
但是核心业务量必须是在数量上是可控的，变化上是可控的，否则又会重蹈因为需求繁多，导致系统业务修改非常频繁，导致架构变化
核心系统核心人员进行统一维护
核心系统的业务增加必须是受到控制的，不能出现赶日常，赶项目的情况
稳定，人，人必须对所负责的系统非常的清楚，能非常清楚的了解当前系统的运行状况，哪些指标出现问题可能会影响稳定，哪些操作可能会影响稳定。所以需要有一个能及时反映系统稳定性指标的系统，而系统是由各个系统的人维护的
稳定性改造
状态码机制，上面提到的一些问题可以通过状态码机制很好的解决，网络远程调用，返回状态码，客户端根据状态码来进行下一步操作，而不会出现资源已经没有的情况下外部请求还是不断的在请求。这个时候可以直接返回一个忙的状态码，由调用方去了解该怎么搞。
主动保护，硬件资源在持续达到一定程度的情况下，不在接受外部请求，让系统恢复之后再接受请求。这个措施至少可以让系统能够有自我恢复的时间，而不是彻底雪崩。
提升QPS，感觉上提升QPS和稳定性相关度不大，而是一个节省成本和提升性能的工作，其实这个对稳定性也非常的明显，QPS的提升结局有两种，1。允许我们减少硬件资源，2。或者在不增加硬件的前提下提升了硬件资源的充足率，再发生故障的时候可以延长系统挂掉的时间，这个也可以帮助我们减少故障时间。不过在提升QPS的时候势必会改造一些依赖，架构等，这个时候需要注意改造本身带来的风险。充分测试，充分beta来减少事故。
减少直接依赖关系 增加异步依赖，把必须的依赖采用直接调用的方式，其他均采用异步方式。这个会增加新的http请求，理论上会额外增加硬件资源。不过这也可以明显提升系统的稳定性，直接依赖越少出概率的几率就越少。不过要小心异步依赖的资源对核心资源调用要有阀值，要确保不会因为这些不是非常重要的异步资源导致重要的核心资源调用不可用，从而导致核心应用雪崩。
定期的系统review，识别风险，这点也可以通过监控系统的一些数据来支持
监控
1.提前发现潜在的问题，持续改进问题，从而持续的提升系统的稳定性
2.在正在发生事故的时候，能及时报警，给出比较明确(或者参考)的事故原因和处理方式，减少事故的持续时间