微服务架构
概述
- BizSpring移动全端国际化电商平台，是建立在Spring Cloud 基础上的微服务应用，服务化是系统达到一定规模以后的必然选择，主流的互联网公司基本都在迁移到服务化架构。
- 我们的微服务化架构给客户带来更多便捷，每个开发团队及各人更加专注于自身业务的开发，每个服务独立开发、部署、更新可以选择更加适合的技术体系，每个服务只需要对外提供接口隐藏了内部复杂的实现方式对调用方更加友好。
- Spring Cloud 微服务架构基于 Spring Boot 框架，是由一系列框架式组件组成的，这些组件包括注册中心、服务网管、服务调用、负载均衡、限流降级等等。
单体服务架构
单体服务架构是前些年使用的一种设计模式，即用户交互端+服务器端架构，将应用简单的分为前端和后端两部分，前端负责显示界面和处理用户交互，服务器负责处理业务逻辑和存储数据。
（单体服务架构图）
微服务架构
不同于传统的单体服务，微服务架构是一种将应用程序分为多个小型、独立的服务的软件架构。这些服务可以通过轻量级通信机制进行通信，每个服务都有自己的数据库和应用程序代码，每个服务运行在自己的进程中。这种模式使得每个服务可以独立部署、扩展和维护，从而提高应用程序的可靠性，这种架构可以更好地支持快速迭代和部署，提高开发效率和灵活性。
微服务架构图
微服务架构概述
微服务架构风格是一类将单一应用程序作为由众多小型服务构成之套件加以开发的方式，其中各项服务都拥有自己的进程并利用轻量化机制（通常为HTTP源API）实现通信。这些服务围绕业务功能建立而成，且凭借自动化部署机制实现独立部署。
微服务的特点
- 应用程序逻辑分为明确定义的职责范围的粒度组件，这些组件相互协调提供解决方案
- 每一个组件都有一个小的职责领域，可以完全部署，也就是说一个服务可以跨越多个应用程序复用(独立部署和维护)
- 服务之间通信基于一些基本的原则，如服务采用http + Json 这样的轻量级通信协议，在不同服务之间进行数据交互。这样不同服务可以使用不同的技术，互不影响，采用轻量级的通信协议作为通信原则、松耦合。
微服务结构的通用性
- 通过服务实现应用的组件化（按功能拆分、可独立部署和维护）
- 围绕业务能力组织服务，根据业务不同的需求进行不同组件的使用
- 所做产品非项目化，对于平台具有一定的通用性
微服务架构的五大优势
提高速度和工作效率
微服务架构的最大优势之一是，它将应用分解为多个可管理的服务，从而解决了速度和工作效率问题。不同的团队可以同时开发不同的应用组件。由于微服务之间在结构上互不依赖，因此一个团队永远不必等待其他团队完成其工作后再创建或更改微服务。另外，独立的微服务更易于定位和修改。每个微服务均可单独测试，因此您可以加快质量保证流程。而且能够在开发其他组件时测试已开发好的组件。
围绕业务功能组织实施
微服务允许根据业务优先级来组织团队和流程，支持构建产品而非项目，团队将专注于构建业务功能，而不是编写用于粘合各个功能的代码。因此你所创建的服务能够适应多种环境。可以在多个业务流程中重复使用同一 服务，甚至还能够按需通过不同的业务渠道使用同一服务。每位团队成员分别负责某项服务，从而组成一支分工明确的跨职能团队。
轻松构建和维护应用
微服务架构的最大优势或许支持轻松构建和维护应用，微服务旨在化繁为简。
当应用被设计成多个较小的部分时，便更易于构建和维护，管理代码也变得轻松很多，因为每个微服务都是单独的代码段。也可以使用不同的数据库、编程语言和软件环境来实现服务。因此每个服务都能够独立部署、构建、重新部署和管理。
如一个微服务分配了太多的内存，或者给处理器带来了繁重的负载。对于微服务架构，这只会影响该特定服务，一个微服务的问题不会影响到整个系统。
提高可扩展性
微服务的另一大优势是可帮助提高可扩展性。因为每个微服务都可以自主运行，因此您能够更轻松地添加、更新、删除并扩展单个微服务。开发人员可以在不破坏应用中其它微服务的情况下做到这一点。当对应用的需求增加时，您只需将更多的资源转移或升级到受需求增加影响的微服务即可，甚至可以使用容器自动扩展各个服务为服务集群。通过只扩展所需的服务，帮助公司节省大量的服务器资源成本。
提升数据安全性
微服务架构有助于提升数据安全性。当微服务之间建立连接时，借助安全的API，您可确保信息仅可供授权用户、应用和服务器访问。
当您的微服务正在管理敏感的财务、账务相关业务机密性信息，安全的API 支持您全面控制哪些数据可供应用访问。
单体服务架构的劣势
- 开发速度缓慢
只能采⽤同⼀种技术，很难⽤不同的语⾔或者语⾔不同版本开发不同功能；
- 难以升级技术栈
团队长期依赖一套相同的技术，单体架构使得采用新的框架和编程语言变的及其困难。
- 系统耦合性强，
⼀旦其中⼀个模块有问题，整个系统就瘫痪了；⼀旦升级其中⼀个模块，整个系统就停机了，难以扩展，不能做到按需扩展，只能是扩展整个系统。要上线必须⼀起上线，互相等待，⽆法快速响应需求，应用程序缺乏故障隔离机制，因为所有模块都运行在同一个进程当中。
- 服务不抗压、稳定性差
单体程序缺乏可靠性，用户量提升将导致频繁的系统故障和宕机。
- 功能越强、代码越混乱
电商系统本身功能过于庞大和复杂，于单体系统以至于任何一个开发者都很难以理解它的全部业务。这种极度的复杂度会形成恶性循环，功能越扩展，越难以下手。
- 难以维护
由于电商系统功能模块诸多过于庞大和复杂，无论是前期开发人员还是后期新聘技术人员都难以新增和维护系统功能，每一次更改都更容易出错且更改后其他人更难理解。
- 新版发布周期长，且容易出问题
代码库复杂，以至于一个更改可能引起的影响是未知的。开发团队分为多个小组时，当需要发布新版本的时候漫长的合并和测试时间非常长。
- 难以聘到技术人员
对于新手来说，看到了一坨庞大的代码，真心是无从下手，你让他接手或者干点活啥的，成本都更高的，且容易犯错。对于有代码情操的人，是会立刻走人的。
BizSpring 电商平台微服务架构
| 名称 | 组件 |
|---|---|
| 核心框架 | Springboot2、Spring Cloud、Spring Cloud Alibaba |
| 配置中心 | Nacos |
| 负载均衡 | Open Feign、Ribbon |
| 服务调用 | Feign |
| 服务容错 | Alibaba Sentinel |
| API网关 | Spring Cloud Gateway |
| 分布式事务 | Seata |
| 持久层框架 | MyBatis-plus |
| 高性能缓存 | Redis 、Redis Cluster |
| 分布式锁 | Redisson |
| 文件管理 | Alibaba oss /七牛云/腾讯cos/Minio |
| SMS短信 | Alibaba SMS |
| 安全 | JWT+oauth2 |
| 数据库 | Mysql8+ |
| API管理 | Swagger2 |
| 搜索引擎 | Elasticsearch 7.6.2 |
| JDK版本 | Java8+ |
| 管理平台框架 | Vue3+ElementPlus |
| 商家平台框架 | Uni-app(一套代码，多端发布) |
| 商城平台框架 | Uni-app(一套代码，多端发布) |
BizSpring商城的架构优势
BizSpring 电商平台使用业内最优秀的服务设计理念，将电商整套流程包括商品（product）、订单(order)，店铺(store)、营销(marketing)分别建设为不同的服务，降低了电商系统业务的耦合性、各服务可单独部署，用户量攀升的期，将业务压力较大的服务可建集群，进一步分担平台压力，顶级式提高架构的扩展性。于开发人员将能更简捷的自己业务范围的功能实现完善好。
Elasticsearch搜素引擎
Elasticsearch 为架构提供高效的搜索和聚合功能，支持实时数据处理，在商城数据写入时立即建立索引。支持多种查询语句，并能够快速地搜索和处理商品、订单、评论、售后的大量数据搜索。
Redis集群存储平台缓存
使用redis集群存储平台缓存，提升数据可靠性，提高读写能力，提高了系统运行中缓存的稳定性。
Nacos注册中心
BizSpring中服务启动后将自己注册到注册中心（Nacos），调用方调用时到注册中心查询可用的服务然后完成调用。注册中心的稳定性直接影响了整个微服务架构的可靠性，所以注册中心的选型至关重要。
OpenFeign Ribbon负载均衡
BizSpring 服务调用使用 OpenFeign 和 Ribbon 配合完成，OpenFeign实现服务调用Ribbon做到负载均衡。