1、直面微服务架构
1.1 单块系统的问题
所谓单块系统,简单来讲就是把一个系统所涉及的各个组件都打包成一个一体化的结构进行部署和运行,在java中这种一体化的结构就是war包,而部署和运行的环境就是Tomcat,如下图所示:
![](https://img.haomeiwen.com/i14249104/5188e8dba0901877.png)
1.1.1 单块系统优点
- 当项目不是太大的时候,一个单块应用可以由一个团队进行独立维护,该团队可以对单块应用快速学习、理解和维护,因为结构非常简单
- 另外因为单块系统打包后就是一个war包,所以对系统的部署也非常简单
- 测试直观,启动应用程序后,使用postman这类工具观察返回结果,即可完成测试
- 水平扩展也比较简单,通常部署多个机器,使用负载均衡就能水平扩展
1.1.2 单体系统缺点
当系统不大时,单体应用很方便。但是随着业务的不断扩张,以及访问量的逐渐增加,单体架构面临着越来越多的挑战
- 过度的复杂性,当一个系统本身过于复杂和庞大,任何一个开发者都难以理解它的全部,所以实现新功能和修复bug变得非常困难(不知道改了一个代码,是否会影响其他的模块)
- 难以扩展,在一些情况下,应用不同模块对资源的需求是不一样的。例如数据相关的模块需要很大的存储空间,而图片处理需要高性能的cpu资源,也就造成了单体系统必须同时满足所有模块的需求
- 当系统足够大的时候,单体系统的可靠性不能保证,当一个模块内存泄漏时,整个服务不可用。
- 需要长期依赖过时的技术栈,在单体系统上尝试新的技术风险都是极高的,因为应用必须被重写,也就意味着,团队必须维护一个已经过时的技术所开发的应用程序。
1.2 微服务架构
根据上面所说的,当系统变得很复杂时,应用程序必须迁移为微服务架构,微服务是什么?先从一个三维可扩展模型:扩展立方体来了解。
1.2.1 扩展立方体
![](https://img.haomeiwen.com/i14249104/3f3325b497ea1774.png)
上图定义了三种不同的扩展应用程序方法:
-
X轴为水平扩展,创建多个实例实现请求的负载均衡
image.png
-
Z轴扩展,根据请求的属性路由请求,和X轴不同的是,X轴的多个实例是相同的,访问任何一个实例结果都是一样的;而Z轴的每个实例仅负责数据的一个子集
image.png
-
X轴和Z轴可以提高应用的拖吞吐量和可用性,但是没办法解决应用程序复杂的问题;为了解决这一问题,需要引入Y轴扩展,Y轴扩展根据功能,将应用程序拆分为服务,同时,服务可以根据需要,使用X轴或者Z轴进行扩展。
image.png
1.2.2
微服务定义
把应用程序功能性的分解为一组服务的架构风格。每一个服务之间都是松耦合的,他们仅仅通过API进行通信(这是实现松耦合的方式之一),并且每个服务都有自己的私有数据库。用户系统对应用户数据库,订单系统对应订单数据库......
1.2.3 微服务的好处
- 微服务的每个服务都可以独立部署。如果负责服务的开发人员需要部署对该服务的更改,不需要其他服务负责人就可以进行
- 每个服务都相对比较小,容易维护。每个服务是专注的、内聚的,并不关注其他服务的功能。
- 更容易实验新的技术。微服务之间仅仅通过API通信,服务只关注返回结果,对被调用服务使用的什么技术完全不关心
- 服务可以独立扩展,服务可以独立部署,也可以采用X轴或者Z轴进行扩展。
- 更好的容错性,服务是部署在不同机器上的,因此某个服务的内存泄口并不会影响到其他服务,例如我的客户服务不能访问了,但是还可以正常的浏览商品并支付
- 更容易尝试新技术,每个服务的负责人可以自由选择适用这个服务的任何框架和语言,而不会影响其他服务。
微服务的缺点
软件世界没有银弹,微服务有非常多的有点,但是也存在一些显著的缺点和问题
- 服务的拆分是一项挑战,如果对服务的拆分出现了偏差,很可能构建出一个分布式的单体应用,将一个很大的服务部署在分布式系统,将分布式和单体应用的缺点集中起来
- 使用分布式会带来各种复杂性,服务之间必须采用进程间通信、必须处理远程服务不可用或者延迟过高的各种情况、分布式事务。除此之外,由于微服务架构的服务增多,必须在生产环境管理更过的活动组件,需要高度自动化的基础设施
- 部署的时候必须将服务按照依赖关系进行排序,并严格按照顺序进行部署
网友评论