【译】微服务 vs API:微服务不仅仅是API

原文链接

开发软件的时候,既要考虑代码的实现也要考虑架构。当以一种逻辑上有意义的方式进行开发的时候,开发会更为有效。除了架构,软件也需要考虑用户交互,以及界面。

API微服务都牵涉到结构与交互。微服务可能会被误解为仅仅是在一个端点上提供一个API。事实上,微服务包含了更多的弹性与功能性。这篇文章会浅析API与微服务的不同,以及微服务能够提供的好处。

开始之前,先看一些定义。

什么是API

首先,让我们看看什么是API。根据维基百科,API是一系列子程序定义,通信协议,以及建立软件的工具。通常情况下,它是一系列定义清晰的方法用于在多个组件之间进行通信。

简单来说,可以将API看做是一个契约,通过一个契约你可以请求一个特定的服务。如今,API大量运用于Web应用,例如社交媒体,银行软件等等。标准的契约让外部程序可以进行交互。

现在,假设你要开发一个与Facebook交互的应用程序。你需要使用 Facebook Graph API 获取数据,例如用户,发布内容,评论等。API简化了使用数据的复杂度并提供了易用的方式让开发者获取数据。

通常的API方法

如今,API通常都以RESTful风格开发。这些API有一系列与HTTP相关的动词,例如:

  • GET
  • POST
  • PUT
  • DELETE

这种一致性的好处是在执行各种操作时有一个统一的标准。四种不同的HTTP动词与CRUD相对应。当在一个应用程序中处理不同的API时,这有助于理解不同操作的含义。

好了,关于API我们就讲这么多,下面让我们看看微服务吧。

什么是微服务

维基百科这么定义微服务: 一种软件开发技术——面向服务架构的变体,以一系列松耦合的服务组织一个应用程序。在微服务架构中,服务是细粒度的且协议是轻量级的。

在我们深入了解什么是微服务之前,让我们看看Monolith。理解微服务与Monolith之间的差别有助于你更好地理解微服务的好处。

微服务的祖先:Monoliths

在早前的软件开发中(以及当前的许多企业环境中),诞生了Monolith的概念。Monolith是一个应用程序,包含了完整的功能集合,在一个地方提供服务,并存储所有内容。它看起来就像这样:

【译】微服务 vs API:微服务不仅仅是API

所有的应用程序组件位于一个地方,包括UI层,业务逻辑层,以及数据访问层。以Monolith方式开发程序是一个简单自然的过程,大部分项目都以这种方式开始。但是添加功能导致了大小与复杂度的增加,随着时间的增加monolith的不断变大带来了很多缺点,包括:

  • 有导致大泥球模式与反面模式的风险
  • 技术栈收到限制。特别是当应用程序变大以后,转向不同的技术栈变得越来越困难,即使之前的技术被认为不再是最好的选择。
  • 修改数据库会影响整个应用程序。例如,如果仅仅是一个业务逻辑需要经常改动,也会迫使重新发布整个应用程序,不仅浪费时间还要承担更多风险。

因此,替代方案就是将monolith分离成微服务。

微服务

让我们将上面的例子转为微服务,程序的架构将像下面这样:

【译】微服务 vs API:微服务不仅仅是API

这个重构中有几个要点:

  • 业务逻辑的细分部分,每个都围绕着一个微服务。整个应用程序不再仅有一个边界,应用程序被拆分开来。程序的复杂度降低,因为不同的的服务之间都有定义良好的交互。例如,允许为每一个服务指派一个团队,负责实现这个抽象的部分。
  • UI层仅需要与客户及事件微服务交互,移除了对账单微服务的依赖。
  • 账单微服务不需要存储数据,它不需要数据访问层及数据库。它直接与客户与事件微服务交互。

这种架构有着诸多优势:

  • 更易于关注点分离。各区域之间的界限能够帮助开发(你只需要关注你自己的微服务,而不是整个应用程序)并能够帮助理解程序的架构。
  • 不像Monolith,微服务可以按照需求使用不同的技术栈。考虑使用一种新语言实现所有内容?仅仅让一个微服务使用新的技术,评估获得的好处,并决定是否继续下去。
  • 整个应用程序的部署变得更为几种。微服务给予你发布不同服务的灵活性。

在上面的例子中,有没有注意到API与微服务其他部分放在一起?我们现在就解释,终于可以讲讲微服务与API的差别了。

微服务与API的区别

微服务与API的主要差别如下:

  • 一个API就是一个契约,为使用者提供指导使用对应的服务。
  • 一个微服务是一种架构设计,将应用程序分成小的,自包含的服务。

根据定义,这意味着,API通常是微服务的一部分,允许微服务进行自我交互。换句话来说,API是作为微服务内部交互的契约,显示与微服务交互的可用选项。

然而,如果我们看了上面的微服务图,我们会发现每个微服务基于它的需求都有轻微的不同,以下是微服务可能有的不同功能的示例:

  • 对一个特定的实体类型提供CRUD操作,例如客户,事件等等。这个服务负责将数据持久化到数据库。
  • 提供一种方法来接收参数并基于计算返回结果。账单微服务可以获取用户和事件信息并返回所需的账单信息,不需要存储数据。

通过上面的例子,我们可能已经发现微服务不仅仅是API。一个完整的应用程序可以包含一系列微服务,每个微服务都用自己的API彼此通信。而且,每个微服务都可以抽象出自身的功能,画出所负责的逻辑边界并分离关注点以获取更易维护的代码库。

总结

希望现在你能更好地理解API与微服务。代码的可维护性与质量都是一个成功的IT策略的至关重要的部分。微服务令你可以两者兼顾。他们使得你的团队更加敏捷,帮助你满足客户需求,并开发出更高质量,更易于维护的代码。

你还在开发monolith代码吗?考虑一下将那些代码分离成微服务吧。一旦你这么做了,你应该就能看出使用微服务的好处。事实上,你甚至可能会转换整个项目。

原文 

https://juejin.im/post/5de0c99351882506db5cb101

本站部分文章源于互联网,本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供。如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。

PS:推荐一个微信公众号: askHarries 或者qq群:474807195,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

转载请注明原文出处:Harries Blog™ » 【译】微服务 vs API:微服务不仅仅是API

赞 (0)
分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址