其他分享
首页 > 其他分享> > 微服务

微服务

作者:互联网

微服务

微服务,我们可以从字面上去理解,即“微小的服务”,下面我们从“服务”和“微小”两个方面进行介绍。

1) 所谓“服务”,其实指的是项目中的功能模块,它可以帮助用户解决某一个或一组问题,在开发过程中表现为 IDE(集成开发环境,例如 Eclipse 或 IntelliJ IDEA)中的一个工程或 Moudle。

2) “微小”则强调的是单个服务的大小,主要体现为以下两个方面:

微服务架构

微服务架构是一种系统架构的设计风格。与传统的单体式架构(ALL IN ONE)不同,微服务架构提倡将一个单一的应用程序拆分成多个小型服务,这些小型服务都在各自独立的进程中运行,服务之间使用轻量级通信机制(通常是 HTTP RESTFUL API)进行通讯。

通常情况下,这些小型服务都是围绕着某个特定的业务进行构建的,每一个服务只专注于完成一项任务并把它做好 ,即“专业的人做专业的事”。

每个服务都能够独立地部署到各种环境中,例如开发环境、测试环境和生产环境等,每个服务都能独立启动或销毁而不会对其他服务造成影响。

这些服务之间的交互是使用标准的通讯技术进行的,因此不同的服务可以使用不同数据存储技术,甚至使用不同的编程语言。

微服务架构 vs 单体架构

在当今的软件开发领域中,主要有两种系统架构风格,那就是新兴的“微服务架构”和传统的“单体架构”。

单体架构是微服务架构出现之前业界最经典的软件架构类型,许多早期的项目采用的也都是单体架构。单体架构将应用程序中所有业务逻辑都编写在同一个工程中,最终经过编译、打包,部署在一台服务器上运行。

在项目的初期,单体架构无论是在开发速度还是运维难度上都具有明显的优势。但随着业务复杂度的不断提高,单体架构的许多弊端也逐渐凸显出来,主要体现在以下 3 个方面:


由于单体架构存在这些弊端,因此许多公司和组织都开始将将它们的项目从单体架构向微服务架构转型。

下面我们就来对比下微服务架构和单体架构到底有什么不同。

不同点微服务架构单体架构
团队规模 微服务架构可以将传统模式下的单个应用拆分为多个独立的服务,每个微服务都可以单独开发、部署和维护。每个服务从设计、开发到维护所需的团队规模小,团队管理成本小。 单体架构的应用程序通常需要一个大型团队,围绕一个庞大的应用程序工作,团队管理的成本大。
数据存储方式 不同的微服务可以使用不同的数据存储方式,例如有的用 Redis,有的使用 MySQL。 单一架构的所有模块共享同一个公共数据库,存储方式相对单一。
部署方式 微服务架构中每个服务都可以独立部署,也可以独立于其他服务进行扩展。如果部署得当,基于微服务的架构可以帮助企业提高应用程序的部署效率。 采用单体架构的应用程序的每一次功能更改或 bug 修复都必须对整个应用程序重新进行部署。
开发模式 在采用微服务架构的应用程序中,不同模块可以使用不同的技术或语言进行开发,开发模式更加灵活。 在采用单体架构的应用程序中,所有模块使用的技术和语言必须相同,开发模式受限。
故障隔离 在微服务架构中,故障被隔离在单个服务中,避免系统的整体崩溃。 在单体架构中,当一个组件出现故障时,故障很可能会在进程中蔓延,导致系统全局不可用。
项目结构 微服务架构将单个应用程序拆分为多个独立的小型服务,每个服务都可以独立的开发、部署和维护,每个服务都能完成一项特定的业务需求。 单体架构的应用程序,所有的业务逻辑都集中在同一个工程中。

微服务的特点

微服务具有以下特点:

微服务框架

微服务架构是一种系统架构风格和思想,想要真正地搭建一套微服务系统,则需要微服务框架的支持。随着微服务的流行,很多编程语言都相继推出了它们的微服务框架,下面我们就来简单列举下。

Java 微服务框架

市面上的 Java 微服务框架主要有以下 5 种:

 

标签:架构,部署,应用程序,开发,单体,服务
来源: https://www.cnblogs.com/canzhen/p/15896866.html