系统软件架构中，现在很流行微服务，那么使用微服务就一定好么？微服务有哪些缺点呢？

下面简单回答下这个问题。在回答这个问题前还是先回顾下微服务架构。

微服务架构概述

微服务架构本质是单个业务系统彻底的组件化（前端，逻辑层，数据库）解耦，同时相互之间通过轻量的服务接口和协议进行协同。这和很早就谈到的组件化架构思想是一致的，实现微服务架构后，你会看到没有传统业务系统的概念了，有的只是微服务模块或小应用。
微服务架构最近又炒的相当活，很多人会说SOA过时了，ESB过时了，甚至还有人用微服务架构去彻底的否定SOA和ESB，这些都是相当危险的信号。在我12，13年写企业私有云PaaS平台的一系列文章的时候，已经提出了业务能力组件化，组件服务化的微服务架构思想，但是实际应用实施效果并不太理想。

我们可以先看下从单体应用到微服务架构的变化图。

把这个核心搞清楚后，再来看下网上找到的对微服务架构的一些定义和阐述：

微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来。在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程。

微服务不需要像普通服务那样成为一种独立的功能或者独立的资源。定义中称，微服务是需要与业务能力相匹配，这种说法完全正确。不幸的是，仍然意味着，如果能力模型粒度的设计是错误的，那么，我们就必须付出很多代价。如果你阅读了Fowler的整篇文章，你会发现，其中的指导建议是非常实用的。在决定将所有组件组合到一起时，开发人员需要非常确信这些组件都会有所改变，并且规模也会发生变化。服务粒度越粗，就越难以符合规定原则。服务粒度越细，就越能够灵活地降低变化和负载所带来的影响。然而，利弊之间的权衡过程是非常复杂的，我们要在配置和资金模型的基础上考虑到基础设施的成本问题。

在了解了微服务架构后，我们来分析下微服务架构又哪些缺点和难点。

微服务模块拆分后，各微服务间集成复杂度指数级增加

简单举例来说，一个企业已经实施了5个业务系统，业务系统之间有10个接口。如果全部微服务化则可能设计到50个微服务模块，上100个接口和集成点。可想而知，在彻底实施微服务后，我们前期架构设计，后期集成和管控的复杂度增加10倍以上。

这种集成难度会远超大多数人想象，如果拿真实做的项目来说，如果谈业务系统只有3个，而到微服务模块级别则有接近60个，而实际涉及到的集成接口上1000个。我们做任何一个复杂端到端业务的联调基本就需要花2，3周甚至更长的时间。

互联网企业为何适合做微服务架构，其重要的一个原因就是互联网企业如电商平台，在进行了微服务化后各个模块之间耦合性很低，并不会有太多的集成和协同点。或者简单来说，各个微服务模块更多的是向上面的PC端或APP端提供服务能力，而模块横向间接口协同很少。

正是在这种低耦合情况下，协同和集成相对来说容易。而转回到企业内部你会发现，在微服务模块化后，各个模块之间的集成点相当多，特别是业务系统拆分到模块或组件这一个级别后，很多原有内部的集成和依赖点全部暴露出来了，你都需要去很好的管理。由于这里面有大量的横向集成和协同点，因此导致的就是微服务模块间的横向集成异常复杂，远超很多互联网应用，这是实际你会面临的问题。

微服务模块拆分后，各微服务间集成复杂度指数级增加

只谈微服务架构的松耦合和高扩展性，而不谈开发和集成复杂度的都是耍流氓。

实际上当前很多企业对微服务架构并没有如此迫切，互联网很多企业推行微服务架构更多的还是考虑到巨大的业务并发量下的系统弹性扩展能力，而实际大多数企业内应用往往并没有如此海量并发。其次，即使在并发量增加的情况下通过进行代码本身的优化，数据库调优或者升级硬件服务器资源都可以较好的解决性能问题。而做这些事情投入的成本远远小于微服务架构带来的开发复杂度增加成本，后期的运维管控成本。

