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