spring cloud 学习之认识SpringCloud

微服务是什么

目前而言，对于微服务业界并没有一个统一的、标准的定义。微服务的提出者 Martin Fowler 是这样描述微服务的：通常而言，微服务架构是一种架构模式或者说是一种架构风格，他提倡将单一的应用程序划分成一组小的服务，每个服务运行在其独立的自己的进程中，服务之间互相协调、互相配合，为用户提供最终价值。服务之间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境，类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务，可以使用不同的语言来编写服务，也可以使用不同的数据存储。有能力的童鞋可以去读一下Martin Fowler的博文《Microservices》，链接：https://martinfowler.com/articles/microservices.html 。微服务化的核心就是将传统的一站式应用，根据业务拆分成一个一个的服务，彻底地去耦合，每一个微服务提供单个业务功能的服务，一个服务做一件事，从技术角度看就是一中小而独立的处理过程，类似进程概念，能够自行单独启动或销毁，拥有自己独立的数据库。

微服务优点

• 每个服务足够内聚，足够小，代码容易理解，每个服务聚焦一个指定的业务功能或业务需求。
• 开发简单、开发效率提高，原则上一个服务就是专一的只干一件事
• 小团队可单独开发，并不需要一定规模的团队
• 松耦合，无论在开发阶段还是部署阶段都是独立的，不受启动顺序，服务依赖等束缚（参照RPC）
• 可使用不同语言开发
• 易于和第三方集成，微服务允许容易切灵活的方式集成自动部署
• 微服务只有业务逻辑代码，不会和HTML，CSS或其他界面组件混合
• 每个微服务都有自己的存储能力，可以是单独的数据库，也可是统一的数据库

微服务缺点

• 服务拆分多，通讯成本增加
• 运维难度增加，监控难度增加
• 数据一致性
• 系统集成测试难度增加
• 分布式系统的复杂性

微服务技术栈

微服务条目	落地技术	备注
服务开发	SpringBoot,Spring,SpringMVC
服务配置与管理	Netflix公司的Archaius,阿里的Diamond等
服务注册与发现	Eureka,Consul,Zookeeper等
服务调用	REST,RPC,gRPC
服务熔断器	Hystrix,Envoy等
负载均衡	Ribbon,Nginx等
服务接口调用(客户端调用服务的简化工具)	Feign等
消息队列	Kafka,RabbitMQ,ActiveMQ等
服务配置中心管理	SpringCloudConfig,Chef等
服务路由(API网关)	Zuul等
服务监控	Zabbix,Nagios,Metrics,Spectator等
全链路追踪	Zipkin,Brave,Dapper等
服务部署	Docker,OpenStack,Kubernetes等
数据流操作开发包	SpringCloudStream(封装与Redis,RabbitMQ,Kafka等发送接收消息)
事件消息总线	SpringCloudBus

Spring Cloud是什么

基于SpringBoot提供了一套微服务架构下一站式解决方案，是各个微服务架构落地技术的集合体，技术包括服务注册与发现，配置中心,全链路监控，服务网关负载均衡，熔断器等组件，除了基于NetFlix的开源组件做高度抽象封装之外，还有一些选型中立的的开源组件。架构图如下：
[外链图片转存失败(img-dUTIs8hV-1564369687091)(https://spring.io/img/homepage/diagram-distributed-systems.svg)]

为什么选择Spring Cloud

各大公司当前采用的微服务架构有：阿里的Dubbo/HSF，京东的JSF，新浪微博的Motan，当当网的DubboX。

功能点/服务框架	Netflix/SpringCloud	Motan	gRPC	Thrift	Dubbo/DubboX
功能定位	完整的微服务框架	RPC框架，但整合了Zookeeper或Consul，实现集群环境的基本服务注册发现	RPC框架	RPC框架	服务框架
支持REST	是，Ribbon支持多种可插拔的序列化选择	否	否	否	否
支持RPC	否	是(Hession2)	是	是	是
支持多语言	是	否	是	是	否
服务注册发现	是(Eureka)	是(Zookepper/Cnsul)	否	否	是
负载均衡	是(服务端Zuul+客户端Ribbon)	是(客户端)	否	否	是(客户端)
配置服务	Netflix Archaius Spring Cloud Config Server集中配置	否	否	否	否
服务调用链监控	是(Zuul),Zuul提供边缘服务，API网关	否	否	否	否
高可用/容错	是(服务端Hystrix+客户端Ribbon)	是(客户端)	否	否	是(客户端)
典型应用案例	Netflix	Sina	Google	Facebook	国内较多的互联网公司
社区活跃程度	高	一般	高	一般	五年没有维护后现在又开始维护了
学习难度	中等	低	高	高	低
文档丰富度	高	一般	一般	一般	高
其他	SpringCloudBus配置	支持降级	Netflix内部在开发集成gRPC	IDL定义	国内实践比较多

国内一般着重对比Dubbo和SpringCloud。最大的区别就是Spring Cloud基于REST API通讯，而Dubbo采用RPC，REST API的形式牺牲的调用性能，而且灵活，不存在代码的强依赖，RPC通讯性能非常高。国内采用Spring Cloud的具体公司有：中国联通子公司，华为，拍拍贷，买单侠，广发银行等。下表是各个组件(功能)的详细对比。

项目	Dubbo	Spring Cloud
服务注册中心	Zookepper	Spring Cloud Netflix Eureka
服务调用方式	RPC	REST API
服务监控	Dubbo-monitor	Spring Boot Admin
断路器	不完善	Spring Cloud Netflix Hystrix
服务网关	无	Spring Cloud Netflix Zuul
分布式配置	无	Spring Cloud Config
服务跟踪	无	Spring Cloud Sleuth
消息总线	无	Spring Cloud Bus
数据流	无	Spring Cloud Stream
批量任务	无	Spring Cloud Task