微服务架构设计实践

微服务架构的核心思想是，一个应用是由多个小的、相互独立的、微服务组成，这些服务运行在自己的进程中，开发和发布都没有依赖，因此构建微服务绝不是在单体架构中把服务拆分开这么简单。

一、微服务设计：规模、范围、业务功能

你可能从零开始用微服务来构建应用，也可能重构现有系统，确定微服务的规模，范围和功能都特别重要。让我们讨论一些有关微服务设计的关键问题和对它的误解：

• “微”很容易被误解：很多开发者会倾向于把服务往尽量小的颗粒度去做
• 在SOA方式下，服务都还是以单体架构在运行，用于支持不同的功能。如果依旧采用SAO类似的服务，仅仅是名义上叫做微服务，并不能带来任何微服务的优势。

那我们在微服务中应该怎样设计呢。以下是微服务的设计指南：

• 职责单一原则（Single Responsibility Principle）：把某一个微服务的功能聚焦在特定业务或者有限的范围内会有助于敏捷开发和服务的发布。
• 设计阶段就需要把业务范围进行界定。
• 需要关心微服务的业务范围，而不是服务的数量和规模尽量小。数量和规模需要依照业务功能而定。
• 于SOA不同，某个微服务的功能、操作和消息协议尽量简单。
• 项目初期把服务的范围制定相对宽泛，随着深入，进一步重构服务，细分微服务是个很好的做法。

二、微服务消息

在单体架构中，不同功能之间通信通过方法调用，或者跨语言通信。SOA降低了这种语言直接的耦合度，采用基于SOAP协议的web服务。这种web服务的功能和消息体定义都十分复杂，微服务需要更轻量的机制。

1