目录
[单体架构 ：](#单体架构 ：)
一、后端项目的导入以及启动服务的配置
将资料当中的项目下载下来后用idea打开；按Alt+8打开Services面板，按照指示添加启动项：
找到Spring Boot：
点击后应该会在services中出现hmall的启动项：
不过这里我并没有出现该项但是弹出了一个弹窗要求我选择启动类，但是idea并不能找到该启动类；这个问题在公司实习时有遇到过，项目导入进来配置启动服务的时候也是找不到启动类，当时是因为没有配置好jdk版本，根据这个思路优先排查该问题，到Project Structure、Settings当中进行基础配置（包括jdk版本、maven配置、utf-8编码）完成后再根据步骤进行配置发现跟图片当中一样，根据下面的提示手动输入local完成配置
我们还需要对这个启动项做简单配置，在HMallApplication上点击鼠标右键，会弹出窗口，然后选择Edit Configuration：
在弹出窗口中配置SpringBoot的启动环境为local：
点击OK配置完成。接下来就可以运行了！
启动完成后，试试看访问下 http://localhost:8080/hi 吧！
效果展示：
二、前端nginx项目的导入
将资料当中前端项目下载下来后，将nginx项目放到没有中文的目录下，在nginx项目目录下打开cmd面板，输入start nginx.exe启动前端项目（或者直接双击nginx.exe文件），之后访问http://localhost:18080
效果展示：
三、linux虚拟机MySql安装
由于虚拟机镜像还在下载，所以暂时无法完成配置，下载完成后补上该部分 //TODO
四、单体架构与微服务
单体架构：
单体架构（monolithic structure）：顾名思义，整个项目中所有功能模块都在一个工程中开发；项目部署时需要对所有模块一起编译、打包；项目的架构设计、开发模式都非常简单。
当项目规模过大时，模块越来越多，代码之间的耦合程度必然提升；代码量一大，编译时间过长，这会导致部署时效率低下；此外在多线程环境下，当一个模块被多线程访问时，其他模块会因为tomcat的资源被占用而导致耗时增加
在上述问题中，前两点相信大家在实战过程中应该深有体会。对于第三点系统可用性问题，很多同学可能感触不深。接下来我们就通过黑马商城这个项目，给大家做一个简单演示。
首先，我们修改hm-service模块下的com.hmall.controller.HelloController中的hello方法，模拟方法执行时的耗时：
接下来，启动项目，目前有两个接口是无需登录即可访问的：
-
http://localhost:8080/hi -
http://localhost:8080/search/list
经过测试，目前/search/list 是比较正常的，访问耗时在30毫秒左右。
接下来，我们假设/hi这个接口是一个并发较高的热点接口，我们通过Jemeter来模拟500个用户不停访问。在课前资料中已经提供了Jemeter的测试脚本：
导入Jemeter并测试：
这个脚本会开启500个线程并发请求http://localhost/hi这个接口。由于该接口存在执行耗时（500毫秒），这就服务端导致每秒能处理的请求数量有限，最终会有越来越多请求积压，直至Tomcat资源耗尽。这样，其它本来正常的接口（例如/search/list）也都会被拖慢，甚至因超时而无法访问了。
我们测试一下，启动测试脚本，然后在浏览器访问http://localhost:8080/search/list这个接口，会发现响应速度非常慢：
如果进一步提高/hi这个接口的并发，最终会发现/search/list接口的请求响应速度会越来越慢。
可见，单体架构的可用性是比较差的，功能之间相互影响比较大。
当然，有同学会说我们可以做水平扩展。
此时如果我们对系统做水平扩展，增加更多机器，资源还是会被这样的热点接口占用，从而影响到其它接口，并不能从根本上解决问题。这也就是单体架构的扩展性差的一个原因。
而要想解决这些问题，就需要使用微服务架构了。
微服务：
微服务架构，首先是服务化，就是将单体架构中的功能模块从单体应用中拆分出来，独立部署为多个服务。同时要满足下面的一些特点：
-
单一职责：一个微服务负责一部分业务功能，并且其核心数据不依赖于其它模块。
-
团队自治：每个微服务都有自己独立的开发、测试、发布、运维人员，团队人员规模不超过10人（2张披萨能喂饱）
-
服务自治：每个微服务都独立打包部署，访问自己独立的数据库。并且要做好服务隔离，避免对其它服务产生影响
例如，黑马商城项目，我们就可以把商品、用户、购物车、交易等模块拆分，交给不同的团队去开发，并独立部署：
那么，单体架构存在的问题有没有解决呢？
-
团队协作成本高？
- 由于服务拆分，每个服务代码量大大减少，参与开发的后台人员在1~3名，协作成本大大降低
-
系统发布效率低？
- 每个服务都是独立部署，当有某个服务有代码变更时，只需要打包部署该服务即可
-
系统可用性差？
- 每个服务独立部署，并且做好服务隔离，使用自己的服务器资源，不会影响到其它服务。
五、SpringCloud
SpringCloud是目前最全面的微服务组件的集合，而且SpringCloud依托于SpringBoot，继承了其强大的自动装配能力，大大降低了项目构建的成本与难度，使得微服务能够进入大众视野从而被广泛应用
目前SpringCloud最新版本为2022.0.x版本，对应的SpringBoot版本为3.x版本，但它们全部依赖于JDK17，目前在企业中使用相对较少。
因此，我们推荐使用次新版本：Spring Cloud 2021.0.x以及Spring Boot 2.7.x版本。
