“业务身份”的设计建模与参考模型

承载业务的平台发展到一定阶段，如果想要进一步的提升，就必须解决“业务身份”的问题。

尤其是业务中台，基础价值就是提供共享可复用的业务能力，但是随着平台支撑的业务场景越来越多，每个垂直领域都有各自的定制化需求，平台必须通过某种技术手段来识别出消费的场景，才能进行下一步处理。

“业务身份”的概念最早由阿里巴巴提出：业务平台在对各业务同时提供服务时，需要能区分每一次业务服务请求的业务身份要素，以便提供差异化个性化的服务；因此需要对企业各业务的身份和特征进行建模和区分，其产出即为“业务身份”。

通俗点说，通过“业务身份”来唯一标志一笔请求的“申请”，例如是哪个客户通过哪个渠道使用的哪个场景产品的哪个模式。

简单粗暴点，大部分平台都是通过“请求流水号”来唯一标志一笔业务请求，可惜的是，没有任何的业务含义。

而只要有了”业务身份“，那么我们的平台，就可以提供更精细化的”业务能力“。

我们接下来看一下业务身份的价值。

1

业务身份的价值

一个框架或者理念最大的业务价值，往往在于它最初提出时要解决的问题。

例如中台，阿里做中台的初心是什么？

中台如火如荼的建设了这么多年以后，反过来看，还是这么一些目标。

甚至阿里要拆中台，也不过是因为无法支撑快速创新了，中小业务最好最便捷的方式还是自己建一套。

为了解决这些问题，阿里提出了中台架构，同时对于TMF框架有了“全链路统一的业务身份”的思想，使得平台可以提供业务与业务之间逻辑隔离的能力，而不是仅仅SPI架构关注技术组件。

笔者在SACC中国系统架构师大会也分享过一个理念，所有的架构的目标，都是：降本、增效、创新。

业务身份的理念，也是其中一环，我们看一下业务身份能提供哪些价值：

扩展性维度

有了业务身份，开发人员实际上不会改变核心交易流程，只是在开发各种“策略”实现。

核心的处理流程，以及执行流程的引擎可以交由专业的团队去维护，保障开发质量。

同时带来的好处就是，非常易于扩展。

平台既可以提供通用的共性服务，又提供了扩展机制，根据业务身份去识别扩展，有效支持一些个性化需求。

部署维度

有了业务身份，就以按照业务维度分集群部署。

如果中台的一个服务，支撑了多个业务场景，当某个场景的业务有新需求或者故障解决等原因，要进行升级部署时，就不可避免的将所有机器都分批进行升级部署。

每一次升级发布，都是一次变更行为，只要有变更就可能会产生新的故障，影响其它的场景。

有了业务身份，就可以根据业务身份做前置路由，将不同的业务身份分配到不同的集群，并按集群去分别部署业务。从物理的隔离，在满足一些业务快速迭代发布的诉求下，还能保障业务的稳定性。

监控维度

有了业务身份后，可以按全局或者业务维度，构建全局调用链路监控大盘。

没有业务身份的监控纯粹的是技术监控，只能去从整体去监控交易量趋势。有些业务，特别是一些新小业务，其早期交易量非常小。即使因为故障交易跌零了，从交易大盘上也无法即使监控到，只有等到客户投诉了才发现有故障发生。

同时可以根据业务身份，做好“业务开关”，而不是简单粗暴的将服务的所有客户全部关闭。

业务稳定性维度

在没有业务身份的识别下，在做性能优化、大促保障时，是没法按业务维度用不同的QoS策略进行差异化的大促保障。比如，无法按照业务维度进行流量分配进行限流、无法按照业务维度建立性能基线并进行性能劣化监控等。有了业务身份，就可以能按照业务进行场景化监控。

例如：

可以按业务维度建立各业务在各个调用场景下的性能基线，如RT、QPS等，一旦某次发布和预设基线有重大差异，就能快速找到性能劣化的业务并进行改进。

可以按业务维度建立外部服务调用的强弱依赖关系，结合强弱依赖关系可制定全局以及业务维度的各种预案开关。

可以看到，业务身份的这个理念，其实已经隐式的体现在日常的架构设计等工作过程中了。

我们现在要显示的提取出来这个概念，是一个非常大的进步。

接下来，我们再看一下业界，或者互联网上资源能看到的应用场景实例。

2

业务身份进一步理解

单维要素：业务身份的定义，系统唯一标识一个业务或者一个场景的标志，可以用枚举或者字符串表示。

最简单的方式，也是平台发展的初期方式，例如：对于业务中台的用户中心来说，要支撑PC端、APP端、微信端等各种渠道登录类型，都可以对应一个业务身份，最简单的可以用“pcLogIn”,”appLogIn”,”wechatLogIn”等字符串来标志。

用一个字符串，来唯一标志一个维度的要素，是最简单的场景。

