SpringCloud介绍

微服务是什么

单体项目

在互联网刚开始的年代,传统的单体项目,一般是一个服务器,对少量的用户足矣。这时候,开发一套系统,可以提供少量的(相比于现在)服务。并发性不大,服务器性能不需要太好都可以跑得好好的。这个时代我没有经历过。

《SpringCloud介绍》

单体项目分布式

互联网稍稍发展起来了,一台服务器好像支撑不大住。这时候,聪明的程序员们就说,如果一个系统撑不住,那就启动两个来为客户服务呀。所以架构就变成这样,用户,可以把请求落到两个随便一毛一样的系统上面,提供服务是一致的。这时候一般考虑 sessionid 的共享。

《SpringCloud介绍》

初代前后端分离

下一个发展阶段,即很多企业发现,如果一台机器,需要做数据库操作,还需要做界面层的渲染,服务器的压力太大。这时候出现了初代前后端分离,后端访问数据库的速度可以使用 redis 加成,而前端项目,大部分是渲染成页面提供给用户。所以这时候的架构演变成下面:这种情况可以根据不同的需求进行拓展,拓展前端,拓展后端都还行。

《SpringCloud介绍》

微服务时代

很快,需求出现爆炸性的增长,后端服务器如果还是单体项目,无论是部署,拓展都显得特别笨重。如果后端服务需要新增一个实例,那么我们都需要手动重新配置前端服务。如果突然之间需要新增多个实例,那么程序猿将会累死累活。所以这时候,急需一个可以自治的生态系统,将拓展的事情交给程序去设定。

这时候,Java 界男神 Martin Fowler 提出了 microservice 架构(原文链接)。即我们将公司所在领域,按照一定的子域进行划分,每个子域自成一个小服务。此时,拓展就变得简单,我们可以给并发量大的服务拓展多几个服务,而并发小的,或者任务不重但是缺一不可的,单机或者少一点服务存在。而上一层路由层,通过网络与不同服务之间进行通讯,共同服务于用户。

而微服务还有另外一个元素,那就是自治能力、监控能力。打个比方,如果前端服务需要增加多台,系统可以自动发现,并将其加入”服务团队”中,快速的进入工作状态。

所以微服务架构急切需要一种,自带管理者,统一入口的软件架构。而在当今社会,常见的就有 Dubbo SpringCloud 以及 SpringCloudAlibaba 等一系列的生态框架出现。

那么架构现状,也发生了质的变化:

《SpringCloud介绍》

最终前后端分离

正在此时,前端由于 vue AngularJS react 的兴起,也没闲住,也发生了剧烈的变化。ES (JS 的现代叫法)不再单纯的操作 document 而是将 document 交给框架,开发者只需要关注数据的变化即可,框架会自动根据数据的变化去修改 document 的展示。所以这时候,会出现前端直接分离出来,由前端开发者自己开发,自己编织架构,后端只提供数据服务的局面。走到这里,前端真正的独立出来,后端开发者不再需要编写 MVC 的页面。前端开发者后期维护也变得简单,因为一个前端项目修改不再需要前端和后端结对编程了。

《SpringCloud介绍》

微前端化

由于业务量爆棚,前端也出现了后端的老路。然后前端也就走了后端的发展路线,一个前端再也支撑不住,所以前端也要分出来不同的业务团队,这时候,前端也就进行了微服务化。不同的业务有不同的模块,然后一个总视图进入前端,统领所有的业务服务模块。这块就不画出来了。

SpringCloud是什么

SpringCloud 是一系列套件的统称,不单单是一门技术框架。而这些套件,恰好是我们做微服务系统的时候,常常使用的套件,包含 注册中心 配置中心 路由器 熔断器 监控 等微服务所需要的框架。套件什么的,做好部署运维,那么就可以将精力集中在业务服务的开发。

为什么选择SpringCloud

常见的面试题就是:为什么使用 SpringBoot

标准答案:因为 Spring 官方提供了自动装配的规范,由第三方框架(MyBatis 等)去实现。然后版本号规约放置于 SpringBoot 的顶级父类里,这样当我们使用对应版本的 SpringBoot 的时候,依赖进来的需要使用的第三方框架也是框架官方提供的,兼容性不错的版本。

而恰恰好,SpringCloud 就是这样集成而来的,所以兼容性问题,并不需要关心太多。

当初选择这个框架,是因为我感觉上手简单,而且套件齐全。公司项目肯定想要稳定,拓展性好的框架。因为 Spring 框架让我放心,因为他是 Spring 公司的。其二,官方提供套件的合成,也不会出现有些不兼容的现象。因为 SpringBoot 的加成,统一的父类,放心的整合。

在快速做一个小服务也是十分的方便,只要把统一的配置放置于 config-server 我在开发新的业务服务的时候,不需要过多的关注他的配置的东西 (比起 Spring 时代的 xml 地狱简直不要太方便)

SpringCloud常用组件

微服务套件 推荐框架 作用 可替换框架
注册中心 Eureka 微服务系统的中心,可用于服务的注册以及服务之间的发现 ZooKeeper Consul
配置中心 ConfigService 业务服务的配置中心,将业务服务通用、系统配置放置于此,服务启动即可发现并应用配置 Apollo
路由器 Gateway 微服务生态总入口,需要请求服务只能通过于此。相对的,权限控制、登陆拦截都落在此处。 Nginx Nodejs自开发
熔断器 Hystrix 熔断器,用于熔断服务的连接。如果服务负载量过大、频繁报错,将会像保险丝一样断开服务,让他休息一会儿再起来
熔断监控 Turbine 熔断器的监控视图,用于监控熔断器的情况,以便人为干涉
消息通知 Stream 用于服务之间的消息通知,进行封装后可以不需要关注分布式锁(谁来处理的问题)
契约开发 Contract 微服务中,进行 TDD 开发的模拟第三方服务返回数据的套件

老夫认为,项目刚刚初始,Eureka Config Gateway Stream 都是初始就要考虑的必备品。

点赞