三、微服务的拆分与编写

【微服务的概念,使用场景,建模,架构通览,拆分微服务并且一步步分析,编写一些基础的微服务功能】

微服务的拆分与编写

(一)、单体架构

什么是单体架构?

一个归档包(例如war格式或者Jar格式)包含了应用所有功能的应用程序,我们通常称之为单体应用。架构单体应用的方法论,我们称之为单体应用架构,这是一种比较传统的架构风格。

架构图

 缺陷

1.复杂性高
整个项目包含的模块非常多,模块的边界模糊,依赖关系不清晰,代码质量参差不齐,整个项目非常复杂。每次修改代码都心惊胆战,甚至添加一个简单的功能,或者修改一个BUG都会造成隐含的缺陷。

2.技术债务逐渐上升
随着时间推移、需求变更和人员更迭,会逐渐形成应用程序的技术债务,并且越积越多。已使用的系统设计或代码难以修改,因为应用程序的其他模块可能会以意料之外的方式使用它。

3.部署速度逐渐变慢,频率低
随着代码的增加,构建和部署的时间也会增加。而在单体应用中,每次功能的变更或缺陷的修复都会导致我们需要重新部署整个应用。全量部署的方式耗时长、影响范围大、风险高,这使得单体应用项目上线部署的频率较低,从而又导致两次发布之间会有大量功能变更和缺陷修复,出错概率较高。

4.扩展能力受限,无法按需伸缩
单体应用只能作为一个整体进行扩展,无法结合业务模块的特点进行伸缩。

5.阻碍技术创新
单体应用往往使用统一的技术平台或方案解决所有问题,团队的每个成员都必须使用相同的开发语言和架构,想要引入新的框架或技术平台非常困难。

(二)、微服务架构

什么是微服务架构?

特性

每个微服务可独立运行在自己的进程里;
一系列独立运行的微服务共同创建起整个系统;
每个服务为独立的业务开发,一个微服务只关注某个特定的功能,例如订单管理、用户管理等;
可以使用不同的语言和数据存储技术(契合项目情况和团队的实力);
微服务之间通过轻量级的通信机制进行通信,例如通过REST API进行调用;
全自动的部署机制。

全景架构图

优点

单个服务更易于开发、维护
单个微服务启动较快
局部修改容易部署
技术栈不受限
按需伸缩

缺点

运维要求高
分布式固有的复杂性

使用环境

大型复杂的系统,例如电商系统
访问压力大的系统,例如秒杀系统
迭代快的系统

(三)、微服务拆分

方法论

合理的粒度

良好的满足业务
幸福感:你的团队认为微服务不是太大,同时部署也非常地高效
增量迭代:每个微服务之间相对独立,每次迭代只会涉及到有限个微服务
持续进化:如果一个微服务使用Java开发的,现在选用Python,风险是可控的
微服务的拆分是一个动态过程

(四)、微信小程序项目

服务拆分

 项目架构图

数据库设计

数据建模

建表

user-center.sql

CREATE DATABASE `user_center`;
USE `user_center`;

-- -----------------------------------------------------
-- Table `user`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `user` (
  `id` INT NOT NULL AUTO_INCREMENT COMMENT ‘Id‘,
  `wx_id` VARCHAR(64) NOT NULL DEFAULT ‘‘ COMMENT ‘微信id‘,
  `wx_nickname` VARCHAR(64) NOT NULL DEFAULT ‘‘ COMMENT ‘微信昵称‘,
  `roles` VARCHAR(100) NOT NULL DEFAULT ‘‘ COMMENT ‘角色‘,
  `avatar_url` VARCHAR(255) NOT NULL DEFAULT ‘‘ COMMENT ‘头像地址‘,
  `create_time` DATETIME NOT NULL COMMENT ‘创建时间‘,
  `update_time` DATETIME NOT NULL COMMENT ‘修改时间‘,
  `bonus` INT NOT NULL DEFAULT 300 COMMENT ‘积分‘,
  PRIMARY KEY (`id`))
COMMENT = ‘分享‘;

-- -----------------------------------------------------
-- Table `bonus_event_log`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `bonus_event_log` (
  `id` INT NOT NULL AUTO_INCREMENT COMMENT ‘Id‘,
  `user_id` INT NULL COMMENT ‘user.id‘,
  `value` INT NULL COMMENT ‘积分操作值‘,
  `event` VARCHAR(20) NULL COMMENT ‘发生的事件‘,
  `create_time` DATETIME NULL COMMENT ‘创建时间‘,
  `description` VARCHAR(100) NULL COMMENT ‘描述‘,
  PRIMARY KEY (`id`),
  INDEX `fk_bonus_event_log_user1_idx` (`user_id` ASC) )