多维要素：

上面的例子实际上是用“渠道类型”来当做了“业务身份”。

如果业务更复杂一点怎么办？

例如，要根据不同的产品做不同的流程处理，那么需要增加“产品”维度。

如果渠道类型有系统直连API类型，那么可能还需要增加“商户”维度，因为有时候不同的商户使用服务的费率以及交互模式可能不一样。

说白了，就是需要保证业务身份在整个业务中台上必须是唯一的，有了业务身份业务中台就可以针对抽象这个业务流程和业务规则，并基于业务身份实现服务路由、业务监控、业务规则配置等等。

业务身份就类似SAAS系统中的租户的概念，不同的业务方在中台通过业务身份进行数据权限隔离，这样能保证各业务的运营只能看见自己业务部分的数据。

业务身份本质就是我们自定义的一个分隔业务的标准协议，在不同的企业可以选取不同过的业务维度决定业务身份，提供了一个全链路的唯一标志。

例如一个业务身份，战略客户A通过API渠道系统直连方式购买了产品p，可以用“URL”方式来标志“a.api.p”。

当然，如果使用类的话，可以使用枚举的方式。

而更好的一种方式，是将业务身份属性字段入库参数化管理。

另外一个问题是，这些业务身份的参数字段，一定是预先配置好策略的，那就意味着，我们可以通过请求服务，将所有的这些要素都获取到。

或者说，我们可以通过api中的请求参数拿到所有的这些多维度要素值。

与配置参数的区别

笔者另外一篇文章，曾经介绍过参数的类型。

其中对于一些控制业务流程或者策略的参数，以往都是分散在各个应用代码中。

现在要把影响业务流转的核心配置(流程控制参数))统一提取出来，并按照业务身份作为主键进行配置，确保整个交易流程链路的标准统一，减少对交易核心链路代码的频繁修改，不同业务根据不同的属性值在相同的交易流程中的不同节点进行灵活切换。

例如：不同场景产品的客群的优惠利率、是否需要发送通知等，所有配置项均通过配置管理后台进行统一维护。

3

开源框架实例分析

Eclipse平台的“业务身份”

eclipse是几乎所有开发人员都知道的一种可扩展式开发平台，可以支持开发各种类型的项目，例如按语言维度区分的python项目、Java项目等，按照jar管理方式的maven项目等。

我们把这些不同类型的项目叫做场景，那么eclipse是如何保证在后续的项目开发过程中，python项目执行的是python流程而不是java流程呢？

换句话说，eclipse是如何识别不同场景的“业务身份”的？

eclipse的项目创建后，只有一个文件.project, 这个文件时eclipse项目的元数据，打开这个文件：

<?xml version="1.0" encoding="UTF-8"?>
<projectDescription>
<name>Test</name>
<comment></comment>
<projects>
</projects>
<buildSpec>
</buildSpec>
<natures>
	<nature>org.eclipse.jdt.core.javanature</nature>
	<nature>org.eclipse.m2e.core.maven2Nature</nature>
</natures>
</projectDescription>

里面的 <nature>标签，就是制定了这个项目是java项目，同时是一个maven项目。

所以，natures就可以认为是eclipse平台的“业务身份”，用来识别是那种类型的项目。

COLA框架

定义了三个维度，来进行业务身份的定义。

业务（Business）：就是一个自负盈亏的财务主体，比如tmall、淘宝和零售通就是三个不同的业务。
用例（Use Case）：描述了用户和系统之间的互动，每个用例提供了一个或多个场景。比如，支付订单就是一个典型的用例。
场景（Scenario）：场景也被称为用例的实例（Instance），包括用例所有的可能情况（正常的和异常的）。比如对于“订单支付”这个用例，就有“可以使用花呗”，“支付宝余额不足”，“银行账户余额不足”等多个场景。

结合我们上文所说的，可以在下面定义出来一个业务身份维度集合。

4

从价值流模型看业务身份建模

业务身份的价值很大，关键就在于，如何对它进行建模。

不同的行业领域有不同的建模维度与方式，因为涉及到的行业不同，要素也千差万别，那么有没有一个统一的建模的思路与原则呢？

答案是肯定的。

从价值流看

一个产品的整个价值流，可以有如下几点：

客群（客户）
这个产品服务的客群，例如是企业级别的战略客户、供应链上的核心企业，还是一级供应商？
所以这个维度，并不一定只有一个要素。可能是（核心企业，融资客户，关联客户）这种类型的一个集合。
渠道
即对外提供服务的渠道，可以包含自营APP、微信小程序、公众号、外部平台，等等一切直接触客的地方。
服务方式
系统直连的API方式暴露服务，或者是H5页面嵌入到外部平台？
产品
这个维度包含的内容更多，按照cola的划分方法，可以有业务（垂直领域）、用例、场景。