要做到完全微服务模块独立，微服务架构下最大的一个变化就是数据库也拆分开了，原来的一个业务系统如果分为5个微服务模块，那理论上就是5个独立的后台数据库，而且数据库间还不能随便相互连接和访问。只有这样微服务模块才能做到独立部署和管理。

由于数据库拆分带来两个问题，其一是我们原来很简单的一个跨表查询操作现在无法做了，我们必须调用两个微服务模块提供的服务，查询到数据后再到逻辑层进行组合。其次最大的问题就是如果一个业务操作需要同时更新两个微服务模块的数据，由于服务本身无状态，导致了这种分布式事务问题很难解决。

企业内业务系统很大一个特点就是业务逻辑和规则相对互联网更加复杂，而且有更高的事务一致性要求。正是由于这个原因，无法解决好分布式事务的问题都将直接导致后续数据不一致和业务错误。

原来通过调用项目内一个API方法就能解决的问题，现在要调用远程WS接口才能解决，这本身就增加了开发和调试的复杂度。一个微服务模块与外部其它模块的集成和协同越少，你会发现该微服务模块和传统业务系统开发没太大区别，但是当其涉及到完成任何一个功能都需要调用外部微服务模块的服务接口时候，其开发模式和效率上就会带来巨大的变化。

微服务架构下运维难度增加

在实施了微服务架构后，运维的复杂度也是成倍增加，任何一个微服务模块出问题都可能影响到整个业务应用的功能使用。我们在运维时候不仅仅要健康单个微服务模块，还需要健康所有的接口服务监控状态。

如果跟Docker集成了，我们看到整个性能监控和问题分析都会变麻烦了，没有实施微服务架构前发现问题，我们直接可以看应用服务器上类似tomcat或jboss日志，而实施了微服务架构后，应用容器已经是自动部署和动态分配的，原有的故障诊断模式行不通，而需要PaaS平台本身提供完整的预警和日志分析能力。

再次，如果发现了性能问题或故障，我们的解决方案是如何的？我们如何保证不影响到业务运行，不出现数据的丢失，或者在微服务模块扩展的时候不出现业务中断等。这些已经不是简单的部署架构层面的冗余能解决的问题，而涉及到我们在整个微服务架构中的消息策略，事务管理机制，持久化机制等问题。

引入微服务后的实施难度增加

一个企业所涉及到的IT开发和架构能力以及企业本身的IT治理管控成熟度都将直接影响到微服务架构能否实施成功，要知道引入微服务架构后集成和后续运维等的复杂度都会成指数级增长。

方式1：引入的外部开发商进行微服务架构化

如果一个企业本身IT部门规模小，软件以外购为主，那么势必在对ERP等各类软件的选型评估后引入不同的软件产品提供商或软件开发商。那么软件商本身都有了成熟的产品或架构，其产品内部的模块是否符合组件化和微服务架构的要求，我们不得而知。

即使招标要求写明软件提供商提供产品需要基于SOA或微服务参考架构，但是实际上由于企业本身的IT能力和水平往往也无法验证，而对于软件厂商来说一定希望是卖现有产品，减少改造和定制实现利润的最大化。

对于软件开发厂商来说对已有的软件产品是没有微服务架构改造的动力的。那在这种情况下要推动微服务架构实施落地必须的就是企业本身有很强的架构管控能力和甲方话语权。

在曾经实施的案例里面可以看到，甲方在有较强的IT规划和架构设计能力情况下，才可能一开始就划分好微服务模块并且设计好微服务模块间的接口，在进行招标和选型。同时甲方话语权强的情况下，可以完全要求软件供应商按照自己定义好的标准，规范，架构进行微服务模块的开发。

简单点来说顶层架构分解和接口设计能力不在单个微服务模块开发商手里面，而是在甲方手里，或者在甲方请的专门负责规划架构设计的技术咨询团队手里。

在这种模式下，技术咨询团队应该对整体模块划分和后续集成负责，技术咨询团队就需要有业务和技术两方面的能力，同时有类似领域的规划设计经验，系统开发建设经验等。这些本身就对技术咨询团队提出了相当高的要求，可以来讲很少有技术咨询团队达到这个水平，包括埃森哲或德勤等也难。

