学习目标
- 能够说出单体架构与微服务架构的优缺点
- 能够了解分布式架构和云原生架构
- 能够搭建黑马商城项目环境
- 能够测试黑马商城项目的业务流程
- 能够说出商城项目的业务模块及技术架构
- 能够创建商品服务、购物车服务
- 能够使用RestTemplate实现远程调用
- 能够说出服务注册与发现流程
- 能够使用Nacos实现服务注册与发现
- 会使用OpenFeign实现远程调用
- 能够抽取API工程
搭建环境
在开始本课程之前请参考“ 环境搭建” 文档搭建黑马商城项目运行环境，最终将黑马商城项目跑起来。
黑马商城项目是一个单体项目，基于Spring Boot开发，数据库使用MySQL。
微服务框架阶段的课程以黑马商城项目作为案例驱动，使用微服务架构去构建黑马商城项目，并解决其中出现的各种问题。
1.认识微服务
之前我们学习的项目一是单体项目，可以满足小型项目或传统项目的开发。而在互联网时代，越来越多的公司采用微服务架构。
这一章我们从单体架构的优缺点来分析，看看开发大型项目采用单体架构存在哪些问题，而微服务架构又是如何解决这些问题的。
1.1 单体架构
单体架构（monolithic structure）：整个项目只有一个工程，所有业务模块都在这一个工程中，并采用一个数据库，如下图：
项目部署时需要对所有模块一起编译、打包，打成一个jar包或war包，如下图：
当项目规模较小时，这种模式上手快，部署、运维也都很方便，因此早期很多小型项目都采用这种模式。
优点：
1.整个项目只有一个工程，结构简单，开发周期短。
2.部署简单。
缺点：
随着项目的规模越来越大，团队开发人员也不断增加，单体架构就呈现出越来越多的问题：
1.团队协作成本高：试想一下，你们团队数十个人同时协作开发同一个Java工程，由于所有模块都在一个工程中，最终要把所有模块代码合并到一个分支，代码冲突率增加，团队协作成本增加。
2.系统发布效率低：任何模块变更都需要发布整个系统，任何一处出现问题都会导致发布失败，往往一次发布需要数十分钟甚至数小时。
3.扩展困难，在单体架构中，所有功能紧密集成，这意味着当某一部分（如订单处理）需要更多资源时，整个系统必须一起扩展。例如，在双十一期间订单量激增，不仅订单接口需要更多支持，支付接口也是如此。但由于采用了单体架构，我们不能单独扩展这些服务，而是需要增加整个系统的资源或者部署更多服务器节点，这可能会导致其他部分资源的浪费。
如下图，单体架构通常用集群的方式提高系统的能力。
应用场景：
单体架构适合小型项目。
1.2 微服务架构
随着软件业的兴起，以及互联网的发展，对于一些大型的软件项目，单体架构已不能适应需求，软件架构经过的几代的演变，如今对于大型项目更多的会采用微服务架构。
微服务架构，将整个项目分为多个服务，每个服务是一个工程，通常是根据业务模块去划分[准确来说是DDD领域模型(可参见：领域驱动设计:软件核心复杂性应对之道)]，比如：电商项目如果按微服务架构开发就需要独立出来：商品服务、用户服务、交易服务、支付服务等多个服务，这些服务最主要的是要做到边界清晰，单一职责，服务的功能范围可以很小，所以称为微服务架构。
例如，黑马商城项目，我们就可以把商品、用户、购物车、交易等模块拆分，交给不同团队开发，并独立部署：
思考以下几个问题：
①商品包含：新增、上架、下架、更新、删除、查找，还有关联的分类信息维护，还有SPU&SKU的维护，请问是都放在一个模块，还是多个模块呢？
②支付和交易的关系：主要是对接微信、支付宝、银联等，是否应该和订单模块放在一起呢？
③购物车服务：只有加入、清空功能吗？商品库存没有或下架后怎么处理？用户未登录怎么加入购物车？
微服务架构的一些特点：
- 单一职责原则：每个微服务专注于执行单一业务功能，并且尽量减少对外部服务的依赖，实现高内聚低耦合。
- 团队自治：每个微服务通常由一个小团队（通常不超过10人，即所谓的“两块披萨团队”）负责，包括开发、测试、部署和运维等全过程。
- 服务自治：每个微服务都是独立的，可以独立部署、扩展和维护，拥有自己的数据库实例，以确保服务之间的隔离性和最小化相互影响。
以上可以简单理解为：微服务架构就是由若干小的单体系统组成的。
单体架构存在的问题可以通过采用微服务架构来解决： - 问题：团队协作成本高
ⅰ. 解决：通过服务拆分，每个服务的代码量相对较小，每个服务通常由1至3名开发者维护，显著降低了协作成本。 - 问题：系统发布效率低
ⅰ. 解决：每个服务都是独立部署的，当某个服务需要更新时，只需对该服务进行打包和部署，提高了发布效率并减少了风险。 - 问题：系统可用性差
ⅰ. 解决：通过将服务独立部署，并确保每个服务都有自己的资源（如独立的数据库），可以有效防止一个服务的问题影响到其他服务。 - 问题：扩展困难
ⅰ. 解决：微服务架构允许根据实际需求有针对性地对特定服务进行扩展或升级，而不需要对整个系统进行扩展，提高了资源利用率和灵活性。
根据上述内容，我们可以总结出微服务架构的优点和缺点如下：
优点 - 有利于项目的扩展与维护
a. 服务之间解耦，易于理解和维护。
b. 每个服务可以独立扩展，提高资源利用效率。
缺点 - 项目复杂性增加
a. 每个服务需要独立的设计、开发和测试，增加了项目的复杂度。
b. 管理多个服务间的依赖关系变得更加困难，例如交易服务可能依赖于商品服务和用户服务。 - 运维成本增加
a. 需要管理和监控多个服务实例，增加了运维的复杂度。
b. 每个服务都需要单独部署、监控和维护，这可能需要更多的自动化工具和技术支持。
综上所述，虽然微服务架构带来了更好的扩展性和维护性，但也引入了额外的复杂性和运维挑战。
应用场景：
微服务架构是适合大型项目
很多人还是会顾虑：不就是把几个包里面的代码拆分拆分吗，为什么非要拆出去呢？
①流量分发：比如订单流量高，一个工程的话，是不是会影响个人中心的登录呢
②故障解耦：订单流量大，容易故障，所以订单挂了不能影响别的服务
③降低成本：订单高QPS TPS给干个4台机器，商品CRUD就一台就好
④管理方便：发布的时候，小应用[个人中心、积分中心]就不用咋管，大应用[订单中心、支付中心]多操心
1.3. 扩展
AI:分布式架构是什么？
分布式架构是指由多个独立计算机组成的一个系统，即一个系统由多个部分组成，每个部分分别部署在不同的计算机上，这些计算机通过网络互相连接，并且能够协同工作以完成共同的任务。
早期的分布式架构是将整个项目拆分成多个系统，相比微服务架构划分服务的粒度是粗的，比如：一个电商项目包括了认证系统，门户，主站等。
发展到微服务架构会将一个项目划分为多个微服务，例如电商项目包括：商品服务、用户服务、认证服务、订单服务等微服务。
所以，微服务架构就是一种分布式架构，将各个服务分布在不同的计算机上，这些服务之间通过协作去完成业务流程。
下面分享几个微服务架构图：
AI:云原生架构是什么？
云原生(Cloud Native)应用程序是为云环境而设计的，能够利用云平台的弹性、可扩展性和服务导向的特性。云原生架构的核心理念包括容器化、微服务、持续交付和DevOps实践。
云原生架构就可以理解为微服务架构的项目使用云平台（阿里云、腾讯云等）去构建。
主要特征
- 容器化：
a. 应用程序运行在容器内，如Docker容器，以便于标准化、隔离和移植。
b. 容器化提供了轻量级的虚拟化，使应用程序能够在任何环境中一致地运行。 - 微服务：
a. 将应用程序分解为一组小型、独立的服务，每个服务都实现了特定的功能。
b. 微服务可以独立部署、扩展和更新，提高了应用程序的可维护性和灵活性。 - 持续交付：
a. 采用自动化工具和流程来频繁地部署和更新应用程序。
b. 通过持续集成和持续部署（CI/CD）管道实现快速迭代和反馈循环。 - DevOps文化：
a. 强调开发人员和运维团队之间的紧密合作。
b. 通过自动化和协作工具促进敏捷开发、快速部署和持续改进。 - 弹性与可扩展性：
a. 设计应用程序以适应不断变化的工作负载，能够自动伸缩资源。
b. 利用云平台提供的服务，如自动扩展、负载均衡和冗余机制，以保证高可用性和性能。
1.4 面试题
你们的项目为什么要用微服务架构？
2 构建微服务工程
2.1 熟悉黑马商城
2.1.1 运行单体项目
接下来，我们就一起使用微服务架构去构建黑马商城项目，并解决其中出现的各种问题。
本项目是为教学需求而设计的简化版项目，在后期的互相网项目阶段我们会接触完整的电商项目。
2.1.2. 熟悉项目
2.1.2.1 登录功能
首先来看一下登录业务流程，下图黄色框内。
登录入口在com.hmall.controller.UserController中的login方法：
2.1.2.2 搜索商品
在首页搜索框输入关键字，点击搜索即可进入搜索列表页面：
该页面会调用接口：/search/list，对应的服务端入口在com.hmall.controller.SearchController中的search方法：
这里目前是利用数据库实现了简单的分页查询。
2.1.2.3 购物车
在搜索到的商品列表中，点击按钮加入购物车，即可将商品加入购物车：
加入成功后即可进入购物车列表页，查看自己购物车商品列表：
同时这里还可以对购物车实现修改、删除等操作。
相关功能全部在com.hmall.controller.CartController中：
2.1.2.4 下单
在购物车页面点击结算按钮，会进入订单结算页面：
点击提交订单，会提交请求到服务端，服务端做3件事情：
● 创建一个新的订单
● 扣减商品库存
● 清理购物车中商品
业务入口在com.hmall.controller.OrderController中的createOrder方法：
2.1.2.5 支付
下单完成后会跳转到支付页面，目前只支持余额支付：
在选择余额支付这种方式后，会发起请求到服务端，服务端会立刻创建一个支付流水单，并返回支付流水单号到前端。
当用户输入用户密码，然后点击确认支付时，页面会发送请求到服务端，而服务端会做几件事情：
● 校验用户密码
● 扣减余额
● 修改支付流水状态
● 修改交易订单状态
