当下，针对大型复杂应用的开发，越来越多的共识趋向于考虑使用微服务架构。但微服务到底是什么？网络上有各种各样的说法，有从代码行数角度去定义，比如微服务是微小的、不超过 100 行代码；还有从开发周期的角度去定义，微服务是开发周期在两周之内。还有比较通用的、被广泛认可的一种定义是面向服务的架构，由松耦合和具有边界上下文的元素组成。

微服务架构的好处很明显，主要有以下几点：

使大型的复杂应用程序可以持续交付和持续部署；
每个服务都相对较小并容易维护；
服务可以独立部署；
服务可以独立扩展；
微服务架构可以实现团队的自治；
更容易实验和采纳新的技术；
更好的容错性。

如果对一项新技术的尝试以失败告终，那么采用微服务架构可以直接放弃这部分工作，而不至于对整个应用带来风险。

这是与单体架构的不同之处，单体架构之下的技术选型会严重限制后期新技术的尝试。
但微服务架构也存在一些弊端和问题，比如：

如何拆分服务？
分布式系统带来的各种复杂性，使开发、测试、部署变得更困难。
在应用开发的哪个阶段可以使用微服务架构？
当部署跨越多个服务的功能时，如何协调更多的开发团队？

微服务是一把双刃剑，好处不言而喻，困难和挑战也同时存在，正是因为这些困难，采用微服务架构是一个必须谨慎思考的决定。在使用微服务架构时，一些问题无法回避，必须得到解决。坦白说，没有一个完美的解决方案，每个问题都可能存在多种解决方法。

创作场景

微服务架构的拯救之道