[技术日志] 从零开始微服务架构 (1) 传统架构的缺点

声明:

本系列 【技术日志】 为记录博主(我)学习微服务架构总结的一些内容,部分来自学习&参考书籍,本声明仅在第一章有,此后不再出现,参考书籍为: 《架构探险 轻量级微服务架构》。 最后,让我们一起来愉快地学习微服务架构吧!

为什么需要微服务架构?

是啊,为什么呢? 其实是因为传统架构的一些问题, 比如:

有一个WEBAPP,里面有WEBUI部分以及若干业务模块,比如 Module AModule BModule C 等,这几个业务模块占用系统资源都不同,(以下进行简称,MA=Module A, MB,MC同理)。

MA占用资源为10%,MB占用资源为10%,MC占用资源为80%。那么,这样运行一段时间,占用资源最大的MC就会成为系统的瓶颈,怎么办呢?

聪明的人们想出一个简单地办法, 就是对应用程序进行水平拓展(即增加计算机的数量提升性能),同时在两台服务器上方架设一台Load Balancer(负载均衡器,简称LB)。

请求首先会发送到LB上,通过LB上的路由算法(例如轮询哈希),将请求转发到后面具体的Web Server上,这类请求转发技术被称为Reverse Proxy(反向代理)。

由于进入LB的流量被均衡到下方各台Web Server中了,流量得到了分摊,负载得到了均衡,因此这项技术也被称为Load Balance(负载均衡)

如果流量加大,我们还可以继续水平拓展,改架构理论上可以无限拓展, 只要LB扛得住巨大的流量就OK。

通过以上方案,轻松地将负载进行了均衡,在一定程度上缓解了流量对Web Server的压力,但此时却造成了大量的系统资源浪费,比如对系统资源占用率不高的MAMB也进行了水平拓展,其实我们只想对MC进行水平拓展而已。

传统应用架构还有哪些问题?

传统应用架构实际上是一个单块应用,我们在部署它的时候,同样会遇到许多麻烦,比如:

  1. 修改了一个 Module(可能只是修改了一行代码),就需要部署整个应用
  2. 部署整个应用所消耗的时间对系统带来的性能开销都是非常多的

而且对于Java Web应用而言,打包在war包里的代码一般都是class文件,这也就意味着,我们的单块应用只是基于Java语言开发的,无法将该应用中某个Module通过其他更合适的开发语言来实现(假如我们不考虑在JVM上运行动态语言的情况下),这样就会产生技术选型单一的问题。

总结

综上所述,传统应用架构存在以下问题:

  1. 系统资源浪费
  2. 部署效率太低
  3. 技术选型单一

当然,传统应用架构的问题还远远不止这些。当业务变的越来越复杂时,应用会变得越来越臃肿,“身材”越来越“胖”,而且无法瘦身。于是,人们找到了新的思路来解决传统应用架构的问题,这就是微服务架构

A person who likes golang

讨论数量: 0
(= ̄ω ̄=)··· 暂无内容!

请勿发布不友善或者负能量的内容。与人为善,比聪明更重要!