乐趣区

关于程序员:基于微服务架构的水果销售系统的设计与实现

拜访【WRITE-BUG 数字空间】_[内附残缺源码和文档]

整体上为微服务架构,应用 SpringCloud 技术,每个独立的服务为一个独自的 SpringBoot 工程;数据库应用 MySQL 数据库;分布式缓存应用 Redis,音讯队列应用 Kafka。包含根底业务撑持服务,订单服务,领取服务,商品服务,门店治理服务,促销流动服务 6 个微服务。具体设计见 md 文件。

第 1 章绪论
1.1 论文钻研次要内容
互联网的高速倒退下,电子商务也失去了急速成长,各电商平台业务流量逐渐递增,原来的整站架构曾经无奈满足现有的需要,所以须要拆分业务,将业务模块化独立成各个微服务,加上容器,调度平台,监控等造成一个残缺的微服务架构。为此,特设计实现了基于微服务架构的水果销售零碎,其中包含根底业务撑持服务,订单服务,领取服务,商品服务,门店治理服务,促销流动服务 6 个微服务。

1.1.1 微服务架构概述
微服务架构是一种架构模式,它提倡将繁多应用程序划分成一组小的服务,服务之间相互协调、互相配合,为用户提供最终价值。每个服务运行在其独立的过程中,服务与服务间采纳轻量级的通信机制相互合作(通常是基于 HTTP 协定的 RESTfulAPI)。每个服务都围绕着具体业务进行构建,并且可能被独立的部署到生产环境、类生产环境等。另外,对具体的服务而言,应依据业务上下文,抉择适合的语言、工具对其进行构建。

就我集体而言微服务架构 ≈ 模块化开发 + 分布式计算。不论微服务架构的定义怎么样,都是在形容一个核心思想:把大零碎拆分成小型零碎,把大事化小,以升高零碎的复杂性,从而大幅升高零碎建设、降级、运维的危险和老本。

1.1.2 水果销售零碎
在现在各大电商平台层出不穷的环境下,商品的分类专卖成为了一种趋势。此零碎是为了实现水果的专售并且实现果农和买家的对接,打消第三方代理商的差价,在买家能买到更优惠,更有品质的前提下晋升果农的支出。

1.2 社区沉闷状态
自 2014 年 MartinFowler 在其博客上发表了“Microservices”一文(http://martinfowler.com/articles/microservices.html)以来,“微服务”这个词在各大技术论坛和社区的迅速沉闷起来,容器,PaaS,CloudNative,gRPC,ServiceMesh,Serverless 等新技术新理念你方唱罢我退场,推动着咱们来到了微服务 2.0 时代。

第 2 章关键技术介绍
2.1 关键性技术剖析和介绍
2.1.1Springboot/cloud
基于 Springboot/cloud 的框架实质上能够认为是一种 RESTFul 框架(不是 RPC 框架),序列化协定次要采纳基于文本的 JSON,通信协定个别基于 HTTP。RESTFul 框架人造反对跨语言,任何语言只有有 HTTP 客户端都能够接入调用,然而客户端个别须要本人解析 payload。目前 Spring 框架也反对 Swagger 契约编程模型,可能基于契约生成各种语言的强类型客户端,极大不便不同语言栈的利用接入,然而因为 RESTFul 框架和 Swagger 标准的弱契约个性,生成的各种语言客户端的互操作性还是有不少坑的。3 月 1 号官网公布了 SpringBoot2.0, 并提供了 Maven 地方仓库地址,该版本反对 SpringFramework5.0。

2.1.2 服务注册核心(Eureka)
SpringCloud 体系,抉择 Eureka 是最佳搭配,Eureka 在 Netflix 通过大规模生产验证,反对跨数据中心,客户端配合 Ribbon 能够实现灵便的客户端软负载,Eureka 目前在 GitHub 上有超过 4.7k 星。

2.1.3 服务网关(Zull)
SpringCloud 体系,则抉择 Zuul 是最佳搭配,Zuul 在 Netflix 通过大规模生产验证,反对灵便的动静过滤器脚本机制,异步性能有余(基于 Netty 的异步 Zuul 迟迟未能推出正式版)。Zuul 网关目前在 GitHub 上有超过 3.7k 星。

2.1.4 音讯零碎(Kafka)
后盾服务次要包含音讯零碎,分布式缓存,分布式数据拜访层和任务调度零碎。后盾服务是一个绝对比拟成熟的畛域,很多开源产品根本能够开箱即用。

音讯零碎,对于日志等可靠性要求不高的场景,则 Apache 顶级我的项目 Kafka 是社区标配。对于可靠性要求较高的业务场景,Kafka 其实也是能够胜任,但企业须要依据具体场景,对 Kafka 的监控和治理能力进行适当定制欠缺。

2.2 其余相干技术
2.2.1MySQL
MySQL,一种关系数据库管理系统。因为其体积小、速度快、成本低,尤其是开放源码这一特点,个别中小型网站的开发都抉择 MySQL 作为网站数据库。

2.2.2Maven
Maven,项目管理工具,蕴含了一个我的项目对象模型,一组规范汇合,一个我的项目生命周期,一个依赖管理系统,和用来运行定义在生命周期阶段中插件指标的逻辑。

2.2.3Redis
Redis,一个高性能的键值对数据库。它提供了 Java,C/C++,C#,PHP,JavaScript,Perl,Object-C,Python,Ruby,Erlang 等不同编程语言客户端,应用很不便。

第 3 章系统分析
3.1 构架概述
常见的微服务组件及概念:

1. 服务注册,服务提供方将本人调用地址注册到服务注册核心,让服务调用方可能不便地找到本人。

2. 服务发现,服务调用方从服务注册核心找到本人须要调用的服务的地址。

3. 负载平衡,服务提供方个别以多实例的模式提供服务,负载平衡性能可能让服务调用方连贯到适合的服务节点。并且,节点抉择的工作对服务调用方来说是通明的。

4. 服务网关,服务网关是服务调用的惟一入口,能够在这个组件是实现用户鉴权、动静路由、灰度公布、A/B 测试、负载限流等性能。

5. 配置核心,将本地化的配置信息(properties,xml,yaml 等)注册到配置核心,实现程序包在开发、测试、生产环境的无差别性,不便程序包的迁徙。

6.API 治理,以不便的模式编写及更新 API 文档,并以不便的模式供调用者查看和测试。

7. 集成框架,微服务组件都以职责繁多的程序包对外提供服务,集成框架以配置的模式将所有微服务组件(特地是治理端组件)集成到对立的界面框架下,让用户可能在对立的界面中应用零碎。

8. 分布式事务,对于重要的业务,须要通过分布式事务技术(TCC、高可用音讯服务、最大致力告诉)保证数据的一致性。

9. 调用链,记录实现一个业务逻辑时调用到的微服务,并将这种串行或并行的调用关系展现进去。在零碎出错时,能够不便地找到出错点。

10. 撑持平台,零碎微服务化后,零碎变得更加碎片化,零碎的部署、运维、监控等都比单体架构更加简单,那么,就须要将大部分的工作自动化。当初,能够通过 Docker 等工具来中和这些微服务架构带来的弊病。例如继续集成、蓝绿公布、健康检查、性能衰弱等等。重大点,以咱们公司的实践经验,能够这么说,如果没有适合的撑持平台或工具,就不要应用微服务架构。

退出移动版