ENGINE = InnoDB
COMMENT = ‘积分变更记录表‘;

content-center.sql

CREATE DATABASE `content_center`;
USE `content_center`;

-- -----------------------------------------------------
-- Table `share`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `share` (
  `id` INT NOT NULL AUTO_INCREMENT COMMENT ‘id‘,
  `user_id` INT NOT NULL DEFAULT 0 COMMENT ‘发布人id‘,
  `title` VARCHAR(80) NOT NULL DEFAULT ‘‘ COMMENT ‘标题‘,
  `create_time` DATETIME NOT NULL COMMENT ‘创建时间‘,
  `update_time` DATETIME NOT NULL COMMENT ‘修改时间‘,
  `is_original` TINYINT(1) NOT NULL DEFAULT 0 COMMENT ‘是否原创 0:否 1:是‘,
  `author` VARCHAR(45) NOT NULL DEFAULT ‘‘ COMMENT ‘作者‘,
  `cover` VARCHAR(256) NOT NULL DEFAULT ‘‘ COMMENT ‘封面‘,
  `summary` VARCHAR(256) NOT NULL DEFAULT ‘‘ COMMENT ‘概要信息‘,
  `price` INT NOT NULL DEFAULT 0 COMMENT ‘价格(需要的积分)‘,
  `download_url` VARCHAR(256) NOT NULL DEFAULT ‘‘ COMMENT ‘下载地址‘,
  `buy_count` INT NOT NULL DEFAULT 0 COMMENT ‘下载数 ‘,
  `show_flag` TINYINT(1) NOT NULL DEFAULT 0 COMMENT ‘是否显示 0:否 1:是‘,
  `audit_status` VARCHAR(10) NOT NULL DEFAULT 0 COMMENT ‘审核状态 NOT_YET: 待审核 PASSED:审核通过 REJECTED:审核不通过‘,
  `reason` VARCHAR(200) NOT NULL DEFAULT ‘‘ COMMENT ‘审核不通过原因‘,
  PRIMARY KEY (`id`))
ENGINE = InnoDB
COMMENT = ‘分享表‘;

