微服务架构的优缺点(微服务架构的优缺点和应用场景)

扫码添加渲大师小管家，免费领取渲染插件、素材、模型、教程合集大礼包！

大家好，今天来介绍微服务架构的优缺点(微服务架构的优缺点是什么?)的问题，以下是渲大师小编对此问题的归纳和整理，感兴趣的来一起看看吧！

微服务架构的优缺点

优点：易于开发和维护:一项服务只关注一项特定的业务功能，业务清晰，代码量少。
微型服务的优点:
1.易于开发和维护:一项服务只关注一项特定的业务功能，业务清晰，代码量少。开发维护单项微服务辩握相当简单。整个应用程序由一些微型服务构建，因此整个应用程序处于可控状态。
2.单一服务启动快:单一服务代码少，启动快。
3.局部修改易于部署:单个应用程序只要有修改，就必须重新部署整个应用程序，微服务解决了这个问题。一般来说，修改某个微型服务，只需重新配置该服务。
4.技术堆栈不受限制:微服务结构可结合业务和团队特点，合理选择技术堆栈。例如，一些服务可以使用关系数据库Mysql，一些服务可以使拦灶肢用非关系数据库redis。甚至简世可以根据需服务可以使用JAVA开发，一些微服务可以使用Node.js开发。
5.按需收缩:可根据需要实现细粒度的扩展。例如，系统中的某个微服务遇到瓶颈，可以结合微服务的特点，增加内存，升级CPU，增加节点。
微型服务的缺点:
1.运输要求高:更多的服务意味着更多的运输投入。在单体结构中，只需保证一个应用程序的运行，在微服务中，需要保证几十到几百个服务器的正常运行和合作，这给运行维护带来了巨大的挑战
2.分户式固有的复杂性:使用微服务结构的是分布式系统。对于分布式系统，系统容错，网络延迟带来巨大挑战。
3.界面调整成本高:微服务之间通过界面通信。

微服务架构的优缺点和拆分

单体式的架构更适合轻量级的简单应用，微服绝耐务架构适合大型、大团队、敏捷迭代型项目。
后台架构的演变：单体结构（没宏丛巨无霸） --> Dubbo 单体结构（小巨无霸） --> 微枯樱服务普通结构 --> 微服务中台结构

微服务架构更加敏捷，如果单体结构的话，任何一次改动的发版，都要重启整个应用。系统之间的耦合度降低

微服务架构缺点：

微服务的拆分：项目拆分 --> 业务拆分（中台）--> 功能拆分
业务拆分：订单系统、支付系统、用户中心、卡券系统、商品系统 等等
功能拆分：支付portal系统 + 支付admin管理系统

谈谈微服务架构是一个怎样的存在

微服务是近些年被广泛提及的一个概念， 微服务架构可以理解为一个轻量级的服务治理方案， 也就是将系统的功能，通过服务的形式发布到服务器上，对服务进行组合调用，实现具体的功能，解决实际业务问题的架构风格。

微服务产生于单体应用的扩大化，随着信息化不断发展，企业对软件功能的要求越来越具体，也愈发的细致，如果通过应用程序来实现，必然是一个极其复杂而又痛苦的过程，由此诞生了微服务的概念。就是 将功能发布成服务，应用程序通过调用不同的服务来实现业务， 这种设计架构称之为微服务。

微服务架构的优败慎李点在于每个服务可以有独立的团队开发，服务之间互不干涉，保障了系统的稳定性。由于功能被拆分到更细的粒度，有效的降低了程序的复杂程度，对硬件的需求也随之降低，但是微服务也有一些不足，比如服务调用带来的系统复杂性，服务间的依赖关系也是难以管理的，如何构建合理的服务依赖是考验架构师能力的重要依据；最后，微服务架构的部署以及跟踪也是很难的。总之， 微服务架构有着自身的应用场景以及特点，了解哪些场景适合微服务比掌握微服务的具体技术更为重要， 适当的技术用在适当的场景，才能发挥合适的价值察迟。

微服务架构是当前最流行的技术架构，主要组件有注册中心、网关、配置中心和各种微服务模块。架构灵活、易扩展、可动态扩容。

在微服务之前，系统架构经历很长时间的演变，简述如下：

1.无架构

页面逻辑和业务逻辑混在一起，甚至页面直接访问数据库。

优点：因为没有太多的访问路径转换，效率是最高的；

缺点：没有分层，逻辑混乱，维护难，扩展难。

2.MVC

架构

单系统，表现层、逻辑层、业务层分开，各层分工协作。

优点：逻辑清晰、分工明确、易维护。

缺点：系统集中部署，属于强耦合，某些业务模块出现异常时，会导致整个系统无法访问。

3.SOA架构

面向服务的架构，多个系统分布式部署，通过消息总线进行通讯。

优点：各个系统的业务相对独立，耦合低；

缺点：消息总线负担太重，中心化太重，接口缺乏规范。

4.微服务架构

一个系统，按照粒度规划，划分为很多的微服务，而每个微服务，对应一个具体的业务实现，并可拥有自己独立的数据库，整个就是微服务架构。

优点：如上，架构灵活、易扩展，在实际运营时，按需扩容，集群部署。各个微服务业务互不影响，耦合性低；

缺点：开发成本高，对部署有一定的专业性要求。

从技术而言，微服务已经是一个设计理念很成熟的架构，可满足不同层次，不同业务场景的需要，而且经过多个版本的迭代，该踩的坑也基本踩完，生态系统完整，开源组件选择多多，很有一统天下的趋势，值得尝试。

但，不要为了微服务而微服务，要根据自己实际的要求去做抉择和取舍。

比较，适合自己的，才是最好的！

