vlambda博客
学习文章列表

微服务架构的拯救之道

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

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

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

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

  • 服务可以独立部署;

  • 服务可以独立扩展;

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

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

  • 更好的容错性。

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

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

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

  • 如何拆分服务?

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

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

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

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

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

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

本社群适合哪些人加入?

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

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

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