SpringCloud是微服务的技术落地方案，微服务是分布式架构的一种，是为了解决项目发展过程中出现的各种问题而出现的新的项目架构方案。
项目中模块繁多，耦合度无法避免的变高，最好的方案就是对服务进行拆分：将一个大型项目根据模块拆分成不同的小模块项目，各司其职完成各自的功能。
单体应用适合小型的项目，访问量小或者业务简单的项目。但是对于大型的、高可用、高并发的项目而言，单体是存在很多弊端的。单个服务并发难以控制、项目更新需要停机、模块更新导致耦合度越来越紧此类的问题，虽然可以通过负载均衡策略或者制定企业开发相关规范来避免，但是在项目体量越来越大、员工越来越多、更新迭代越来越频繁的情况下此类的维护成本也会指数级增加。
微服务提倡将模块以独立服务的方式独立管理，整个项目依靠多个小型的服务同时运作来支撑，单个服务只关注自己的业务实现并且有专业的团队进行开发。服务之间使用轻量的协议进行消息传送，并且对于单个模块的升级不应影响其他服务，也不应该被其他服务感知。每个服务可以发布多个实例，所有的服务组建成一个网状的服务集群。
从前单体项目中也会涉及到跨模块间方法的调用，那在微服务中同样也可以通过网络进行跨模块调用。模块之间的依赖关系错综复杂，并且因为每个服务都是独立启动的，相互之间必要的存在一些调用和交互，调用谁、怎么调用、调用失败怎么办，那微服务思想就是对此类服务集群的治理提供一套解决标准和思想。
刚刚说到服务之间要做相互的调用，那调用谁就是一个问题。服务之间要想完成调用首先要知道谁和自己是同一个集群的，注册中心就是用来统计集群中的各个服务以及服务状态的。
未来微服务集群中，单个服务并不是单个实例运行的：如果某个模块的负载较高，就需要多实例负载均衡运行。那多个实例的配置在管理过程中如果要每个都进行独立设置和管理，运维期间是很麻烦的，所以需要一个配置中心对微服务集群的配置进行统一的管理，在配置中心的设置将同步到所有的需要此配置的服务中。
网关就是网络关卡，每一个微服务讲将到的消息有两种：来自客户端的、来自其他微服务的。来自其他微服务的大可放行，但客户端的就需要进行鉴权和认证类的判断，并且客户端所请求的服务极有可能正处在负载均衡的状态，那就还要在多个同服务实例中选择最佳的一个。网关就是拦截在客户端与服务器之间的一道关卡，通过负载均衡算法进行具体服务的调用然后响应客户端。
PS：客户端是直接访问网关的，网关再对服务进行负载均衡。如果要对网关进行负载均衡的话，就需要采用Nginx类反向代理工具对网关进行负载均衡。
当一个请求通过网关落到一个具体的服务之后，此服务可能会请求其他服务进行相关操作，同样的这个调用链路可能非常的长。那客户端等待的时间就是所有服务执行时间之和，但对于客户端来说也许大多数的等待是没有意义的。所以可以采用异步的消息队列，来完成各个服务之间的无需返回的请求调用，降低响应时长。
在微服务中多个实例的健康管理非常复杂，所以需要借助服务治理工具对服务进行监控和管理，并对日志采集、响应速度、健康状况等进行统一的统计，以解决运维过程中复杂问题的排查和服务健康管理。
庞大集群下每个服务实例的启动和部署将非常复杂，所以对于项目编译部署可以通过相关工具进行自动化管理。
需要明确的是虽然每个服务都会提供CRUD操作，但永远查询大于其他操作。分布式系统中通常会采用分布式存储方案，但为减轻数据库查询压力，通常会在数据库前拦截一层缓存层，用于缓存接口的查询数据。
数据库和缓存都是无法支撑海量数据查询的，并且在分布式缓存和存储架构下，查询效率也会降低，所以要采用分布式搜索引擎来解决数据的搜索问题。
PS：在分布式数据存储设计中，缓存存储的是热点数据，数据库主要做写操作和对事务要求较高的操作，分布式搜索主要做大规模数据快速搜索操作。
