1
如何理解生产决定分配
马克思所讲的生产要素的分配包括两层含义：
第一，
从分配过程
看，是指生产要素的分配方式，即资源配置方式；第二，从分配结果
看，
是指生产要素所有权的分配。
这两者共同决定了产品分配的关系，
第一个层次解释了具体的分配方式的决定因素，
第二个层次解释了分
配的性质的决定因素。
”
“生产决定分配，但生产又包括两个方面，即
生产要素的所有制结构和生产要素的配置方式，前者决定分配的性
质，说明要素所有者得到报酬的权利，后者决定分配的方式，说明要
素所有者得到报酬的权利所实现的程度。
”①对此，笔者认为，有几
点是需要提出来讨论的。
一、马克思的“生产要素分配”的含义究竟是什么？
崔向阳认为，
马克思所讲的生产要素分配的第一层含义是指
“生
产要素的分配方式，即资源配置方式”
。这里明显存在对马克思的误
解。
对于生产要素分配的含义以及生产要素分配对产品分配的决定作
用，马克思是这样论述的：
“消费资料的任何一种分配，都不过是生
产条件本身分配的结果。
而生产条件的分配，
则表现生产方式本身的
性质，例如，资本主义生产方式的基础就在于：物质的生产条件以资
本和地产的形式掌握在非劳动者的手中，
而人民大众则只有人身的生
产条件，即劳动力。既然生产的要素是这样分配的，那么自然而然地
就要产生消费资料的现在这样的分配。
”②这段论述再清楚不过地表

本篇中，我们来讨论一个重要概念：“灰度发布”，及其解决方案。
文章目录
基本概念
理论与现实的冲突与思考
怎么设计流量的分配
怎么控制灰度的粒度
实战解决方案
一、准备外部配置源，实现热配置
二、控制权交由业务方，实现粒度自由
总结

基本概念
“灰度发布”的基本含义如下：

灰度发布（又名金丝雀发布）是指在黑与白之间，能够平滑过渡的一种发布方式。在其上可以进行A/B  testing，即让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。
来自 百度百科

可以发现，“灰度发布”主要针对的是“产品特性”。那么什么叫产品特性呢？从我们技术的角度来看，大多数人可能理解为“功能接口”，就像这样：

对于用户（这里的用户不一定只是局限于使用产品的人，也可能是使用产品的其他产品或单位，泛指一切需要使用我们产品的角色），我们根据我们的业务需求，进行不同流量的转发。
比如可能一开始30%的请求流量打给新版功能，70%打给旧版功能。在用户反馈良好的情况下，慢慢提升新版功能的接入流量，直到彻底完成新旧更替。




理论与现实的冲突与思考
可能会有同学觉得，灰度发布不是很简单直接吗，有什么好冲突的？
冲突点主要来源以下几个方面：
怎么设计流量的分配
之前的例子中，说的是从30-70的流量比例开始，慢慢调大新系统的接入流量比例，直到彻底完成新旧更替。
如果一切都很符合理想，没有什么外部约束的话，最好的方式一定是从0-100的比例开始，慢慢调整到100-0，是最安全最有稳定性的。
但现实总是有外部约束，例如：


来自效率的约束
产品经理：这个新功能三天内必须完全上线！


来自成本的约束
谁负责慢慢调节流量？谁来监控？或者交给算法来做，谁来写这个算法？涉及到的成本会很多。


那么如何权衡效率、成本与稳定性呢，就需要我们有充分的运维经验了。而这方面其实与开发是分不开的，我们开发者对于代码和业务复杂性的评估，将是我们去为灰度发布keep balance的重要依据。


怎么控制灰度的粒度
在这里为我们提出两个问题：


“系统级”还是“接口级”？
在V1版本的产品和V2版本的产品之间，进行灰度是十分合理的。但有时候并非只是这么简单，例如：
V1和V2之间有A、B、C三个新功能接口的迭代。其中A功能比较简单，也不是核心功能，基本不太需要灰度就可以发布；而C功能是非常核心且复杂的重点功能，一旦出bug可能导致严重的线上问题，需要谨慎发布。
那么如果我们只针对V1和V2进行灰度，就会发现整个版本迭代的效率是以A、B、C三个功能中最慢的那个为准的。我们是否有可能针对A、B、C分别进行灰度呢？这样就可以迅速上线A这样比较简单的新功能，而对于复杂的C功能则延缓彻底上线的速度。
那这样的话，是不是就意味着我们需要V1，V2，V3，V4四个版本？其中V2、3、4分别对A、B、C进行灰度。这样未免成本太高了。
思考一下，应该如何去做？






