何为微服务架构？

1.“微服务”--> 见于博文http://martinfowler.com/articles/microservices.html

Spring Cloud被戏称为 “全家桶” 的微服务处理框架。

2.一句话概括：将一个原本独立的单体系统拆分成多个微服务，各自独立运行，通过 HTTP的RESTful API 进行通信协作，属于架构范畴的一种设计风格。

3.分布式反例--->单体系统

a.一般通过业务类型来构建一个项目，按照技术划分团队等，或者需求分为：数据库，后端（服务端），前端展示。单体系统往往部署在一个进程内，随着业务需求激增，开发、测试、部署上线臃肿度可想而知
b.系统的性能容量不易评估。

4.微服务的缺点有三

a.运维难度增大
b.服务“员”之间的暗号，“信号必须一致”，接口一致原则。ps:拆分后的微服务，服务“员”之间从老的代码依赖变成了服务通信依赖。业务逻辑依然存在。
c.分布式的“外在”环境复杂：由于是靠通信进行协作，免不了收不到信号的时候。eg:网络延迟、分布式事物、异步消息。。。

ps：微服务实现的敏捷开发和自动化部署等优点盖过了其缺点。

5.九大特性

a.服务组件化。既然由大拆小，那每个小的部件、服务“员”之间就可以独立开发、部署。服务，是一种进程外的组件，通过HTTP协议通信，而传统组件是嵌入到母体工作。
b.按照业务，而非技术划分来组织团队。让每一个服务“员”针对特定的业务达到宽栈、全栈实现，以此可以减少内耗，团队的边界更加清晰。
c.做“产品”的态度。小团队里的每个服务“员”应该以做产品的态度，对待产品的整个生命周期，而不是以完成开发、测试、上线部署并交付给项目负责人为目标。
d.智能端点与哑管道。（对此名词不是很理解）
 单体系统中，组件通过函数调用来交互，而微服务中，有两种方式:一是通过HTTP的RESTful API或者轻量级的消息发送协议。二是类似RabbitMQ等提供可靠异步交换的中间件。
e.去中心化治理。采用轻量级的契约定义接口，使我们对服务本身具体的技术平台不再那么敏感，从而让微服务架构系统中的各个服务针对不同的业务特点选择不同的技术平台。
f.去中心化管理数据。让每一个服务来各自管理自己的数据库。不过会产生问题：“数据一致性”不好保证。解决办法：补偿机制。
g.基础设施自动化。对于运维而言，从一开始就建立“持续交付”平台来支撑整个实施过程，平台所需两大不可缺内容：自动化测试，自动化部署。
h.容错设计。单体系统，一挂全挂。微服务由于各自运行在独立的进程中，一个挂了，其他可以正常。但是也有一个问题，就是服务之间由于调用不到而挂起的线程过多导致阻塞问题。
i.演进式设计。初期并实施设计单体系统，（初期核心业务不太变化，随业务体量增大，后期会将业务中易变的部分或有时间效应的内容进行微服务处理，单体中多变的模块会拆分出来，稳定不变的部分会形成核心微服务存在于整个架构之中。）

6.为何选择Spring Cloud？

服务治理：阿里巴巴开原的Dubbo和当当网在其基础上扩展出来的DubboX、Netflix的Eureka、Apache的Consul等。
分体式配置管理：百度的Disconf、Netflix的Archaius、360的QConf、Spring Cloud的Config、淘宝的Diamond等。
批量任务：当当网的Elastic-Job、LinkedIn的Azkaban、Spring Cloud的Task等。
服务跟踪：京东的Hydra、Spring Cloud的Sleuth、Twitter的Zipkin等。

ps：这些是实施微服务初期都需要考虑的问题，以及一些针对性的开源解决方案。Spring Cloud他不像前面列举的框架那样，只是解决某一个问题，而是一个解决微服务架构实施的综合性解决框架，既整合了已经被广泛实践并证明的框架作为基础部件，又在此基础上创建了一些优秀的边缘组件。

7.Spring Cloud简介

Spring Cloud是一个基于SpringBoot实现的微服务架构开发工具。为微服务中涉及到的：配置管理、服务治理、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话 和 集群状态管理 等操作提供了一个简单的开发方式，包含的子项目有：

• Spring Cloud Config：配置管理工具，支持使用Git存储配置内容。
• Spring Cloud Netflix：核心组件，对多个Netflix OSS开源套件进行整合。
  • Eureka：服务治理组件。包含服务注册中心、服务注册与发现机制的实现。
  • Hystrix：容错管理组件。实现断路器模式，帮助服务依赖中出现的延迟和 为故障提供强大的容错能力。
  • Ribbon：客户端负载均衡的服务调用组件。
  • Feign：基于Ribbon和Hystrix的声明式调用组件。
  • Zuul：网关组件。提供智能路由、访问过滤等功能。
  • Archaius：外部化配置组件。
• Spring Cloud Bus：事件、消息总线，用于传播集群中的状态变化或事件，以触发后续的处理。eg：用来动态刷新配置等。
• Spring Cloud Cluster：针对ZooKeeper、Redis、Hazelcast、Consul 的选举算法和通用状态模式的实现。
• Spring Cloud Cloudfoundry：与Pivotal Cloudfoundry 的整合支持。
• Spring Cloud Consul：服务发现与配置管理工具。
• Spring Cloud Stream：通过Redis、Rabbit 或者Kafka 实现的消息微服务，可以通过简单的声明式模型来 发送和接收 消息。
• Spring Cloud AWS：用于简化整合Amazon Web Service 的组件。
• Spring Cloud Security：安全工具包。提供在Zuul 代理中对OAuth2 客户端请求的中继器。
• Spring Cloud Sleuth：Spring Cloud应用的分布式跟踪实现，可以完美整合Zipkin。
• Spring Cloud ZooKeeper：基于ZooKeeper 的服务发现与配置管理组件。
• Spring Cloud Starters：Spring Cloud的基础组件。它是基于Spring Boot 风格项目基础依赖模块。
• Spring Cloud CLI：用于在Groovy 中快速创建Spring Cloud应用的Spring Boot CLI插件。
  。。。。。。以上是常用 的组件。

8.版本名与版本号

由于Spring Cloud不像Spring 社区其他一些项目那样相对独立，它是 一个拥有诸多子项目的 大型综合项目。【大型综合超市VS小摊位？！】可以说是对微服务架构解决方案的综合套件组合。其包含的各个子项目也都独立进行着内容更新与迭代，各自都维护着自己的发布版本号。为了区别开，Spring Cloud没有采用子项目拥有的版本号方式，而是采用命名方式。

image.png

image.png

谢谢你，读到这里。。。
Less is more.