微服务架构的拯救之道

阅读数:1 2019 年 12 月 20 日 17:43

微服务架构的拯救之道

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

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

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

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

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

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

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

评论

发布