微服务的扩展方式与服务拆分

 微服务扩展方式：

1 微服务架构的定义：把应用程序功能性分解为一组服务的架构风格。

2 SOA与微服务的比较

 

	SOA	微服务
服务间通信	智能管道，例如Enterprise Service Bus(ESB), 往往采用重量级协议，例如SOAP或其它WS*标准	使用哑管道，例如消息代理，或者服务之间点对点通信，使用轻量级协议，例如REST或者gRPC
数据管理	全局数据模型并共享数据	每个服务都有自己的数据模型和数据库
典型服务的规模	较大的单体应用	较小的服务

扩展立方体：

X轴扩展：在多个实例之间实现请求的负载均衡

Z轴扩展：根据请求的属性路由请求

 

Y轴扩展：根据功能把应用拆分为服务

X轴合Z轴扩展有效地提升了服务的吞吐量合可用性，但是没有解决日益增长的开发问题和应用复杂性。

服务拆分

微服务架构的关键思想是如何进行功能分解。传统上的软件架构的目标是可扩展性、可靠性和安全性。当前微服务架构要求能够快速安全地交付软件，这点非常重要。此外还要求用用程序提供跟高的可维护性、可测试性和可部署性。

软件架构的4+1视图模型：

什么是架构的风格

架构风格根据结构组织模式定义了一系列此类系统。更具体地说，架构风格确定可以在该风格的实例中使用的组件和连接器的词汇表，以及关于如何组合它们的一组约束。特定的架构风格提供了有限的元素（组件）和关系（连接器），你可以从中定义应用程序架构的视图。例如：分层式架构风格。分层架构将软件元素按“层”的方式组织。每个层都有明确定义的职责。分层架构还限制了层之间的依赖关系。每一层只能依赖于紧邻其下方的层（如果严格分层）或其下面的任何层。三层架构是应用于逻辑视图的分层架构，可以分为表现层，业务逻辑层，数据持久化层。六边形架构是分层架构风格的替代品。六边形架构风格选择以业务逻辑为中心的方式组织逻辑视图。

应用程序具有一个或多个入站适配器，而不是表示层，它通过调用业务逻辑来处理来自外部的请求。分层架构和六边形架构都是架构风格的实例。

微服务架构是一种架构风格

单体架构：将应用程序构建为单个可执行和可部署组件。
微服务架构：将应用程序构建为松耦合、可独立部署的一组服务。

服务是一个单一的、可独立部署的软件组件，它实现了一些有用的功能。微服务架构中的每项服务都有自己的架构，可能还有独特的技术栈。但是典型的服务往往都具有六边形架构。

微服务架构的松耦合
微服务架构的最核心特性是服务之间的松耦合性 。
服务之间的交互采用API完成，以此

• 封装了服务的实现细节

• 可以在不影响客户端的情况下，对实现方式做出修改。

共享类库的角色
最简单的方式是，在微服务架构中使用共享库。如此，似乎是减少服务中代码重复的好方法。但是可能，会意外地在服务之间引入耦合。
应该努力使用共享库来实现不太可能改变的功能。例如，在典型的应用程序中，在每个服务中都实现一个通用的Money类（例如用来实现币种转换等固定功能）没有任何意义。相反，你应该创建一个供所有服务使用的共享库。

服务的大小并不重要
实际上，服务大小不是一个重要的考虑因素。
更好的目标是将精心设计的服务定义为能够由小团队开发的服务，并且交付时间最短，与其他团队协作最少。

如何定义微服务架构

第一步是将应用程序的需求提炼为各种关键请求。不是根据特定的进程间通信技术（如REST或消息）来描述这些请求，而是使用系统操作这个概念。系统操作（system operation）是应用程序必须处理的请求的一种抽象描述。它既可以是更新数据的命令，也可以是检索数据的查询。

第二步是确定如何分解服务。有几种策略可供选择。

• 一种源于业务架构学派的策略是定义与业务能力相对应的服务。

• 另一种策略是围绕领域驱动设计的子域来分解和设计服务。但这些策略的最终结果都是围绕业务概念而非技术概念分解和设计的服务。

第三步是确定每个服务的API。为此，你将第一步中标识的每个系统操作分配给服务。服务可以完全独立地实现操作。或者，它可能需要与其他服务协作。

识别系统操作

起点是应用程序的需求，包括用户故事及其相关的用户场景。

第一步，创建由关键类组成的抽象领域模型，这些关键类提供用于描述系统操作的词汇表。可以使用名为事件风暴（Event Storming）的技术定义领域模型。
创建领域模型会采用一些标准的技术，例如通过与领域专家沟通后，分析用户故事和场景中频繁出现的名词。

第二步，确定系统操作，并根据领域模型描述每个系统操作的行为。系统操作可以创建、更新或删除领域对象，以及创建或破坏它们之间的关系。

可以把系统操作分为两种类型：
命令型：创建、更新或删除数据的系统操作。
查询型：查询和读取数据的系统操作。

不必在意这些实现细节，识别系统指令的切入点是分析用户故事和场景中的动词。多数与系统操作是命令。查询虽然仅仅是简单地获取数据，但是也同样重要。

抽象的领域模型和系统操作能够回答这个应用“做什么”这一问题。

根据业务能力进行服务拆分

有多种拆分策略可供识别应用服务。但是殊途同归，这些策略的结果都是一样的：一个包含若干服务的架构，这样的架构是以业务而不是技术概念为中心。
我们先来看看第一个策略：使用业务能力来定义服务。

业务能力是指一些能够为公司（或组织）产生价值的商业活动。特定业务的业务能力取决于这个业务的类型。例如，保险公司业务能力通常包括承保、理赔管理、账务和合规等。

组织的业务能力通常是指这个组织的业务是做什么，它们通常都是稳定的。与之相反，组织采用何种方式来实现它的业务能力，是随着时间不断变化的。

一个组织有哪些业务能力，是通过对组织的目标、结构和商业流程的分析得来的。每一个业务能力都可以被认为是一个服务。业务能力规范包含多项元素，比如输入和输出、服务等级协议（SLA）。

业务能力通常集中在特定的业务对象上。例如，理赔业务对象是理赔管理功能的重点。能力通常可以分解为子能力。例如，理赔管理能力具有多个子能力，包括理赔信息管理、理赔审核和理赔付款管理。

从业务能力到服务
某些顶级能力（如会计记账能力）将映射到服务。在其他情况下，子能力映射到服务。决定将哪个级别的能力层次结构映射到服务是一个非常主观的判断。

围绕能力组织服务的一个关键好处是，因为它们是稳定的，所以最终的架构也将相对稳定。

根据子域进行服务拆分

领域模型以解决具体问题的方式包含了一个领域内的知识。它定义了当前领域相关团队的词汇表，DDD也称之为通用语言（Ubiquitous language）。

在微服务架构的设计层面，DDD有两个特别重要的概念，子域和限界上下文。

识别子域的方式跟识别业务能力一样：分析业务并识别业务的不同专业领域，分析产出的子域定义结果也会跟业务能力非常接近。

拆分单体应用为服务的难点

• 网络延迟。

• 同步进程间通信导致可用性降低。

• 在服务之间维持数据一致性。

• 获取一致的数据视图。

• 上帝类阻碍了拆分，更好的方法是应用DDD并将每个服务视为具有自己的领域模型的单独子域。