微服务的优势
具有边界的健壮模块
有边界的模块化业务，可以随着团队规模的扩大而陆续增加。
微服务最大的好处就是功能模块的划分，彼此可以分离解耦，我想要修改某一部分，只需要弄清楚这个小模块，做些改动。
模块虽然可以解耦，但由于模块间的边界，也造成了一些引用的障碍。单体系统虽然可以很容易的绕过这个障碍，但也会削弱模块的结构和降低团队生产力，所以将模块放入独立的服务，可以使这种自杀式的解决方案难以实现。
在一个单体系统中，使用模块化完全可能，但是它需要纪律来保证。使用微服务，可以实现更好的模块化。
另外，微服务的一个好处就是，和单体架构相比，团队更容易扩张，在项目初期使用微服务，到需要人手的时候，就可以让一大批人涌入。但缺点是可以耗费了更多的人力。
独立部署
服务的部署更加简单容易，另外，因为每个微服务是独立的，所以其中一个出问题不会影响到整个系统。
微服务的一个关键原则是， 每个服务都是系统的一个组件，均可独立部署。所以现在当你做出改变时，你只需要测试和部署一个小服务。如果你把它搞砸了，你不会把整个系统都搞砸。毕竟，事先对故障进行了设计，即使失败了，你的组件也不应该停止其他部分的系统工作，尽管功能上有些退化。
同时，许多服务也需要频繁的部署，那这时候的应用快速部署和快速配置（自动化技术）也就成了微服务的先决条件。对任何以此为基础的服务，都需要持续交付。
持续交付的好处是减少了由想法变成软件的时间。那么，团队可以快速响应市场变化，并快于竞争对手先引入新的功能。
技术的多样性
由于每个微服务都是一个独立的部署单元，你有相当的自由选择需要的技术。微服务可以用不同的语言，使用不同的库，并使用不同的数据存储方式。这使得团队可以选择合适的工具来工作，有些语言和库更适合某些类型的问题。
微服务另外一个好处就是版本问题（我理解的是pom依赖）。单体应用一般使用单一的版本库，这种情况经常会导致版本库升级出问题，系统的一部分可能需要升级，来实现使用它的新功能，但不能因为升级而中断系统的另一部分。处理库的版本问题是其中的一个难题，因为随着代码库的增大，难度会呈指数级增长。
用单体架构系统，早期对语言和框架的决定是很难逆转的。经过十年左右，这些的决定可能会限制团队并使团队陷入尴尬的技术境地。微服务让团队尝试新工具，并逐步一次迁移系统的一个服务，使新老技术有所关联。
微服务的附加成本
分布式
分布式系统编程相对困难，因为远程调用慢，所以可能总是会存在失败的风险。
微服务采用分布式系统来提高模块化。但是分布式软件有一个主要的缺陷，就是分布式系统本身。
首先是性能，微服务使用远程调用的方式来进行信息的传递，如果服务调用了一些远程服务，远程服务又调用了其他的远程服务，这些时间加起来，延迟也是很久的。但也可以降低延迟，第一种方法是使用粗粒度的API，减少调用的数目，但也会使程序变复杂。第二种方法就是使用异步通信。如果六个服务异步并行调用，延迟只会是那个最慢的调用，而不是所有调用延迟的总和。这大大改善了性能，但也带来了认知成本。异步编程很难，你很难用好它，而且很难调试。
速度之后就是可靠性的问题。你期望in-process函数调用能够成功，可是一个远程调用可能在任何时间失败。在很多的微服务中，甚至有很多的潜在的故障点。
最终一致性
在分布式系统中，保持强一致性是非常困难的，所以必须要处理最终一致性。
在分布式系统上，存在这种情况，更新被节点P收到，请求却被另一个节点G处理。直到节点G从节点P那儿得到更新之前，一直处于数据不一致的状态，虽然最终会变成一致的，但业务逻辑可能会停滞在对不一致的信息上做出决策，当这种事发生时，就比较麻烦。
微服务带来了最终一致性的问题，是因为他们坚持对去中心的数据管理。单体架构在这些问题上同样不能全身而退。随着系统的增长，更需要使用缓存来提高性能，缓存失效是 另一个困难的问题。
操作复杂性
你需要一个经验丰富的运营团队来管理很多需要定时重新部署的服务。
当单体应用变成几百个微服务的时候，迅速部署独立的小单位成了运维的福音，但也增加了额外的复杂度。
持续交付在单体应用和微服务中一样重要。没有自动化协作，持续交付也无法处理那么多的服务。运维的复杂性也是由管理这些服务和监控的需求的增加而增加。
处理这种运维复杂度，需要一个新的技能和工具——重点是技能。工具仍然是不成熟的。要想高效解决这个问题，需要引入一个DevOps文化：开发者和运维之间的紧密合作，每个人都参与软件交付。
总结
单体架构和微服务并不是简单的二选一。两者都是模糊的定义，意味着大多数系统都将在一个模糊的边界区域。当然也还有其他系统，不适合这两个类别的。大多数人，讨论微服务时用单体架构作对比，这是因为它们更常见，但我们必须记住，还是有系统不属于这两类的。我认为，单体架构和微服务是架构设计领域重要的两部分。它们值得被讨论，因为它们存在有趣的特性，以及有用的讨论，但是没有合适的架构师可以对它们在架构设计领域进行一个全面的区分。
总结起来，微服务的好处：微服务提高了生产效率，但同时也带来了复杂性。所以如果可以用单体架构管理好系统，那么就无需微服务。
对微服务的讨论不应该让我们忘记了更重要的问题，驱动软件项目成功和失败的重要因素。软因素如团队中人的素质，以及他们如何彼此合作，与领域专家的沟通能力，这都会对是否使用微服务有更加的影响。在纯技术层面上来讲，更重要的是把重点放在干净的代码、完善的测试，并持续关注架构的演化进步。
