这段时间尝试搞了一下spring cloud，之前其实也搞过，不过时间太长，加上当时的demo早就被我删掉了，已经没有什么印象了，这次重新搞一下spring cloud，其实感受挺深的，为什么要用spring cloud的呢？简单来说就是解决三高问题，高并发，高可用，高性能的问题，听着确实高大上，但是其实代价也是极为高昂的，实际上spring cloud只解决了高可用的问题，高并发和高性能其实和它没什么关系，所以我们先谈高可用
什么是高可用呢？
说白了，高可用就是保证系统在任何时刻都可以使用，如果不能使用，也要尽量维持最低限度的运行，不能出现所谓宕机
那为什么传统项目从来不谈高可用呢？
两方面原因，对于传统项目，高可用基本就是对服务器烧香拜佛看，服务器比较争气，上线几年一直没挂，那就是高可用了，如果服务器不怎么争气，老是蓝屏，死机，如果不是项目本身的问题，那么就只能换机器，或者请人来修了，所以传统项目的高可用一般是一个玄学问题，完全看服务器心情，不过对于一些企业内部系统来说，其实影响也不大，最坏的情况，服务器彻底宕机，只能更换，最多手机群发一条短信，告知全体员工，良心一点就放假一天，资本一点就人肉代替电脑，勉强维持运行，反正等新机器来再上线就行了，而且一般情况下也很少出现彻底凉凉的情况，最多重启一波，对于传统项目来说，5分钟项目宕机而已，能有多大损失？
另外一方面，高可用的同时也代表高费用，在没有明显影响或影响有限的情况下，我是老板，我也选择低可用，额外的机器花费，额外的维护人员花费，还有系统本身设计的难度提升所带来的更高技术需求，总结起来就一句话，为了解决高可用，花费的钱太多了，不值得，即使对高可用要求较高的系统，解决方案也不需要对高可用本身进行处理，多买几台电脑，把项目多跑几次，第一个项目挂了，就访问第二个网址，用概率学打败高可用，对不起，穷人的解决方式就是这么朴实无华而且省钱
那为什么现在所有公司都开始谈高可用了呢？
因为现在是互联网时代了，公司的项目不仅仅只是面向公司那一小撮人，而是全世界的用户，你指望他们会去记住那么多网址吗？第一个进不去就直接溜了，加上人数规模之大，宕机的损失也是几何数的往上翻，所以，为了小钱钱，大家也开始追求高可用这个东西了
说了这么多，那么spring cloud是怎么实现高可用呢？
那spring cloud本质上是个什么东西呢？说白了就是一个傻子数数的游戏，傻子（注册中心），每隔一段时间，数一数自己的苹果（服务），还在不在，使用的手段就是所谓的心跳检测，心跳检测是检测人（服务）死没死，而对于傻子来说，就是苹果（服务）坏没坏，坏了，就把这个坏苹果扔掉（去除服务），保证自己手上的苹果是好的，此时肚子饿了（请求来了），就趁苹果不注意，偷偷咬一口（调用服务），这时候如果有人帮傻子把坏苹果烂掉的地方挖掉，傻子就觉得这苹果好了，就把苹果抢回去（重新注册）
那如果傻子实在太饿了（请求间隔时间较短），很多时候来不及去看苹果（服务），坏没坏，怎么办呢，吃到坏的吐出来就行了（断路器），那傻子有一天突然好了（注册中心宕机了），不傻了，溜走了怎么办呢？多找几个傻子不就行了，大家推举出一个傻子王，傻子王跑了，剩下的傻子就再推举一个傻子王不就行了