微服务与Spring Cloud
要想搭建一套微服务架构需要考虑如下几个问题：
1、微服务之间的通信协议，需要使用同一的通信协议；
2、网络拥塞与延迟，一个请求跨多个微服务必定会增大响应时间，可以通过分析请求的具体情况通过缓存或者限制请求数量解决（比如MQ）；
3、数据一致性问题，每个微服务都要自己的数据库，比如订单系统下单后，但库存系统没有商品。这就是数据一致性和完整性带来的影响，这就需要分析数据的具体情况，看看那些数据需要保持强一致性那些不需要，对于需要强一致性的数据可以通过回调的方式来解决；
4、容错机制，微服务之间的调用应该有超时处理，当出现超时次数到达一定的阈值时可以考虑隔离，然后寻找超时原因；
5、微服务那么多，我怎么知道那个微服务在正常使用，那个微服务挂了。这就需要有一个方法统一管理所有的微服务，能够随时监控微服务的状态。
6、熔断机制，如果一个微服务挂了，但是请求还不断进来，微服务又无法处理，造成大量的请求在等待，不断占用资源，就会造成雪崩效应，这就需要有一个熔断机制来处理这种情况。
7、通信安全问题，每一个请求都多个服务，微服务之间的调用就必须考虑请求被拦截的问题，如果微服务部署到内网的还好，如果部署到公网的，那就需要考虑使用一些数据安全方面，比如数据加密，签名认证；
8、session共享
9、现在能想到就这么多，其实还有很多很多问题我还没有遇到。。。（死亡不可怕，可怕的是未知）
------------------------------------------------------------------------------------------------------------------------------------------
Spring Cloud就为上面的问题提供了一套解决方案，但是搭建微服务架构出现的问题spring Cloud不可能100%解决。Spring Cloud只是提供了一套管理微服务的方案，是对在搭建微服务可能遇到的问题进行归纳总结提出的一种解决方案。
1、在微服务架构中，跨服务调用是非常频繁的，但是如果其中一个微服务挂了，其他的微服务依然不断发请求过来，每个请求都在等待响应，这样就非常被动。最好有一个办法能够知道那个微服务可以正常使用，那个微服务挂了。Spring Cloud提出了一个注册中心的概念，可以通过注册中心知道每个微服务是否可用。每个微服务启动后都需要将自己的ip端口项目名等基本信息提交给注册中心，然后注册中心每30s会发一个心跳请求到微服务，如果在多个心跳周期（3个）内没有回应，就会将这个微服务的信息删掉。而微服务之间的访问都会先经过注册中心到微服务，如果在注册中心找不到对应的服务就会执行快速失败操作。（问题：这个心跳怎么维持，用什么技术实现的？）注册中心还可以提供负载均衡的作用。
2、熔断机制，Spring Cloud提供了熔断器功能，当对特定服务的访问出现故障到达一定的阈值（默认5秒20次故障）时，电路打开，不进行通话，直接就执行快速失败。还有重试功能，每隔一定时间后重新尝试访问，不断尝试，直到成功，关闭电路。（问题：如何控制断路器？）
3、所有微服务都注册在同一个注册中心，如果这个注册中心挂了怎么？做集群，要保证高可用。
4、微服务配置管理问题，每个微服务都有配置信息，由于微服务是独立部署的，那么配置信息的管理是一件非常麻烦的事情，而且在实际开发中，每个微服务的配置信息有很多是相同，比如：redis服务器配置等，因此Spring Cloud提供一种方案，将配置信息做成一个微服务，即配置中心，将其集群化，从而达到高可用。
5、日志管理，Spring Cloud有提供日志收集包，但我们也可以集成其他系统，比如ELK。
6、链路监控，如果客户端段的一个请求需要经过多个微服务之间的调用，当出现调用异常，想要快速定位问题所在不是一件简单的事情，因此Spring Cloud提供了一个链路监控模块，可以监控每一个访问（从请求到响应），出现异常也比较好定位到具体的哪一个微服务出了问题。
Spring Cloud提供的微服务解决方案我有很多没有使用，等后面有使用到再回来总结。