在微服务架构下，我们希望的是一个业务系统如果由三个微服务模块组成，在我们进行了前期的架构和接口设计后，我们完全可以将三个模块发标给不同的软件开发商建设和实施，然后在根据预先定义的服务接口进行集成。这个从理论上是行得通的，但是实际上出现两个问题。

其一是刚开始的模块划分或接口设计不合理，在后面开发过程中才发现又很难再大变更。
其二是微服务模块间的接口服务太多，导致了模块间的集成和联调异常复杂。

从上面也看到引入微服务架构后，企业本身可以削弱单个软件供应商对企业本身的约束，防止被单一厂商绑定。因此企业没有特色要求，从软件厂商来说没有任何动力和意愿推微服务架构。

方式2：企业自由开发团队实践微服务架构

如果企业本身的IT成熟度没有达到一定阶段，显然是不可能推行实施微服务架构的。这个道理前面已经谈到过，在企业IT建设中，如果连粗粒度的业务系统以及它们之间的集成都管理不好，那么更没有能力管理细粒度的微服务模块。那么如果企业IT成熟度达到一定水平，在推广微服务架构还存在的难点如下：

首先是架构设计能力的显性化，即架构设计这个工作的输入，输出和过程需要更加的显性化出来形成团队都认同的标准工件。一个业务系统没有拆分开时候，虽然有架构设计和组件划分，但是这个工作是属于团队内部的事情，即使架构设计不合理，在后期集成也可以通过诸多变通方式解决掉。而现在是不同的微服务模块可能分派到两个独立的团队开发，原来属于自己内部黑盒的问题变为团队间问题。

简单来说你原来藏着或没做规范的东西太多，而现在这些不能再藏着掖着了，当真要把这些东西拿出来的时候，你才会发现你原来架构能力是有欠缺的。正如我们理解了一个东西，那么要让我们清楚的讲出来困难，那么我们的理解有欠缺。对于我们能讲清楚的东西，要系统的写下来有困难，那么说明我们讲的结构和条理有欠缺。

其次管控要求和规范体系的建立，对于管控要求可以看到如果两个微服务模块分给同一个团队开发，如何才能保证开发的团队保持两个模块的完全独立和解耦，两个模块间不会出现相互交叉的数据库直接调用，也不会存在直接绕开Service接口的其它耦合调用？这些如果没有完整的管控和检查体系我们很难约束。以上即是引入微服务架构后带来的难点或缺点，供参考。自己也长期专注于SOA，微服务，DevOps支撑平台建设实施，欢迎交流。

1. 问题描述

系统软件架构中，现在很流行微服务，那么使用微服务就一定好么？微服务有哪些缺点呢？

问题结论

架构都是为业务而服务的，我们在选择具体哪个架构的时候肯定是基于业务进行选型。微服务适用于大型互联网公司，需求迭代比较快。如果业务相对而言比较简单，单体应用不失为一个很好的选择。

2. 微服务简述

2.1 微服务的理解

• 微服务就是按照业务划分，将一组特定的业务划分成一个服务（比如：支付系统，只是服务库存做操作，不涉及到其他任何业务），每个服务都有自己独立的数据库，独立部署，服务直接通过rest api（或rpc api）进行通讯。每一个独立运行的服务组成整个系统。

• 微服务的架构风格就是一个大型软件系统由一个或多个微服务组成。每个微服务仅负责一件业务任务，系统中各个微服务可被独立部署，更快地交付并推出市场，各个微服务之间是松耦合的。

比如我们所看到的各种电商App，其对接的服务端很可能是成百上千个微服务，即使团队内部，也很难说清楚到底有多少个服务，也许一个页面就涉及到4~5个微服务，其各自均有独立的数据库与之对应。

2.2 微服务的优点

相比起集成式大型应用。微服务主要优点在于：

• 每个服务足够内聚，足够小，代码容易理解、开发效率提高。
• 服务之间可以独立部署，微服务架构让持续部署成为可能。
• 每个服务可以各自进行负载均衡扩展和数据库扩展，而且，每个服务可以根据自己的需要部署到合适的硬件服务器上。
• 容易扩大开发团队，可以针对每个服务（service）组建开发团队。
• 提高容错性（fault isolation），一个服务的内存泄露并不会让整个系统瘫痪。
• 统不会被长期限制在某个技术栈上，在合理的通信机制下，每个微服务可以独立使用自己的技术栈。

