博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
微服务架构简单介绍
阅读量:4171 次
发布时间:2019-05-26

本文共 2143 字,大约阅读时间需要 7 分钟。

一、几种架构简单介绍

1、单体架构

对于复杂的系统,一个模块在一个包里面,最后打成一个war包去部署,这就是我们说的单体架构。

官方术语:在项目中,我们通常将需求分为三个部分:数据库、服务器处理、前端展示。如果这些需求都实现在了同一个应用中,那么这个项目就是单体架构的。

2、分布式架构

一个war包可以做水平扩容,做集群分布式架构,这是分布式架构
分布式系统(distributed system)是建立在网络之上的软件系统。

官方术语:什么是分布式架构?

内聚性是指每一个数据库分布节点高度自治,有本地的数据库管理系统。
透明性是指每一个数据库分布节点对用户的应用来说都是透明的,看不出是本地还是远程。
在分布式数据库系统中,用户感觉不到数据是分布的,即用户不须知道关系是否分割、有无副本、数据存于哪个站点以及事务在哪个站点上执行等。
简单来讲:在一个分布式系统中,一组独立的计算机展现给用户的是一个统一的整体,就好像是一个系统似的。
分布式系统作为一个整体对用户提供服务,而整个系统的内部的协作用户来说是透明的,用户就像是在使用一个MySQL一样。
如分布式MySQL中间件-Mycat,来处理大并发大数据量的构架。

3、微服务架构

相对于单体架构来说,整个后端的架构变了。原来在工程下的一个模块,微服务中会变成一个个独立的子系统。每个package都会被抽取出来,变成一个个独立的子项目,最后上线的时候,每个子系统都会打成独立的war包,部署在Tomcat上,这就叫微服务架构的拆分。

官方术语:什么是微服务架构?

微服务是一种架构风格,一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署各个微服务之间是松耦合的,每个微服务内聚不同的业务模块。

二、常见疑问

1、原来每个模块之间有交互,现在变成独立的子系统,之间也要有交互,怎么办?

完全独立的子系统之间的交互式式通过接口的,常见的接口无非就是HTTP接口或者偏底层的RPC接口。
注意微服务架构web应用层调后端微服务,也是通过接口。

三、微服务架构好处

第一:它通过分解巨大单体式应用为多个服务方法解决了复杂性问题。在功能不变的情况下,应用被分解为多个可管理的模块或服务。每个服务有以 RPC 或者消息驱动 API 形式定义清楚的界限。微服务架构模式给采用单体式编码方式很难实现的功能提供了模块化的解决方案。因此单个的服务可以更快的开发,更简单的理解和维护。

第二:微服务架构使得每个服务都可由单独的小团体独立开发,开发者可专注于某个具体的服务,可自由选择合理的技术,只要服务遵守 API 约定即可。许多公司试图避免混乱,只提供某些技术选择,这种自由意味着开发者不再受限于使用可能过时的技术,可以选择现在的技术。由于因为服务相对较小,所以使用当前的技术重写老服务是可行的。

第三:微服务架构模式使每个微服务均能被独立部署。开发者不再需要调整本地对其服务的更变而进行部署。不论何中类型类型的变更均能在测试时立即部署。微服务架构模式让持续部署成为可能。

第四:微服务架构模式使每一个服务都可被独立扩展。根据每个服务的规模来部署满足需求的规模。甚至于,你可以使用更适合于服务资源需求的硬件。系统资源浪费比较小,有针对性。

通俗举例:

(一)单体架构部署到线上,如果有个小问题,假设这个问题是个不重要的模块,比如日志获其他边缘的业务功能导致的问题,但是造成了OOM,导致整个网站都用不了了。拆了微服务架构之后,只要核心的服务没有问题,整个网站是可以正常运行的。
做了微服务架构之后,出现问题影响的层面会缩小一点。

(二)大型的开发团队如果使用单体架构做开发的话,几百上千人每天都在一个工程上开发项目,提交代码、更新代码会有大量的冲突,项目提测上线会有很多很多问题,比如各个环境之间的相互依赖,存在很多管理上的问题,是非常麻烦的。

做了微服务架构拆分之后,大的开发团队也会随着系统的拆分成一个小团队,管理起来也比较容易

(三)像双十一这种情况,从很早之前就要做一些服务扩容,针对于单体架构,则需要根据这个网站扩容。但是双十一这种场景一般对电商网站来说,交易模块的压力是最大的,那么在扩容的时候就可以针对性的添加,压力大的可以多加机器,压力小的就少加点机器,机器的资源利用率会大大提高。

(四)随着系统做微服务架构的拆分,随之对应的业务数据库表也拆分到不同的数据库中了。

数据库本身做水平扩容就比较麻烦(不是说不可以做,但是相对于web应用来说,做水平扩容会麻烦的多)。拆分服务之后不同的业务都有自己对应的数据库,无形之中对数据库也做了扩容

四、微服务架构不足

任何事物都是有双面性的,微服务架构除了带来上面所述的一些好的地方,还是存在一些不足之处

(一)架构复杂

(二)学习成本高

(三)单体架构,可能都不需要运维,自己就可以搞定,但是微服务架构将系统拆分成了几十甚至上百个服务,整个服务的架构会非常复杂,运维的成本非常高。

(四)数据一致性问题。跨服务的事务不好把控,虽然可以借助分布式事务来解决,但是分布式事务想要做的好很不容易

(五)多个服务相互调用,若是中间任何一个环节出了问题,想排查问题比较麻烦。

转载地址:http://xayai.baihongyu.com/

你可能感兴趣的文章
区块链问与答
查看>>
css常用小知识点
查看>>
js常用小知识点
查看>>
Java常用小知识点
查看>>
Java小知识点之lambda
查看>>
开源Java诊断工具Arthas简单使用说明
查看>>
深入理解Mysql索引底层数据结构与算法(二)
查看>>
IDEA自动去掉无用的import
查看>>
js数字转换成汉字
查看>>
MySQL不同存储引擎底层真正存储结构
查看>>
MySQL存储引擎底层常见面试题
查看>>
MySQL Explain执行计划详解
查看>>
索引最佳实践具体实例
查看>>
临时关闭MySQL缓存
查看>>
HBase学习和使用
查看>>
LSTM
查看>>
牛客网 数字游戏
查看>>
逆波兰表达式
查看>>
逆波兰表达式
查看>>
K-means中K值的选取
查看>>