微服务架构的优缺点

1.优点

由于每个微服务都足够小，这可以让开发人员快速理解与掌握，而且对于微服务来说项目工程代码少，不会造成IDE速度变慢，开发和调试速度也非常有效率。
微服务架构不会要求我们在一个应用中选用同一个技术栈，每个服务可以根据应用特性、开发人员特长选择合适的开发语言和框架。因为微服务足够小，非常容易进行重构或重写，同时在重构或重写的时候可以选择合适的开发语言和框架，而且一旦有更合适的技术也可以在低风险的情况下对应用进行升级改造，而不致于影响整个应用。通过微服务架构的实施，可以为我们带来开发、运维、升级上的灵活性。
因为每个服务都可以独立进行部署，开发人员可以很快对自己所开发的服务做出变更，而不会影响其他服务，也不会受到其他微服务的影响，持续集成和开发都非常灵活。
每个微服务都可以快速地实施X、Z轴扩展，并且可以为每个服务定义合适的硬件环境（I/O密集型、计算密集型），而不像单体架构应用采用大锅饭的方式，可以为组织节约硬件成本。从另一个角度来说，微服务架构可以进行错误隔离，比如之前所讲的内存泄漏，在微服务场景下，只会影响其本身的微服务实例，而不会对其他微服务造成影响。

• 松耦合：基于微服务架构的应用是一系列小服务集合，这些服务之间通过非具体实现的接口及非专有通信协议进行通信（比如REST），这样只要原接口没有改变，就不会对服务消费者造成任何影响。
• 抽象：一个微服务对其数据结构和数据源拥有绝对的控制权，只有该服务才可以对数据做出修改，其他微服务只有通过该服务才能够访问数据。因此，该服务可以很方便地对所能提供的数据进行有效控制。
• 独立：每个微服务都可以在不影响其他微服务的情况下进行编译、打包和部署，这是单体架构应用所无法做到的。
• 应对用户需求的多样性：微服务架构可以让我们轻松应对不同客户的特殊需求，通过定义良好的接口，可以让不同的微服务承担不同的职责，同时快速部署上线能力可以让用户需求尽早实现。
• 更高可用性和弹性：微服务架构可以认为是一个去中心化的应用，每一个微服务都可以随时上线或下线。这样当某个微服务出现问题时只需要将其下线即可，其他同类型的微服务将承担其功能，对外仍旧可以提供服务，不会造成整个服务无法正常工作。

2. 缺点

• 可用性降低：微服务之间都是通过远程调用进行协作的，而远程调用的代名词就是不稳定，如果没有有效的方案，微服务架构可能会大大降低应用的可用性。当一个服务不可用时，有可能会引起级联反应，最终会造成应用的“雪崩效应”而拖垮整个应用。
• 处理分布式事务较棘手：当一个用户请求的业务涉及多个微服务时，如何保障数据的一致性就成为一个棘手的问题。传统开发通常会使用两阶段提交的解决方案来解决这个问题。但对于微服务架构来说，这个解决方案并不是一个很好的选择，甚至在某些情况下很难实现。
• 全能对象（God Classes）阻止业务拆分：在进行微服务拆分时可能最让人头痛的一个问题就是全能对象。几乎对于任何一个业务应用来说都可能存在一个或多个这样的全能对象。比如，对于电子商城应用中的订单就是这种对象，订单几乎会涉及电商应用中的每一个业务，它会阻止你进行业务拆分。
• 学习难度曲线加大：微服务架构虽然可以将业务分解为更小、更容易开发的模式，但是也需要开发人员学习掌握一系列的微服务开发技术，加大了进入门槛，这也是非常有难度的一个挑战。
• 组织架构变更：虽然对于单独一个微服务的部署简化了，但是整个应用部署的复杂度却提升了，需要涉及服务编排和服务治理等一系列处理，即不仅需要制定微服务之间的部署编排、关联关系、回滚计划等，还需要协调不同的团队，以及在人事组织上进行调整来适应这种变化。

来自SpringCloud微服务架构开发实战