微服务架构优势在哪,与传统服务又有什么区别呢…

2019-08-23 07:36:17来源:编程学习网 阅读 ()

新老客户大回馈,云服务器低至5折


一、概述

说起微服务,在程序界,可算是当下相对火爆的词,那么微服务到底是什么?与传统的服务有什么区别,为什么要使用微服务呐?

需要指出的是:微服务架构并不是为了拆分而拆分,真正的目的是通过对微服务进行水平扩 展解决传统的单体应用在业务急剧增长时遇到的问题,而且由于拆分的微服务系统中专业的人做 专业的事,人员和项目的职责单一、低藕合、高内聚,所以产生问题的概率就会降到最小。

二、微服务架构描述

先看看微服务的架构图,看看当前火的微服务架构图:


从图得出如下结论:

· 微服务把每一个职责单一的功能放在一个独立的服务中 。
· 每个服务运行在一个单独的进程中。
· 每个服务有多个实例在运行,每个实例可以运行在容器化平台内,达到平滑伸缩的效 果。
· 每个服务有自己的数据存储,实际上,每个服务应该有自己独享的数据库、缓存、消息 队列等资源。
· 每个服务应该有自己的运营平台,以及独享的运营人员,这包括技术运维和业务运营人 员:每个服务都高度自治,内部的变化对外透明。
· 每个服务都可根据性能需求独立地进行水平伸缩 。


三、传统架构描述

先看看传统架构图,粗略看看传统架构的实现方式:



从上图可以得到如下结论:

·传统单体架构将所有模块化组件混合后运行在同一个服务 口而4 进程中 。
· 可对包含多个模块化组件的整体 川岛f 进程进行水平扩展,而无法对某个模块化组件进 行水平扩展。
· 某个模块化组件发生变化时,需要所有的模块化组件进行编译、打包和上线 。

· 久而久之,模块间的依赖将会不清晰,互相糯合、互相依赖成为家常便饭。

通过对比来看,微服务架构更灵活并且可水平伸缩,可以让专业的人来做专业的事。


四、微服务架构与传统单体架构的对比

单块架构应用:功能集中,代码和数据中心化,一个发布包部署后运行在同一个进程中的应用程序

单块架构的优势:

1)易于开发

2)易于测试

3)易于部署

4)易于水平伸缩(所有的功能都会打成一个包,在集群中新建一个节点,配置好节点的运行环境,复制软件包到响应的位置,保证负载均衡的分发策略有效分发到当前节点即可)


面临的挑战:

1)维护成本增加,代码量过大,不利于快速定位问题

2)持续交付周期长:构建 部署和测试的实际都会随着代码量的增加而成倍的增长

3)新人培养周期长:业务熟悉和环境部署都会有很大的难度

4)技术选型成本高:较大规模的系统,最初的选型会影响新技术的使用

5)可扩展性差:

  a 垂直扩展:增加服务器

  b 水平扩展:在集群中添加节点,使用负载均衡(若应用有一部分是需要内存密集型缓存大量数据,有一部分是需要CPU密集型,需要进行大量运算,那么每次扩展新的节点都需要足够的内存和CPU来满足需求)

6)构建全功能团队难:会出现功能的扩展需要跨团队沟通


微服务架构:


是一种架构模式,提倡将单一应用程序划分为一组小的服务,服务之间相互协调,相互配合,为用户提供最终价值,每个服务运行在独立的进程中,服务间采用轻量级的通信机制相互沟通(通常是基于http的restful api),每个服务围绕自己的具体业务构建,可以独立部署,应尽量避免统一的,集中式的服务管理机制,对于具体的一个服务而言,应根据业务上下文,选择合适的语言 工具来进行构建,也就是:


通过对特定业务领域的分析和建模,将复杂的应用分解成小而专一的,耦合度低并且高度自治的一组服务,每一个服务都是一个小的应用


编译语言有良好的语言类型约束和编译期检查,但代码比较复杂


动态语言灵活性高,运行时可以改变其内存结构,无类型检查,无需写交较多类型相关的代码,但不方便调试


开发 测试 部署完全独立,语言独立


服务与服务之间相互独立,相互隔离


在单块架构中,应用程序的代码虽然被分成逻辑上的3层或者4层,但并非物理上的分层,所有的功能经过编译,打包,部署后还是会运行在同一个进程中,这就意味着对应用部署时必须停掉正在运行的服务,部署完成后再重新启动进程,无法独立部署

一般为了代码的重用性,会把重复的代码封装成组件(可独立升级,独立替换掉的部分),传统架构中,通常是共享库,比如jar包或者是win下的dll等

但在微服务架构中,应用程序由多个服务组成,每个服务都是一个具有高度自治的独立业务实体,每个服务可以运行在一个独立的进程中,不同的服务可以轻易的部署到不同的主机上

理论上可以把不同的服务部署到同一个节点上,运行到不同的进程里,但是不推荐,既然是微服务,最好保证高度的自治性和隔离性,运行在同一个节点上,虽然省去了节点的开销,却增加了部署和扩展的复杂度,部署某一个新的服务时,可能会对该节点的原有服务造成影响,另外随着业务的发展,可能某些业务需要水平扩容,有些不需要,如果不能有效的组织服务,可能会给服务的水平扩容带来不必要的麻烦。


原文链接:http://www.phpxs.com/post/6491/
如有疑问请与原作者联系

标签:

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有

上一篇:购物车增删改与清空,用Redis实现一下吧

下一篇:你们知道JWT是什么吗?