SpringCloud个人理解

我们的项目是一个mvc项目，开始在生产环境下跑起来没啥问题，慢慢的，访问量在曾多，项目有些慢。同时可以预见的是往后的访问量会越来会多，这个时候很明显我们的服务器肯定有一天会扛不住，

这个时候有两个选择：

1、增加服务器硬件，比如加大内存。

2、服务架构更改。分布式或者微服务。

如果先择1；

优点：效果很明显，我们加了内存，系统短时间会很明显的变快。

缺点：长时间来看，这个作用微乎其微，过一段时间，访问量增加，又要增加内存。同时成本会更加的大。

如果选择2：

优点：可以随着访问量的增加，增加部署的服务个数。

缺点：如果访问量不大，微服务的成本会比单体成本高很多。

单体项目改成微服务架构。

单体项目改成微服务架构，思路1：

直接将单体服务布置多份，这样子去减轻单体的访问需求。优点也很明显，改动小，只需要对网关进行一个负载均衡配置即可。这样子同样缺点也很明显，服务层的数量增多了，但是数据库的访问压力并没有减小。同时单服务的请求处理时间还是会很长，在数据库也会很容易发生故障。同时每个服务处理事件的时间没有减少。

思路二

对系统进行服务层次拆分。例如下单的服务，就需要1、创建订单。2、减少库存。3、计算优惠。4、创建物流信息等。如果是单体服务，这么多的流程，会需要很久才能走完，如果请求多了，请求会都积压在系统里。整体的性能会很慢很慢。这样子的情况下，服务就很容易宕掉。这个时候我们如果对服务进行拆分，将每个流程单独拆分称服务，同时每个服务部署多个节点，这样子就可以抵抗较高的并发。同时由于每个服务都会有自己的数据库，这样子对数据库的访问压力也会变小。

当服务的数量增加，随之而来的问题也会增加。

1、网关、如何确保前端的请求可以均匀的分发下去。

2、网络、各个系统之间如何通信且保证服务宕掉后可以自动断开。

3、注册、如何确保你的服务可以被其他服务发现。

4、配置、如何保证各个系统的配置一致，同时易于修改。

而这几个问题的解决方案就是spring cloud。

Eureka

提供者配置

可以在

 查看对应服务信息

对应上述的描述服务的连接名字 

DiscoveryClient可以通过该接口获取对应的服务信息