低调的牛肉
非常有兴趣来回答题主的问题。
首先，软件架构只有合适不合适，并没有绝对的好坏之分。随着系统、业务的发展，架构也是需要不断进行调整的。架构的选型和行业、企业、团队以及系统、业务等多个方面都有关联，因此我们在进行架构选型时需要从多个维度来分析和论证。回到正题，微服务的优劣势有哪些呢？
一、微服务架构的优势
1、高内聚、低耦合实践者
微服务架构是“模块化”的延伸，是SOA架构的一种思想。微服务体现的并不是服务有多“小”，而是“高内聚、低耦合”的具体实现。在微服务架构中，每个服务都足够内聚，易于迭代和发布。整个系统由多个微服务构成，微服务之间的调用有标准的规范，从而尽可能降低微服务之间的耦合程度。而且，容器时代的到来，使得服务的部署和运维成本进一步的得到的控制。因此，微服务+容器成了很多企业追捧的方案。
2、服务的专注程度高
每个微服务都只专注与其自身，有助于降低开发难度以及提升开发效率，同时也可以让整个系统的层级和组成变更清晰和调理，降低系统整体的维护难度。
3、语言、技术栈不受限
在微服务架构中，服务之间调用都满足公共的标准，不再关注具体的技术实现。因此，在开发语言和技术栈的选择上会更加灵活。
二、微服务架构的劣势
1、微服务架构是天然的分布式架构，因此其继承了分布式架构的所有劣势
分布式和单体应用在设计、开发、维护层面的差异是巨大的，最经典的问题就是数据一致性问题（分布式事务），此外还有维护成本高（相对）、定位问题困难（相对）、等等问题。虽然Docker出现大大降低了自动化的成本，部署服务的成本得到了控制，但是相对单体应用来说，成本还是不容忽略的。
2、对人的要求更高
微服务并不是单纯的进行服务拆分，而是要从相对更高的层面进行设计，而任何业务系统都必然会存在业务的依赖，因此对设计人员的要求人员也会更高。
总之，在架构选择上需要结合实际情况具体进行分析，接下来我举两个例子来说明吧。
1、城市商业银行的系统建设。银行本身是一个对数据一致性有很高要求的行业，大多城市商业银行自身的技术储备有限，系统建设需要依赖第三方（各种外包服务商），而且城商行的规模和交易量相对于互联网企业也有一定的差距。因此，大多城商行在架构选型上更加喜欢具备一定伸缩能力的单体架构，不但可以通过增加软硬件的方式来提升系统的能力，同时也相对易于维护。
2、我们最近在考虑开发一个系统，用于日常办公。用户群稳定且单一，可投入的开发测试人员又非常少，经费也少的可怜，那还搞什么微服务，直接单体干就完了。
以上就是我的一些观点，希望可以帮助到您。
空心小窝头
还是以公司的实际情况来选择技术架构吧，不要为了微服务而微服务。
微服务的特征
微服务是一种软件架构设计思想，它以【单一责任】的功能模块为基础，再利用模组化的方式组合出复杂的大型应用程序；微服务的主要特征有这些：
每个微服务的业务功能会尽可能的单一（只关注负责的业务）；
可以独立部署；
轻量级的通信协议；
每个微服务拥有单独的数据持久化（有些项目的微服务改造，数据库依然是一个数据库）；
不仅服务微，团队也要“微”；
微服务带来的好处
每个微服务可以独立扩展，因为服务微，所以单个服务可以快速扩展；
因为彼此没有依赖关系，所以可以独立升级（需要使用到灰度发布）；
故障和资源隔离，出现事故只会影响单个或几个微服务（当然如果是关键服务发生问题，影响面也会比较大）；
只要约定好通信协议，每个微服务可以采用不同的技术栈；
如果采用微服务的架构来管理团队，团队将不再以职责划分（开发团队、需求团队、测试团队、运维团队），每个微服务团队都包含各个方面的人员，合作起来会更加“敏捷”。
微服务的缺点和它的优点一样明显
说是缺点，也可以说是挑战：
极大地增加了运维的复杂程度，包括上线发布、BUG排查、故障解决等；如果没有良好的自动化运维平台和工具，上微服务要谨慎（人肉运维会死人的）；
数据一致性不好控制；如果是单体服务，几张表的读写通过事务很容易控制，但是在微服务的架构中，数据一致性是一个很大的难题；
增加了集成测试的难度；
需要一个统筹全局的角色，否则很容易做很多重复性的开发；
微服务间的调用会有延迟（通信成本），网络延迟可能带来整体系统的响应缓慢问题；
总之，微服务不仅仅是技术方面的问题，它涉及的方方面面还有很多，还是要选择适合公司的架构。
我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。
会点代码的大叔
微服务之前的架构——单体架构
在微服务没有盛行的时候，所有的企业都是基于单体架构。也就是JAVA的一个WAR包，GoLang的单一可执行文件，Ruby或
Node.js
的一个目录和它之下的子目录中包含的各种源码。单体架构存在多种好处，包括：
1. 开发简单
2. 易于更改
3. 测试相对简单直观
4. 部署简单
5. 横向扩展简单
...
但是，随着时间的推移，开发、测试、部署和扩展都会变得非常困难。
随着公司的发展，研发团队规模不断状大，代码库规模变大。曾经小巧、简单的，由一个团队开发维护的项目，经过多年成长，演变成一个由大团队开发的巨无霸单体架构应用程序。
如下图所示
单一源代码仓库导致额外的沟通和协调成本，从代码得交到生产环境部署需要经历很多周折，变更必须等待手工测试。 应用变得庞大、复杂、不可靠、难以维护。
也就是说，当单体架构变得过度庞大和复杂，以至于任何一个开发者都很难理解它的全部，修复软件中的问题和正确地实现新功能将变得困难且耗时，而且非常容易出问题。
解决单体架构问题-微服务（忽略SOA等过程发展....）
如图，微服务的概括定义是：把应用功能性分解为一组服务的架构风格。每一个服务都是由一组专注的、内聚的功能职责组成。
所以，微服务可以有这些好处
1. 大型复杂应用程序可以持续交付和持续部署
2. 每个服务相对较小并容易维护
3. 服务可以独立部署
4. 服务可以独立扩展
5. 可以实现团队的自治
6. 更好的容错性等
...
但是，微服务同样也来带了弊端。
1. 服务的拆分和定义是一项挑战
2. 分布式系统带来的各种复杂性，使开发、测试和部署变得困难
3. 当部署跨越多个服务的功能时需要谨慎地协调更多开发团队
...
内容小结
所以，微服务是一把好处和弊端共存的双刃剑，采用微服务架构是一个需要认真思考的决策。
在使用微服务架构时，一些问题无法回避，必须得到解决。每个问题都可能存在多种解决办法，同时伴随着各种权衡和取舍，并没有一种完美的解决方案。
在开发中使用单体架构还是直接使用微服务架构，需要根据具体的情况来判断。
一切的脱离场景说架构，都是而流氓。
java架构笔记
——什么是微服务：微服务(Microservices Architecture)，它是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。
优点：每一个服务足够内聚，足够的小，所以代码容易理解，这样能够聚焦一个指定的业务功能或业务需求。它开发简单，开发效率也提高，一个服务可能就是专一的只干一件事情。微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的，微服务能够被小团队单独开发， 也能使用不同的语言开发。
微服务易于第三方集成，微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如Jenkins、Hudson等。微服务容易被一个开发人员理解、修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值，它允许你利用融合最新技术， 只是业务逻辑的代码，不会和HTML/CSS或其他界面组件混合，每个微服务都有自己的存储能力，可以有自己的数据库，也可以统一数据库。
缺点：微服务将原来的函数式调用改为服务调用，不管是用rpc，还是http、rest方式，都是增大系统整体延迟。这个是再所难免的了，就需要我们将原来的串行编程改为并发编程甚至异步编程，所以增加了技术门槛。
微服务应用程序是一个分布式系统，这带来了复杂性，开发人员需要选择并实现基于消息传递或RPC的进程间通信机制。此外呢，还必须编写代码来处理部分故障，因为请求的目的地可能很慢或不可用。
TM野指针
在“微服务”这几个字被明确地提出来之前，其实已经有很多it开发团队在实施自己的类似概念了。针对客户不同的业务需要，从设计阶段就开始有意地拆分各项业务功能，使它们之间尽可能地降低耦合度，做到最大程度上的独立；并且在具备足够条件的情况下，将每一个独立服务做单独部署。
这么做的好处显而易见，在设计及开发阶段，独立服务模块就可以交给独立团队去开发，做到整个系统开发时间能够大幅缩短；在实施阶段，无论哪个服务模块需要升级或调整，只要遵循早期设计的接口规范，都能对其它服务做到最低程度的影响，而不是说因为需要调整某一项小功能而导致整个生产系统全面停止工作。
但微服务带来的问题也是很显著的，那就是各项独立服务之间要怎么通信，换言之就是如何做到数据传递的有效性和及时性。所以伴随着“微服务”概念的大规模提出，浮现出了大量的数据通信和交互、消息队列、身份认证同步等等非业务产品和解决方案。并且微服务架构对开发团队的综合项目管理能力也会有一定的要求，否则繁杂的接口设计和沟通会拖垮整个开发过程。
所以说，使用微服务到底好不好，到底要不要使用，还是取决于具体的业务需要。切忌盲目跟风，为了微服务而微服务，很多时候反而会得不偿失。
斯人若月
我认为
没有最好的服务架构，只有最适合的服务架构。微服务好不好要根据公司的业务来判断。很多互联网大公司在做中台化改造是因为业务发展的需要，当业务体量上来之后倒逼公司服务架构和组织架构调整。微服务的优势显而易见，主要有几个特点：无中心化，松耦合，服务自治，组件化。这样的结构便于将复杂的系统结构拆分，各个服务团队更加灵活，能够提高交付速度，快速响应市场变化。
然而不能为了微服务而微服务，公司在架构选型的时候首先要评估业务体量与复杂度是否有微服务化的必要，如果业务本身不复杂，那么完全没必要去微服务化。否则不仅不能提高业务运行效率，反而为增加开发运维的负担。
微服务的缺点如下：
首先服务的切分需要慎重考虑，微服务化是手段不是目的，最终目的是通过有效的拆分应用，实现敏捷开发和部署，提高交付速度，拥抱变化。
其次微服务应用是典型的分布式系统，需要更加关注服务的可用性和一致性问题。服务注册与发现，容错，降级，熔断，限流等服务治理问题在微服务场景下可能要复杂的多。
第三微服务带来了运维的复杂性。一次完整的业务调用可能需要多个服务协同完成，服务的调用关系更加复杂，可能是串行/并行，可能同步/异步。如果没有强大的工具链的支撑，运维会是一场噩梦。
最后微服务不仅是技术架构的调整也是组织架构的调整。伴随着业务系统微服务化的同时，组织架构也应该打破传统的筒仓效应，更加扁平和灵活。
攻城狮Bilbo
大家好，我是一名科技领域的创作者，很高兴为大家回答这个问题，让我给大家解决一下！下面我说一下我的个人观点，希望可以帮助到大家，同时也希望得到大家的认可！
微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。
首先来说下有点：
第一、每个微服务都很小，这样能聚焦一个指定的业务功能或业务需求
第二、微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的
第三、微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值
再来说下缺点：
第一、微服务架构可能带来过多的操作
第二、分布式系统可能复杂难以管理
第三、.当服务数量增加，管理复杂性增加
希望以上为大家分享这一个问题对大家有所帮助，我希望我的分享关于这个问题能够帮助到大家，也同时也希望大家能够喜欢我的分享。
欢迎你们来互相讨论
深度微观察
微服务架构主要针对日流量千万以上，研发团队规模不少于50人的公司，如果小于这个规模我建议认真评估是否真的需要采用微服务架构。
— 这是我见过的最良心的话，BAT等大厂出来的技术，不断祸害创业界。很有必要在这里严正指出微服务的使用范围，也就是规模匹配度，很多技术leader丢掉【规模】这个重要参数搭建不适合业务的架构。
想当年，当年毛泽东品读《战争论》，深思到以少胜多的战役，只是凤毛麟角，于是抛弃其他奇技淫巧，集中优势兵力，歼灭有生力量。
作为创业的你， 日订单十万就足够对吗？ 那就不要考虑微服务架构了。
太早了，等融资到D轮都不迟！
创业者田甜
微服务的初衷大概是因为服务化成本太高，想做低成本的服务化，乃名微服务。但病诊对了，药没开对，多数吃药的反而病情加重了，吃药后因为服务化带来的繁琐和低效更甚以前。总之，病是真病，药是错药。这一点和中台倒很像。
微服务的药方，大多是拆分邪路，restful邪路，独立布署邪路。这些都是增加成本，降低效率的。
以拆分为例批一下（这破概念毛病太多，懒得一一批了）
一个业务的复杂度不会因为拆分而减少。相反还会增加额外的技术成本，协作成本。整体复杂度是升高而不是降低的。开发效率是降低而不是升高的。
正确的做法是
1，了解拆分是业务复杂度到一定程度下，难以控制的分治之法。复杂性无法治理是前提。
简单业务用分布式微服务框架，无疑是火车拉芝麻。效率低下，成本高昂。
2，知道分治这种方法存在的问题，会增加合成成本。警惕拆分，理智分治。分治之法为不得已法。
正确的做法是一只眼看拆分，一只眼看合成。拆分以分治领域复杂度，合成兼顾学习，使用，运维低成本。
大多数人只看前者，忽视后者。这就导致大多数微服务的深入实践效果并不好。这根本上是由于微服务本身的哲学思想分治的必然结果，而大多数人难以体会掌控其中的微妙之处。很难使用的好。
但是类似springboot、springcloud等经过幸存者偏差而存在微服务框架的确是好的。
初学者使用微服务，原业务不动，基础设施换为微服务框架，最初一定会得益于大量基础设施，感觉东西好。
但是，如果不深入拥抱，只是浅尝辄止，只是将框架换为微服务，在微服务原教旨主义者看来不过是换了一件衣服。是假的微服务，是可鄙的，low的。而初学者也难以自视，多数会追求进步。而一旦深入，开始拆分业务。一定会越来越差。
这其中奥妙是第二只眼兼顾合成的要求实在是太高，兼顾合成本质是要预料未知（的业务情况）做应对，使得业务发生的时候极具针对性，使用简单底层本。这前提是大量知识和经验前提这本身已经足够pass掉大多数人了；并且内置业务变化适配也是违反内聚耦合的；其中设计还要掌握尺寸，既不过度设计，还要简单好用；玄之又玄，其难度远超普通开发甚至大多数所谓架构师的水平。很难掌控的住微妙。微服务确实是很好，却不具备方法的一般性。普通的公司、个人极少见到用的好的。
所以，大多数的微服务实践，一定是越深入越烂。所谓拆分一时爽，合并火葬场。霸王枪不是人人都hold的住的。
中台的病，不是服务低效病，而是中国式的业务驱动式开发带来的低效病，最终产生了焦油坑。本质是《人月神话》所描述的软件工程面临的深层次的痼疾。虽然是马云第一个看病，但是效者云集，一时洛阳医贵，人人皆以病为荣，以中台为荣。
虽然不少楚王细腰，但其实也是星星之火，非一日之寒。万企热热闹闹做中台，大部分还都是有病的。人月神话的病，焦油坑的病，谁没有呢？病必定在，不过轻重缓急而已。只要软件在变，业务在变，就有病。不过是变得频率快慢，决定了病的急徐。这是软件内在的规律决定的。
中台病虽然开了一堆的药方，但仔细看看，却发现什么字都没有。另外很多数据中台，技术中台，XX中台，看起来不像药方，倒像蹭饭。
要说和微服务的不同，可能是药方都没开的出来，各种江湖偏方、野郎中纷纷上阵，万众中台，人人试药。不过至今没见到有效果的。不过吃挂了的倒不多见。这倒是不开药方的好处了，好歹乱吃的时候，还是有点辨别的；若大师开了药方，便是虽然直觉不妙，但是捏着鼻子也要硬吃下去的。
中台病难治啊。 阿里最初定了个15一18的三年中台战略，不过一直到19年都没宣布成功。19年行癫宣布阿里不做saas只做被集成。这意味着阿里在业务市场上的疯狂扩张进入了停滞期，业务中台战略碰到了极大困难。19年末业务中台大将玄难离职。星环陨落。
但，阿里中台不成功，未必别人不成功。没有证据证明阿里现在的技术就是最完美无瑕的，不能再做进化的。也没有证据证明中台阿里做不成别人必然做不成。但可以知道的是我们现在的技术和现况距离完美无瑕还差的很远。并且人月深化虽然号称没有银弹，却也没有确切的逻辑和证据能证明这一点。
IT技术管理那些事儿
简介
系统架构中，微服务是很流行的，尤其是现在我们的系统的数据越来越大，越来越复杂，为了设计更合理，支持高可用、高性能，最好的实践方式就是进行微服务化。其中的优点就不多说了。单就从缺点层面来分析。
缺点
技术要求变高
对于开发人员的技术要求越来越高，随着服务的微服务化。一个系统的微服务应该怎么拆，拆的维度是什么？这个是没有一定的标准可言，而是要根据项目本身的业务而定，这就需要一个有经验的架构师进行微服务化。而是简单的进行垂直拆分即可。
除此之外你还需要考虑如何避免多个微服务之间开发人员的重复开发工作，做到公共资源的合理分配。微服务中的监控指标数据等。
这样的拆分对于之后的系统升级、扩展是不是合理，会不会导致系统架构重组等问题，都是其中的一个弊端。
运维成本
随着你的微服务化，会导致服务数量的激增，你需要去维护更多的服务，以及服务之间的性能监控，数据调用链等数据指标。而传统的单体方式，本身的调用都是内部的，你只需要维护单个应用即可。
注意，这个也并非是指分布式，而是你的系统微服务化，所以传统单体应用也可以做到高可用。
复杂度高
微服务之间的调用方式是通过RPC方式来进行数据交互，相比传统模式，你需要考虑过载、消息丢失、重试、负载等场景，需要处理的逻辑也很多。
首先你需要有一个注册中心，来帮助微服务之间的调用，这是一个需要额外实现的点。
另外在服务调用（服务发现）的时候，会存在负载均衡、容错、代理透明、RPC协议中的序列化、协议编解码等比较复杂的详细逻辑，都是需要微服务化需要去考虑的。
分布式锁、分布式事务层面的问题，你都需要再进行设计，在传统的模式下，这些都是在同一个应用里面进行，不存在问题。但是微服务化后，你为了保证数据一致性，这些相关的点，都是你需要进行额外的开发。难度成本也会成倍加高。
性能层面
随着你需要为了微服务化，而加入更多的解决方案的时候，你的系统会变得更加的复杂，虽然架构清晰，设计合理。但是其中的性能问题，也是你不得不考虑的问题，越多的中间件组合在一起，只要其中一个环节出现问题。你整体的性能就会大打折扣，比如你微服务RPC环节、通信延迟、微服务宕机等情况。不像传统模式，环节少。
总结
微服务化的优点很多，但是同时带来的问题也是客观存在的开发要求高、复杂性、性能等。
针对以上的一些拙见，个人的建议是对于你是否引入微服务化，应当考虑维度在于业务逻辑和系统边界是否清晰。可以先从最简单的传统单机模式开发，渐渐稳定系统后可以再慢慢的微服务化的拆分工作。