微服务是近几年技术社群讨论很多的一种软件架构方式，可以说是SOA的现代版本、 时尚 版本。不过这次浪潮不是由大公司倡导的，而是由工程师们引领的。比如，它采用工程师们熟悉的RESTful接口，而不是笨重的WebService，也不需要一大堆昂贵的中间件。

那微服务为什么流行起来？按理说它们都是让软件更加模块化，使相互之间保持松耦合，从而优化系统架构。

国内流行起来的微服务架构——RestCloud

RestCloud 为了保证服务不注册中心癿高可用性，服务不注册中心通过水平扩展癿能

力允许对服务不注册中心迚行集群配置，开在网关层做了服务癿注册癿数据缓存。

Spring Cloud Eureka 是 Spring Cloud Netflix 微服务套件中癿一部分，它基于 Netflix Eureka做了二次封装。主要负责完成微服务架极中的服务治理功能。

易用性

如果你目前使用SpringBoot开发API服务则无需修孝带改任何代码，只需引入RestCloud配置中心的jar包即可由配置中心接管所有配置，对开发人员无任何感知，如果你使用RestBoot开发平台开发API则已经是天然集成了配置中心的客户端Jar包无需任何依赖。 如果你使用php,c#开发目前RestCloud并没有提供现成的解决方案，你需要通过Rest API来接入RestCloud配置中心并自已在本地实现配置缓存管理。

稳定性

RestCloud采取全新的本地配置持久化技术，保证配置中心不会形成单点故障，因为所有的配置数据在应用则具有本地缓存和持久化技术，假定RestCloud配置中心出现故障且长时间未能恢复的情况下，应用则的程序会自动读取本地缓存配置数据. 进一步假定这时应用也刚好出现故障需要重启，则本地缓存在重启后将会消失,这时应用将自动从持久层再次读取配置数据到缓存中从而恢复运行，所以RestCloud配置中心不会出现故障后影响应用的运行,RestCloud配置中心优于目前开源的大多数配置中心解决方案。

易用性

如果你目前使用SpringBoot开发API服务则无需修改任何代码，只需引入RestCloud配置中心的jar包即可由配置中心接管所有配置，对开发人员无任何感知，如果你使用RestBoot开发平台开发API则已经是天然集成了配置中心的客户端Jar包无需任何依赖。 如果你使用php,c#开发目前RestCloud并没有提供现成的解决方案，你需要通过Rest API来接入RestCloud配置中心并自已在本地实现配置缓存管理。

稳定性

RestCloud采取全新的本地配置持久化技术，保证配置中心不会形成单点故障，因为所有的配置数据在应用则具有本地缓存和持久化技术，假定RestCloud配置中心出现故障且长时间未能恢复的情况下，应用则的程序会自动读取本地缓存配置数据. 进一步假定这时应用也刚好出现故障需要重启，则本地缓存在重启后将会消失,这时应用将自动从持久层再次读取配置数据到缓存中从而恢复运行，所以RestCloud配置中心不会出现故障后影响应用的运行,RestCloud配置中心优于目前开源的大多数配置中心解决方案。

网站链接：http://www.restcloud.cn/restcloud/mycms/index.html

https://blog.csdn.net/kezi/article/details/81276727

微服务架构的优缺点

微服务在近几年大火，它具备了灵活部署、可扩展、技术异构等优点，但同时也带弯嫌来了开发、运维的复杂性。是否要采用微服务架构需要根据系统的特点，结合企业的组织架构、团队能力等多个方面进行综合陪闹扮的判断，而不是为了微服务而微服务。例如基于微服务架构的MK-PaaS平台，通过将传统流程服务、组织服务、门户服务、消息服务、集成服务、生态组织、主数据芦灶等能力中台化；并提供统一集成&开发能力，整合生态服务能力。帮助大、中型组织高效构建内、外协作一体化的数字化平台，提高生态型组织的效率，提升业务敏捷度，夯实产业互联网&商业模式创新基座，赋能数字化转型升级，敏捷应对业务需求变化。

微服务架构的缺点

介绍微服务架构好处的文章比较多，最近交付的一个项目发现的缺点也比较明显，给方案设计，性能，测型拦试，运维，问题排查，数据管理，配置管理，事务管理，研发管理都带来了不少挑战。如果使用不慎，研发成本，交付成本和运维成本都可能会大幅度上升。

自己的体会，不能简单通过技术角度看待微服务化，为了微服务而微服务潜在风险很大，不好的微服务切分会带来不必要的沟通路径，而沟通路径增加会带来更大的复杂度，这违背了微服务设计的初衷。微服务“入门容易，掌握难，出门难”。

建议的原则是业务驱动，设计保障，演进式让樱迭代，保守治疗的方式。搞不清楚，有争议的地方先尽量不要拆，如果确实要拆，要经过业务分析后慎重设计，把真正相对独立的部分拆分出来，可以借鉴DDD的方式。拆了以后要观察微服务的接口是否稳定，针对业务需求的变更微服务的模块是否可以保持相对稳定，是否可以独立演进。

正好看了一个国外帖子，总结的不错，翻译并增加了自己的一些体会：

以下是微服务架构的缺点：

架构演进应该还是需要业务驱动和演进式迭代的，重新看了Martin Fowler的那篇
Microservices 经典卜滑胡之作。再来体会一下这句话会有不同的体验：
“One reasonable argument we've heard is that you shouldn't start with a microservices architecture. Instead begin with a monolith , keep it modular, and split it into microservices once the monolith becomes a problem.”
不要一上来就以微服务架构做为起点。相反，要用一个单块系统做为起点，并保持其模块化。当这个单块系统出现了问题后，再将其分解为微服务。

另外看到一篇文章《Microservices - Not A Free Lunch!》,也提出了微服务的几个潜在问题：