微服务的优势以及面临的挑战

微服务顾名思义,就是很小的服务,所以它属于面向服务架构的一种。通俗一点来说,微服务类似于古代著名的发明,活字印刷术,每个服务都是一个组件,通过编排组合的方式来使用,从而真正做到了独立、解耦、组件化、易维护、可复用、可替换、高可用、最终达到提高交付质量、缩短交付周期的效果。
从专业的角度来看,微服务架构是一种架构模式,它提倡将单一应用程序划分成一组小的服务,服务之间互相协调、互相配合,为用户提供最终价值。每个服务运行在其独立的进程中,服务与服务间采用轻量级的通信机制互相沟通(通常是基于 HTTP 协议的 RESTful API)。每个服务都围绕着具体业务进行构建,并且能够被独立的部署到生产环境、类生产环境等。另外,应当尽量避免统一的、集中式的服务管理机制,对具体的一个服务而言,应根据业务上下文,选择合适的语言、工具对其进行构建。
所以总结起来,微服务的核心特点为:小, 且专注于做⼀件事情、轻量级的通信机制、松耦合、独立部署。
优势
1.微服务的优势
微服务之所以能盛行,必然是有它独特优势的,下面我们来分析微服务有哪些方面的优势。
(1)技术异构性
在微服务架构中,每个服务都是一个相对独立的个体,每个服务都可以选择适合于自身的技术来实现。可以混合使用多种编程语言、开发框架以及数据存储技术.
如,要开发一个社交平台,此时,我们可能使用文档型数据库来存储帖 子的内容,使用图数据来存储朋友圈的这些关系等,这样可以把每一块的性能都充分发挥 出来。
同时,在应用新技术时,微服务架构也提供了更好的试验场。因为对于单块的系统而 言,采用一个新的语言、数据库或者框架都会对整个系统产生巨大的影响,这样导致我们 想尝试新技术时,望而却步。但微服务不同,我们完全可以只在一个微服务中采用新技术, 待技术使用熟练之后,再推广到其他服务。
(2)弹性
弹性主要讲的是系统中一部分出现故障会引起多大问题。在单块系统中,一个部分出现问题,可能导致整体系统的问题。而微服务架构中,每个服务可以内置可用性的解决方案与功能降级方案,所以比单块系统强。
(3)扩展
单块系统中,我们要做扩展,往往是整体进行扩展。而在微服务架构中,可以针对单个服务进行扩展。
(4)简化部署
简单的服务更容易部署, 每个服务的部署都是独立的, 单个服务出问题不会导致整个系统的故障.
在大型单块系统中,即使修改一行代码,也需要重新部署整个应用系统。这种部署的影响很大、风险很高,因此不敢轻易地重新部署。而微服务架构中,每个服务的部署都是 独立的,这样就可以更快地对特定部分的代码进行部署。
(5)与组织结构相匹配
为服务强调模块化的结构, 可以将架构与组织结构相匹配,避免出现过大的代码库,从而获得理想的团队大小及生产力。
我们都知道,团队越大越难管理,同时团队越大也代表系统规模越大代码库越大,这样容易引起一系列的问题。且当团队是分布式的时候,问题更严重。微服务架构就能很好地解决这个问题,微服务架构可以将架构与组织结构相匹配,避免出现过大的代码库,从而获得理想的团队大小及生产力。服务的所有权也可以在团队之 间迁移,从而避免异地团队的出现。
(6)可组合性
在微服务架构中,系统会开放很多接口供外部使用。当情况发生改变时,可以使用不同的方式构建应用,而整体化应用程序只能提供一个非常粗粒度的接口供外部使用。
(7)对可替代性的优化
在单块系统中如果删除系统中的上百行代码,也许不知道会发生什么,引起什么样的问题,因为单块系统中关联性很强。但在微服务架构中,我们可以在需要时轻易地重写服务,或者删除不再使用的服务。
挑战
2. 微服务面临的挑战
软件开发业内有一句名言“软件开发没有银弹”,虽然前面介绍了微服务很多方面的优势,但微服务并不能解决所有问题。下面我们来分析在使用微服务架构时可能面临的一些挑战。
(1)分布式系统的复杂度
使用微服务实现分布式系统的复杂度要比单块系统高。这表现在多个方面,如:性能方面微服务是拆分成多个服务进行部署,服务间的通信都是通过网络,此时的性能会受影响。同时可靠性也会受影响。数据一致性也需要严格控制,其成本也比单块系统高。
(2)运维成本
相比传统的单块架构应用,微服务将系统分成多个独立的部分,每个部分都是可以独立部署的业务单元。这就意味着,原来适用于单块架构的集中式的部署、配置、监控或者日志收集等方式,在微服务架构下,随着服务数量的增多,每个服务都需要独立的配置、部署、监控、日志收集等,因此运维成本呈指数级增长。
(3)部署自动化
传统单块系统部署往往是以月、周为单位,部署频度很低,在这种情况下,手动部署是可以满足需求的。而对于微服务架构而言,每个服务都是一个独立可部署的业务单元,每个服务的修改都需要独立部署。这样部署的成本是比较高的,如亚马逊,每天都要执行数十次、甚至上百次的部署,此时仍用人工部署是行不通的,要使用自动化部署。如何有效地构建自动化部署流水线,降低部署成本、提高部署频率,是微服务架构下需要面临的一个挑战。
(4)DevOps 与组织结构
传统单块架构中,团队通常是按技能划分,如开发部、测试部、运维部,并通过项目的方式协作,完成系统交付。而在微服务架构的实施过程中,除了如上所述的交付、运维上存在的挑战,在组织或者团队层面,如何传递 DevOps 文化的价值,让团队理解 DevOps 文化的价值,并构建全功能团队,也是一个不小的挑战。
微服务不仅表现出一种架构模型,同样也表现出一种组织模型。这种新型的组织模型意味着开发人员和运维的角色发生了变化,开发者将承担起服务整个生命周期的责任,包括部署和监控,而运维也越来越多地表现出一种顾问式的角色,尽早考虑服务如何部署。因此,如何在微服务的实施中,按需调整组织架构,构建全功能的团队,是一个不小的挑战。
(5)服务间依赖测试
由于微服务架构是把系统拆分为若干个可独立部署的服务,所以需要进行服务间的依赖测试。在服务数量较多的情况下,如何有效地保证服务之间能有效按照接口的约定正常工作,成为微服务实施过程中必须面临的巨大挑战。
(6)服务间依赖管理
传统的单块系统,功能实现比较集中,大部分功能都运行在同一个应用中,同其他系统依赖较少。而微服务架构则不同,在将系统功能拆分成相互协作的独立服务之后,随着微服务个数的增多,如何清晰有效地展示服务之间的依赖关系,成为了一个挑战。

你可能感兴趣的:(软考高级系统架构师,JAVA高级架构师面试,数据库,node.js,restful)