微服务架构简介

2020-04-08 · 树下魅狐 · · 本文共1,069个字,预计阅读需要5分钟。

什么式微服务?

微服务是指开发一个单个、小型、具备有业务功能的服务。其特点如下:

  • 每个服务运行在自己的进程中,通过轻量的通讯机制(基于HTTP/REST API)联系。
    其中,使用 REST API 更好些,因为 REST本身就是 Web,而不是基于 Web:“Be of the web, not behind the web”。
  • 每个服务可以使用不同的编程语言编写。
  • 每个服务提供一个模块边界,服务上下文。
  • 每个服务都有一个用RPC-或者消息驱动API定义清楚的边界。
  • 每个服务能够通过自动化方式独立地部署在单个或多个服务器上。
  • 每个服务能够通过自动化方式弹性扩展伸缩。
  • 每个服务能够独立更换、独立升级,而不影响其它服务。
  • 每个微服务都有自己的存储能力,可以有自己的数据库,也可以有统一的数据库。

传统应用架构与微服务架构之间的区别

单体式应用的需求的一个小改变会导致整个系统重新构建重新部署,难以让变化只影响在一个模块内,进行扩展伸缩时也只能整个系统扩展,而不能针对其一部分扩展其资源能力。

单体式应用在不同模块发生资源冲突时,扩展将会非常困难。比如,一个模块对CPU敏感,另外一个内存数据库模块对内存敏感。然而,由于这些模块部署在一起,因此不得不在硬件选择上做一个妥协。

单体式应用另外一个问题是可靠性。因为所有模块都运行在一个进程中,任何一个模块中的一个BUG,比如内存泄露,将会有可能弄垮整个进程。除此之外,因为所有应用实例都是唯一的,这个BUG 将会影响到整个应用的可靠性。

康威定律:设计系统的组织,最终产生的设计会反映出组织内部和组织之间的沟通结构

“organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations”

—— Melvin Conway 1960’s

传统的MVC架构,会导致任何一个需求改变都必须要跨团队交流。

微服务这种极度松耦合的架构需要极度松耦合的组织团队。按业务而不是按功能划分服务,每个服务可以使用不同的技术堆栈,每个服务是跨功能的,团队成员是拥有全部的技能。

微服务与SOA的区别

从表面上看,微服务架构模式有点像SOA,它们都是由多个服务构成。
从业务角度看,微服务是具备有业务功能的服务,而SOA中Web服务可能是个非业务功能的原子服务。
从技术角度看,微服务架构模式是一个不包含Web服务(WS-)和 ESB服务的SOA。微服务应用采用简单轻量级协议,比如REST,而不是WS-,在微服务内部避免使用ESB以及ESB类似功能。微服务架构模式也 拒绝使用canonical schema等SOA概念。