零基础搭建一套完整的微服务框架【window版】

技术栈:springboot+dubbo+docker 零基础搭即可建微服务,完整运行

本文你想学到什么?

本文将以实战方式,首先对“微服务”相关的概念进行概要介绍,然后开始手把手教你搭建这一整套完整的微服务系统。

项目完整代码下载地址

https://github.com/gggcgba/mall

微服务架构解决了什么问题

此系统建立完以后,你的整个系统将被拆分成一个个独立的子系统,独立运行,系统与系统之间通过RPC远程方式调用,这样大大降低了系统的耦合度,系统也极容易扩展和维护,团队协作效率得到明显提升。这种方式的实现我们通过最流行的springboot和阿里巴巴开源的dubbo来实现。

什么是微服务?

微服务一次近几年相当火,逐渐成为程序员容易讨论的话题,你如果不了解它,会不会感觉自己少了很多东西?下面我用最为通俗易懂的语言介绍它。

要讲清楚微服务,我先要从一个系统架构的演进过程讲起。

1. 单机结构

我想大家最熟悉的就是单机结构,一个系统业务量很小的时候所有的代码都放在一个项目中就好了,然后这个项目部署在一台服务器上就好了,整个项目所有的服务都由这台服务器提供。这就是单机结构。 那么,单机结构有啥缺点呢?我想缺点是显而易见的,单机的处理能力毕竟是有限的,当你的业务增长到一定程度的时候,单机的硬件资源将无法满足你的业务需求。此时便出现了集群模式,接续看。

2.集群结构

集群模式在程序猿界右各种名词解释,有的让你根本无法理解,其实就是一个很简单的玩意儿。

单机处理到达瓶颈的时候,你就把单机复制几份,这样就构成了一个“集群”。集群中每台服务器就叫做这个集群的一个“节点”,所有节点构成了一个集群。每个节点都提供相同的服务,那么这样系统的处理能力就相当于提升了好几倍(有几个节点就相当于提升了这么多倍)。

但问题是用户的请求究竟由哪个节点来处理呢?最好能够让此时此刻负载较小的节点来处理,这样使得每个节点的压力都比较平均。要实现这个功能,就需要在所有节点之前增加一个“调度者”的角色,用户的所有请求都先交给它,然后它根据当前所有节点的负载情况,决定将这个请求交给哪个节点处理,这个“调度者”有个牛逼的名字——负载均衡服务器。

集群结构的好处就是系统扩展非常容易,如果随着你们系统业务的发展,当前的系统又支撑不住了,那么给这个集群再增加节点就行了。但是,当你的业务发展到一定程度的时候,你会发现一个问题————无论怎么增加节点,貌似整个集群性能的提升效果并不明显了。这时候,你就需要使用微服务结构了。

3.微服务结构

先来对前面的知识点做个总结。 从单机结构到集群结构,你的代码基本无需要作任何修改,你要做的仅仅是多部署几台服务器,每天服务器上运行相同的代码就行了。但是,当你要从集群结构演进到微服务结构的时候,之前的那套代码就需要发生较大的改动了。所以对于新系统我们建议,系统设计之初就采用微服务架构,这样后期运维的成本更低。但如果一套老系统需要升级成微服务结构的话,那就得对代码大动干戈了。所以,对于老系统而言,究竟是继续保持集群模式,还是升级成微服务架构,这需要你们的架构师深思熟虑、权衡投入产出比。

OK,下面开始介绍所谓的微服务。 微服务就是将一个完整的系统,按照业务功能,拆分成一个个独立的子系统,在微服务结构中,每个子系统就被称为“服务”。这些子系统能够独立运行在web容器中,它们之间通过RPC方式通信。

举个例子,假设需要开发一个在线商城。按照微服务的思想,我们需要按照功能模块拆分成多个独立的服务,如:用户服务、产品服务、订单服务、评价服务等等。这一个个服务都是一个个独立的项目,可以独立运行。如果服务之间有依赖关系,那么通过RPC方式调用。

