这几年在 Java 工程师招聘时,会看到很多人的简历都写着使用了 Spring Cloud 做微服务实现,使用 Docker 做自动化部署,并且也会把这些做为自己的亮点。而比较有趣的这其中以小公司出来的人为绝大多数,大的公司出来的人简历上倒是很少提这些东西。
对于我自己来说,从 15 年就开始关注这一块,看过马丁.福勒最开始的关于微服务的论文、也看过不少对微服务的论证的英文文章和书,也研究过 Spring Cloud、Sofa 等开源实现以及 Service mesh。
考虑到我们公司研发团队人力不足、基础设施不完善,当初是没有推行微服务的。但随着看到上述的那种简历越来越多,有时候我也会疑问:难道真的不用微服务就落后了吗?公司的同事如果不掌握这些就真的没有竞争力了吗。
Spring Boot 是 Spring 全家桶的上层封装,并不是什么崭新的技术,也不是什么值得觉得成为自己杀手锏的技术。
Spring Cloud 中 Spring Cloud Netflix 的组件是经过生产环境验证的,其他的则建议慎重选择。
微服务是什么
微服务起源于 2005 年 Peter Rodgers 博士在云端运算博览会提出的微 Web 服务 (Micro-Web-Service ),根本思想类似于 Unix 的管道设计理念。
2014 年,由 Martin Fowler 与 James Lewis 共同提出了微服务的概念,定义了微服务架构风格是一种通过一套小型服务来开发单个应用的方法,每个服务运行在自己的进程中,并通过轻量级的机制进行通讯(HTTP API)。关键的三点是 small、automated 以及 lightweight。
对比 SOA,微服务可以看做是 SOA 的子集,是轻量级的 SOA,粒度更细的服务,独立进程、数据分离,更注重敏捷、持续交付、DevOps 以及去中心化实践。其共同的架构原理:
在引入微服务之后,传统的单体应用变为了一个一个服务,之前一个应用直接提供接口给客户端访问的架构不再适用。微服务架构下,针对不同设备的接口做为 BFF 层(Backend For Frontend),也叫做用户体验适配层,负责聚合、编排微服务的数据转换成前端需要的数据。服务之间的调用则在允许的情况下(允许延迟)尽可能使用异步消息传递方式,如此形成面向用户体验的微服务架构设计模式。如下图所示:
Client -> API Gateway -> BFF(Backend For Frontend) -> Downstream Microservices
Spring Boot
Spring Boot 是用来简化新 Spring 应用的初始搭建以及开发过程的。其虽然不是微服务框架,但其设计的初衷本质就是微应用的底层框架,因此非常适合用于微服务基础设施的开发以及微服务的应用开发。尤其对于Spring 技术栈的团队来说,基于 Spring Boot 开发微服务框架和应用是自然而然的一个选择。
Spring Cloud
Spring Cloud 是基于 Spring Boot 实现的微服务框架,也可以看做一套微服务实现规范。基本涵盖了微服务基础设施的方方面面,包括配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等。其基于 Spring 生态,社区支持非常好。但其很多组件都没有经过生产环境验证,需要慎重选择。
Spring Cloud Netflix 是 Spring Cloud 的一个子项目,是 Spring 对Netflix OSS 的集成实现。基于 Netflix 的大规模使用,其中的已经被广泛使用的组件包括:
此外,另一个子项目 Spring Cloud Alibaba 则是 Alibaba 开源的基于 Spring Boot 的微服务框架,主要是对阿里云服务的支持。
Eureka: 服务注册和服务发现
Ribbon:弹性而智能的进程间和服务通讯机制,客户端负载均衡
Hystrix: 熔断器,在运行时提供延迟和容错的隔离
Zuul: 服务网关
Service Mesh
上述的微服务框架都是侵入式的,服务化的过程都需要进行代码改造。Service Mesh 则是下一代微服务架构,最明显的特征就是无入侵。采用sidecar 模式来解决系统架构微服务化后的服务间通信和治理问题。如下如所示:
目前主流的开源实现包括:
限于 Service Mesh 带来的性能延迟的开销以及 sidecar 对分布复杂性的增加,其对大规模部署(微服务数目多)、异构复杂(交互协议/开发语言类型多)的微服务架构带来的收益会更大。