标签：简单的 业务 分布 高级 分析 地方 设置 崩溃 部署
我们都经历过巨石应用，单一应用某个功能诱发的故障导致整个站点挂掉，任何人都无法访问，只能一一排错再部署上线，这样造成的影响就是用户的流失。而分布式应用就没有这样的问题，就算某个节点出现故障，那么主备切换，替换主节点，整个系统还是照样运行，完全没有访问不了的现象。
要使系统达到一定的容错性，那么
首先要实现的就是高可用，最简单的就是进行节点集群化，使用心跳机制让好的节点替换坏的节点。
其次要保证系统的稳定性，如果运维有事没事上去重启一次，这样也不太好吧（其实很多应用在一开始都是每周重启一次的）
然后整个系统平台的安全性当然要提高，比如防CSRF攻击，防IIS攻击等等，安全性一旦提高系统崩溃的几率也相应降低。
最后就是系统的可维护性，这个在我看来是最高级别的，一旦系统难以维护，那么开发人员以及运维人员的工作量是巨大的，甚至会出现有人不想维护而离职不干，这都是会发生的情况，所以一个系统的可维护性非常考验架构师的能力。
对于故障的分类有代码级别的，也有硬件方面的，硬件的故障咱们姑且不说，而代码方面的故障我们要做的就是日志分析了，设置好日志级别，在很多发生业务的地方会产生大量的日志，这个时候就需要ELK来进行分析了，通过日志来解决代码放的bug，也是必要的。
标签：简单的 业务 分布 高级 分析 地方 设置 崩溃 部署
原文地址：http://www.cnblogs.com/leechenxiang/p/7057753.html