2.3 微服务的缺点

• 运维要求比较高：之前就一个war包，现在一个系统中会有很多的服务，每个服务都对应一个war包，维护起来就会变得很麻烦。
• 技术复杂性提高：微服务就会带来一系列的问题，事务问题，Session一致性问题，锁问题，服务治理问题、多环境实例管理问题、微服务架构拆分粒度和时机的把我问题等。

3. 小结

不必强求微服务“全家桶”套餐，理解微服务的优势，也要警惕微服务造成的问题。一般来讲，能单应用就用单应用，业务量大可以考虑做分布式集群。更大规模的场景，单应用已经无法支撑业务，考虑微服务化。为了微服务而微服务完全没有必要，在提出微服务概念以前，一个大系统本身分成很多小系统，这和现在的微服务并没有本质的区别。而微服务本质是应对复杂的系统架构，n个小团队维护大的系统规模，在遗留系统中做架构演进，各个微服务独立部署又紧密集成，共同支撑业务系统提供服务。

作者：夕阳雨晴，欢迎关注我的头条号：偶尔美文，主流Java，为你讲述不一样的码农生活。

还是以公司的实际情况来选择技术架构吧，不要为了微服务而微服务。

微服务的特征

微服务是一种软件架构设计思想，它以【单一责任】的功能模块为基础，再利用模组化的方式组合出复杂的大型应用程序；微服务的主要特征有这些：

• 每个微服务的业务功能会尽可能的单一（只关注负责的业务）；

• 可以独立部署；

• 轻量级的通信协议；

• 每个微服务拥有单独的数据持久化（有些项目的微服务改造，数据库依然是一个数据库）；

• 不仅服务微，团队也要“微”；

微服务带来的好处

• 每个微服务可以独立扩展，因为服务微，所以单个服务可以快速扩展；

• 因为彼此没有依赖关系，所以可以独立升级（需要使用到灰度发布）；

• 故障和资源隔离，出现事故只会影响单个或几个微服务（当然如果是关键服务发生问题，影响面也会比较大）；

• 只要约定好通信协议，每个微服务可以采用不同的技术栈；

• 如果采用微服务的架构来管理团队，团队将不再以职责划分（开发团队、需求团队、测试团队、运维团队），每个微服务团队都包含各个方面的人员，合作起来会更加“敏捷”。

微服务的缺点和它的优点一样明显

说是缺点，也可以说是挑战：

• 极大地增加了运维的复杂程度，包括上线发布、BUG排查、故障解决等；如果没有良好的自动化运维平台和工具，上微服务要谨慎（人肉运维会死人的）；

• 数据一致性不好控制；如果是单体服务，几张表的读写通过事务很容易控制，但是在微服务的架构中，数据一致性是一个很大的难题；

• 增加了集成测试的难度；

• 需要一个统筹全局的角色，否则很容易做很多重复性的开发；

• 微服务间的调用会有延迟（通信成本），网络延迟可能带来整体系统的响应缓慢问题；

总之，微服务不仅仅是技术方面的问题，它涉及的方方面面还有很多，还是要选择适合公司的架构。

我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。

题主做软件的应该听说过“没有银弹”这句话吧？如果真有一个能解决所有问题的软件，还要这么多软件开发人员干嘛？如果有人说有，不是没干过软件，就是在打广告。

“微服务”不是银弹，解决不了所有问题，有其自己的适应场景。我大致总结了如下场景：

• 业务发展较快，希望能在后期快速的支撑爆发增长的访问量（首先确认是不是真的业务发展很快）
• 业务非常复杂，且有很多不确定性，可以考虑领域驱动设计+微服务实现
• 项目很大，人员很多，考虑切分为多个小组进行微服务开发
• 需要整合很多的老系统，可以考虑微服务的sidecar模式或者SOA
• 希望在公司层面构建一套统一的业务技术平台。登陆，文件服务，日终服务等，由业务平台提供，开发人员只需要关注业务服务

