基础知识
Spring Cloud生态的各类组件:
服务治理组件Eureka、客户端负载均衡组件Ribbon、服务容错保护组件Hystrix、声明式服务调用组件Fegin、ApI网关治理组件Zuul、分布式配置中心组件Config、消息总线组件Bus、消息驱动组件Stream、分布式服务跟踪组件Sleuth。
服务治理，容错保护，API网关，配置管理，消息总线等
什么是微服务架构：
简单地说，微服务是系统架构上的一种设计风格，他的主旨是将一个原本独立的系统拆分成多个小型服务，这些小型服务都在各自独立的进程中运行，服务之间通过基于HTTP的RESTFUL API进行通信协助。被拆分成的每一个小型服务都围绕着系统的某一项或一些耦合度较高的业务功能进行构建，并且每个服务都维护着自身的数据存储、业务开发、自动化测试案例以及独立部署机制。由于有了轻量化的通信写作基础，所以这些微服务可以使用不同的语言进行编写。
与单体系统的区别：
单体系统在初期虽然可以非常方便地进行开发和使用，但是随着系统的发展，维护成本会变得越来越大，且难以控制（由于单体系统部署在一个进程内，往往我们修改了一个很小的功能，为了部署上线会影响其他功能的运行。并且，单体应用中的这些功能模块的使用场景、并发量、消耗的资源类型都各有不同，对于资源的利用又相互影响，很难对各个业务模块的系统容量给出较为准确的评估）。
实施微服务--新的问题：
1.运维的新挑战:
在微服务架构中，运维人员需要维护的进程数量会大大增加。运维过程需要更多的自动化，这就要求运维人员具备一定的开发能力来编排运维过程并让它们能自动运行起来。
2.接口的一致性：
虽然拆分了服务，但是业务逻辑上的依赖并不会消除，只是从单体应用中的代码依赖变为了服务间通信依赖。而当我们对原有接口进行了一些修改，那么交互也需要协调这样的改变来进行发布，以保证接口的正确调用。我们需要更完善的接口和版本管理，或是严格地遵循开闭原则。
3.分布式的复杂性：
由于拆分后的各个微服务都是独立部署并运行在各自的进程中，它们只能通过通信来进行协作，所以分布式环境的问题都将是微服务架构系统设计时需要考虑的重要因素，比如网络延迟、分布式事务、异步消息等
· 微服务架构的九大特性（经过多年的发展，Martin Fowler在Microservices一文中提出，用于指导大家设计架构）
服务组件化：
组件，是一个可以独立更换和升级的单元。
在微服务架构中，需要我们对服务进行组件化分解。服务，是一种进程外的组件，它通过HTTP等通信协议进行协作，而不是像传统组件那样以嵌入的方式协同工作。每一个服务都独立开发、部署，这样可以避免一个服务的修改引起整个系统的重新部署。
按业务组织团队：
当决定如何划分微服务时，通常也意味着我们要开始对团队进行重新规划与组织。
以往技术层面划分：比如DBA团队、运维团队、后端团队、前端团队、设计师团队等。以一个简单的变动，都可能引起跨团队的时间耗费和预算审批。
在实施微服务架构时，需要采用不同的团队分割方法。
由于每一个微服务都是针对特定业务的宽栈或是全栈实现，既要负责数据的持久化存储，又要负责用户的接口定义等各种跨专业领域的职能。因此，面对大型项目的时候，对于微服务团队的拆分更加建议按业务线的方式进行拆分，一方面可以有效减少服务内部修改所产生的内耗；另一方面，团队边界可以变得更为清晰。
做“产品”的态度：
在实施微服务架构的团队中，每个小团队都应该以做产品的方式，对其产品的整个生命周期负责。而不是以项目的模式【以完成开放与交付并将成果交接给维护者为最终目标】。
开发团队通过了解服务在具体生产环境中的情况，可以增加他们对业务的理解。比如，很多时候，一些业务中发生的特殊或异常情况，很可能产品经理都并不知晓，但细心的开发者很容易通过生产环境发现这些特殊的潜在问题或需求。
所以，我们需要用做“产品”的态度来对待每一个微服务，持续关注服务的运作情况，并不断分析以帮助用户来改善业务功能。
智能短点与哑管道：
在单体应用中，组件间直接通过函数调用的方式进行交互协作。而在微服务架构中，由于服务不在一个进程中，组件间的通信模式发生了改变，若仅仅将原本在进程内的方法调用改成RPC方式的调用，会导致微服务之间产生繁琐的通信，使系统表现更为糟糕，所以，我们需要更粗颗粒度的通信协议。
微服务架构中，通常使用以下两种服务调用方式：
1.使用HTTP的RESTFUL API或轻量级的消息发送协议，实现信息传递与服务调用的触发。
2.通过在轻量级消息总线上传递消息，类似RabbitMQ等一些提供可靠异步交换的中间件。
去中心化治理：
当我们采用集中化的架构治理方案时，通常在技术平台上都会制定统一的标准，但是每一种技术平台都有其短板，这会导致在碰到短板时，不得不花费大力气去解决，并且可能因为其底层原因解决得不是很好，最终成为系统的瓶颈。
在实施微服务架构时，通过采用轻量级的契约定义接口，使得我们对于服务本身的具体技术平台不再那么敏感，这样整个微服务架构系统中的组件就能针对其不同的业务特点选择不同的技术平台。（避免杀鸡用牛刀、杀牛用指甲钳的尴尬）
【不是每一个问题都是钉子，不是每一个解决方案都是锤子】
去中心化管理数据：
定义：我们在实施微服务架构时，都希望让每一个服务来管理其自有的数据库
在去中心化过程中，我们除了将原数据库中的存储内容拆分到新的同平台的其他数据库实例中之外（如日志信息存储到MongoDB中或把用户登录信息存储到Redis中）。
虽然数据管理的去中心化可以让数据管理更加细致化，通过采用更合适的技术可让数据存储和性能达到最优。但是，由于数据存储于不同的数据库实例中后，数据一致性也成为微服务架构中亟待解决的问题之一。
分布式事务本身的实现难度就非常大，所以在微服务架构中，我们更强调在各服务之间进行“无事务”的调用，而对于数据一致性，只要求数据在最后的处理状态是一致的即可；若在过程中发现错误，通过补偿机制来进行处理，使得错误数据能够达到最终的一致性。
基础设施自动化：
因拆分的原因，数量成倍增长，使得运维人员需要关注的内容也成倍增长，并且操作性任务也会成倍增长。运维人员的噩梦
所以，在微服务架构中，务必从一开始就构建起“持续交付”平台来支撑整个实施过程，该平台需要两大内容，缺一不可：
1、自动化测试：每次部署前的强心剂，尽可能地获得对正在运行的软件的信心。
2、自动化部署：解放繁琐枯燥重复操作以及对多环境的配置管理。
容错设计:
在单体应用中，一般不存在单个组件故障而其他部件还在运行的情况，通常是一挂全挂。
而在微服务架构中，由于服务都运行在独立的进程中，所以存在服务出现故障，而其他服务正常运行的情况。
比如：当正常运作的服务B调用到故障服务A时，因故障服务器A没有返回，线程挂起开始等待，直到超时才能释放，而此时若触发服务B调用服务A的请求来自服务C，而服务C频繁调用服务B时，由于其依赖服务A，大量线程被挂起等待，最后导致服务A也不能正常服务，这时就会出现故障的蔓延。
所以，在微服务架构中，快速检测出故障源并尽可能地自动恢复服务是必须被设计和考虑的。通常，我们都希望在每个服务中实现监控和日志记录的组件，比如服务状态、断路器状态、吞吐量、网络延迟等关键数据的仪表盘等。
演进式设计：
要实施一个完美的微服务架构，需要考虑的设计与成本并不小，对于没有足够经验的团队来说，甚至要比单体应用付出更多的代价。
所以，在很多情况下，架构师都会以演进的方式进行系统的构建。随着系统的发展或者业务的需要，架构师会将一些经常变动或是一定时间效应的内容进行微服务处理，并逐渐将原来在单体服务中多变的模块逐步拆分出来，而稳定不太变化的模块就形成一个核心微服务存在于整个架构之中。
Spring Cloud 简介
Spring Cloud是一个基于Spring Boot实现的微服务架构开发工具。它为微服务架构中涉及的配置管理、服务治理、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等操作提供了一种简单的开发方式。
Spring Cloud包含了多个子项目（针对分布式系统中涉及的多个不同开源产品，还可能会新增），如下所述：
1.Spring Cloud Config：配置管理工具，支持使用Git存储配置内容，可以使用它实现应用配置的外部化存储，并支持客户端配置信息刷新、加密/解密配置内容等
2.Spring Cloud Netflix：核心组件，对多个Netfix OSS开源套件进行整合。
a. Eureka：服务治理组件，包含服务注册中心、服务注册与发现机制的实现。
b. Hystrix：容错管理组件，实现断路器模式，帮助服务依赖中出现的延迟和为故障提供强大的容错能力。
c. Ribbon：客户端负载均衡的服务调用组件。
d. Feign：基于Ribbon和Hystrix的声明式服务调用组件。
e. Zuul：网关组件，提供智能路由、访问过滤等功能。
f. Archaius：外部化配置组件。
3.Spring Cloud Bus：事件、消息总线，用来传播集群中的状态变化或事件，以触发后续的处理，比如用来动态刷新配置等。
4.Spring Cloud Cluster：针对ZooKeeper、Redis、Hazelcast、Consul的枚举算法和通用状态模式的实现。
5.Spring Cloud Cloudfoundry：与Privotal Cloudfoundry的整合支持。
6.Spring Cloud Consul：服务发现与配置管理工具。
7.Spring Cloud Stream：通过Redis、Rabbit或者Kafka实现的消费微服务，可以通过简单的声明式模型来发送和接收消息。
8.Spring Cloud AWS：用于简化整合Amazon Wed Service的组件。
9.Spring Cloud Security：安全工具包，提供在Zuul代理中对OAuth2客户端请求的中继器。
10.Spring Cloud Sleuth：Spring Cloud应用的分布式跟踪实现，可以完美整合Zipkin。
11.Spring Cloud Zookeeper：基于ZooKeeper的服务发现与配置管理组件。
12.Spring Cloud Starters：Spring Cloud 的基础组件，它是基于Spring Boot风格项目的基础依赖模块。
13.Spring Cloud CLI：用于在Groovy中快速创建Spring Cloud应用的Spring Boot CLI插件。
... 等等