微服务架构简介（1）—微服务架构的特征

软件架构可以定义为系统设计的一组规则和原则，它定义了软件系统的元素、行为、结构和不同组件之间的关系。在20世纪80年代初期，出现了一些大型软件系统，亟需一种统一的模式（也就是后来的架构）来解决设计这些庞大系统所面临的一些常见问题。从那时开始，演化了今天我们所熟知的“软件架构”的概念。自此之后，很多架构类型被引入到大型软件系统的设计当中。细细数来，软件行业已经见证了从不共享架构（shared nothing），到单体架构（monolithic），到客户-服务器架构（client-server），到分布式多层架构（n-tire），再到面向服务架构（service-oriented architecture，SOA）等架构风格。微服务架构无疑就是这条演化链上的一个新节点。近年来，微服务这个词的热度在各种软件开发者/架构师社区中呈指数级增长。我们经常听到一些采用了单体架构的组织抱怨发布周期太长、调试烦琐、维护成本高、扩容难等问题。这些问题罄竹难书，以至于即使是少数管理得很好的单体应用也需要花费大量的人力物力来解决这些问题。微服务为解决这些问题提供了一种高效的办法，这也毫无疑问是其日益火热的原因之一。一言以蔽之，微服务架构可以把一个很大、很复杂的问题分解成一系列相对较小的服务，并且每个服务只负责自己分管的那一部分。

微服务架构的基本哲理是：

只做一件事，并把它做到极致。微服务的核心是单一职责原则（Single Responsibility Principle，SRP）。

在微服务架构中，大的业务块会被拆分为一些小的任务，每一个小的任务都依托于一个微服务来完成。在微服务架构的系统中，微服务的数量可多可少，取决于业务需求以及任务被拆分的情况。微服务架构可以给组织带来很多单体架构所没有的好处，但是同时，微服务架构也有自己的一些问题需要解决。我们会在接下来的章节中继续讨论微服务架构的优势和短板。

1.1 常规微服务架构

微服务架构的灵感来自面向服务架构（SOA）。微服务架构没有什么黄金法则，如果我们观摩一下现在软件行业中实现的这些不同的微服务架构，就会发现每项应用都有自己的不同风格的微服务架构。关于微服务，并没有完美或标准化的清晰定义。但是总的来说，我们可以通过一些特征和原则归纳出微服务架构。

1.2 微服务架构的特征

任何呈现出下面这6个原则和特征的架构都可以划归微服务架构的范畴。

系统由两个及以上运行单元或组件组成。这些组件将其自身功能以服务的形式展现出来。每个组件服务于一个业务目标，各个组件之间是松耦合的。组件之间按照预先定义的协议进行交互，协议包括消息队列、HTTP请求/响应模型等。

系统应该是与编程语言无关的，某一个组件可以用Java开发，与此同时另外一个组件可以用.NET开发。单独某一个服务在实现时的技术选型应该不会影响到整个应用的架构。

系统的数据库应该是去中心化的。理想情况下，每个微服务应该享有自己的数据库，该数据库仅供该服务自己使用，任何其他组件或者服务都不能提取或者修改该数据库中的数据。

系统中的每个组件都应该是内聚、独立且可以自行部署的。任何一个组件在正常工作和部署的时候都不应该依赖其他组件或者资源。为了实现快速上线，每个组件应该有自己的持续集成/持续部署（CI/CD）流水线。

系统应该有自动化测试。微服务架构最值得称道的特征就是快，在构建、测试到上线的整个周期中，如果没有自动化测试，速度快就是一纸空谈。

任何一个组件/服务的故障都应该是隔离的。单个服务的故障不应该拖垮整个应用，也不应该影响其他组件和服务。为了做到这一点，应该有一些故障回滚的机制。意思是说，如果某个服务出现了故障，它应该能够很容易地回滚到之前的一个能正常工作的版本。下面我们举个简单的例子来具象化我们所说的这些原则。

.2.1 问题定义

假设我们需要一个能根据注册用户的权限生成打折优惠的在线购物应用。对于铂金用户打八折，黄金用户八五折，白银用户九折，普通访客九五折。

1.2.2 解决方案

在这个架构中，我们有两个微服务。第一个服务用来验证用户权限，这个服务需要接受用户登录时的认证信息，然后将用户的权限等级作为应答返还给消费者。第二个服务接受一个权限等级，然后按照用户的购物车（购物车本身应该是另外一个服务）返回适用的折扣比例。在图1-1所示的架构图中，有两个组件，它们分别有各自对应的数据库。假设这两个组件都以REST接口的形式公开其服务。消费者可以在认证服务MS1中通过登录认证信息得到用户的详细信息，包括用户的权限等级，然后可以在第二个折扣服务MS2中，通过权限等级得到折扣百分比。

图1-1

该解决方案贴合了哪些微服务架构的原则每个服务只为一个业务目的服务（原则1）。每个服务可以是不同平台的，相互之间无影响（原则2

）。每个微服务都有自己独享的数据库（原则3）。多个服务之间是相互独立的，也就是说它们不共享各自的数据库，并且可以各自独立部署（假设已经有了相应的CI/CD流水线，也就是原则4）。现在我们假设在某些极少数的情况下，认证服务MS1由于运行时异常或者内存泄漏

问题挂掉，此时消费者在访问认证服务时，会得到404的HTTP状态码响应。404（未找到）会被消费者理解成该用户在数据库中不存在，此时消费者会将该用户理解为普通访客，紧接着就会按照普通访客的方式计算折扣。也就是说，系统始终处于运行状态。认证服务MS1故障并没有危害其他正在运行的服务（对应原则6故障隔离）。

在传统的单体架构中，如果出现这种问题（内存泄漏），我们就需要重启整个应用，包括其中的所有组件，也就是说整个系统会有一段死机时间。

微服务架构成功的基础是深入分析问题领域，并将整个应用程序拆分成若干恰到好处的较小的独立组件。拆分做得好，架构就能朝好的方向继续演进。典型的微服务架构的示意图如图1-2所示。

一般而言，每个开发团队只负责一个微服务。根据微服务的大小和复杂程度，团队成员可多可少。每个微服务应该有自己的发布计划，某个微服务的部署过程不会影响到另一个微服务的部署。如果在某个时间点上，有5个微服务进展到测试和质量分析（QA）阶段，并且只有2个通过了质量分析阶段，那么就只有这2个微服务可以发布到生产环境，它们的发布不应该受其他微服务的影响也不应该依赖于其他微服务的发布。

原文网址：https://www.epubit.com/book/detail/27566

内容来源：异步社区；版权属【人民邮电出版社 异步社区】所有，转载已获得授权；未经授权，不得以任何方式复制和传播本书内容，如需转载请联系异步社区。