微服务架构的拯救之道

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

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

• 使大型的复杂应用程序可以持续交付和持续部署；

• 每个服务都相对较小并容易维护；

• 服务可以独立部署；

• 服务可以独立扩展；

• 微服务架构可以实现团队的自治；

• 更容易实验和采纳新的技术；

• 更好的容错性。

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

这是与单体架构的不同之处，单体架构之下的技术选型会严重限制后期新技术的尝试。

但微服务架构也存在一些弊端和问题，比如：

• 如何拆分服务？

• 分布式系统带来的各种复杂性，使开发、测试、部署变得更困难。

• 在应用开发的哪个阶段可以使用微服务架构？

• 当部署跨越多个服务的功能时，如何协调更多的开发团队？

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

目前各大厂在微服务实践中踩了哪些坑？获得了哪些经验？InfoQ 与华为云原生团队共建【容器魔方】技术社群，扫描下方小助手二维码，回复：公司 + 职位 + 姓名，加入社群，探讨：微服务架构到底是什么？

当下，你可能正“纠缠”于大型复杂的单体应用程序，每天开发和部署应用程序的经历缓慢而痛苦。微服务架构也许非常适合你的应用程序，但是掌握它，你还需要听听别人的建议。

软件开发人员、架构师、CTO 或工程研发的副总裁。

你目前正在经历单体架构的“痛苦”。

如果你觉醒到微服务的重要价值，正在企图有所改变。