F版本SpringCloud1—大白话为啥要有微服务?啥是微服务?SpringCloud为什么有那么多组件?

编程

前言

  • 为什么要有微服务呢?
  • 什么是微服务?
  • SpringCloud 中为什么会有那么多的组件?

......

作为SpringCloud教程的第一篇,不讲解具体的技术使用,通过一个通俗易懂的小故事,来解决这些疑惑。

本文分为三个部分:

  1. 架构的演变,即为什么会出现微服务技术
  2. 什么是微服务,即微服务的标准概念
  3. 微服务要解决什么问题,即微服务中那么多的组件都是干嘛的

从单体到微服务「小故事讲解架构演变」

新技术会站在老技术的基础上,解决老技术出现的问题的同时,进行迭代和演化

这年,可能是十年前也可能是十五年前,小鹿入职了一家处于萌芽期的电商公司—并夕夕商城。

这个时候公司初创,人少,事儿少,用户少,当然了老板的钱也少,本着多快好省的信念,作为公司唯一开发工程师小鹿,跌跌撞撞的开发了一款能用的商城网站,架构如下:

网站整体非常的简单,在没什么用户的现阶段也是非常的好用,而且还非常的省心,但是没有想到的是,公司业务越来越好,用户量是越来越大,随着访问量的不断增大,项目经常卡死故障。

于是老板大手一挥,指引商城技术改革,emmm,还加钱招人,又招了小羊,小马数位同事,对并夕夕商城进行升级优化。

经过激烈的讨论,优化方向为:增加应用负载能力,即负载均衡,应用服务器集群

于是,噔噔蹬蹬,新的架构出现了

负载均衡

增加负载均衡之后,应用服务器不再是系统的瓶颈了,可以灵活的随着访问量增大的同时增加应用服务器集群的数量。

但是,时间长了,数据库出问题了,由于数据量的不断增加,再加上促销,日志等新业务模块的出现,数据库存取出现了问题,一个数据库能够承受的人生压力毕竟是有限的。

于是老板大手一挥,指引商城技术改革,emmm,又加钱招人,又招了小牛,小明等数位同事,对并夕夕商城进行升级优化。

经过激烈的讨论,优化方向为:数据库读写分离

于是,噔噔蹬蹬,新的架构出现了

读写分离

通过将数据库进行集群,读写分离,让数据库能够承受的压力得到大幅提升,但是随着对业务的进一步深根细作,新的问题暴露了。

  • 新增加的商品搜索功能,使用数据库的模糊查询,效率低下,且查询结果不准确
  • 不同模块的数据访问热度不一样,有部分数据,例如首页数据,需要频繁的进行查询展示,每次都查询数据库效率太低

    ......

于是老板大手一挥,指引商城技术改革,emmm,又加钱招人,又招了数位同事,对并夕夕商城进行升级优化。

经过激烈的讨论,优化方向为:引入全文搜索,Redis等技术。

于是,噔噔蹬蹬,新的架构出现了

ES+Redis集群

新的架构一切看上去都是这么完美的亚子,团队众人终于可以过个好年了。

岁月静好。

随着并夕夕商城不断壮大,公司迎来了风投,风投两个亿,于是商城发展的更快了,新的问题出现了。

什么问题呢?

  • 不同的业务模块之间代码耦合度太高,一个模块出问题,整个项目宕机
  • 维护困难,每次代码更新都要对所有的服务器进行重新的部署
  • 有些业务模块的用户访问量实在太小,没有必要部署在多台服务器上

    ......

于是老板大手一挥,指引商城技术改革,emmm,有钱了就要做一些符合土豪身份的枯燥事情,大手一挥,挥金如土直接买了一个大牛团队来对商城进行技术优化。

优化方向:服务化。

服务化

所谓服务化,就是将公司的项目按照模块来进行分割,把每个模块都做成一个可以独立运行,单独部署的的应用程序,如图所示:

订单,商品,首页,促销等,每一个业务模块都是一个独立的应用程序,我们把这样按照模块划分的应用程序称之为服务。

  • 可以根据需要独立的部署在服务器上,首页模块被访问的比较多,就可以多部署几个
  • 可以独立的访问数据库,每个服务都可以有自己的数据库

    ......

等等等,好处不要太多。这样情况我们实际上也称之为微服务。

服务化要解决的问题?「更多问题到来」

当项目进行服务化改造的时候,这个过程并不是一蹴而就,一拍脑袋就成功了。要把项目服务化,需要解决很多的问题,例如:

  1. **服务之间怎么调用?**订单服务想要调用到商品服务的数据,怎么调用?怎么调用更加的稳定,更加高效?【服务调用技术】
  2. **服务之间怎么负载均衡?**订单服务要调用商品服务,商品服务可能有很多个,怎么负载均衡【负载均衡技术】
  3. **服务怎么被管理?**服务怎么定位?有故障了怎么处理?【服务注册与发现技术】
  4. 故障怎么监控?微服务系统中业务模块很多,组件也很多,不同组件的指标不同,那么这些组件怎么进行监控【监控技术】
  5. **故障怎么定位?**微服务架构中,一个用户的请求会涉及到多个内部服务的调用,那么如何定位问题呢?【链路追踪技术】
  6. **日志怎么分析处理?**业务模块多了,日志也就多了,直接查看日志文件已经变的不显示了,那么如何对日志进行分析查找呢?【日志分析技术】
  7. **权限管理?**微服务拆分服务之后,会有很多服务对外暴露接口,这些接口如何进行统一的权限处理呢?【网关技术】
  8. **服务调用出现问题怎么处理?**当一个服务因为各种原因停止响应时,调用方通常会等待一段时间,然后超时或者收到错误返回。如果调用链路比较长,可能会导致请求堆积,整条链路占用大量资源一直在等待下游响应。怎么解决呢?【熔断,降级,限流】

还有测试,自动化部署等等问题,都随着微服务的出现到来了,上面的每个问题要进行解决都需要在项目中引入一个或者多个新技术,而这些新技术我们一般称之为组件,也是微服务学习的重点,一整套技术,一套解决上述所有问题的解决方案。

上面出现的问题,在此处我们暂时一笔带过,在所有的教程中,再进行详细的分析和讲解。

什么是微服务【重点】

the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

  • 每个服务可独立运行在自己的进程里
  • 一系列独立运行的微服务共同构建起整个系统
  • 每个服务为独立的业务开发,一个微服务只关注某个特定的功能,例如订单管理,用户管理
  • 微服务之间通过一些轻量的通信机制进行通信,例如Restful API进行调用
  • 可以使用不同的编程语言与数据存储技术开发

官网链接:https://www.martinfowler.com/articles/microservices.html

总结

新技术会站在老技术的基础上,解决老技术出现的问题的同时,进行迭代和演化。

微服务技术是一整套技术,是一套解决多个问题的技术解决方案。

恭喜你完成了本章的学习,为你鼓掌!如果本文对你有帮助,请帮忙点赞,评论,转发,这对作者很重要,谢谢。

要掌握SpringCloud更多的用法,请持续关注本系列教程。

求关注,求点赞,求转发

欢迎关注本人公众号:鹿老师的Java笔记,将在长期更新Java技术图文教程和视频教程,Java学习经验,Java面试经验以及Java实战开发经验。

以上是 F版本SpringCloud1—大白话为啥要有微服务?啥是微服务?SpringCloud为什么有那么多组件? 的全部内容, 来源链接: utcz.com/z/514646.html

回到顶部