跳至主要內容

从根儿上学习微服务01:微服务的“前世今生”

ltyzzz约 3191 字大约 11 分钟

前言

大家好,我是「周三不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 云服务器上,并顺利地上线了小程序和后台管理系统网站~

img
img

做完后的他也没闲着,赶快把项目的架构画了出来,便于日后项目升级时进行 review(👦小T果然深思熟虑~)

image-20230705075332246
image-20230705075332246

多实例单数据库的单体架构

👦小T在上线之前,联系了很多实体商场、停车场的老板,经过一番软磨硬泡,终于有几个老板愿意尝试用他的系统。

在 👦小T 的一番努力下,车场用户数越来越多,每天 DAU 上千甚至过万。但随着小程序流量越来越大,预约或付款时开始出现访问迟缓的问题。

👦小T 很快便意识到这一性能瓶颈。为了尽快解决,他升级了服务器的配置。虽然问题得到了一定的缓解,但是 👦小T 目光更加长远,他想控制整个城市的车场业务。为了长期的发展,他综合考虑了经济成本与可扩展性,决定不再纵向升级,而是采取横向扩容的方式,缓解单节点压力。

为了实现分担不同节点压力,👦小T 又在这些服务器实例智商,引入了负载均衡层。

这么一番骚操作下来,性能问题立马得到了解决,赢来了初期用户的一致好评。这次,👦小T 再一次画下了升级后的系统架构图。

image-20230705080042520
image-20230705080042520

多实例多数据库的单体架构

车场小程序持续运作了一年多的时间,用户数量、预约数量、订单数量越来越多,而且又有好几个停车场加入了 👦小T 的旗下,项目越做越大。总数据量逐渐达到了千万级别。此时,性能瓶颈问题又出现了。👦小T 发现这次即使再次进行横向扩容,也无济于事,用户的响应时间仍然居高不下,惹来差评一片。👦小T 有点慌,但他也立马定位到了问题所在 —— 数据库。

👦小T 立马对数据库架构进行改进,他想起之前看到过一篇文章里说到,读写分离是最低廉的解决数据库性能瓶颈的方式。

说干就干,他立马搭建起了多个数据库:

  • 一个主数据库专门用于处理写请求。当用户进行更新、删除等写操作时,请求打到这台主数据库。
  • 其他从数据库处理读请求。当用户进行读操作时,请求平均打散到这些从数据库中。

聪明的 👦小T 也想到,为了保证主从数据库的一致性,主数据定期将数据同步到从数据库中。

虽然问题得到了解决,但思考长远的 👦小T 担心不久后再次出现这种类似的问题,他干脆一不做二不休,咬咬牙引入了 Redis 缓存,存储用户的订单数据、车场经纬度数据,加快响应速度。

按照惯例,每次升级后,👦小T 都会画出对应的系统架构图。(👍 爆赞)

image-20230705080729889
image-20230705080729889

SOA 架构

随着项目越做越大,嗅觉敏锐的 👦小T 逐渐发现了新的市场需求。他竟然想在他的小程序中卖货!做一个车品商城!这么一来,小程序功能数量翻倍,但他人手不太够了。他又招了几个人,一起搭建这个简单的商城。

但是做着做着,他发现不对劲。每次车品商城进行测试时,都需要整体测试、并重新构建和部署,严重影响到了核心车场功能的维护与开发,压根没办法进行敏捷开发。于是,他和初创团队的人开始考虑着手进行项目重构,将两个项目分开,项目之间用消息总线 ESB 进行通信。团队也被拆分为两个小组,开发进程互不影响。

  • 消息总线 ESB:负责协议转换、消息路由、负载均衡

就这样,👦小T 团队再次向前迈进了一步,从原先的单体架构升级到了 SOA 架构

image-20230705081747145
image-20230705081747145

微服务架构

👦小T的车场小程序越做越大,在他团队几年的努力经营下,几乎实现了他当初的野心,引入了该城市的大多数车场。但他仍然不满足于此,他想要将他的停车场小程序更加现代化,他认为其它应用有的他也要有!于是,他引进了推荐系统,并且添加了很多额外的功能,如:优惠券、系统通知、加油站、电动车充电、洗车等多个业务。

项目逐渐变得越来越庞大,开发人员也越来越多,团队达到了大几十人。这时,👦小T 意识到原来的服务拆分粒度太 “粗”,而且原先系统的所有流量都会经过 ESB 进行分发,造成系统的可用性下降,甚至在流量峰值出现部分节点宕机的情况,这是一大隐患。

于是,👦小T 又开始着手进行项目改进。首先,他决定进一步拆分团队,拆分服务,将原先的车场服务与车品商城服务又进行了拆分,拆出了用户服务、商品服务、车场服务、订单服务、支付服务、优惠券服务、推荐服务等 10 余个服务。为了治理这些服务,他的团队引入了微服务架构,用微服务网关注册中心代替原有的消息总线,并采用分布式部署。除此之外,一系列微服务治理框架Devops 自动化运维部署流程也随之引入,每一个微服务均通过容器化方式部署上线。

(可恶的 👦小T 并没有告诉我具体内容,他说等他有空再问他~

image-20230705083445392
image-20230705083445392

总结

故事讲完了,相信大家一定对微服务架构的演进,有了更加深刻的认识。

车场项目其实是我之前做的小程序,之后我会将它优化为一个真正的微服务项目并开源~

今天,我们从一个车场项目的角度出发,分析了为什么要进行架构升级,并给出了每个架构的示意图。

现在我们来总结一下各个架构的特点:

  • 单体架构:所有功能都集中在同一个项目内,统一测试,统一部署,牵一发而动全身,适合初创项目进行试错,不适合大型商业项目。
    • 在此基础做的纵向升级、横向扩容、一主多从等仍然属于单体架构,因为其仍然是单一服务、单一项目。
  • SOA 架构:进行了初步的服务拆分,但是服务拆分的粒度较粗,并且没有引入服务治理组件,流量集中于消息总线。
  • 微服务架构:是 SOA 架构的升级,基本沿用了 SOA 的思想,但是服务拆分粒度更细,并且引入了服务治理组件,结合流行的容器化技术,实现 Devops 自动化部署与运维。
    • Devops 总是与微服务一起出现,因为 Devops 带来的是敏捷开发、更快交付,而微服务通常由各个小团队负责开发,迭代周期更快、更敏捷。
    • CI/CDDevops 的核心。

其实,仔细想想微服务架构也就那么回事,还是文章开头提到的那句话,技术永远服务于业务,正是由于互联网的扩张与业务的膨胀,才会倒逼技术架构进行升级迭代,最后有了今天的微服务。这也提醒着作为技术开发的我们,需要时刻关注业务,根据业务来决定我们的技术走向,去适应业务的发展。

那么今天的微服务内容就到这里啦,大家先对微服务架构有一个基本的理解,至于本篇文章提到的负载均衡、服务治理、容器化技术等内容,我会在之后的文章中进行更详细的讲解~

大家觉得有用的话请点个赞并持续关注呀,下期再见~