文章目录

  • 前言
  • 什么是微服务
  • 为什么需要微服务
  • 微服务与单体架构的区别
  • 什么样的项目适合微服务
  • 微服务开发框架


前言

在了解Spring Cloud之前,首先应该对微服务架构有一定的了解。
微服务:
首先开发过程中,将项目分为多个模块,每个模块占用不同的端口号,且每个模块可作为一个单独的应用启动。
(1)微服务是架构风格
(2)把一个项目拆分成独立的多个服务,多个服务独立运行,每个服务占用独立进程。
也就是一个服务一个进程。
类似这种模式称为微服务架构。

什么是微服务

微服务最早由Martin Fowler与James Lewis于2014年共同提出,微服务架构风格是一种使用一套小服务来开发单个应用的方式途径,每个服务运行在自己的进程中,并使用轻量级机制通信,通常是HTTP API,这些服务基于业务能力构建,并能够通过自动化部署机制来独立部署,这些服务使用不同的编程语言实现,以及不同数据存储技术,并保持最低限度的集中式管理。

为什么需要微服务

在传统的IT行业软件大多都是各种独立系统的堆砌,这些系统的问题总结来说就是扩展性差,可靠性不高,维护成本高。到后面引入了SOA服务化,但是,由于 SOA 早期均使用了总线模式,这种总线模式是与某种技术栈强绑定的,比如:J2EE。这导致很多企业的遗留系统很难对接,切换时间太长,成本太高,新系统稳定性的收敛也需要一些时间。

微服务与单体架构的区别

(1)单体架构所有的模块全都耦合在一块,代码量大,维护困难。

微服务每个模块就相当于一个单独的项目,代码量明显减少,遇到问题也相对来说比较好解决。

(2)单体架构所有的模块都共用一个数据库,存储方式比较单一。

微服务每个模块都可以使用不同的存储方式(比如有的用redis,有的用mysql等),数据库也是单个模块对应自己的数据库。

(3)单体架构所有的模块开发所使用的技术一样。

微服务每个模块都可以使用不同的开发技术,开发模式更灵活。

什么样的项目适合微服务

微服务可以按照业务功能本身的独立性来划分,如果系统提供的业务是非常底层的,如:操作系统内核、存储系统、网络系统、数据库系统等等,这类系统都偏底层,功能和功能之间有着紧密的配合关系,如果强制拆分为较小的服务单元,会让集成工作量急剧上升,并且这种人为的切割无法带来业务上的真正的隔离,所以无法做到独立部署和运行,也就不适合做成微服务了。

微服务开发框架

目前微服务的开发框架,最常用的有以下四个:

Spring Cloud:http://projects.spring.io/spring-cloud(现在非常流行的微服务架构)

Dubbo:http://dubbo.io

Dropwizard:http://www.dropwizard.io (关注单个微服务的开发)

Consul、etcd&etc.(微服务的模块)