SpringCloud - 01入门介绍
（1）微服务概述
（1.1）是什么
马丁.福勒（Martin Fowler） 描述微服务 ： https://martinfowler.com/articles/microservices.html
（1.2）微服务架构
- 微服务架构是一种架构模式或者一种架构风格，它提倡将单一应用程序划分成一组小的服务，每个服务运行在其独立的自己的进程中。
- 服务之间互相协调、互相配合，为用户提供最终价值。服务之间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）。
- 每个服务都围绕着具体业务进行构建，能够被独立地部署到生产环境、类生产环境中。
- 应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建，
- 可以有一个非常轻量级的集中式管理来协调这些服务。可以使用不同的语言来编写服务，也可以使用不同的数据存储。
- 微服务化的核心就是将传统的一站式应用，根据业务拆分成一个个的服务，彻底地去耦合，每一个微服务提供单个业务功能的服务，一个服务做一件事。
- 从技术角度看就是一种小而独立的处理过程，类似于进程概念，能够自行单独启动或销毁，拥有自己独立的数据库。
- 强调的是服务的大小，它关注的是某一个点，是具体解决某一个问题/提供落地对应服务的一个服务应用。
（1.3）优点
- 每个服务足够内聚，足够小，代码容易理解，这样能聚焦一个指定的业务功能或业务需求。
- 开发简单、开发效率高，一个服务可能就是专一的只干一件事。
- 微服务能够被小团队单独开发，这个小团队是2到5人的开发人员组成。
- 微服务是松耦合的，是有功能意义的服务，无论是开发阶段还是部署阶段都是独立的。
- 微服务可以使用不同的语言开发。
- 易于和第三方集成， 微服务允许容易且灵活的方式集成与自动部署，通过持续集成工具，如Jenkins、Hudson、bamboo等。
- 微服务易于被一个开发人员理解、修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。
- 微服务允许利用融合最新技术。
- 微服务只是业务逻辑的代码，不会和HTML、CSS或其他页面组件混合。
- 每个微服务都有自己的存储能力，可以有自己的数据库。也可以有统一数据库。
（1.4）缺点
- 开发人员要处理分布式系统的复杂性
- 多服务运维难度，随着服务的增加，运维的压力也在增大。
- 系统部署依赖
- 服务间通信成本
- 数据一致性
- 系统集成测试
- 性能监控
（2）微服务的技术栈
- 服务开发： SpringBoot、 Spring、 SpringMVC
- 服务配置与管理： Netflix的Archaius、 阿里的Diamond等
- 服务注册与发现： Eureka、Consul、Zookeeper等
- 服务调用： Rest、RPC、gRPC
- 服务熔断器： Hystrix、Envoy等
- 负载均衡： Ribbon、Nginx等
- 服务接口调用（客户端调用服务的简化工具）： Feign等
- 消息队列： Kafka、RabbitMQ、ActiveMQ等
- 服务配置中心管理： SpringCloud Config、 Chef等
- 服务路由（API网关）： Zuul等
- 服务监控： Zabbix、Nagios、Metrics、Spectator等
- 全链路追踪： Zipkin、Brave、Dapper等
- 服务部署： Docker、OpenStack、Kubernetes等
- 数据流操作开发包： SpringCloud Stream（封装与Redis、RabbitMQ、Kafka等发送接收消息）
- 事件消息总线： SpringCloud Bus
（3）微服务架构
（3.1）选型依据
- 整体解决方案和框架成熟度
- 社区热度
- 可维护性
- 学习曲线
（3.2）常见微服务框架
- 阿里Dubbo/HSF
- 京东JSF
- 新浪微博Motan
- 当当网DubboX
（3.3）框架对比
| 功能点 | SpringCloud | Dubbo/DubboX | Motan | gRPC | Thrift |
| 定位 | 完整的微服务框架 | 服务框架 |
RPC框架,整合了Zookeeper或Consul， 实现集群环境的基本的服务注册/发现 |
RPC框架 | RPC框架 |
| 支持REST | 是，Ribbon支持多种可插拔的序列化选择 | 否 | 否 | 否 | 否 |
| 支持RPC | 否 | 是 | 是（Hession2） | 是 | 是 |
| 支持多语言 | 是 | 否 | 否 | 是 | 是 |
| 服务注册/发现 | 是（Eureka） | 是 | 是（Zookeeper/Consul） | 否 | 否 |
| 负载均衡 | 是，服务端zuul+客户端Ribbon | 是（客户端） | 是（客户端） | 否 | 否 |
| 配置服务 | Netflix Archaius/ SpringCloud Config | 否 | 是（Zookeeper提供） | 否 | 否 |
| 服务调用链监控 | 是 | 否 | 否 | 否 | 否 |
| 高可用/容错 | 是，服务端Hystrix+客户端Ribbon | 是（客户端） | 是（客户端） | 否 | 否 |
| 应用案例 | Netflix | 阿里巴巴 | Sina | ||
| 社区活跃度 | 高 | 高 | 一般 | 高 | 一般 |
| 学习难度 | 中等 | 低 | 低 | 高 | 高 |
| 文档丰富度 | 高 | 高 | 一般 | 一般 | 一般 |
| 其他 | SpringCloud Bus | 实践公司多 | 支持降级 | Netflix内部开发集成gRPC | IDL定义 |
（4）SpringCloud
（4.1）介绍
SpringCloud ： 分布式微服务架构下的一站式解决方案，是各个微服务架构落地技术的集合体，俗称微服务全家桶。
SpringCloud，基于SpringBoot提供了一套微服务解决方案，包括服务注册与发现、配置中心、服务网关、全链路监控、负载均衡、熔断器等。
（4.2）SpringCloud和SpringBoot的关系
- SpringBoot专注于快速方便地开发单个个体微服务。
- SpringCloud是关注全局的微服务协调治理框架，它将SpringBoot开发的一个个单体微服务整合并管理起来，
- 为各个微服务之间提供服务发现、配置管理、路由、断路器、微代理、事件总线、全局锁、决策竞选、分布式会话等集成服务。
- SpringBoot 可以离开SpringCloud独立使用开发项目，但是SpringCloud离不开SpringBoot，属于依赖关系。
（4.3）SpringCloud组件
- 服务注册与发现（Eureka）
- 服务消费者（REST+Ribbon）
- 断路器（Hystrix）
- 断路器监控（Hystrix Dashboard）
- 路由网关（Zuul）
- 分布式配置中心（Spring Cloud Config）
- 消息总线（Spring Cloud Bus）
- 服务链路追踪（Spring Cloud Sleuth）
（4.4）SpringCloud与Dubbo
最大区别： SpringCloud 抛弃了Dubbo的RPC通信， 采用的是 基于HTTP的REST方式。
REST相比RPC更为灵活，服务提供方和调用方的依赖 不存在代码级别的强依赖。
