学习目标
- 能够说出单体架构与微服务架构的优缺点
- 能够了解分布式架构和云原生架构
- 能够搭建黑马商城项目环境
- 能够测试黑马商城项目的业务流程
- 能够说出商城项目的业务模块及技术架构
- 能够创建商品服务、购物车服务
- 能够使用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. 每个服务都需要单独部署、监控和维护，这可能需要更多的自动化工具和技术支持。
综上所述，虽然微服务架构带来了更好的扩展性和维护性，但也引入了额外的复杂性和运维挑战。