这样的好处有很多:

  1. 系统之间的耦合度大大降低,可以独立开发、独立部署、独立测试,系统与系统之间的边界非常明确,排错也变得相当容易,开发效率大大提升。

  2. 系统之间的耦合度降低,从而系统更易于扩展。我们可以针对性地扩展某些服务。假设这个商城要搞一次大促,下单量可能会大大提升,因此我们可以针对性地提升订单系统、产品系统的节点数量,而对于后台管理系统、数据分析系统而言,节点数量维持原有水平即可。

  3. 服务的复用性更高。比如,当我们将用户系统作为单独的服务后,该公司所有的产品都可以使用该系统作为用户系统,无需重复开发。

那么问题来了,当采用微服务结构后,一个完整的系统可能有很多独立的子系统组成,当业务量渐渐发展起来之后,而这些子系统之间的关系将错综复杂,而且为了能够针对性地增加某些服务的处理能力,某些服务的背后可能是一个集群模式,由多个节点构成,这无疑大大增加了运维的难度。微服务的想法好是好,但开发、运维的复杂度实在是太高。为了解决这些问题,阿里巴巴的Dubbo就横空出世了。

我们以在线商城为例,进行系统搭建。

  • 产品管理
    产品的增删改查

  • 订单管理
    订单的增删改查

  • 用户管理
    用户的注册 登录 等级等等

  • 评价管理
    评价的增删改查

创建项目

开发工具idea

  • 创建一个Maven Project,命名为 “mall”
    这个Project由多个Module构成,每个Module对应着“微服务”的一个子系统,可独立运行,是一个独立的项目。 这也是目前主流的项目组织形式,即多模块项目。

  • 在mall下创建各个子模块,每个模块都是独立的springboot项目

    • mall-product 产品管理服务
    • mall-order 订单管理服务
    • mall-user 用户管理服务
    • mall-evaluate 评价管理服务
    • mall-controller 本系统的控制层,和以往的controller层一样,请求调度,但是在本微服务系统中单独抽取为一个独立的系统运行。
    • mall-common-service 它处于本系统的最底层,被所有模块依赖,一些公用的类库都放在这里。

零基础搭建一套完整的微服务框架【window版】_第1张图片

开始搭建项目

New 一个Product

零基础搭建一套完整的微服务框架【window版】_第2张图片
选择Spring Initializr零基础搭建一套完整的微服务框架【window版】_第3张图片
设置groupId、artifactId、version

    <groupId>com.mall</groupId>
    <artifactId>mall</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <name>mall</name>
    <description>mall</description>

零基础搭建一套完整的微服务框架【window版】_第4张图片
父product创建完成,接下来在此product上右键 新建Module
零基础搭建一套完整的微服务框架【window版】_第5张图片
步骤跟刚才一模一样,只是artifact 修改为对应子模块 例如 mall-product

所有项目创建完以后目录结构如下图

零基础搭建一套完整的微服务框架【window版】_第6张图片

父子模块创建完以后,实际上他们之间并没有任何联系,好了,让我们通过pom文件把他们联系起来。
mall-product
mall-order
mall-user
mall-evaluate

这四个系统相当于系统中的service层,只不过在service层各个系统都被单独抽取成了一个子系统,他们提供rpc接口供给mall-controller调用,他们之间的调用由dubbo来完成,所以pom中无需做任何配置,但是此四个系统与mall-common-service是本地调用,所以在子系统的各个pom中需要引入mall-common-service

首先我们把mall-common-service打成jar包,安装到本地仓库中。

然后在其它四个模块的pom中引入此jar包,好吧 直接在父pom中一处引入,四个字系统就相当于都引用了。

<groupId>com.mall</groupId>
<artifactId>mall-common-service</artifactId>
<version>0.0.1-SNAPSHOT</version>
  • 在总pom中指定子模块
   <modules>
       <module>mall-controller</module>
       <module>mall-order</module>
       <module>mall-product</module>
       <module>mall-evaluate</module>
       <module>mall-user</module>
       <module>mall-common-service</module>
   </modules>

零基础搭建一套完整的微服务框架【window版】_第7张图片

modules标签指定了当前模块的子模块是谁,但是仅在父模块的pom文件中指定子模块还不够,还需要在子模块的pom文件中指定父模块是谁。

    <parent>
        <groupId>com.mall</groupId>
        <artifactId>mall</artifactId>
        

你可能感兴趣的:(docker,java,微服务)