拜访【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 等工具来中和这些微服务架构带来的弊病。例如继续集成、蓝绿公布、健康检查、性能衰弱等等。重大点，以咱们公司的实践经验，能够这么说，如果没有适合的撑持平台或工具，就不要应用微服务架构。