-- -----------------------------------------------------
-- Table `mid_user_share`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mid_user_share` (
  `id` INT NOT NULL AUTO_INCREMENT,
  `share_id` INT NOT NULL COMMENT ‘share.id‘,
  `user_id` INT NOT NULL COMMENT ‘user.id‘,
  PRIMARY KEY (`id`),
  INDEX `fk_mid_user_share_share1_idx` (`share_id` ASC) ,
  INDEX `fk_mid_user_share_user1_idx` (`user_id` ASC) )
ENGINE = InnoDB
COMMENT = ‘用户-分享中间表【描述用户购买的分享】‘;

-- -----------------------------------------------------
-- Table `notice`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `notice` (
  `id` INT NOT NULL AUTO_INCREMENT COMMENT ‘id‘,
  `content` VARCHAR(255) NOT NULL DEFAULT ‘‘ COMMENT ‘内容‘,
  `show_flag` TINYINT(1) NOT NULL DEFAULT 0 COMMENT ‘是否显示 0:否 1:是‘,
  `create_time` DATETIME NOT NULL COMMENT ‘创建时间‘,
  PRIMARY KEY (`id`));

原文地址:https://www.cnblogs.com/my-program-life/p/12253139.html

时间: 2024-11-08 16:25:12

三、微服务的拆分与编写的相关文章

Spring Cloud Alibaba微服务从入门到进阶 完整版

第1章 课程介绍课程的总体介绍,课程需要的环境搭建和一些常用的快捷键介绍. 第2章 Spring Boot基础前期先带着学习Spring Boot基础,创建Spring Boot项目,讲解Spring Boot的配置,是学习Spring Cloud Alibaba的必知必会. 第3章 微服务的拆分与编写这一章讲解的微服务的概念,使用场景,建模,架构通览,讲师带着拆分微服务并且一步步分析,编写一些基础的微服务功能 第4章 Spring Cloud Alibaba介绍学习Spring Cloud A

Spring Cloud Alibaba微服务从入门到进阶 持续更新中

一.Spring Cloud Alibaba简介  https://www.cnblogs.com/my-program-life/p/12203487.html 二.Spring Boot基础  https://www.cnblogs.com/my-program-life/p/12253009.html 三.微服务的拆分和编写  https://www.cnblogs.com/my-program-life/p/12253139.html 原文地址:https://www.cnblogs.c

以实例说明微服务拆分(以SpringCloud+Gradle)

前言 之前,我都是说了很多的关于微服务的概念,说到底,很多人看了之后会认为没有什么意思,因为没有实际的东西说明,即使每个概念都明白了,也很难赋之实践.所以这次,我来用一个实际的例子去说明,在实际的项目过程中我们会如何去构建我们的微服务. PS:我们只是利用场景去模拟我们微服务构建或者说拆分的整个过程,对于场景本身在实际中会出现的问题我们不做考虑,说白了就是我们不考虑场景本身在实际生活中是不是这样的. 使用SpringCloud+Gradle构建 本文目的:让你体会到服务拆分本身,引起你对服务拆分

微服务拆分

微服务拆分是做微服务架构很重要也很难的话题,很多时候,几个服务是合还是拆在设计团队内也很难达成共识. 当你纠结应该拆分和合并时我建议就先合并,等后面版本迭代需要时有必要再去做拆分.从系统发展的角度说,很多平台也都是从单体大应用.逐步拆分演化而来的,就像有位大牛说的那样,一开始就拆分的很好的微服务实践往往是失败的,成功的微服务平台都是在演化中迭代而来的.因为微服务拆分看似单个服务明确简单了,但服务间调用管理就麻烦很多,原来进程内函数调用.单数据库表查询连接及事务处理都不能用了,要用各种方法处理数据

从 Spring Cloud 开始,聊聊微服务架构实践之路

[编者的话]随着公司业务量的飞速发展,平台面临的挑战已经远远大于业务,需求量不断增加,技术人员数量增加,面临的复杂度也大大增加.在这个背景下,平台的技术架构也完成了从传统的单体应用到微服务化的演进. 系统架构的演进过程 单一应用架构(第一代架构) 这是平台最开始的情况,当时流量小,为了节约成本,并将所有应用都打包放到一个应用里面,采用的架构为 .NET SQL Server: 表示层:位于最外层(最上层),最接近用户.用于显示数据和接收用户输入的数 据,为用户提供一种交互式操作的界面,平台所使用

从实践出发:微服务布道师告诉你Spring Cloud与Spring Boot他如何选择

背景 随着公司业务量的飞速发展,平台面临的挑战已经远远大于业务,需求量不断增加,技术人员数量增加,面临的复杂度也大大增加.在这个背景下,平台的技术架构也完成了从传统的单体应用到微服务化的演进. 系统架构的演进过程 单一应用架构(第一代架构) 这是平台最开始的情况,当时流量小,为了节约成本,并将所有应用都打包放到一个应用里面,采用的架构为.net+sqlserver: 表示层 位于最外层(最上层),最接近用户.用于显示数据和接收用户输入的数 据,为用户提供一种交互式操作的界面,平台所使用的是基于.

037 关于微服务的认识

对于微服务,还是只是一个感性的理解,缺乏系统的整理. 而且,读每一篇文章,都感觉有道理.这样就需要,先将人家比较好的文档列举,然后整理出自己文档. 一:一个简单的普通的理解,不涉及具体的技术 一.什么是微服务? 微服务架构风格是一种讲一个单一应用程序开发为一组小型服务的方法,每个服务运行在自己的进程中,服务间通信采用轻量级通信机制,这些服务围绕业务能力构建并且可通过全自动部署机制独立部署,这些服务公用一个小型的集中式的管理,服务可用不同的语言开发,使用不同的数据存储. 微服务具备以下的特性: 每

3.微服务--GRPC

1.gRPC入门 1.1gRPC简介 gRPC 由 google 开发,是一款语言中立.平台中立.开源的远程过程调用系统 gRPC 客户端和服务端可以在多种环境中运行和交互,例如用 java 写一个服务端,可以用 go 语言写客户端调用 1.2gRPC与Protobuf介绍 微服务架构中,由于每个服务对应的代码库是独立运行的,无法直接调用,彼此间的通信就是一个大问题. gRPC可以实现微服务,将大的项目拆分成多个小且独立的业务模块,即服务,各服务间使用搞笑的protobuf协议进行RPC调用,g

微服务架构与实践及云原生等相关概念

微服务架构与实践 笔记:<微服务架构与实践> 王磊 著 一 单块架构 1 定义:对于这种功能集中.代码和数据中心化.一个发布包.部署后运行在同一进程的应用程序,我们通常称之为单块架构应用,并非物理上的分层. 2 单层架构:数据 逻辑 页面 混合 3 三层架构: 1)表示层:数据显示和用户交互 2)业务逻辑层:业务逻辑处理 3)数据访问层:数据存储访问 4 优势: 比较适合小项目 易于开发:开发简单直接,集中式管理,基本不会重复开发,集成工具适合 易于测试:单进程 易于部署:单项目包,功能都在本