一般初期公司需要面对非常复杂的业务场景,而且随着业务的发展,变化的可能性非常高。所以在微服务架构设计之初,我们就期望我们的微服务体系能:
- 不绑定到特定的框架、语言
- 服务最好是Restful风格
- 足够简单,容易落地,将来能扩展
- 和Docker相容性好
目前常见的微服务相关框架:
- Dubbo、DubboX
- Spring Cloud
- Motan
- Thrift、gRPC
这些常见的框架中,Dubbo几乎是唯一能被称作全栈微服务框架的“框架”,它包含了微服务所需的几乎所有内容,而DubboX作为它的增强,增加了REST支持。
它优点很多,例如:
- 全栈,服务治理的所有问题几乎都有现成答案
- 可靠,经过阿里实践检验的产品
- 实践多,社区有许多成功应用Dubbo的经验
不过遗憾的是:
- 已经停止维护
- 不利于裁剪使用
- “过于Java”,与其他语言相容性一般
Motan是微博平台微服务框架,承载了微博平台千亿次调用业务。
优点是:
- 性能好,源自于微博对高并发和实时性的要求
- 模块化,结构简单,易于使用
- 与其他语言相容性好
不过:
- 为“短平快”业务而生,即业务简单,追求高性能高并发。
Apache Thrift、gRPC等虽然优秀,并不能算作微服务框架,自身并不包括服务发现等必要特性。
如果说微服务少不了Java,那么一定少不了Spring,如果说少不了Spring,那么微服务“官配”Spring Cloud当然是值得斟酌的选择。
优点:
- “不做生产者,只做搬运工”
- 简单方便,几乎零配置
- 模块化,松散耦合,按需取用
- 社区背靠Spring大树
不足:
- 轻量并非全栈
- 没解决RPC的问题
- 实践案例少
根据我们的目标,我们最终选择了Spring Cloud作为我们的微服务框架,原因有4点:
- 虽然Dubbo基础设施更加完善,但结构复杂,我们很难吃得下,容易出坑
- 基于
Apache Thrift
和gRPC
自研,投入产出比很差 - 不想过早引入RPC以防滥用,Restful风格本身就是一种约束。
- 做选择时,
Motan
还没有发布
Spring Cloud
Spring Cloud是一个集成框架,将开源社区中的框架集成到Spring体系下,几个重要的家族项目:
spring-boot
,一改Java应用程序运行难、部署难,甚至无需Web容器,只依赖JRE即可spring-cloud-netflix
,集成Netflix优秀的组件Eureka、Hystrix、Ribbon、Zuul,提供服务发现、限流、客户端负载均衡和API网关等特性支持spring-cloud-config
,微服务配置管理spring-cloud-consul
,集成Consul支持
服务发现和配置管理
Spring Cloud Netflix提供了Eureka服务注册的集成支持,不过没选它是因为:
- 更适合纯Java平台的服务注册和发现
- 仍然需要其他分布式KV服务做后端,没解决我们的核心问题
Docker作为支撑平台的重要技术之一,Consul几乎也是我们的必选服务。因此我们觉得一事不烦二主,理所应当的Consul成为我们的服务注册中心。
Consul的优势:
- 使用Raft一致性算法,能保证分布式集群内各节点状态一致
- 提供服务注册、服务发现、服务状态检查
- 支持HTTP、DNS等协议
- 提供分布式一致性KV存储
也就是说,Consul可以一次性解决我们对服务注册发现、配置管理的需求,而且长期来看也更适合跟不同平台的系统,包括和Docker调度系统进行整合。
最初打算自己开发一个Consul和Spring Cloud整合的组件,不过幸运的是,我们做出这个决定的时候, spring-cloud-consul
刚刚发布了,我们可以拿来即用,这节约了很多的工作量。
因此借助Consul和 spring-cloud-consul
,我们实现了
- 服务注册,引用了
srping-cloud-consul
的项目可以自动注册服务,也可以通过HTTP接口手动注册,Docker容器也可以自动注册 - 服务健康状态检查,Consul可以自动维护健康的服务列表
- 异构系统可以直接通过Consul的HTTP接口拉取并监视服务列表,或者直接使用DNS解析服务
- 通过分布式一致性KV存储进行微服务的配置下发
- 为一些业务提供选主和分布式锁服务