低调的牛肉
我认为没有最好的服务架构，只有最适合的服务架构。微服务好不好要根据公司的业务来判断。很多互联网大公司在做中台化改造是因为业务发展的需要，当业务体量上来之后倒逼公司服务架构和组织架构调整。
微服务的优势显而易见，主要有几个特点：无中心化，松耦合，服务自治，组件化。这样的结构便于将复杂的系统结构拆分，各个服务团队更加灵活，能够提高交付速度，快速响应市场变化。
然而不能为了微服务而微服务，公司在架构选型的时候首先要评估业务体量与复杂度是否有微服务化的必要，如果业务本身不复杂，那么完全没必要去微服务化。否则不仅不能提高业务运行效率，反而为增加开发运维的负担。
微服务的缺点如下：
首先服务的切分需要慎重考虑，微服务化是手段不是目的，最终目的是通过有效的拆分应用，实现敏捷开发和部署，提高交付速度，拥抱变化。
其次微服务应用是典型的分布式系统，需要更加关注服务的可用性和一致性问题。服务注册与发现，容错，降级，熔断，限流等服务治理问题在微服务场景下可能要复杂的多。
第三微服务带来了运维的复杂性。一次完整的业务调用可能需要多个服务协同完成，服务的调用关系更加复杂，可能是串行/并行，可能同步/异步。如果没有强大的工具链的支撑，运维会是一场噩梦。
最后微服务不仅是技术架构的调整也是组织架构的调整。伴随着业务系统微服务化的同时，组织架构也应该打破传统的筒仓效应，更加扁平和灵活。
攻城狮Bilbo
还是以公司的实际情况来选择技术架构吧，不要为了微服务而微服务。
微服务的特征
微服务是一种软件架构设计思想，它以【单一责任】的功能模块为基础，再利用模组化的方式组合出复杂的大型应用程序；微服务的主要特征有这些：
每个微服务的业务功能会尽可能的单一（只关注负责的业务）；
可以独立部署；
轻量级的通信协议；
每个微服务拥有单独的数据持久化（有些项目的微服务改造，数据库依然是一个数据库）；
不仅服务微，团队也要“微”；
微服务带来的好处
每个微服务可以独立扩展，因为服务微，所以单个服务可以快速扩展；
因为彼此没有依赖关系，所以可以独立升级（需要使用到灰度发布）；
-
故障和资源隔离，出现事故只会影响单个或几个微服务（当然如果是关键服务发生问题，影响面也会比较大）；
只要约定好通信协议，每个微服务可以采用不同的技术栈；
如果采用微服务的架构来管理团队，团队将不再以职责划分（开发团队、需求团队、测试团队、运维团队），每个微服务团队都包含各个方面的人员，合作起来会更加“敏捷”。
微服务的缺点和它的优点一样明显
说是缺点，也可以说是挑战：
极大地增加了运维的复杂程度，包括上线发布、BUG排查、故障解决等；如果没有良好的自动化运维平台和工具，上微服务要谨慎（人肉运维会死人的）；
数据一致性不好控制；如果是单体服务，几张表的读写通过事务很容易控制，但是在微服务的架构中，数据一致性是一个很大的难题；
增加了集成测试的难度；
需要一个统筹全局的角色，否则很容易做很多重复性的开发；
微服务间的调用会有延迟（通信成本），网络延迟可能带来整体系统的响应缓慢问题；
总之，微服务不仅仅是技术方面的问题，它涉及的方方面面还有很多，还是要选择适合公司的架构。
我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。
会点代码的大叔
微服务之前的架构——单体架构
在微服务没有盛行的时候，所有的企业都是基于单体架构。也就是JAVA的一个WAR包，GoLang的单一可执行文件，Ruby或
Node.js
的一个目录和它之下的子目录中包含的各种源码。单体架构存在多种好处，包括：
1. 开发简单
2. 易于更改
3. 测试相对简单直观
4. 部署简单
5. 横向扩展简单
...
但是，随着时间的推移，开发、测试、部署和扩展都会变得非常困难。
随着公司的发展，研发团队规模不断状大，代码库规模变大。曾经小巧、简单的，由一个团队开发维护的项目，经过多年成长，演变成一个由大团队开发的巨无霸单体架构应用程序。
如下图所示
单一源代码仓库导致额外的沟通和协调成本，从代码得交到生产环境部署需要经历很多周折，变更必须等待手工测试。 应用变得庞大、复杂、不可靠、难以维护。
也就是说，当单体架构变得过度庞大和复杂，以至于任何一个开发者都很难理解它的全部，修复软件中的问题和正确地实现新功能将变得困难且耗时，而且非常容易出问题。
解决单体架构问题-微服务（忽略SOA等过程发展....）
如图，微服务的概括定义是：把应用功能性分解为一组服务的架构风格。每一个服务都是由一组专注的、内聚的功能职责组成。
所以，微服务可以有这些好处
1. 大型复杂应用程序可以持续交付和持续部署
2. 每个服务相对较小并容易维护
3. 服务可以独立部署
4. 服务可以独立扩展
5. 可以实现团队的自治
6. 更好的容错性等
...
但是，微服务同样也来带了弊端。
1. 服务的拆分和定义是一项挑战
2. 分布式系统带来的各种复杂性，使开发、测试和部署变得困难
3. 当部署跨越多个服务的功能时需要谨慎地协调更多开发团队
...
内容小结
所以，微服务是一把好处和弊端共存的双刃剑，采用微服务架构是一个需要认真思考的决策。
在使用微服务架构时，一些问题无法回避，必须得到解决。每个问题都可能存在多种解决办法，同时伴随着各种权衡和取舍，并没有一种完美的解决方案。
在开发中使用单体架构还是直接使用微服务架构，需要根据具体的情况来判断。
一切的脱离场景说架构，都是而流氓。
java架构笔记
简介
系统架构中，微服务是很流行的，尤其是现在我们的系统的数据越来越大，越来越复杂，为了设计更合理，支持高可用、高性能，最好的实践方式就是进行微服务化。其中的优点就不多说了。单就从缺点层面来分析。
缺点
技术要求变高
对于开发人员的技术要求越来越高，随着服务的微服务化。一个系统的微服务应该怎么拆，拆的维度是什么？这个是没有一定的标准可言，而是要根据项目本身的业务而定，这就需要一个有经验的架构师进行微服务化。而是简单的进行垂直拆分即可。
除此之外你还需要考虑如何避免多个微服务之间开发人员的重复开发工作，做到公共资源的合理分配。微服务中的监控指标数据等。
这样的拆分对于之后的系统升级、扩展是不是合理，会不会导致系统架构重组等问题，都是其中的一个弊端。
运维成本
随着你的微服务化，会导致服务数量的激增，你需要去维护更多的服务，以及服务之间的性能监控，数据调用链等数据指标。而传统的单体方式，本身的调用都是内部的，你只需要维护单个应用即可。
注意，这个也并非是指分布式，而是你的系统微服务化，所以传统单体应用也可以做到高可用。
复杂度高
微服务之间的调用方式是通过RPC方式来进行数据交互，相比传统模式，你需要考虑过载、消息丢失、重试、负载等场景，需要处理的逻辑也很多。
首先你需要有一个注册中心，来帮助微服务之间的调用，这是一个需要额外实现的点。
另外在服务调用（服务发现）的时候，会存在负载均衡、容错、代理透明、RPC协议中的序列化、协议编解码等比较复杂的详细逻辑，都是需要微服务化需要去考虑的。
分布式锁、分布式事务层面的问题，你都需要再进行设计，在传统的模式下，这些都是在同一个应用里面进行，不存在问题。但是微服务化后，你为了保证数据一致性，这些相关的点，都是你需要进行额外的开发。难度成本也会成倍加高。
性能层面
随着你需要为了微服务化，而加入更多的解决方案的时候，你的系统会变得更加的复杂，虽然架构清晰，设计合理。但是其中的性能问题，也是你不得不考虑的问题，越多的中间件组合在一起，只要其中一个环节出现问题。你整体的性能就会大打折扣，比如你微服务RPC环节、通信延迟、微服务宕机等情况。不像传统模式，环节少。
总结
微服务化的优点很多，但是同时带来的问题也是客观存在的开发要求高、复杂性、性能等。
针对以上的一些拙见，个人的建议是对于你是否引入微服务化，应当考虑维度在于业务逻辑和系统边界是否清晰。可以先从最简单的传统单机模式开发，渐渐稳定系统后可以再慢慢的微服务化的拆分工作。
油腻的Java
题主做软件的应该听说过“没有银弹”这句话吧？如果真有一个能解决所有问题的软件，还要这么多软件开发人员干嘛？如果有人说有，不是没干过软件，就是在打广告。
“微服务”不是银弹，解决不了所有问题，有其自己的适应场景。我大致总结了如下场景：
- 业务发展较快，希望能在后期快速的支撑爆发增长的访问量（首先确认是不是真的业务发展很快）
- 业务非常复杂，且有很多不确定性，可以考虑领域驱动设计+微服务实现
- 项目很大，人员很多，考虑切分为多个小组进行微服务开发
- 需要整合很多的老系统，可以考虑微服务的sidecar模式或者SOA
- 希望在公司层面构建一套统一的业务技术平台。登陆，文件服务，日终服务等，由业务平台提供，开发人员只需要关注业务服务
相对的，需要快速落地的简单业务就不适合微服务，后期维护成本远超成本。
就像，大型超市有多个收银台，小超市也搞多个收银台，营业额还不够发人员工资的。
最后，技术是为业务服务的，一个技术在某个场景的优势，在另一个场景下可能就变成了劣势，抛开业务讨论哪个技术好不好，都是耍流氓～
架构思维
微服务架构主要针对日流量千万以上，研发团队规模不少于50人的公司，如果小于这个规模我建议认真评估是否真的需要采用微服务架构。
— 这是我见过的最良心的话，BAT等大厂出来的技术，不断祸害创业界。很有必要在这里严正指出微服务的使用范围，也就是规模匹配度，很多技术leader丢掉【规模】这个重要参数搭建不适合业务的架构。
想当年，当年毛泽东品读《战争论》，深思到以少胜多的战役，只是凤毛麟角，于是抛弃其他奇技淫巧，集中优势兵力，歼灭有生力量。
作为创业的你， 日订单十万就足够对吗？ 那就不要考虑微服务架构了。
太早了，等融资到D轮都不迟！
创业者田甜
微服务适用于拥有 500 多名工程师的公司。它们通过创建强大的所有权边界，强大的产品定义，松散的耦合来帮助团队管理复杂的相互依赖性，并允许团队以自己的速度和部署节奏进行工作。如果您要与 20 个人一起进行微服务，那您做错了。
程序君
微服务主要是经过组件分离各自拥有独立的生命周期，并且按需进行扩展，这种方式打破了组件之间的技术依赖，这就允许每个服务各自选择最合适的技术进行实现，即不同的服务甚至可以采用不同的编程语言来实现，一定程度上微服务使技术方案变得更加灵活。
微服务在使用过程中开发、测试、部署等环节十分便捷，整体是以松耦合高内聚的形式存在，符合IT技术思想。但是在实际使用过程中，还是存在一些不足，比如在开发微服务时，对于服务粒度的设计需要对业务理解比较深刻；客户端调用微服务耗时比较严重，随着需求的迭代，管理难度越来越大，服务间耦合度开始增强，代码难以复用和修改等等。
综上所述，对于复杂的大型的项目来说，采用微服务实现就会变得十分复杂且周期也会很长。在这种情况下，通常建议采用SOA架构帮助企业制定正确的IT架构战略（具体包括应用架构、数据架构、技术架构），通过微服务辅助实现应用架构，是一个不错的选择。
数通畅联
首先环节多了，系统架构复杂了，管理和维护难度加大了。
其次，微服务之间的调用相对于内部方法调用更加复杂，需要考虑更多的异常处理机制。
第三，微服务的拆分粒度大小一直都是困扰架构小组的问题，不仅仅是大小问题，还要考虑业务划分合理性及应用调用便捷可靠性的问题。
第四，随着系统规模的增长，微服务也会不断增多，系统复杂度增长，故障定位会较为困难。相应的，如果要恢复出错交易，可能需要涉及多个系统的协同和联动，处理时间增加。
第五，多小组之间的协同开发也是个难题，沟通成本增加。
死鬼麻烦
2014年用微服务解决了单体应用的问题；2016年用docker解决了微服务的问题；2018年用k8s解决了docker的问题…… 哪有银弹？只是见招拆招。
