微服务是什么
目前而言,对于微服务业界并没有一个统一的、标准的定义。微服务的提出者 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 | 国内较多的互联网公司 | ||
社区活跃程度 | 高 | 一般 | 高 | 一般 | 五年没有维护后现在又开始维护了 |
学习难度 | 中等 | 低 | 高 | 高 | 低 |
文档丰富度 | 高 | 一般 | 一般 | 一般 | 高 |
其他 | 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 |