架构中的“大象”

本文主要是介绍架构中的“大象”，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

西方有句谚语叫做：“an elephant in the room”。

用以指代那些显而易见又容易被忽视的东西。

这些东西是什么呢？

“an elephant”：我们可以解释为那些重要的，困难的或者棘手的。

这里我们要讨论的则是架构中的"大象"：业务价值。

通常我们做架构评估的时候，一般会对关联系统的性能，容错弹性，业务扩展性等进行论证，但很少会考虑各个系统的业务价值以及这些业务价值和前述架构特性之间的关系。

没有这些价值关联的理解，对于架构设计中的一些关键因素选择就会很难做决定。

交易系统容错

以向交易系统添加容错机制为例，通常需要花费大概几万到几十万不等。那么这笔钱到底值不值得花呢？

做这个决定的前，要先了解系统所承载的业务价值，如果是日亿级的交易量业务，那么上面所说的花费就显得微不足道，是否添加容错机制这个架构元素也就更容易做决策了。

这里举上述这个例子，并不是为了申述架构团队在做决策时容易忽略业务价值因素这个问题。相反，这个点的考虑也已成为了普遍会进行考量的关键点。这里所要重点指出的是，很多时候，架构团队并不能很好的明晰各个系统所承载的业务价值是什么？价值的量是多少？不同系统模块对业务表现的贡献？

保险公司系统微服务化

一个保险公司确定要将公司的单体服务拆分为产品线维度微服务（家庭险、个人险、车险等），但是它们对不同业务线对公司利润的贡献比例不甚清楚。那么这种情况下需要优先考虑哪些决策因素呢？可以肯定的是首先需要拆分出的一定不是价值最高的业务，因为第一次拆分必然会伴随着许多不定性的风险。前期非核心系统迁移的试错，经验积累必不可少。

一、核查架构价值流映射

首先要做的是针对架构中的每一个系统模块，构建其价值映射。也就是每个系统对应的业务价值映射。

企业通过业务系统来服务外部客户，客户在使用企业的服务时都会遵循特定的行为步骤。

以用户购买商品为例，用户通常会执行登录、查询商品、对比价格、下单、支付，查看订单、跟踪物流，商品签收，服务评价等一系列操作。用户每一个操作行为都对应于业务系统特定的服务模块。基于此，我们可以明晰每个业务系统模块对于服务用户这个商业行为的贡献价值，以及各个环节的失败影响。

二、考量系统异常的业务价值影响

我们评估一个业务系统模块的价值的时候，除了有明确的其承载的业务价值的标准，对于哪些无法明确考量的（如底层数据库，存储等）模块，我们可以从另外一个角度来估量：失败异常会造成的损失。

例如，在某个重大节日大促将要到来之前，研发排期里已经罗列很多业务功能 feature 迭代需求。此时，要如何将一个看似和业务无关的“数据库灾备、恢复演练”需求插入到日程里呢？

此时，只需要提出如下问题即可：假如节日大促时，数据库服务宕机了，会造成多大的损失？希望数据库服务能在多长时间内恢复？

在评估业务价值风险时可以通过如下两种方式：

1、自上而下，跟踪业务功能流程并识别支持每个流程节点的业务系统。

2、自下而上，检查各个业务系统，分析其失败所影响的业务功能。

风险考量另一个需要关注的点是：不同的失败异常所可能引发的影响不同。不同的业务系统所需要的系弹性是不同的。

例如，人门对开盘日宕机的股票交易系统和一时无法使用的内部报销系统的容忍系数是完全不同的。达成何种弹性界别完全一种业务决策

还有常见的“数据一致性”问题也是同样的道理，例如在对待分布式数据存储时，相对于可用性，架构师更倾向于追求数据一致性表现。但是就商业层面来看，以订票业务为例，重复订票反而是无伤大雅，人们更加不愿意看到的是无法订票这种情景。

就如我们经常会谈论到的CAP理论一样，CP ？还是 AP ？从来都是一个业务决策，而不是技术决策。

三、基于业务价值评非功能需求

在评估功能价值时，不应只关注单一的业务功能，还要考虑如系统质量、兼容性、稳定性等非功能性需求。

如果我们想要系统达到某些技术标准，那么我们就需要让非技术人员了解到，如果达不到这些标准将会失去什么样的业务价值。

评估非功能更性需求价值通常都比较困难，许多技术人员也常常会回避由此产生的争论。但是避而不谈则会产生比低价值技术投入更大的危害，同时也会在技术人员和非技术人员之间产生更大的合作障碍。

以业务价值的理解和组件灵活性需求决策为例，某个客户的支付处理组件是由特定的支付处理供应商提供服务的。现在客户想要将支付组件升级为可配置化，这样就能够更好的应对支付供应商的变化。要实现这个需要有两种方案可选，一是将和服务提供商的交互逻辑进行硬编码处理，二是将所有的交互逻辑可配置化。但是，交互逻辑可配置化处理必然会增加支付组件的复杂性及其它变更的成本，这也会是一个相当大的投入。然而，通常支付提供商变更的商务谈判交互会就会花费相当长的时间，这里或许根本不需要支付组件上的快速配置变更，反而，低成本的硬编码处理更加适合。

四、非功能性需求业务价值评估因组件而异

上述实例的阐述说明了在评估如系统弹性、灵活性等非功能性需求业务价值上不能单纯的采取“一刀切”的统一标准。

例如，实现一个交易系统的5个9的可用性是合理的，但是对于一个内部订餐系统则是完全没有必要。

对不同层级业务提供不同级别标准的服务系统是我们应当遵循的基本准则。

特定服务的宕机是否会立刻影响到用户体验及收入？能否承受数据库几个小时的宕机，恢复损失？等等。

关于分析系统支撑业务价值，另一个需要关注的情景是：单个组件支撑多个业务价值流及不同业务价值流所需的不同级别可靠性。简单来说就是公共服务组件问题，尤其在单体服务模式下更为明显。这也促成了人们对微服务模式的追捧，关注核心价值业务并提供高级别服务系统。

五、基于监控工具评估业务价值

监控是必要且必需的。

随着分布式大行其道，交互逻辑，交互流程日趋繁杂，监控更是我们能够把控服务健康状态的必要工具。

监控数据通常分为两类：1、技术性指标，这是术人员通常关注的；2、业务性指标，则是我们这里所需要讨论的，对评估业务价值非常有用的数据。

业务性监控数据，如交易数据走势，营收曲线，用户活跃度等等，往往成为日常经营决策基础，更加科学化的以数据驱动企业发展。

六、只进行必要的核心业务上云

随着云服务的日趋繁盛及成熟，很多企业都倾向将自有业务系统迁移至云上服务。迁移的过程通常会持续很长一段时间，在这段时间内，云上，云下服务通常会并行运行。在这个过程中，人们通常会犯的一个错误是将所有服务完全的照搬到云上，简单的理解为一个复制粘贴过程，这是非常不可取的。

上云应该是一个优化，提升的过程。我们前面论述过，核心价值的业务才是最值得关注的。另外，在历久的业务迭代过程中，存在着许多无用的，低价值的，甚至对业务优化形成干扰的功能。因此，上云之前应该对整个业务系统进行充分的分析，拆解，提优去糟，只将最核心，必要的的业务优化上云。相对于完全的照搬策略，这样反而更容易实施，roi更高。