相对的，需要快速落地的简单业务就不适合微服务，后期维护成本远超成本。

就像，大型超市有多个收银台，小超市也搞多个收银台，营业额还不够发人员工资的。

最后，技术是为业务服务的，一个技术在某个场景的优势，在另一个场景下可能就变成了劣势，抛开业务讨论哪个技术好不好，都是耍流氓～

微服务主要是经过组件分离各自拥有独立的生命周期，并且按需进行扩展，这种方式打破了组件之间的技术依赖，这就允许每个服务各自选择最合适的技术进行实现，即不同的服务甚至可以采用不同的编程语言来实现，一定程度上微服务使技术方案变得更加灵活。

微服务在使用过程中开发、测试、部署等环节十分便捷，整体是以松耦合高内聚的形式存在，符合IT技术思想。但是在实际使用过程中，还是存在一些不足，比如在开发微服务时，对于服务粒度的设计需要对业务理解比较深刻；客户端调用微服务耗时比较严重，随着需求的迭代，管理难度越来越大，服务间耦合度开始增强，代码难以复用和修改等等。

综上所述，对于复杂的大型的项目来说，采用微服务实现就会变得十分复杂且周期也会很长。在这种情况下，通常建议采用SOA架构帮助企业制定正确的IT架构战略（具体包括应用架构、数据架构、技术架构），通过微服务辅助实现应用架构，是一个不错的选择。

从个人从业角度来看的话，我觉得微服务跟人工智能、区块链等一样被很多公司吹的过头了，软件系统架构没有说哪一个是一定好的，不是什么流行就必须要上的，软件架构的核心应该是要结合业务应用场景来设计，这样的架构才是合适和合理的。

现在对于很多政府单位、企事业单位来说，像前几年炒的很火的大数据、人工智能，到现在实际应用到哪个程度了呢？我相信只要是行业内的人都知道，目前别说是大数据了，连基本的一些业务应用系统都没有上全，更别说做数据采集、清洗、整合和挖掘了，传统政府行业目前还没有到达这样的数据体量，这不像互联网公司，电商数据、搜索数据、交易数据等那么多。

那是否不用使用微服务架构呢？这个真的要结合实际情况来看，如一些政府便民服务类的应用，这些是非常适合做成微服务架构的，这类应用因为牵涉到所有居民，用户的使用量和使用频率会比较多，把它做成微服务架构能很好的提升系统的稳定性和访问效率，提升整体的政府服务形象，而其他的一些应用，建议只有牵涉到跨部门数据交换频繁和访问并发要求高的可以考虑采用微服务架构。

希望我的回答，对你有帮助。

我认为没有最好的服务架构，只有最适合的服务架构。微服务好不好要根据公司的业务来判断。很多互联网大公司在做中台化改造是因为业务发展的需要，当业务体量上来之后倒逼公司服务架构和组织架构调整。

微服务的优势显而易见，主要有几个特点：无中心化，松耦合，服务自治，组件化。这样的结构便于将复杂的系统结构拆分，各个服务团队更加灵活，能够提高交付速度，快速响应市场变化。

然而不能为了微服务而微服务，公司在架构选型的时候首先要评估业务体量与复杂度是否有微服务化的必要，如果业务本身不复杂，那么完全没必要去微服务化。否则不仅不能提高业务运行效率，反而为增加开发运维的负担。

微服务的缺点如下：

首先服务的切分需要慎重考虑，微服务化是手段不是目的，最终目的是通过有效的拆分应用，实现敏捷开发和部署，提高交付速度，拥抱变化。

其次微服务应用是典型的分布式系统，需要更加关注服务的可用性和一致性问题。服务注册与发现，容错，降级，熔断，限流等服务治理问题在微服务场景下可能要复杂的多。

第三微服务带来了运维的复杂性。一次完整的业务调用可能需要多个服务协同完成，服务的调用关系更加复杂，可能是串行/并行，可能同步/异步。如果没有强大的工具链的支撑，运维会是一场噩梦。

