前言
大家好，我是「周三不Coding」，今天我们一起聊一聊微服务。
想来第一次与微服务结缘是在我的第一个 SpringBoot 项目，我接触到了 Nacos 和 Gateway，从那时起，便对微服务产生了浓厚的兴趣，微服务的架构设计、服务拆分、服务治理等内容确实很有意思，这其实也是我选择从事后端开发的原因之一。
学了一段时间后，我想着是时候输出一些内容了，把微服务以更加通俗易懂的方式讲出来，让更多人轻松地了解学习微服务的核心内容。
话不多说，咱们进入今天的正题 —— 微服务的「前世今生」。
微服务架构演进
顺着互联网发展的历史，我们来捋一捋项目的架构演进。
为了使大家更能通俗易懂地理解，我们引入一个实际的停车场移动端/小程序项目开发场景，一步步地优化其项目架构。
也希望大家在看的时候，想一想，如果让你来实现这个项目，应该如何做如何设计？
大家可以从一个初创项目的角度出发，而不是一上来就直接考虑高大上的技术架构。因为技术永远依托于业务，服务于业务，技术选型本质是一个 Trade-off，我们需要以最小的金钱 / 技术 / 精力成本，换取局部 / 当前最优的实现方式。
从 0 到 1 的思考过程，使我们能够从现实的个人开发者角度看待问题，代入到真正的开发场景，加深对于微服务架构演进的理解。
为什么不用商城项目举例呢？因为商城项目太过泛滥，容易让大家产生思维定式，认为商城项目使用微服务架构是理所应当。
接下来，我们以 👦小T 的视角，看看他是如何从 0 到 1 开始他的停车场项目，并逐步优化为微服务架构～
单实例单数据库的单体架构
某一天，👦小T 在某停车场停车时，发现每次出这个停车场，都得先叫醒值班室睡得正香的保安大爷。扫二维码付款后，保安大爷按下按钮，道闸抬起后才能出去。
此时，👦小T 陷入了深深的沉思：为什么我不能将所有与人打交道的操作放入手机中呢？他仔细想了想，最后从多个需求中提取出了核心需求：
- 查看附近车场位置及其它详情信息
- 停车前支持预约指定车场
- 停车后支持在手机上扫码下订单、付款
- 查询记录
- 与停车场网络摄像头、道闸等硬件设备联调，实现智能入库出库
👦小T 本身也是计算机科班出身，做个小程序不在话下。他立马拉了两三个技术不错的朋友，和他一起做这个项目。
他在做技术选型时，想到之前某个叫什么「周三不Coding」的人说过，初创项目尽量不选用高大上的技术架构。于是，👦小T 选择了他最熟悉的技术栈：前端 Uniapp&Vue + 后端 Spring 全家桶 + MySQL 数据库。并且，他根据职责单一的设计模式，将车场详情功能、预约功能、订单功能、支付功能等拆分到了不同的模块，尽可能地降低耦合性，考虑的算是很周到啦哈哈哈～
做好技术选型后，👦小T 便开始方案设计、数据库设计、实现代码等一系列操作，
很快啊，👦小T 完成了停车场项目的第一个版本，并将其部署到了他白嫖的 2 核 2 G 云服务器上，并顺利地上线了小程序和后台管理系统网站～
做完后的他也没闲着，赶快把项目的架构画了出来，便于日后项目升级时进行 review（👦小T果然深思熟虑～）
多实例单数据库的单体架构
👦小T在上线之前，联系了很多实体商场、停车场的老板，经过一番软磨硬泡，终于有几个老板愿意尝试用他的系统。
在 👦小T 的一番努力下，车场用户数越来越多，每天 DAU 上千甚至过万。但随着小程序流量越来越大，预约或付款时开始出现访问迟缓的问题。
👦小T 很快便意识到这一性能瓶颈。为了尽快解决，他升级了服务器的配置。虽然问题得到了一定的缓解，但是 👦小T 目光更加长远，他想控制整个城市的车场业务。为了长期的发展，他综合考虑了经济成本与可扩展性，决定不再纵向升级，而是采取横向扩容的方式，缓解单节点压力。
为了实现分担不同节点压力，👦小T 又在这些服务器实例智商，引入了负载均衡层。
这么一番骚操作下来，性能问题立马得到了解决，赢来了初期用户的一致好评。这次，👦小T 再一次画下了升级后的系统架构图。
多实例多数据库的单体架构
车场小程序持续运作了一年多的时间，用户数量、预约数量、订单数量越来越多，而且又有好几个停车场加入了 👦小T 的旗下，项目越做越大。总数据量逐渐达到了千万级别。此时，性能瓶颈问题又出现了。👦小T 发现这次即使再次进行横向扩容，也无济于事，用户的响应时间仍然居高不下，惹来差评一片。👦小T 有点慌，但他也立马定位到了问题所在 —— 数据库。
👦小T 立马对数据库架构进行改进，他想起之前看到过一篇文章里说到，读写分离是最低廉的解决数据库性能瓶颈的方式。
说干就干，他立马搭建起了多个数据库：
- 一个主数据库专门用于处理写请求。当用户进行更新、删除等写操作时，请求打到这台主数据库。
- 其他从数据库处理读请求。当用户进行读操作时，请求平均打散到这些从数据库中。
聪明的 👦小T 也想到，为了保证主从数据库的一致性，主数据定期将数据同步到从数据库中。
虽然问题得到了解决，但思考长远的 👦小T 担心不久后再次出现这种类似的问题，他干脆一不做二不休，咬咬牙引入了 Redis 缓存，存储用户的订单数据、车场经纬度数据，加快响应速度。
按照惯例，每次升级后，👦小T 都会画出对应的系统架构图。（👍 爆赞）
SOA架构
随着项目越做越大，嗅觉敏锐的 👦小T 逐渐发现了新的市场需求。他竟然想在他的小程序中卖货！做一个车品商城！这么一来，小程序功能数量翻倍，但他人手不太够了。他又招了几个人，一起搭建这个简单的商城。
但是做着做着，他发现不对劲。每次车品商城进行测试时，都需要整体测试、并重新构建和部署，严重影响到了核心车场功能的维护与开发，压根没办法进行敏捷开发。于是，他和初创团队的人开始考虑着手进行项目重构，将两个项目分开，项目之间用消息总线 ESB 进行通信。团队也被拆分为两个小组，开发进程互不影响。
- 消息总线 ESB：负责协议转换、消息路由、负载均衡
就这样，👦小T 团队再次向前迈进了一步，从原先的单体架构升级到了 SOA 架构。
微服务架构
👦小T的车场小程序越做越大，在他团队几年的努力经营下，几乎实现了他当初的野心，引入了该城市的大多数车场。但他仍然不满足于此，他想要将他的停车场小程序更加现代化，他认为其它应用有的他也要有！于是，他引进了推荐系统，并且添加了很多额外的功能，如：优惠券、系统通知、加油站、电动车充电、洗车等多个业务。
项目逐渐变得越来越庞大，开发人员也越来越多，团队达到了大几十人。这时，👦小T 意识到原来的服务拆分粒度太 “粗”，而且原先系统的所有流量都会经过 ESB 进行分发，造成系统的可用性下降，甚至在流量峰值出现部分节点宕机的情况，这是一大隐患。
于是，👦小T 又开始着手进行项目改进。首先，他决定进一步拆分团队，拆分服务，将原先的车场服务与车品商城服务又进行了拆分，拆出了用户服务、商品服务、车场服务、订单服务、支付服务、优惠券服务、推荐服务等 10 余个服务。为了治理这些服务，他的团队引入了微服务架构，用微服务网关与注册中心代替原有的消息总线，并采用分布式部署。除此之外，一系列微服务治理框架与 Devops 自动化运维部署流程也随之引入，每一个微服务均通过容器化方式部署上线。
（可恶的 👦小T 并没有告诉我具体内容，他说等他有空再问他～
总结
故事讲完了，相信大家一定对微服务架构的演进，有了更加深刻的认识。
今天，我们从一个车场项目的角度出发，分析了为什么要进行架构升级，并给出了每个架构的示意图。
车场项目其实是我之前做的小程序，之后我会将它优化为一个真正的微服务项目并开源～
现在我们来总结一下各个架构的特点：
- 单体架构：所有功能都集中在同一个项目内，统一测试，统一部署，牵一发而动全身，适合初创项目进行试错，不适合大型商业项目。
- 在此基础做的纵向升级、横向扩容、一主多从等仍然属于单体架构，因为其仍然是单一服务、单一项目。
- SOA 架构：进行了初步的服务拆分，但是服务拆分的粒度较粗，并且没有引入服务治理组件，流量集中于消息总线。
- 微服务架构：是 SOA 架构的升级，基本沿用了 SOA 的思想，但是服务拆分粒度更细，并且引入了服务治理组件，结合流行的容器化技术，实现 Devops 自动化部署与运维。
- Devops 总是与微服务一起出现，因为 Devops 带来的是敏捷开发、更快交付，而微服务通常由各个小团队负责开发，迭代周期更快、更敏捷。
- CI/CD 是 Devops 的核心。
其实，仔细想想微服务架构也就那么回事，还是文章开头提到的那句话，技术永远服务于业务，正是由于互联网的扩张与业务的膨胀，才会倒逼技术架构进行升级迭代，最后有了今天的微服务。这也提醒着作为技术开发的我们，需要时刻关注业务，根据业务来决定我们的技术走向，去适应业务的发展。
那么今天的微服务内容就到这里啦，大家先对微服务架构有一个基本的理解，至于本篇文章提到的负载均衡、服务治理、容器化技术等内容，我会在之后的文章中进行更详细的讲解～
大家觉得有用的话请点个赞并持续关注呀，下期再见～
