1. 聊聊微服务这回事儿

咱们今天从最基础的 “单体架构” 说起，看看为啥做大型项目（包括咱们自己练手的黑马商城）时它不太行，而微服务又是怎么救场的。保证说得明明白白，就算你从没听过微服务也能懂～

1.1. 啥是单体架构？

说白了，单体架构就是 “一锅烩”：整个项目（比如咱们的黑马商城）的所有功能 —— 商品展示、用户登录、购物车、下单支付 —— 全塞在一个工程里，开发、打包、部署全绑在一起，简单粗暴得很。

刚开始项目小时，这玩意儿是真方便！就像咱们刚开始搭黑马商城，功能少、就自己一个人开发，上手快，改完代码点一下运行就搞定，部署也简单，就像搭个小帐篷，一会儿就弄好。

但架不住项目越做越大啊！假设咱们想给黑马商城加更多功能，甚至拉上朋友一起开发，这 “一锅烩” 就出问题了：

团队协作像打仗：哪怕就两三个人一起开发黑马商城，所有代码都在一个项目里，你改商品模块、我改订单模块，改着改着就可能改到同一个文件，最后合并代码时，光解决冲突就能把人逼疯！
发布新版本太费劲：哪怕就改了商品详情页的一个按钮颜色，整个黑马商城都得重新打包、部署。就像你只想换件 T 恤，结果得把全身衣服都脱下来重新穿一遍，还总担心穿错，一次发布搞半天是常事。
一个模块崩了，全商城躺枪：所有功能都捆在一个服务里，就像一群人挤在一个救生圈上 —— 要是商品搜索功能突然被很多人访问（比如搞促销），占了太多服务器资源，那用户登录、下单这些功能就可能卡得动不了。

前两个问题估计自己多写几行代码就有体会，第三个 “系统可用性” 的坑，咱们拿咱们的黑马商城具体说说：

咱们先给黑马商城的一个接口加个 “小测试”—— 让 /hi 接口干活变慢（比如每次响应要等 500 毫秒），路径在 hm-service模块下的com.hmall.controller.HelloController 里，很好找。

然后启动项目，现在有两个不用登录就能访问的接口：

接下来模拟个场景：假设 /hi 这个接口突然成了 “网红”（比如被误当成某个活动入口），用 Jemeter（咱们课前资料里有脚本）模拟 500 个人同时狂点它。结果呢？这个慢悠悠的接口处理不过来，请求越堆越多，最后把服务器资源全占满了。

这时候你再去访问那个正常的商品搜索接口 /search/list，我的天，响应速度慢得像蜗牛爬！要是再加点并发，直接就超时打不开了 —— 就因为一个接口 “堵车”，整个黑马商城都被拖垮了。

有人说：”那我多开几台服务器运行黑马商城不就行了？” 没用啊！因为它们还是捆在一起的，新服务器的资源照样会被那个 “堵车又热门” 的接口霸占，商品搜索、用户登录该卡还是卡。

微服务的核心思路就一个字：拆！把原来的黑马商城大单体拆成一个个独立的小服务，比如商品服务专门管商品展示和搜索，用户服务专门管登录注册，购物车服务、订单服务各自独立，每个小服务单独部署、单独干活。

而且这些小服务得遵守几个规矩：

比如咱们的黑马商城，拆成 “商品服务”、”用户服务”、”购物车服务”、”订单服务” 后，谁也别管谁。

那之前单体架构的坑，微服务能填上吗？必须能！

所以说，微服务就是为了让项目（哪怕是咱们自己的练手项目）能从小做大、灵活扩展而生的，现在大公司基本都这么玩。你可能听过 “分布式架构”，其实微服务就是分布式架构里最靠谱的一种玩法。

当然啦，天下没有免费的午餐。拆成微服务后，新问题也来了：

别担心，这些问题咱们后面慢慢学，一步步解决～

微服务拆完后，刚才说的那些新问题总得解决吧？SpringCloud 就是 Java 圈里最流行的 “微服务工具箱”—— 里面全是现成的工具，能帮我们搞定这些麻烦事，比如让服务之间能互相调用、能找到对方、能互不干扰。

而且它跟 SpringBoot 是好兄弟，用起来特别简单（自动配置懂吧？不用写一堆复杂代码）。对咱们这种自己练手的学习者来说，简直是救星，不用自己费劲造轮子。

SpringCloud 官网在这儿，想深入研究的可以看看。

不过版本这块得注意：最新的 SpringCloud（2022.0.x）得配 SpringBoot 3.x，还得用 JDK17，现在咱们练手项目里用的还不多。咱们稳妥点，用次新的：SpringCloud 2021.0.x + SpringBoot 2.7.x，这对组合目前最主流，资料也多。

另外，阿里的 SpringCloudAlibaba 也是个好东西，现在也算 SpringCloud 家族的一员了，功能实用，咱们后面练手时会用到它的一些工具。

对了，咱们黑马商城的父工程 hmall 里已经配好这些依赖了，版本也都调好，后面直接用就行，不用自己费劲选版本啦~