微服务架构的特点

相对于单体式应用,微服务有如下优点

技术异构性

在单体架构下,会非常依赖于项目一开始对技术的选择,一旦选择了个技术栈,之后几年都会被绑定在这样个技术栈下,很难应对变化。给我们提供了一个更细粒度使用技术的可能在不同的服务里可以使用完全不同的技术栈不同的语言、框架甚至数据库,真正做到用最适合的技术解决最适合的问题,从而让我们可以更加敏捷地响应需求和市场的变化提高了竞争力。

弹性

弹性弹性工程学的一个关键概念是舱壁。如果系统中的一个组件不可用了,但并没有导致级联故障,那么系统的其他部分还可以正常运行。服务边界就是一个很显然的舱壁。在单块系统中,如果服务不可用,那么所有的功能都会不可用。对于单块服务的系统而言,可以通过将同样的实例运行在不同的机器上来降低功能完全不可用的概率,然而微服务系统本身就能够很好地处理服务不可用和功能降级问题。

扩展

庞大的单块服务只能作为一个整体进行扩展即使系统中只有一小部分存在性能问题,也需要对整个服务进行扩展。如果使用较小的多个服务,则可以只对需要扩展的服务进行扩展,这样就可以把那些不需要扩展的服务运行在更小的、性能稍差的硬件上。

简化部署

在有几百万行代码的单块应用程序中,即使只修改了一行代码,也需要重新部署整个应用程序才能够发布该变更。这种部署的影响很大、风险很高,因此相关千系人不敢轻易做部署。于是在实际操作中,部署的频率就会变得很低。这意味着在两次发布之间我们对软件做了很多功能增强,但直到最后一刻才把这些大量的变更一次性发布到生产环境中。这时,另外一个问题就显现出来了:两次发布之间的差异越大,出错的可能性就更大在微服务架构中,各个服务的部署是独立的这样就可以更快地对特定部分的代码进行部署。如果真的出了问题,也只会影响一个服务,并且容易快速回滚,这也意味着客户可以更快地使用我们开发的新功能。 Amazon和 Netflix等组织采用这种架构主要就是基于上述考虑。这种架构很好地清除了软件发布过程中的种种障碍。微服务部署领域的技术在过去几年时间里发生了巨大的变化,第6章会对该话题做更深入的讨论。

与组织结构相匹配

我们经历过太多由于团队和代码库过大引起问题的情况。当团队是分布式的时候,问题会更明显。我们也知道在小型代码库上工作的小团队更加高效。

可组合性/组件化

分布式系统和面向服务架构声称的主要好处是易于重用已有功能。而在微服务架构中,根据不同的目的,人们可以通过不同的方式使用同一个功能,在考虑客户如何使用该软件时这一点尤其重要。单纯考虑桌面网站或者移动应用程序的时代已经过去了。现在我们需要考虑的应用程序种类包括Web、原生应用、移动端Web、平板应用及可穿戴设备等,针对每一种都应该考虑如何对已有功能进行组合来实现这些应用。现在很多组织都在做整体考虑,拓展他们与客户交互的渠道,同时也需要相应地调整架构来辅助这种变化的发生。在微服务架构中,系统会开放很多接缝供外部使用。当情况发生改变时,可以使用不同的方式构建应用,而整体化应用程序只能提供一个非常粗粒度的接缝供外部使用。如果想要得到更有用的细化信息,你需要使用榔头撬开它!第5章会讨论如何将已有的单块应用程序分解成为多个微服务,并且达到可重用、可组合的目的。

对可替代性的优化

如果你在一个大中型组织工作,很可能接触过一些庞大而丑陋的遗留系统。这些系统无人敢碰,却对公司业务的运营至关重要。更糟糕的是,这些程序是使用某种奇怪的Fortran变体编写的,并且只能运行在25年前就应该被淘汰的硬件上。为什么这些系统直到现在还没有被取代?其实你很清楚答案工作量很大,而且风险很高。当使用多个小规模服务时,重新实现某一个服务或者是直接删除该服务都是相对可操作的。想想看,在单块系统中你是否会在一天内删掉上百行代码,并且确信不会引发问题?微服务中的多个服务大小相似,所以重写或移除一个或者多个服务的阻碍也很小。使用微服务架构的团队可以在需要时轻易地重写服务,或者删除不再使用的服务。当个代码库只有几百行时,人们也不会对它有太多感情上的依赖,所以很容易替换它。

其他

  • 每个微服务相对较小,开发者易于理解, IDE处理效率快,利于提高劳动生产率,Web容器压力小,容器启动速度快,易于提供劳动生产率和生产环境部署速度。
  • 每个微服务都可以独立部署,简化了部署新服务版本的流程。
  • 于规模化开发,多个开发团队可以并行开发,每个团队负责一项服务。这意味着,对于开发这而言,仅需要了解自己负责的一部分业务逻辑即可,然而这对于开发者并不一定是好事情。
  • 改善故障隔离。一个服务宕机不会影响其他的服务。

微服务架构的不足

  • 微服务强调了服务的大小,但实际上这并没有一个同意的标准。
  • 微服务架构带来了分布式数据库事物,以及分布式系统架构。分布式系统相对于单体应用更加复杂。由于CAP原理的约束,使得我们不得不放弃传统的强一致性,而是转而追求最终一致性。
  • 微服务架构对测试也带了很大的挑战。测试人员需要构建部署复杂的分布式应用进行测试。
原文地址:https://www.cnblogs.com/haihua85/p/8684200.html