SpringCloud微服务
架构演进
单体架构
Monolithic
单体只是表明系统中主要的过程调用都是进程内调用，不会发生进程间通信，仅此而已。
首先单体架构并不是一个“反派角色”。单体架构，在整个软件架构演进的历史进程里，是出现时间最早、应用范围最广、使用人数最多、统治历史最长的一种架构风格。“单体”这个名称，是在微服务开始流行之后才“事后追认”所形成的概念。
对于小型系统—即单台机器就足以支撑良好运行的系统，单体不仅仅易于开发、易于测试、易于部署且由于系统中各个功能、模块、方法的调用过程都是进程内调用，不会发生进程间通信（IPC，可以认为RPC属于IPC的一种特例），因此也是运行效率最高的一种架构风格，完全不应该被贴上反派角色的标签。
SOA
SOA架构（Service-Oriented Architecture）
面向服务的架构是一次具体地、系统性地成功解决分布式服务主要问题的架构模式
SOA，将应用程序不同功能单元（称为服务）通过定义良好的接口和契约联系起来。这些服务是独立的、可复用的组件，可以在不同的系统和应用程序中被调用，以实现特定的业务功能。
但是，在处理大规模复杂系统时，由于倾向于构建企业级的服务总线（ESB）连接各个服务，导致整个架构变得非常复杂。随着业务的增长和服务数量的增加，ESB会称为一个庞大而复杂的中心枢纽，其中包含大量的消息转换、路由规则配置，使得系统的维护和理解成本极高。
到这里，“如何使用多个独立的分布式服务共同构建一个更大型的系统”，“让开发人员不必关心服务是远程还是本地，都能够透明地调用服务或者访问资源”，引出了微服务。
微服务时代
微服务架构（Microservices）
微服务是一种通过多个小型服务来构建单个应用的架构风格，这些服务围绕业务能力而非特定的技术标准构建。各个服务都可以采用不同的编程语言，不同的数据存储技术，运行在不同进程之中。服务采取轻量级的通信机制和自动化的部署机制实现通信与运维。
一开始，微服务是作为SOA的一种变体被提出来的，后来成为了经过不停地更新、蜕变发展才有了现代微服务。文章《Microservices: A Definition of This New Architectural Term》中是这样描写的:“通过多个小型组合来构建单个应用的架构风格，这些服务围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言，不同的数据存储技术，运行在不同的进程之中。服务采取轻量级的通信机制和自动化的部署机制实现通信与运维”。
后面还有后微服务时代和无服务时代先不做了解。
以上全是来自对 凤凰架构中的简单摘要，以了解为何要应用微服务，为何要学习微服务。
SpringCloud
注：暂时先将了解先不实践，了解完后需要不上实践代码以及过程。
是微服务架构落地的一套技术栈，其中大多数技术都是基于Netflix（奈飞）公司的技术进行二次研发。
包括以下技术点：
- Eureka-服务注册与发现
- Ribbin-服务负载均衡
- Feign-服务之间的通讯
- Hystrix-服务的线程隔离以及断路器
- Zuul-服务网关
- Stream-实现MQ的使用
- Config-动态配置
- Sleuth-服务追踪
服务注册与发现
服务注册中心：把所有服务的信息都告诉服务注册中心(Eureka、Consul、Nacos、Zookeeper)
Eureka帮助我们维护所有服务的信息，以便服务之间的相互调用
服务负载均衡
Ribbin是帮助我们实现服务和服务负载均衡，Ribbin属于客户端负载均衡（服务端负载均衡）
客户端负载均衡：customer客户模块，将2个Search模块信息全部拉取到本地的缓存，在customer中自己做一个负载均衡的策略，选中某一个服务。
服务端负载均衡：在注册中心中，直接根据你指定的负载均衡策略，帮你选中一个指定的服务信息，并返回。
服务间调用
Feign 帮助我们实现面向接口编程，直接调用其他服务，简化开发。
服务隔离断路
Hystrix解决服务雪崩问题
- 降级机制：当某一个服务出现超时，资源不足出现了异常时，可执行一个降级方法，返回一个拖底数据
- 隔离：提供了一个Hystrix线程池，信号量，和Tomcat的线程池相互隔离
- 熔断：当某个服务的失败率达到一定的阈值时，自动触发降级
- 缓存：请求缓存的功能
服务网关
Zuul
GateWay
- 客户端维护大量的ip和port信息，直接访问指定服务
- 认证和授权操作，需要在每一个模块中都添加认证和授权的操作
- 项目的迭代，服务要拆分，服务要合并，需要客户端进行大量的变化
- 统一的把安全性校验都放在Zuul中
多语言支持
Sidecar
在SpringCloud的项目中，需要接入一些非Java的程序，第三方接口，无法接入eureka，hystrix，feign等等组件。启动一个代理的微服务，代理微服务去和非Java的程序或第三方接口交流，通过代理的微服务去计入SpringCloud的相关组件。
服务间消息传递
Stream就是在消息队列的基础上，对其进行封装，让咱们更方便的去操作MQ消息队列（Kafka、RabbitMQ）。
服务的动态配置
- 配置文件分散在不同的项目中，不方便维护。
- 配置文件的安全问题。
- 修改完配置文件，无法立即生效。
所以有了一个统一的动态配置
服务追踪
在整个微服务架构中，微服务很多，一个请求可能需要调用很多很多的服务，最终才能完成一个功能，如果说，整个功能出现了问题，在这么多的服务中，如何去定位到问题的所在点，出现问题的原因是什么。
Sleuth可以获得到整个服务链路的信息。
Zipkin通过图形化界面去看到信息。
Sleuth将日志信息存储到数据库中。
架构图（大概）
