微服务业务架构体系定义

在讲述微服务业务架构体系前，我们首先要理清楚业务微服务是什么？这需要澄清两个概念。一个是技术微服务，一个是业务微服务。技术微服务是一个微服务类型，是用技术层面上提供服务的微服务，如文件微服务，缓存微服务，分布式微服务、目录微服务、数据存储微服务、消息微服务、安全微服务、认证微服务等等。业务微服务是针对解决具体业务应用问题而把各个业务组件封装成的微服务，这也是一种微服务类型。如用户权限微服务、支付微服务等等。

在微服务技术架构体系中，业务微服务主要就是其中的服务架构部分，如图1所示，在框内的这部分形成的架构才是业务微服务架构。

图1微服务架构中业务微服务图

业务微服务有五个特征：

业务微服务与IT实现要分离。IT实现的方式有很多，比如不同的编程语言，各式各样的技术框架等等。业务微服务与IT实现分离，可以不依赖一些有限制特征的开发语言和技术框架的约束。这样能保证系统业务逻辑必须按照真实的业务场景来描述，而不受IT实现手段的强制性的约束和限制。

业务微服务的独立可测试性。业务微服务必须能独立测试，不需要表现层（如UI）、存储层（如缓存和数据库），运行容器（如Web服务器、应用服务器等）或者一些其他的外部条件的限制和缺失。

业务微服务与外部计算机依赖环境等松耦合。比如，业务微服务与UI分离。这样可以在不改变UI的同时，能非常容易独立地修改业务微服务内容。当把系统的UI从Web UI改成控制台UI，并不需要改变任何业务微服务提供的微服务。与数据库的分离。能很方便地在各种关系数据库中切换，如Oracle，SQL Server，Sybase、MySQL或半关系数据库如Mongo DB，BigTable，CouchDB或其他数据库等。业务微服务决不能依赖这些数据库。业务微服务还需要与外部运行环境和基础设施的分离，这样业务微服务并不需要知道任何的基础设施结构，无论是公有云，还是私有云，或是混合云。

业务微服务不同于业务服务。两者出于需求和设计的不同阶段。业务微服务最终一定是要由IT技术来实现的业务服务。我们在谈论业务架构的时候，总喜欢引用业务服务的概念，某个业务服务包括几个业务功能。但业务微服务不是业务架构的业务服务，业务架构中的业务服务并不是全部都要通过IT技术来实现。这是两者的区别。根据系统架构设计需求和颗粒度的要求，也许会把几个业务服务整合到一个业务微服务中。也许一个业务服务由多个业务微服务来提供。业务微服务是设计层面的服务，而业务服务是需求层面的服务。

业务微服务之间的关系。主要是依赖和被依赖之间的关系。一个业务微服务依赖另一个业务微服务，有调用，引用关系。调用者依赖被调用者，包括有触发、调用、引用、访问等。不同于技术微服务的同步调用或异步调用等。

那么我们如何来说明和描述一个业务微服务？一般而言可以从下面五个属性来表述，即描绘一个业务微服务有五个维度：（1）业务微服务存在的价值，实现的功能；（2）业务微服务的组成和依赖项（依赖组件）；（3）业务微服务的自治模式；（4）业务微服务提供了哪些服务；（5）该业务微服务依赖哪些外部服务。

业务微服务存在的价值，实现的功能。即业务微服务的可用性，一个业务微服务如果不能产生价值，在这个微服务架构中没有作用，那就没有存在的必要。一般可以从该业务微服务实现的功能中提取出其存在的价值。

业务微服务的组成和依赖项（依赖组件）；主要描述业务微服务的内部组件情况。

业务微服务的自治模式，如何能实现这个业务微服务。

业务微服务提供的服务，以列表形式列出该业务微服务提供的服务，如服务名称，服务实现的功能，输入参数，返回结果等。

业务微服务依赖外部服务。

例如：有这么一个支付微服务，我们把它定义为业务微服务，其结构如图2所示。

图2微服务架构中业务微服务图

支付微服务的描述其内容如表1描述。

表1例子：支付微服务的描述

当讨论业务微服务架构时，就要排除所有关于IT实现手段和工具等内容。因为这些内容只是一些实现手段，如采用什么样的编程语言，是否有缓存，是否采用关系数据库，是否在云平台等等，并不是业务本质的内涵。业务微服务就是纯粹的业务，讨论业务问题时不要牵涉到技术问题。

微服务业务架构体系就是把多个业务微服务组合起来的体系架构。微服务业务架构是以业务微服务之间的关系、业务微服务与业务上下文环境之间的关系为内容的系统基本结构以及演化的原理。而这种仅仅是业务微服务的组成形成的架构体系，我们也简称为业务微服务模型。业务微服务模型也是一个组件模型，通过微服务之间定义良好的接口和契约相关联。业务微服务接口采用中立的方式定义，独立于具体实现服务的硬件基础设置平台、操作系统、编程语言、技术框架和平台，业务微服务可以使用统一和标准的方式进行交互和通信。这种具有中立的服务接口定义的特征被称为微服务之间的松耦合。

在这个定义中，概括为两点：（1）它是一种业务信息架构。业务微服务架构不是软件，也不是一种编程语言，更不是一种具体的实现技术和产品，而是一种信息架构。微服务业务架构尝试给出在特定行业或业务场景下推荐采用的一种架构，从这个角度上来说，业务微服务架构是面向业务应用服务的解决方案框架。（2）业务微服务是整个业务微服务架构实现的核心。业务微服务架构的基本元素是业务微服务，业务微服务架构实指定一组实体（微服务提供者、微服务消费者、微服务注册中心、微服务代理和微服务契约），这些实体详细说明了如何提供和消费微服务。遵循业务微服务架构观点的微服务系统必须要有微服务，这些微服务是可互操作的、独立的、模块化的、位置明确的、松耦合的，并且有自己独立的位置。

一个或多个微服务很容易单独地运行。但是，把这些微服务有机地组合起来，实现各个微服务的互联互通，即所有正在运行的微服务需要安排内部业务流程来统筹管理。这显然不是一个技术问题，因为分布式技术是完全可以实现。针对这种问题，这就需要由微服务业务架构来解决。微服务业务架构是一种业务微服务的设计结构，在设计时就要考虑业务微服务相互交互方式。交互方式也非常多，如顺序的交互方式，微服务按照业务顺序，一个一个地调用执行，这样多个业务微服务交互需要经历许多相互等待的阶段，在计算机行业里面叫线性编程（顺序编程），我们常把这种模式叫管道和过滤器架构模式。另一方面，微服务的执行步骤也可以是并行，并在最后一个微服务执行完成所有任务。但是，这并不意味着并行架构就优于线性模式，也不是说线性架构就比并行架构好。重要的是根据具体的业务场景，了解几种最好的几种可能的架构，这样可以轻松地创建一个适合所有要求的优化方案。