最后微服务不仅是技术架构的调整也是组织架构的调整。伴随着业务系统微服务化的同时，组织架构也应该打破传统的筒仓效应，更加扁平和灵活。

非常有兴趣来回答题主的问题。

首先，软件架构只有合适不合适，并没有绝对的好坏之分。随着系统、业务的发展，架构也是需要不断进行调整的。架构的选型和行业、企业、团队以及系统、业务等多个方面都有关联，因此我们在进行架构选型时需要从多个维度来分析和论证。回到正题，微服务的优劣势有哪些呢？

一、微服务架构的优势

1、高内聚、低耦合实践者

微服务架构是“模块化”的延伸，是SOA架构的一种思想。微服务体现的并不是服务有多“小”，而是“高内聚、低耦合”的具体实现。在微服务架构中，每个服务都足够内聚，易于迭代和发布。整个系统由多个微服务构成，微服务之间的调用有标准的规范，从而尽可能降低微服务之间的耦合程度。而且，容器时代的到来，使得服务的部署和运维成本进一步的得到的控制。因此，微服务+容器成了很多企业追捧的方案。

2、服务的专注程度高

每个微服务都只专注与其自身，有助于降低开发难度以及提升开发效率，同时也可以让整个系统的层级和组成变更清晰和调理，降低系统整体的维护难度。

3、语言、技术栈不受限

在微服务架构中，服务之间调用都满足公共的标准，不再关注具体的技术实现。因此，在开发语言和技术栈的选择上会更加灵活。

二、微服务架构的劣势

1、微服务架构是天然的分布式架构，因此其继承了分布式架构的所有劣势

分布式和单体应用在设计、开发、维护层面的差异是巨大的，最经典的问题就是数据一致性问题（分布式事务），此外还有维护成本高（相对）、定位问题困难（相对）、等等问题。虽然Docker出现大大降低了自动化的成本，部署服务的成本得到了控制，但是相对单体应用来说，成本还是不容忽略的。

2、对人的要求更高

微服务并不是单纯的进行服务拆分，而是要从相对更高的层面进行设计，而任何业务系统都必然会存在业务的依赖，因此对设计人员的要求人员也会更高。

总之，在架构选择上需要结合实际情况具体进行分析，接下来我举两个例子来说明吧。

1、城市商业银行的系统建设。银行本身是一个对数据一致性有很高要求的行业，大多城市商业银行自身的技术储备有限，系统建设需要依赖第三方（各种外包服务商），而且城商行的规模和交易量相对于互联网企业也有一定的差距。因此，大多城商行在架构选型上更加喜欢具备一定伸缩能力的单体架构，不但可以通过增加软硬件的方式来提升系统的能力，同时也相对易于维护。

2、我们最近在考虑开发一个系统，用于日常办公。用户群稳定且单一，可投入的开发测试人员又非常少，经费也少的可怜，那还搞什么微服务，直接单体干就完了。

以上就是我的一些观点，希望可以帮助到您。

简介

系统架构中，微服务是很流行的，尤其是现在我们的系统的数据越来越大，越来越复杂，为了设计更合理，支持高可用、高性能，最好的实践方式就是进行微服务化。其中的优点就不多说了。单就从缺点层面来分析。

缺点

技术要求变高

对于开发人员的技术要求越来越高，随着服务的微服务化。一个系统的微服务应该怎么拆，拆的维度是什么？这个是没有一定的标准可言，而是要根据项目本身的业务而定，这就需要一个有经验的架构师进行微服务化。而是简单的进行垂直拆分即可。

除此之外你还需要考虑如何避免多个微服务之间开发人员的重复开发工作，做到公共资源的合理分配。微服务中的监控指标数据等。

这样的拆分对于之后的系统升级、扩展是不是合理，会不会导致系统架构重组等问题，都是其中的一个弊端。

运维成本

随着你的微服务化，会导致服务数量的激增，你需要去维护更多的服务，以及服务之间的性能监控，数据调用链等数据指标。而传统的单体方式，本身的调用都是内部的，你只需要维护单个应用即可。

