spring cloud
SpringCloud是基于SpringBoot提供了一套微服务解决方案，它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。Spring Cloud并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。
单体架构与微服务
先看一下示意图：
Springboot单体应用在项目的开发初期能够满足我们需求，这种
单体架构优点
非常的明显：
容易测试：本地就可以起完整的系统，不需要外部依赖。
容易开发：我们只需引入依赖，选择框架便可快速开发。
易于部署：单体架构部署也较简单，直接打包即可。
易于水平伸缩：这里的伸缩是指当我们需要部署多个服务器时也比较方便。
相应的，
单体架构的缺点
也是显然的：
代码膨胀，难以维护：代码越来越多，开发人员也就越来越多，一旦出现bug，定位、修复成本很高，而且人员太多，代码都放在一起，容易引起冲突，且由于业务集中在一起，业务复杂，很难全局把握，改一个bug可能会再多出两个bug。
构建、部署成本大：项目太大，构建和部署就会非常慢，效率低下。
上手困难：代码过于集中，导致业务非常复杂，新人想要上手变得非常困难。
技术创新困难：代码过于集中，我们很难使用到新技术，因为改动实在太大，容易出现问题。
可扩展性差：这里的可扩展性是指因为项目都必须部署在一台服务器中，那项目所要的资源会越来越大，这样我们只能扩展硬件（集群可以分散压力，但是单个应用所要的资源还是不能少的）。
微服务的出现就是为了解决这些问题，微服务将系统拆分成一个个小服务（一般是按照模块进行拆分，比如用户服务、支付服务、订单服务、出入库服务等），即使业务量增加，我们也可以通过新增服务的形式来解决，这样代码就不会膨胀，构建、部署也不是问题。由于服务不在一个框架中，那么我们可以很方便的对某一个服务进行技术创新，对一个服务的进行技术升级改动不会太大，而当我们有新技术产生时，我们就可以也可以应用到新服务中。
微服务比较通用的理解是：
使用一套小服务来开发单个应用的方式，每个服务运行在独立的进程里，一般采用轻量级的通讯机制互联，并且它们可以通过自动化方式部署。
微服务的特征：
微服务是由一系列的小服务共同组成的；
每个微服务都有自己独立的进程；
每个服务都是独立的业务开发，单一原则；
每个服务都能独立的部署（一般部署在容器中）；
微服务之间通过轻量级通信机制进行通信；
分布式的管理。
从上图可以看出每个微服务都有自己独立的数据库，每个服务都会暴露自己的REST API 给外部调用，服务之间会存在互相调用关系，而每个服务都有可能被客户端直接调用，另外我们看到还有一个API Gateway,这是统一个服务接口，它通常可以有以下作用：
提供统一服务入口，让微服务对前台透明；
聚合后台的服务，节省流量，提升性能；
提供安全，过滤，流控等API管理功能。
微服务的优缺点
微服务的优点很多，微服务的优点其实就是单体架构的缺点的反面，因为微服务本身就是来解决单体架构问题的。
优点
独立性：微服务从构建、部署，扩容、缩容、甚至数据库都是独立的，服务只要管理好自己就可以，这样就极大的降低了系统的复杂性。服务完全独立之后，从构建到部署，到后期的扩容缩容都会变得简单，基本就解决单体架构上碰到的很多问题。
敏捷性：敏捷性是针对开发人员来讲的，服务拆分之后，可以独立专一开发，开发人员可以通过API快速的了解本服务的业务，互相之间并不影响。
技术栈灵活：微服务可以完全独立的拥有技术栈，只需要保证提供的服务API不变，内部使用何种技术栈很灵活。
缺点
服务的拆分：服务如何拆分其实是非常重要且复杂的，服务拆分的太大或太小都不合适，这需要我们有非常丰富的经验，而这个在单体中是不存在的。
数据一致性：单体架构中只有一个数据库，我们可以通过事务解决多表之间数据的一致性，而在微服务中，每个服务中都有自己独立的数据库，要保证服务之间的数据一致性也是一个大的挑战。
服务间通信成本：服务间互相通信也需要时间成本。
测试复杂性提高：服务之间存在依赖，那么测试时就必须启动这些依赖，这就增加了复杂度。
运维部署复杂性提高：微服务应用由大量服务组成，每个服务会起多个实例，要进行配置，部署，扩展和监控。此外，还需要实现服务发现机制。
