微服务是松耦合的分布式软件服务,这些服务执行少量的定义明确的任务。Spring Boot 和 Spring Cloud 为Java开发者提供了一条从开发传统单体的Spring应用到开发可以部署在云端的微服务应用的迁移路径。
1.1 什么是微服务
在微服务的概念逐步形成前,绝大部分基于Web的应用都是使用单体架构的风格来进行构建的。在单体构架中,应用程序作为单个可部署的软件制品交付,所有的UI(用户接口)、业务数据、数据库访问逻辑都被打包在一个应用程序制品中并且部署在一个应用程序服务器上。
微服务的概念最初是在2014年前后悄悄蔓延到软件开发社区的意识中。微服务是一个小的、松耦合的分布式服务。
在思考微服务时,一个需要信奉的概念就是:分解和分离应用程序的功能,使它们完全彼此独立。
微服务具有以下特征:
- 应用程序逻辑分解为具有明确定义了职责范围的细粒度组件,这些组件互相协调提供解决方案
- 每个组件都有一个小的职责领域,并且能够完全独立部署。微服务应该对业务领域的单个部分负责。此外,一个微服务应该可以跨多个应用程序复用
- 微服务之间的通讯基于一些基本的原则,并采用HTTP和JSON这样的轻量级通信协议,在服务消费者和服务提供者之间进行数据转换
- 服务的底层采用什么技术实现并没有什么影响,因为应用程序始终使用技术中立的协议(如JSON)进行通信。这意味着构建在微服务之上的应用程序能够使用多种编程语言和技术进行构建
- 微服务利用其小、独立和分布式的性质,使组织拥有明确责任领域的小型开发团队。如交付一个应用程序,每个团队只负责他们在做的服务
1.2 Spring 与微服务
在基于Java的应用程序构建中,Spring已经成为事实上的标注开发框架。Spring的核心是建立在依赖注入的概念上的。Spring能够快速引入特性,使用J2EE技术栈开发应用的企业级Java开发人员迅速采用它作为一个轻量级的替代方案。J2EE栈虽然强大,但其过于庞大。此外J2EE应用程序强制用户使用成熟的(沉重的)Java应用程序服务器来部署自己的应用程序。Spring的另一个迷人的特性就是它能够与时俱进并且能进行自我改造。
Spring Boot是对Spring框架理念重新思考的结果。虽然Spring Boot包含了Spring的核心特点,但它剥离了Spring中许多“企业特性”,而提供了一个基于Java的、面向REST的微服务构架。只需要一些简单注解,Java开发者就能够快速构建一个可以打包和部署的REST微服务,且并不需要外部的应用容器。
Tips:REST的核心概念是:服务应该使用HTTP动词(GET、POST、PUT和DELETE)来表示服务中的核心操作,并且使用轻量级的面向Web的数据序列化协议(如JSON)来从服务请求数据和从服务接收数据。
在构建基于云的应用时,微服务已经成为更常见的架构模式之一,因此Spring社区为开发者提供了Spring Cloud。Spring Cloud在一个公共框架下封装了多个流行的云管理微服务框架,并且让这些技术的使用和部署像为代码添加注解一样简便。
1.3 云计算的3种基本模式
- 基础设施即服务(IaaS)
- 平台即服务(PaaS)
- 软件即服务(SaaS)
Tips:新的云平台类型正在出现。包括“函数即服务”(FaaS),像亚马逊的Lambda技术和Google Cloud函数这样的设施;“容器即服务”(CaaS),像亚马孙逊的弹性容器服务等等。
1.4 云和微服务
微服务的构架的核心概念之一就是每个服务被打包和部署为离散的独立制品。服务实例应该快速启动,服务的每个实例都是完全相同的。
作为编写微服务的开发人员,我们迟早要决定是否将服务部署到下列某个环境之中:
- 物理服务器——虽然可以构建和部署微服务到物理机器,但由于物理服务器的局限性,很少有组织会这样做
- 虚拟机镜像——微服务的优点之一是能够快速启动和关闭微服务实例,以响应可伸缩性和服务故障事件。虚拟机是主要云供应商的心脏和灵魂。微服务可以打包在虚拟机镜像中,然后开发人员可以在IaaS私有或者公有云上快速部署和启动服务的多个实例
- 虚拟容器——虚拟容器是在虚拟机镜像上部署微服务的自然延伸。许多开发人员不是将服务部署到完整的虚拟机,而是将Docker容器或者其他容器部署到云端。虚拟容器在虚拟机中运行。使用虚拟容器,可以将单个虚拟机隔离成共享相同虚拟机镜像的一系列独立进程
基于云的微服务的优势是以弹性的概念为中心。云服务提供商允许开发者在几分钟内快速启动新的虚拟机和容器。
我们接下来构建的服务都会打包为Docker容器。Docker作为容器技术,可以部署到所有主要的云供应商之中。
1.5 微服务不只是编写代码
构建单个微服务的概念比较容易理解,但运行和支持健壮的微服务应用程序(尤其是在云中运行)不知是涉及为服务编写代码,还应考虑如下因素:
- 大小适当——如何确保正确的划分微服务的大小,以避免微服务承担太多的职责?请记住,适当的大小允许快速更改应用程序,并降低整个应用程序中断的总体风险
- 位置透明——在微服务应用程序中,多个服务实例可以快速启动和关闭时,如何管理服务调用的物理细节?
- 有弹性——如何绕过失败的服务,确保采取“快速失败”的方法来保护微服务消费者的应用程序的整体完整性?
- 可重复——如何确保提供的每个新服务实例与生产环境中的所有其他服务实例具有相同的配置和代码库?
- 可伸缩——如何使用异步处理和事件来最小化服务之间的直接依赖关系,并确保可以优雅地拓展服务?
我们采用基于模式的方法来回答这些问题。以下是6类微服务模式: - 核心微服务开发模式
- 微服务路由模式
- 微服务客户端弹性模式
- 微服务安全模式
- 微服务日志记录和跟踪模式
- 微服务构建和部署模式