注意，这个也并非是指分布式，而是你的系统微服务化，所以传统单体应用也可以做到高可用。

复杂度高

微服务之间的调用方式是通过RPC方式来进行数据交互，相比传统模式，你需要考虑过载、消息丢失、重试、负载等场景，需要处理的逻辑也很多。

首先你需要有一个注册中心，来帮助微服务之间的调用，这是一个需要额外实现的点。

另外在服务调用（服务发现）的时候，会存在负载均衡、容错、代理透明、RPC协议中的序列化、协议编解码等比较复杂的详细逻辑，都是需要微服务化需要去考虑的。

分布式锁、分布式事务层面的问题，你都需要再进行设计，在传统的模式下，这些都是在同一个应用里面进行，不存在问题。但是微服务化后，你为了保证数据一致性，这些相关的点，都是你需要进行额外的开发。难度成本也会成倍加高。

性能层面

随着你需要为了微服务化，而加入更多的解决方案的时候，你的系统会变得更加的复杂，虽然架构清晰，设计合理。但是其中的性能问题，也是你不得不考虑的问题，越多的中间件组合在一起，只要其中一个环节出现问题。你整体的性能就会大打折扣，比如你微服务RPC环节、通信延迟、微服务宕机等情况。不像传统模式，环节少。

总结

微服务化的优点很多，但是同时带来的问题也是客观存在的开发要求高、复杂性、性能等。

针对以上的一些拙见，个人的建议是对于你是否引入微服务化，应当考虑维度在于业务逻辑和系统边界是否清晰。可以先从最简单的传统单机模式开发，渐渐稳定系统后可以再慢慢的微服务化的拆分工作。

微服务一般用于大型嗯架构 比较重量级 更多的可以隔离 解藕 适合数据中台 云平台 大数据平台等 缺点就是不太灵活 小型的系统平台没有使用的必要 不如使用ssm

微服务之前的架构——单体架构

在微服务没有盛行的时候，所有的企业都是基于单体架构。也就是JAVA的一个WAR包，GoLang的单一可执行文件，Ruby或

Node.js

单体架构存在多种好处，包括：

1. 开发简单

2. 易于更改

3. 测试相对简单直观

4. 部署简单

5. 横向扩展简单

...

但是，随着时间的推移，开发、测试、部署和扩展都会变得非常困难。

随着公司的发展，研发团队规模不断状大，代码库规模变大。曾经小巧、简单的，由一个团队开发维护的项目，经过多年成长，演变成一个由大团队开发的巨无霸单体架构应用程序。

如下图所示

单一源代码仓库导致额外的沟通和协调成本，从代码得交到生产环境部署需要经历很多周折，变更必须等待手工测试。 应用变得庞大、复杂、不可靠、难以维护。

也就是说，当单体架构变得过度庞大和复杂，以至于任何一个开发者都很难理解它的全部，修复软件中的问题和正确地实现新功能将变得困难且耗时，而且非常容易出问题。

解决单体架构问题-微服务（忽略SOA等过程发展....）

如图，微服务的概括定义是：把应用功能性分解为一组服务的架构风格。每一个服务都是由一组专注的、内聚的功能职责组成。

所以，微服务可以有这些好处

1. 大型复杂应用程序可以持续交付和持续部署

2. 每个服务相对较小并容易维护

3. 服务可以独立部署

4. 服务可以独立扩展

5. 可以实现团队的自治

6. 更好的容错性等

...

但是，微服务同样也来带了弊端。

1. 服务的拆分和定义是一项挑战

2. 分布式系统带来的各种复杂性，使开发、测试和部署变得困难

3. 当部署跨越多个服务的功能时需要谨慎地协调更多开发团队

...

内容小结

所以，微服务是一把好处和弊端共存的双刃剑，采用微服务架构是一个需要认真思考的决策。

在使用微服务架构时，一些问题无法回避，必须得到解决。每个问题都可能存在多种解决办法，同时伴随着各种权衡和取舍，并没有一种完美的解决方案。

在开发中使用单体架构还是直接使用微服务架构，需要根据具体的情况来判断。

一切的脱离场景说架构，都是而流氓。