“接口级”还是“代码级”？
如果刚才提到的C接口内部代码逻辑很复杂，但旧版本的C接口和新版本的C接口代码复用率很高。我们有必要开发出两种版本的C接口，然后再进行灰度吗？是不是可以只针对那一部分不一样的代码进行灰度呢？
如果想只针对一部分代码进行灰度，既然不再是针对接口了，那我们该如何把控流量呢？
停下来，再思考一下。在后面的解决方案中，我们再继续探讨。






实战解决方案
现在有了这样一个需求：
我们希望能够灵活地解决灰度问题，针对代码级的变更进行灰度发布。
与此同时，我们希望这种变更是可控的，是可以热配置的。例如现在某个功能的流量中，30%走的旧代码，70%走的新代码。我希望不需要通过手动重新修改并部署项目，就可以非常方便地将流量比例转为50-50，直到最后转为100-0。在这段流量比例的变更期间，都不需要我重新部署项目。
这将是一个非常灵活且低成本的灰度发布解决方案。应该如何去做呢？


一、准备外部配置源，实现热配置
为了让我们能够热配置我们的灰度，那么这种配置就一定不能硬编码在我们的程序中。而且最好能以可读性较高、且较易编写的方式放在我们的配置文件/配置平台中，
毕竟我们现在想针对“代码级”的新旧版本进行灰度配置，那么可以想象，当需要灰度的代码块很多的时候，这种配置也会很多。如果不能以较好的格式存储，就会非常杂乱而不易维护。
那么应该如何设计这种配置的数据格式呢？比如可以像这样：




serviceId 服务名
strategyType 灰度策略类型
percent 百分比
otherParam… 其他相关参数……




loginService
PERCENT
50



具体解释一下：


serviceId 服务名
唯一标识我们需要灰度的代码块。因为不同的服务可能需要不同的灰度策略（比如当A服务希望现在是70%灰度的时候，B服务希望目前只是30%的灰度），所以以服务id为唯一标识。


strategyType 灰度策略类型
在我们的示例中，只有PERCENT——按百分比进行灰度这种类型。但其实灰度策略可以有很多种，比如黑名单策略，白名单策略……


percent 百分比
显然，这个percent字段是为了PERCENT策略类型服务的。我们需要知道该服务想要的百分比值，才能为它提供百分比灰度策略服务。


otherParam… 其他相关参数……
这个与percent参数类似，只是可能是为其他的灰度策略服务的。例如如果采取一个白名单策略，也许我们就需要一个whitelist参数，看看有哪些用户可以纳入白名单。


那么这种数据结构，我们可以存在我们的数据库中，也可以写入我们的配置文件中，等等。
然后我们的程序则会通过访问这个配置，执行相应的灰度逻辑，来实现我们的灰度发布。
而通过我们人为修改这个配置数据，就可以实现灰度的热配置。


二、控制权交由业务方，实现粒度自由
既然要针对**“代码级“**进行灰度，也就是应该会设计有如下逻辑：
//判断接下来是走旧流程还是走新流程
boolean gray = isGray(this.serviceId);

//如果判断为false，走旧流程
if(gray == false){
	//doSomething...
}
//如果判断为true，走新流程
if(gray == true){
	//doSomething...
}

而isGray(this.serviceId)方法应当抽象出来，专门设计到一个模块中，允许所有业务方进行调用。
isGray(this.serviceId)要做些什么呢？

获取到调用方的serviceId（通过方法传参获取到了）
根据serviceId，到配置文件/平台中获取相关数据，包括strategyType，percent等等
根据strategyType，并配合其他参数，执行相应的灰度逻辑
返回true或false，告知业务方本次调用应当走入新旧哪个流程

也就是说，我们可以自设计一个通用灰度模块，在里面实现isGray方法。
而具体的调用，则交给业务方。
每个业务方是否想要灰度，想要走什么灰度策略，都完全可以由自己来控制。而具体的策略逻辑，则由我们的通用灰度模块来提供即可。


总结
在真正接触灰度发布的实践之前，我们对灰度的理解是浅薄片面的。
而到小型系统上，或许我们也只会考虑到使用nginx等工具，利用负载均衡功能来实现灰度。
其实灰度的”水“还是挺深的，希望这样一篇文章可以开阔你的视野，打通你的思维。