什么是微服务?

Kon*_*rad 14 architecture microservices

微服务为此,微服务,但向一个简单的人解释什么是微服务?我是一个简单的程序员,几乎没有理论背景.但我不需要一个术语微服务来做我做的事情.有人可以用简单的话来解释我微服务是什么吗?亚马逊AWS =微服务?

我读到这个:https://en.wikipedia.org/wiki/Microservices但显然我太愚蠢了解这是什么.

Hub*_*iak 46

我自己的微服务,希望简单的术语

石柱

传统的Web应用程序很大.您编写一个在服务器上运行的软件,并以HTML,XML或JSON的形式回复请求.如果您希望Web应用程序执行新操作,请将该功能添加到现有应用程序中.这样的大系统被称为"单片"(巨石是一块非常大的岩石).

整体块是有问题的,因为它们通常随着时间的推移而增大尺寸和复杂性.在团队中开发某些东西时,这是一个问题.开发人员正在向系统添加新代码,并且无法更改或重用现有代码,因为代码片段之间存在许多依赖关系.他们也害怕删除旧代码,因为它可能会在某处使用.

在向客户提供此类代码时,例如将其放在互联网上,我们称之为"部署".部署和部署后的常规测试很困难,因为在一个大系统中,有很多东西可能会破坏.找出问题的原因以及应该解决的问题非常困难,需要人们了解整个问题.

另一个缺点是可扩展性.我们的意思是"我们怎样才能同时为更多用户服务?" 单个Web服务器计算机只能处理并行访问它的一定数量的用户.将该计算机升级到更好的硬件使其能够为更多用户提供服务,但您很快就会达到硬件可能性的范围.此升级称为垂直缩放.我们还可以将我们的Web应用程序放在两个或更多服务器上,以便我们可以处理更多用户.这称为水平缩放.单片应用程序传统上只考虑垂直缩放.

微服务

为了简化大型应用程序的工作流程,我们可以将其拆分为更小的部分.每个部分都有一个特定的用途.我们称之为"(网络)服务".这些Web服务使用起来非常灵活.您可以在现有的单片应用程序中使用它们,无论是在服务器部分还是在客户端部分中.您还可以拥有使用其他Web服务的Web服务.

拆分为单个Web服务允许您松散地耦合您的应用程序.这意味着作为服务的用户,您只依赖于正在运行,可用和正常运行的服务.您不再需要处理其依赖项,编译,部署或测试.

您可以将此责任交给其他开发人员或团队.您不能破坏他们的Web服务,因为您不通过源代码访问它.他们甚至可以使用不同的编程语言,您仍然可以使用他们的服务.

通过决定使用通用格式和通用协议(协议是一种通信方式),可以实现这种独立性.对于Web服务,最流行的格式是JSONXML.最常用的协议是HTTP,因为它很简单,所有现有软件都很好地支持,并且您的浏览器也在使用它.

"微服务"中的"微"一词强调了使这些Web服务尽可能小的想法.如果您需要更复杂的服务,通常最好创建一个依赖于一个或多个其他服务的新服务.

什么时候用哪个?

在以下情况下使用微服务:

  • 从长远来看,你期望很多人在系统上工作(松散耦合)
  • 您需要扩展到数百万并发用户(水平缩放)
  • 您需要一个具有冗余的高可用性系统(模块化)

单片应用程序不是老派或过时的!在某些情况下,它们比微服务具有很多优势.使用它们:

  • 该系统由一个人或一个小团队(单个代码库)开发
  • 系统不需要具有超级可扩展性,例如,它仅供公司内的数百或数千人使用或有限的客户圈(垂直缩放)
  • 您需要一个易于理解,维护,部署和监控的简单架构(简单的基础架构)

使用微服务构建的系统示例

假设您有一个用户可以创建虚拟明信片的应用程序.

下面的图表显示了以单片风格构建的此类应用程序的基本组件: 巨石的例子 (用户界面组件正在越过系统的边界,因为在大多数情况下,我们使用浏览器来呈现应用程序中生成的HTML.)

这就是使用微服务架构实现这样的应用程序的方法: 微服务示例 请注意每个组件如何独立存在,并且仅通过UI进行寻址.

详细地:

  • 一个精简的静态网页,仅包含HTML,CSS和JavaScript
  • 一个微服务卡库,提供卡模板列表,包括其尺寸和意图.
  • 一个微服务缩略图,给定卡片模板名称,为您提供卡片的小预览.
  • 一个微服务渲染器,它需要填充模板和文本.然后渲染卡片图像并返回该图像.

他们如何连线:

  1. 网页包含卡片库和渲染器的URL.用户的浏览器正在调用JavaScript代码发出的这些服务.
  2. 该库正在使用缩略图返回包括缩略图在内的卡片列表
  3. 当用户选择一个时,浏览器将带有用户输入的模板发送给渲染器,浏览器显示返回的图像.

通过这种方法,您最终得到了三个微服务和一个共享的Web GUI.您可以将每个服务提供给自己的开发人员或团队,独立测试,随时部署,甚至可以交换全新的内容,而无需接触其他服务.同时,您必须确保服务彼此兼容,这可能需要API版本控制,动态服务发现(例如,将您连接到所有其他服务的其他高可用性服务)和其他更高级的技术.


小智 5

微服务的正确用语是“适当规模的服务”。范围和规模微服务应基于以下

  1. SRP - 微服务应该有一个单一的变更原因。应该做一件事,并且把它做好。
  2. 业务能力——它应该代表一种业务能力,本质上应该是相对自主的,并且可以由团队执行,与其他能力的交互最少
  3. BC/UL 应以BC 和 UL为基础。这些是来自 DDD 的概念。详情请参阅链接。